First, apologies to Kim Cameron for taking a while to get to posting this. Being at a conference in Montreal, I was distracted from in-depth blog entries. Go figure. Anyway, in a back and forth on to develop a short explanation of Infocard, we are at:
The relying party states what assertions it wants, the Identity Selector allows the user to control what identity provider to use, and the identity provider packages up the identity assertions, signs them and sends them to the relying party in a token format. The identity authority can be something local to the identity selector, or something reachable over the internet, and the token format can be XML, including SAML, or anything else. The whole visual metaphor and user experience is called InfoCard, the protocols are WS-Trust, and the mesh of interoperating parties and technologies are the Identity Metasystem.
I think that’s a usefully short description.
While it may well be an accurate description of the protocol, I have a problem with the technological determinism of the first clause, “the relying party states what assertions it wants.” From there, things proceed apace, with the assumption that I want to provide statements of equal truthfulness in response to each demand. (Are there optional requests?) For example, as anyone who looked closely at my TSA FOIA response might have noted, there’s an interesting phone number listed, because I don’t want the airline to call me. They’ve certainly never called for anything useful, like to tell me my flight was cancelled. I generally provide a customized email address at one of my many domains for each
spam provider entity I do business with. Which is to say, I would prefer not to share the same information around.
Now, the advice is to ask only for things you need:
Many Web services don’t need any personally identifiable information at all, and you shouldn’t ask for anything you don’t absolutely need. With InfoCard, a great way to start is by simply identifying the user with a Private Personal Identifier (PPID). This is communicated as a base64-encoded byte array. (“Step-by-Step Guide To Infocard,” MSDN Magazine)
I expect the definition of ‘abosolute’ to become ‘might,’ as in “you should ask for anything you might need.” I would prefer not to see this happen.
So, if, for example, my credit card provider wants to be a identity authority, and certify a billing number and a mailing address, can I then take that signed assertion, add a set of bits that the RP wants, but I prefer not to provide in a certified way, and send it off?
Is this control in line with the “7 Laws of Identity?” I think it is not. In the case of a disagreement about what is “required,” it feels like the first law, “User Control and Consent,” is not being obeyed. I would prefer more control.