On DisplayToken

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 🙂

Comments (4)

  1. ejnorman says:

    VIttorio, you have two bullets above about "why can’t".

    The first in invalid.  Just because information is encrypted for the RP does not mean that the same information (bunch of bits) can’t be decrypted and read by an identity selector that is relaying it.  There are many cryptographic methods for doing this (with both symmetric and asymmetric keys) and they are well known.  For example, the identity selector could generate and distribute a symmetric encryption key.  The way PKCS7 does it is another example.

    Well, the second bullet is a lot more valid.  However, the question about violation of law 1 still hasn’t been addressed.  The question is: why shouldn’t a user be able to inspect what’s being said about him and sent to a relying party to verify that it’s what was expected?

  2. Hello Eric.

    I didn’t mean that it is phisically impossible to do it, but that as it is implemented today it isn’t.

    I’m not very deep on the "human rights" side of identity system, so I may be naive here and there; and I am also oriented at heuristics rather than in finding the exact sound & complete algebra that models a problem space and demonstrate theorems against it. That said,I am not sure I see why the displaytoken is such a bad solution.

    – One of the big advantages that I’ve always appreciated of the new system is the increased confidence that the RP can have in the value of the data received in form of tokens.

    If the token is encrypted for the RP directly at the source (that is, the STS), the RP is reasonably sure that the data inside it are safe regardless of the fact that the subject machine may be compromised. As of today, the selector shows the values in the displaytoken but those values never leave the selector itself, while the actual token is returned to the application that elicited the token issuance in the first place (ie the browser or a rich client). If the token itself would be readable by a process in the subject machine, then the RP confidence would be greatly diminished. True, "user centered identity management" should put user’s needs first: but a thriving ecosystem is in the interest of everybody.

    That said: what happens if somebody writes a rogue identity selector and tries to leverage the displaytoken? Well, using a displaytoken gives some chance of mitigating the attack: for example, I may have an SSN or credit card claim which shows just the last 4 digits in the display token, so that a user that onws the corresponding info can verify and exercise control. If the token would be directly readable by the selector, this last resort would be negated (and that would be bad for both the user and the RP).

    – There are already many things that the subject *cannot* verify firsthand in how the STS operates, and just have to trust it to do the right thing. It seems weird to me that I wouldn’t trust the STS to give me a correct DisplayToken while I still trust it to follow the standards or actually verify my credentials in the right way (as opposed to being sloppy and not checking the signature of the RST, for example)

    In summary: IMHO the display token is a good mechanism for enabling user control & consent, since again IMHO trusting the IP to produce a correct display token is reasonable since the subject already trusts the IP to do even more fundamental things. I also think that allowing the selector to directly peek into the token would deprive the RP from some of the assurances it can count on today, with adverse effects on high value scenarios.

    Now, the problem could probably be posed in term of a continuum, that is: is the display token good ENOUGH? I actually like the idea of degrees of user & consent, like we have degrees of security (somebody said it’s a ladder).

    I am sure that there can be ways in which the above issues can be overcome while still being cryptographically air tight, but I would guess that the price to pay in term of complexity would be pretty high. And the complexity is enemy of adoption and robustness. So, considered all the above IMHO the display token is good enough. Maybe, once it will be of common usage and the users will be more aware of their identities, I won’t find this good enough anymore: but for the time being, considering that there are users revealing their IM username and passwords to social networking websites just for crawling thier contact automatically, I think that the display token is a quantum leap in control and awareness 🙂

  3. Francis says:

    Hi Vittorio, thanks for the response. I’ve written up my thoughts on the matter here:


    warm regards,


  4. Vibro.NET says:

    On the Paris-Seattle flight, coming back after 2 weeks spent stuffing myself with all sorts of food with

Skip to main content