Matt, a reader who downloaded Ian Brown's early version of Information Cards for Safari, wrote to me with the following question:
I just signed up to your identity blog using the Safari CardSpace selector you mentioned on your blog.
I'm interested to know whether the (genuine) identity data in my CardSpace selector (populated out of my Address Book entry I think) is transmitted to you, if it is where it is stored, and what is done with it and to protect it.
Matt is unclear about what information he has sent to Identityblog because the Safari and Firefox user interfaces don't yet deal with displaying what subset of the information in a card is being asked for by the site he is visiting.
That's because the current versions are very much prototypes and works in progress. As Ian says on his blog:
This is currently still at the proof of concept stage, and is lacking most of the features found in the official CardSpace selector from Microsoft.
This being said, I have verified that the demo Firefox selector only releases required claims, and I'm pretty sure the Safari selector follows suit.
The current Cardspace interface design was refined through ongoing “usability work” in which we encountered this kind of confusion and explored (and measured the efficacy of) different alternatives for avoiding it.
As a result, when you release any new information to a site within Cardspace you see a screen like this one:
It doesn't matter whether a user has filled out other fields in their chosen Information Card. Only the fields asked for by the site will be presented for approval. Then the user can decide whether to proceed or not.
On subsequent visits to a site, the information release screen is not shown by default. The thinking is that once information has been released once, it forms part of the “contract” between the user and the site. If we were to ask the user to “approve” the release time after time, the release page would become nothing more than a “click through page” – meaning the user wouldn't even “see” it.
As for what I store, my approach is to ask for as little information as I can.
I request an email address so I can verify that you are not a spammer, and so you can change your infocard by using the email address as an “alternate authentication channel” (more on this in a future post). I'm working with some friends on a version where we won't store the actual email address – we will use a hash of it instead so we can recognize you but not expose your address to possible breaches.
I also store what you've given me as a first and last name because WordPress uses that to show who has written posts and comments. I will eventually change this so I only store your names once you have written a post or comment (i.e. done something ‘public’).
There needs to be an incentive for sites to minimise the “required” information (beyond “you can't log in here if you don't provide your first name, last name, e-mail address” — like this site).
The most recent version of the Safari selector (available here) will display and submit only the information required by the relying party. Additionally, if the relying party allows for optional claims to be submitted, the selector will display the optional information, and let the user choose to send ot not sned the optional information.
While it's still a far cry from the CardSpace selector's experience and functionality (multiple cards, managed cards, etc.), it is slouching towards a somewhat useful implementation.