A few weeks ago, a handful of web companies lead by Meebo and Google (with moral support from Yahoo!) announced their support for a new protocol called XAuth. The idea is very simple and seemingly appealing – create a sort of shared-cookie service for sites to use to store and find which identity providers a user prefers, solving the OpenID NASCAR problem. It is a similar idea to existing commercial products such as JanRain’s RPX.
I’ve heard about this proposal a few months ago and have been rolling my eyes ever since. Why? Because this is – to borrow from one of my son’s favorite book – a terrible, horrible, no good, very bad idea. It is a dangerous and over simplified hack aimed at solving a complex problem – how to manage online identities and improve the usability of distributed identity providers.
One of the criticisms leveled against OpenID is that it uses HTTP URLs to identify users, and that users don’t understand URLs-as-identifiers (especially those who are not very technical). User Experience research confirms this.
Email addresses, on the other hand, are widely understood to identify people. So why can’t we use email addresses as OpenIDs? The reason is that, in OpenID 2.0, the way you perform discovery on an OpenID makes it necessary for that OpenID to be an HTTP URL: discovery information is obtained either through an X-XRDS-Location HTTP header sent by the server when accessing the OpenID (which is an HTTP URL), or by parsing through the document itself that is returned when accessing the OpenID HTTP URL. Continue reading
In my last article I wrote about the differences between user discovery and provider discovery. In this article, I will explain how both of these discovery flows can be easily be done using the “Link-base Resource Descriptor Discovery” (LRDD) pattern. A resource descriptor is, for the purposes of OpenID discovery, an XRD document describing meta-data about a resource, which can either be a user’s OpenID (i.e., identified by a user identifier) or an OpenID provider (i.e., identified by a provider identifier).
Actually, I don’t have a well-thought, proven, and complete case to make.
What I have instead is some loose consensus from a small group of people and a lot of experience trying other ideas. Historically, this is a bad way to start a discussion about new URI schemes. Getting consensus for new URI schemes is often more difficult than solving American healthcare.
The proposed ‘acct’ URI scheme is designed to identify an account. ‘Account’ is a pretty straight-forward concept. It is some sort of identifier – a string – that is specific to an authority – usually a server or domain. For most people, their account is also their email address, and in recent years, the emphasis on email has surpassed the concept of an account. When I started using the web 20 years ago, I had an account on a server. It just happened that this account has a mailbox associated with it.
Today, there are two discovery flows in OpenID: Directed Identity and Claimed Identity. This is not how they are called in the spec. In fact, they’re not separated in the spec at all (more about this below).
In the Claimed Identity flow, the relying party (RP) knows the user’s identifier (i.e., his or her OpenID URI), and attempts to figure out the OpenID provider (OP) for that user (i.e., the web site that will authenticate the user to the RP).
In the Directed Identity flow, the RP doesn’t know the user’s OpenID, but still figures out the user’s OP endpoint.
OpenID has been around for a while, but has for most of its life been a niche technology. This is not too surprising since it was originally designed for authenticating bloggers wanting to comment on other bloggers’ blogs.
More recently, it has been embraced by some big players like MySpace, Yahoo, Google, and Facebook. Even before it was picked up by the industry heavy-weights, the OpenID community revved the version to 2.0, anticipating some of the use cases beyond blogs. For example, users were no longer required to know their OpenID URL, and enter it at the Relying Party’s (RP) web site. Instead, they could just tell the RP who their OpenID Provider (OP) was, and log into the RP that way.
Still, OpenID 2.0 is in some ways inadequate for today’s requirements.
Yesterday Twitter released ‘Sign-in with Twitter’, the ability to use Twitter as a delegated sign-in provider for third-party websites. The cool thing about this new feature, which is part of their OAuth API beta, is that it is completely standard OAuth. No extensions, not secret sauce, and not another proprietary provider (yes, I’m looking at you Facebook).
It is Open done right.
With this small enhancement of the Twitter OAuth API, Twitter created a product that directly competes with Facebook Connect. The implementation details are significantly different (and there are some technical shortcoming on both sides), but there is little you can do with one and not the other. There is no reason why ‘Sign-in with Twitter‘ cannot be used anywhere Facebook Connect is offered, including blog posts and activity streaming.