Identity Crisis

A couple weeks ago, I spent a couple of days learning about login/identity. Didn’t come around to blog it until today.

Revisits of Microsoft Passport
Although Microsoft almost declares Passport Network a defeat, I think it can be made useful with a few twists. I feel that what it requires most is actually not technical related. First, it should improve its transparence to user on how its work. It should require user explicit consent to allow third party site to identify a user id, and allows easy modification of the allow list. It should not assume user has only one identity. It should also get rid of the centralized data store in msn sites.

Otherwise, the login delegation mechanism and the ability to use the same login for multiple sites are worthwhile to keep, at least until something else come along.
The login delegation works like this:
1/ User visits a site that supports login delegation. (let’s call it the action site for now)
2/ The site forward user to the login site (such as Passport)
3/ The login site shows login page to request user for password (if not yet log in)
4/ The login site forward user back to the action site with some information that identify the user as successfully logged in.

If a user already logged to Passport network previously with the same browser, and visits an action site (that supports Passport) site, the site can request Passport network to identify him by forward it to the login site.

User might expect to browse the site anonymously but was being identified. The problem can be fixed by letting user to identify what site should identity him and what site shouldn’t. If user is being forwarded by an action site the first time, user should be shown an agreement and warning. User should be let to choose between “Always Allow”, “Allow for this session only”, “Disallow”. If user chooses Disallow, every time the action site requests the user to be identified, the login site should always forward back as if no user is login to that computer. User should able to modify his/her choice later by going to the login site directly.

It should not assume user to have only one identity. The problem can also be helped with the above modification. When user logged into works, an action site shouldn’t able to identify his work id without his consent. When the same user logged into his hotmail account, if the user approves, the action site might identify him.

New to InfoCard
Microsoft takes InfoCard as the next steps of Passport Network.

Folks in the group identified a few critical rules for identity and authentication in general: The LAWS OF IDENTITY. While all seven of them are totally critical, I don’t think they are covering everything.

The omission was portability (or should I say accessibility). Without total portability, users are bounded to two choices. First, not accessing the feature they want where they need it (for example, don’t check email in a public computer, don’t use cell phone to check WAP mail), or use a different mechanism when another feature is supported. The first choice is painful. The second choice… the strength of a chain is its weakest link. Either way, it doesn’t solve the original problem. It either restricts access, or leave user alone when he needs the security most.

It is a chicken and egg problem. The portability limits the adoption. And, the adoption limits new devices to support the mechanism, which eventually limits portability.

The omission is leaking from the laws to InfoCard, and I think it is fatal.

Tag: ,