I was recently browsing the home page of http://cardspace.netfx3.com/, and a post from the forum caught my eye.

The main argument is if the display token violates or not the first law, since the STS may decide to use different values in the display token and in the token itself; then there are a number of considerations about security that suggests we may not have done enough for explaining how things work. I am giving myself 30 mins for providing an alternative explanation and address the points mentioned in the forum post. Anyway, the bottom line is that the display token is actually what makes respecting the first law possible in the first place.

Why can’t the identity selector show claim values directly from the requested token?

There are two main reasons.

• As correctly mentioned, the token requested may be encrypted for the intended RP hence unreadable from the selector
• The token may be in a format that is not understood from the subject’s machine. CardSpace makes no assumptions about the token format, and leaves the matter in the hand of the RP and IP; the two can agree on a specific format by comparing their policies. This design keeps the door open for extensibility: if today you invent the coconut token (or the Durian oken, as I often say to my SIngapore colleagues & customers :)) you can go ahead and use it without changing anything in CardSpace’s installation. So, even if the token given back by the STS would be unencrypted it would still be unwise to expect the selector to be able to parse it since there are no assumptions about the format.

Without the display token, the selector would have no way to show to the user the values being handled without somehow weakening the requirements above.

What if the STS injects different values in the displaytoken and in the actual token?

The correct implementation of the standard (or guidelines, in the case of the displaytoken) cannot be enforced, it’s systemic and not just something that affects display tokens. What if the STS does not actually verify the credentials in the RST and just gives a token with your data to anyone who requests it using your name somewhere in the RTS? What if the RP does not check the signature of the incoming token, or does not honor the AudienceRestriction? And so on, and so forth.

What about confidentiality?

The DisplayToken needs to be readable from the subject’s machine, but doesn’t mean that it travels naked. It is part of the RSTR, and as such it is secured; despite the fact that it’s a token it travels in the body, rather than in the WS-Security header, exactly like the requested token (since this is actually argument of the function performed rather than an infrastructure artifact).

Below one of my signature schemas, which will hopefully clarify (I think that the line artist at AW wants to strangle me, given all the intricate schema he had to turn from my scrappy sketches into intelligible figures for the book).

Note that here I am showing a possible binding; there are many other possibilities, like transport based security or session keys. This one is for spelling out as clearly as possible who can see what.

The RST is encrypted for the STS (yellow key) and signed with a smartcard key (green key) for authenticating the requestor.

The RSTR is encrypted AS A MESSAGE with the public key corresponding to the smartcard certificate used for securing the RST; this encryption will last just the time to deliver the message to its destination. Cozy cozy, the display token travels in a body element protected by this encryption as well. The requested token itself contains a signature form the STS (yellow key) and it is encrypted for the intended RP (azure key); signature and encryption are going to stay with the token in all the future messages that will use the token itself.

Note that, regardless all cryptographic considerations, STS and RP have the necessary manager classes for understanding the token format while the selector does not.

Ok, took 35 mins. Not too bad 🙂