Consent, Control, and Minimal Disclosure

Last Saturday I posted some screen shots showing some help text included in the Microsoft Cardspace client that indicate that what is displayed (display tokens) is not necessarily what is transmitted to a web site, and further that there are no guarantees that Cardspace has no control over what the web site does with the information once submitted.

Interestingly, Kim wrote a response to a thread on a similar topic on an exchange between Citi's Francis Shanahan, Microsoft's Vittorio Bertocci, and University of Wisconsin's Eric Norman. This exchange talks about Cardspace and whether or not it violates Kim's Law of Identity #1 - User Control and Consent - "Technical identity systems must only reveal information identifying a user with the user's consent."

Aside: If you haven't already read Kim's 7 Laws of Identity, I recommend reading them. My opinion is that they set an excellent starting point for minimum requirements - though I believe many other observations will be made in the future (e.g. Madsen's Lemma of Dubious Attributes).

While I agree with Kim that some level of compromise is needed to make the identity meta-system work, I also think this thread indicates there is more work to do.

With regards to the issue of concealed or coded information which is not displayed in the display token, one of the justifications I can think of for coded information are reference pointers. These pointers might be there because of Law#2 - minimal disclosure.

For example, when going to a book merchant web site I would normally provide my shipping address so that I can receive my order. However, if I had an existing relationship with a courier firm, then that firm could act as a managed card provider with the web merchant. When ordering a book, I could elect to use my courier's managed card which would include a shipping reference token. The web merchant would use that token to mark my package and notify the courier. When the courier picks up the package, the courier is able to translate the shipping reference token into my confidential mailing address. This allows me to avoid giving my shipping address to the web merchant.

What we have here is a case of Law #2, minimal disclosure causing conflict with Law#1. The shipping reference isn't meaningful to me, but it does work on my behalf. It allows me to avoid giving out my address.

There are of course many other cases where the encoded information is not in the user's best interests. And so, the Cardspace client should be able to test a token from a managed card provider to see if the display text matches the encoded text.

While we can’t then prevent evil, we can detect and punish it. The claims in the token are cryptographically bound to the claims in the display token. The binding is auditable.

In this case though, the audit should be done by the Cardspace in order to verify the token. This would allow Cardspace to warn the user of encoded data or additional data not originally requested.

I also agree strongly that Identity Providers need to be trusted. This is why the Liberty Alliance has begun work on the Identity Governance Framework and the Identity Assurance Framework. BTW. Both IGF and IAF are intended to work in a multi-protocol environment, including WS-Trust (Law#5 - Pluralism of Operators and Technologies). ;-)