The evolution of OpenID: you’re not a URL after all

The US government has just announced a pilot program to integrate OpenID (and Information Cards) into public government web sites. This is very interesting news, as it will likely catalyze even greater OpenID deployment and use.

[I’ve poo-poo’ed OpenID here and here, because of phishing and privacy concerns. I’m still very worried. I’ve suggested ways to defend OpenID against phishing, and I helped Creative Commons deploy a privacy-conscious OpenID service.]

What’s fascinating to me is the evolution of OpenID. The pitch used to be “log in with your URL.” The backend protocol was cool, but it didn’t really matter. Authentication was reduced to proving that you own a particular URL: I can prove that I control http://ben.adida.net, thus, for all intents and purposes, that URL is my identity. I *am* http://ben.adida.net. *How* I prove that I own that URL, that’s a good thing to define precisely, but it wasn’t central to the OpenID story.

A lot of folks, myself included, think URLs as human identifiers are not ideal. People aren’t used to them. They don’t provide a communication channel. It is awkward to type a URL into what is effectively a “username” box. Plus, if you give every site your URL, then multiple sites can correlate identities easily, and that’s probably not a good thing when all you really want is single sign-on.

So OpenID evolved. In version 2.0, instead of typing your full OpenID URL, you can just type the domain name of your provider, i.e. yahoo.com. Then, you get redirected to Yahoo, where you log in, and when you’re done, Yahoo provides a pseudonymous identifier to the third-party web site where you want to log in. And as it turns out, that’s exactly the mode of authentication that the government is requiring for its approved OpenID providers, because they don’t want the NIH and CDC to have the ability to correlate your activities across government services. (In passing… how refreshing to see this privacy concern come out of the US government!). So the NIH thinks you’re 83nbxcvndfs34@google.com and the CDC thinks you’re j23nsnsblkjsdfl45@google.com.

My guess is that URLs as human identifiers are effectively dead. OpenID is now the backend protocol. Identifiers are pseudonyms, not public URLs.

I also suspect the next step is a communication channel for these pseudonyms: identity providers will give relying parties a way to send messages to the pseudonyms that logged into their sites, the same way Facebook lets apps notify its users. Something missing in your NIH grant application? The NIH will make an API call to Google saying “please deliver this note to user 83nbxcvndfs34” and Google will forward it appropriately. (Maybe this feature already exists in OpenID 2.0 and I just don’t know about it?)

On the phishing front, OpenID providers will probably duke it out with various mitigating solutions. It would be nice if the OpenID standard tackled the issue, though.

On the privacy front, only the core OpenID protocol can help. I’d like to use my Google credentials to log in everywhere, but I don’t see why Google needs to look over my shoulder every time I log in to every weird site I visit. The only way to fix this is with cryptographic credentials. I don’t see that anywhere in the OpenID spec’s future, but without it, there are going to be deep privacy issues.

In the end, OpenID 2009 looks almost nothing like OpenID 2006. That’s okay, though. One lesson is that, in the end, the OpenID effort inspired and coalesced a number of disparate efforts to achieve an open-standard for web-based single sign-on. Though the solution has evolved significantly, OpenID has succeeded: we have an open web-based single sign-on system. Now, OpenID will have to deal with the consequences of its success. It will get attacked, a lot. Its issues with phishing and privacy will become greater concerns. It should be a fun ride.