OpenID Connect

When last we looked in on OpenID, it was close to finalizing the OpenID 2.0 specification. That was in 2007; since that time, various other identity management solutions have come about and have been more widely adopted, OAuth in particular. One of the architects of OpenID, David Recordon, has put out a idea (or "strawman" as he calls it) for a new API that combines the best of OpenID and OAuth into "OpenID Connect".

There are a number of shortcomings of OpenID that Recordon and others would like to see addressed. In the three years since the last revision, the internet has not stood still, but OpenID has. OpenID works reasonably well for web sites, but is much more difficult to use for things like desktop widgets or mobile applications. A bigger problem is that OpenID's user-centric nature has made those users less "valuable" to web sites, which results in fewer sites adopting OpenID.

OpenID is structured such that users need only share a limited amount of data (typically just a URL) with a site in order to register with it. That is good from a privacy perspective, but doesn't give site owners information that they want, like name, email address, photo, and so on. According to Chris Messina—who originated the OpenID Connect concept and name—that makes OpenID users into second-class citizens: "Because OpenID users share less information with third parties, they are perceived as being 'less valuable' than email-based registrants or users that connect to their Facebook or Twitter accounts."

More and more sites are farming out their identity management to big sites like Facebook and Twitter using OAuth. Messina and Recordon's idea is to reimplement OpenID atop OAuth 2.0, which would leverage that existing—widely adopted—API for identity management. It would also allow OpenID to become simpler for web site operators to implement. Recordon pointed out some of the problems he has heard about:

Based on that, one might wonder why OpenID doesn't just adopt OAuth, rather than build atop it, but there is an important distinction between the two. OpenID Connect would still decentralize the storage of user information and allow the user-centric nature of OpenID to survive. Users would be able to choose their provider or run their own that stored their personal information. That way, users would get to choose whom to trust or to only trust their own server.

Another problem that OpenID Connect hopes to solve is to simplify things for users. Right now, users have to remember and type in a URL that corresponds to their OpenID provider, or click on multiple buttons for popular providers (which leads to the so-called NASCAR problem where there are multiple logos as buttons). OpenID Connect would allow for simpler URLs or even email addresses as identifiers.

It is important to recognize that this proposal is being driven by the fact that OpenID adoption has largely stalled. That has happened because the sites that folks want to use want a little—or a lot—more information about those who are signing up for or using their services. There is a trade off, clearly, as it is not unreasonable for site owners to require more information as a kind of payment, as long as they are up front about it. But the privacy conscious are likely to still be marginalized as the demands for information increase.

While there currently is a lot of noise being made about privacy concerns for sites like Facebook, there appears to be little actual action about it by most users. Privacy just does not seem to be something that is high on most users' priority lists, or, perhaps, Scott McNealy was right: "You have zero privacy anyway ... Get over it." OpenID Connect seems like a reasonable idea, overall, but as long as the majority are happy with the current OAuth-based systems, it is a little hard to see it making any headway. Yes, it may be used by a small minority of internet users, but it is likely to require just enough effort that most will not take advantage of it. It would seem that many are already "over it".