Display Tokens for Information Cards

In a recent talk on CardSpace, one of my students asked a question about managed cards. One of the premises of Information Cards are the seven laws, and the first law implies that the user should be able to see the information being disclosed about her identity. This needs to hold true even when the security token is being issued by a third party, which is the case in managed card scenarios.

This question comes up a lot: "Because the claims in the security token may be encrypted so that only the RP can read them, how can the subject's identity selector (CardSpace, for example) show the values of these claims to the user?"

The way we get around this is through something called a "Display Token". The idea is that the security token is ultimately a communication between the identity provider (IdP) and the relying party (RP). Indeed the subject's identity selector may not even understand the token format given that Information Cards can use a variety of token formats to communicate claims. So the display token is specifically crafted for the IdP to show the subject what claims are being sent.

The obvious follow up question is, "How can we be certain that the claims in the display token accurately reflect what's in the security token?" The identity selector has no way of validating this. The subject must ultimately trust her IdP not to lie to her, just as she must trust the IdP not to allow other users to impersonate her. This is a big reason why the fifth law exists. There are multiple identity providers, and you should choose one that you trust given the context in which you want to use it.

For those who want to know more about how display tokens work, Vittorio's recent post has some great pictures and further details.