I wrote an entry on Tuesday about CardSpace as a Password Manager. Kim responded with a request: “I’d like to hear Pat’s ideas about the user experience of bootstrapping the passwords into the Identity Provider.”.
Well, I see this happening at the relying party (RP) – if you already had an account there you would go to some ‘change password’ page containing the information card ‘script’ to invoke the identity selector and proceed as I detailed in the earlier post. When the identity provider (IP/STS) receives this initial request, it will see that it has no password for that RP/user, create (and record) a new one and send it to the RP, which will write it into the user’s entry exactly as if the user had just typed it in.
If you didn’t have an account, the relying party would do the information card thing as part of the signup, as an alternative to just prompting you for a password. In both cases, the relying party could display the password on screen (probably requiring a mouse click to ‘unmask’ it) so the user could independently make a note if she really wanted to.
In all three cases, signup, login and change password, it’s the same code from the RP point of view – just a way of getting a password from the user. And, in both cases, the password could be nice and strong, since the user doesn’t really need to remember it. One other detail is that the RP would need to communicate its password policy (e.g. 5-12 characters, alphanumeric plus !, @, #, $, %) to the IP/STS; sp:RequestSecurityTokenTemplate looks like it could carry that in its optional wsp:Policy element.
Going further, Gerry posted this morning on how the identity provider could even provide a series of strong, one time use, passwords, providing additional security, albeit with some incremental complexity at the RP.
I don’t get it.
In this scheme, all three of IdP, identity selector, and RP need to speak the information card protocols. If they do that, then why not just use the regular information card stuff?
Is there something missing in the information card protocols whereby these password tokens would add value? If so, what is it?
This looks to me like it’s just adding more code and complexity without adding any value.
That’s a good question – where is the benefit here, and to whom? Well, the benefit for the RP over the regular information card model is that the RP does not have to correlate Information Card Private Personal Identifiers (PPID’s) with user accounts. At the cost of adding some minimal code to the login process (parsing username/password from a posted information card token, rather than from the usual form fields), the RP enables CardSpace login. The RP doesn’t need to add a PPID column to its user table and doesn’t need a strategy for linking incoming PPIDs with existing accounts. If the RP is running some off-the-shelf web application, with no access to its underlying user management model, this could be very useful, indeed.
For the user, this allows them to use strong passwords with a huge potential population of web sites, all based on a single authentication to their identity provider, this authentication via an identity selector such as Windows CardSpace, rather than a web page in a browser.
For the identity provider, this is a value-added service that it could either charge for, or (more likely) provide free-of-charge as a competitive differentiator.