Jumping on the DisplayToken Bandwagon

Vittorio defends Cardspace against the criticism that the DisplayToken mechanism, as it does not distinguish as to whether the displayed list of attributes is different than the actually transferred attributes, violates a law.

DisplayToken is presented as a sort of kludge, necessary because of the nature and protections of the actual identity token. Vittorio writes

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.

These are legitimate reasons - driven by security and complexity (as explored here by Mark Wahl). But of course there is an implicit 'as we have designed Cardspace' in both of them.

Cardspace could have been designed such that:

1. the token itself was not opaque to the client, or
   
2. even if opaque, it was made clear that the display token is the IdP's claim as to the attributes being transferred, and not the client's examination of which attributes are sent.

In the first case, the client could directly look into the token and report back to the user what it saw. This of course opens up MITM etc



In the second case, at least the user would have a better idea of the reality of the situation. For instance, at the part of the Cardspace ceremony at which the DisplayToken is shown (see graphic, probably out of date) the user could be forgiven for being uncertain about whether it is Cardspace or the IdP (or their Mother for all most will know) informing them of the attributes being transferred.

Cardspace is a smart identity client that performs a variety of steps to facilitate identity operations for the user. As such Cardspace will set users' expectations as to 'identity operation facilitation' quite high. When Cardspace is doing little more than a dumb browser would (as in rendering the Display Token), I suggest that that should be made clear.

I fully agree with some of the commenters that if the IdP has gone 'bad', then there are untold more damaging ways it can hurt the user than by inserting unrequested attributes or arbitrarily replacing them in the token - the Display Token issue is not the worst of your problems. But, there needn't be a malicious IdP for there to be the possibility of divergence between the actual and the displayed attributes.

Tags: Cardspace Display Token