Simon Willison’s Weblog

An OpenID is not an account!

10th January 2007

I’m excited to see that OpenID has finally started to gain serious traction outside of the Identity community. Understandably, misconceptions about OpenID continue to crop-up. The one I want to address in this entry is the idea that an OpenID can be used as a replacement for a regular user account.

Update at 23:55pm: I originally tried to illustrate this misconception with a quote from Don Park; unfortunately I misunderstood the quote and consequently misrepresented his position, for which I apologise unreservedly.

The old OpenID homepage (which I miss; the new one uses jargon-heavy terms like “a free framework for user-centric digital identity”) included this in nice big letters:

What about trust?

This is not a trust system. Trust requires identity first.

OpenID solves the identity problem, not the trust problem. When a user authenticates with OpenID, what they are doing is stating “I have the ability to prove my ownership of this URL”.

I used the phrase “have the ability” deliberately. Just because the OpenID authentication was successful doesn’t mean that the user is the only person who can authenticate against that OpenID. It would be trivial to create the OpenID equivalent of Mailinator: an identity provider that says “Yes, that’s them!” to any identity request. I’m tempted to build it just to emphasize this point! Update: Jayant Gandhi has built one.

The key thing here is that you should never trust an OpenID on its own. It could be a real person, or it could be a spammer, psycopath or general undesirable.

Does this mean OpenID is completely useless? Absolutely not! You just have to think of it in the same way that you think of username and password combinations: as the “key” to an account.

Most web application signup processes work something like this:

1. Bob selects a username
2. Bob enters a password, twice
3. Bob enters his e-mail address
4. Bob clicks a validation link in an e-mail sent to that address

Some sites throw a CAPTCHA in there for good measure.

OpenID replaces at most the first two steps of that registration process. Instead of having a user set up a new password you get them to authenticate with their OpenID at the start of the process. After that you might still want them to pick a username (especially if you are integrating OpenID in to an existing account system) and you’ll almost certainly want them to jump through the e-mail and/or CAPTCHA steps.

In the future, they can sign in to your site using their OpenID rather than having to dig around for whichever username and password they used.

A nice thing about the above flow is that it demonstrates how easy it should be to add OpenID support to an existing Web application. If you’ve already got a user account system that’s fine—just give your users a mechanism to associate an OpenID with their existing account so they can log in without using their password. You could even require new users to set up a full account (complete with password that they never intend to use) and then associate it with their OpenID, although doing so eliminates the lower barrier to entry advantage for OpenID users.

The trust issue is now null and void. An OpenID is just as trustworthy as a regular username and password (which could have been posted to bugmenot and shared with thousands of people).

One last time: an OpenID is not an account. Just treat it as an alternative to a traditional username and password and you can’t go wrong.