I recently attended the Internet Identity Workshop 10 (IIWX) at the Computer History Museum in Mountain View to learn about the direction of OpenID. I spent many hours this semester researching and writing a paper for school about social factors limiting the diffusion of OpenID. Between the time that I came up with the idea for the paper and I turned it in, the OpenID and surrounding community has become involved a series of fascinating conversations that seem, to me, to be the future of the Internet playing out in a day-to-day drama.
OpenID has had only limited success. There are many reasons – security, usability, trust issues, and legal issues are some of the obvious ones. There are also competitive standards. Sites like Twitter and LinkedIn allow you to authenticate via OAuth. But wait, I though OAuth was for authorization, not authentication? OpenID and OAuth both support authentication and authorization in some form. And the two standards seemed to be in a steel cage match. Enter Facebook. Facebook had a platform for single-sign on and sharing across the web called Facebook Connect. It was, for the most part, a closed and proprietary standard that didn’t acknowledge the existence of OpenID and OAuth and the other elements of the OpenStack.
In 2009, Facebook joined the OpenID Foundation and became an OpenID Relying Party (RP) by accepting OpenID accounts. This was in contrast to other large companies like Microsoft, Google, and Yahoo, who are only OpenID Providers (OP) and don’t allow you to log in to their services with another identity. Essentially, Facebook said, “fine, you can log in to Facebook with your OpenID. But we want to make sure you log in to other sites with Facebook Connect, not OpenID.” Facebook has taken a lot of flak for privacy debacles – from Beacon to their dynamic privacy policies. Some suggested that Facebook Connect was an attempt to make Facebook the identity layer for the web. Since you are always logged into Facebook (right?), sites could access your social graph (not to mention verify your geographic location and age) through the information shared from your profile via Facebook Connect.
Facebook recently revealed that they were killing the proprietary Facebook Connect stack and replacing it with OAuth 2.0. OAuth 2.0 is a re-imagining of the OAuth protocol that promises to make life simple by eliminating the need to perform cryptography on the client with Bearer Tokens and requiring SSL to improve security.
So now, if you want to allow users to log in to your site with their Facebook or Twitter accounts, you had to support OAuth, not OpenID. And guess what, site owners? There’s good news. The OAuth protocol gives you a token that lets you get all sorts of fun data about users. So why would you even need OpenID?At the recent Facebook f8 conference, several influential members of the Identity community hosted a panel discussing the OAuth 2.0 changes. When asked about OpenID, a Facebook engineer replied: “Developers aren’t asking for OpenID. OpenID [is] a layer of complexity nobody is asking for.” This was followed by an informal poll showing an overall lack of enthusiasm for the OpenID technology.
So wait, OpenID is done for? That’s what I wanted to figure out at this conference. A few days earlier, David Recordon dropped the Open ID Connect strawman proposal, which was discussed further at several IIW sessions. Generally, OpenID Connect builds on top of OAuth 2.0 and includes plenty of inspiration from earlier OpenID/OAuth hybrids. The idea is to move the OpenID itself to a single “scope” of an OAuth flow. The move to OAuth 2.0 forces everyone to use SSL, which happens to break OpenID 2.0.
Even if it breaks backwards compatibility, I think OpenID Connect would encourage OpenID adoption. It simplifies OpenID, which is a critical hurdle, and provides default security in the form of SSL. It also gives sites the carrot of an OAuth token and potentially rich social information about its users. This is what concerns me about tightly integrating OpenID and OAuth. I think it will encourage services to only accept third-party logins from sites that have lots of social information about users, as opposed to allowing arbitrary OpenID URLs.
If Facebook, Google, and Twitter are on board, full steam ahead, right? But OpenID Connect is just a strawman proposal. There’s an entirely different OpenID charter called v.Next. The two proposals share a lot of the same goals, and seem to involve a lot of the same people. But, in the meetings at IIW, you could sense a tension between the two sides. OpenID Connect is about, at its core, simplicity. The decision to build OpenID Connect on top of OAuth 2.0 is a fait accompli. v.Next wants to support Public Key Infrastructure, it wants to provide NIST Levels of Assurance, it wants to support existing OpenID infrastructure like Attribute Exchange. OAuth 2.0 compatibility is a nice to have. The two sides seem to have fundamentally different visions for the technology. From the OpenID Connect proposal:
Q: Haven’t there been OpenID Foundation Working Group proposals for OpenID v.Next?
A: Yes, there have been proposals for working groups on discovery and attributes over the past month (and talk about doing so for almost a year). Combined they have over a dozen new features and there hasn’t even been a proposal for the core OpenID Authentication spec yet. OpenID needs to be driven by simplicity and elegance, not by support for over a dozen new features.
So who will win out? My hope is that the next OpenID standard will be a compromise between the two parties. There are several tradeoffs here: simplicity versus extensibility, privacy versus usability, security versus complexity, and so on. I’m worried that the v.Next vision to support everyone doing everything sounds a lot like the WS-*debacle, where there seem to be more specs than there are implementations. On the other hand social behemoths Google, Twtter, and Facebook are prominently involved in the OpenID Connect specification that encourages social sharing and may (just may) disempower users who find themselves forced to share potentially embarrassing information in order to register for sites. Hopefully a fine line can be drawn to protect users interest and support a wide set of use cases, while keeping OpenID simple enough to encourage people to use it.
Irony footnote: Yes, I don’t have OpenID enabled for comments on the blog. Yet.
