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.
This post is mostly me thinking out loud.
XRD is still very much a work-in-progress, and the OpenID community has yet to consider or endorse the new XRD protocol for its discovery needs. But since many of my readers consider OpenID discovery as the primary use case for XRD, I think this is a worthwhile excursion.
This post will offer one way in which XRD could be used as a new discovery layer for OpenID. Keep in mind that there are other ways XRD could be used for OpenID. The next post on this topic will look into specifying OpenID extensions as well as other ways to describe the provider.
But first, let’s cover the basics…
Two weeks ago I posted two items about OpenID. The first praised the significant contribution OpenID is making to the Open Web. The second raised questions about the direction the OpenID user experience is taking, and how the community discussion seems to be taking a very strong corporate voice. Needless to say, some people didn’t like my questions and what they thought I was implying. Ironically, they opted to send their comments in private.
Let me start by reiterating some points about my employer’s position, wearing my Yahoo! hat for a second, something I rarely do on this blog.
- Yahoo!’s support for OpenID is unequivocal.
- Yahoo! is an active member of the community, a specification contributor, and a sustaining member of the foundation.
- Yahoo! has made a commitment not to invent any new or proprietary alternatives to OpenID.
- We are also committed and actively seeking ways to support OpenID as a relaying party, accepting OpenID logins from other providers.
If a single theme emerged from the recent OpenID usability summit hosted by Facebook (to which I was not invited), it is that ‘Brands’ are the key to OpenID success. Users, more than anything else, identified themselves with brands such as Yahoo!, Facebook, and MySpace, and when presented with a federated login dialog, found the logos of these providers to be the most intuitive way to login. This is the driving force behind Facebook Connect adoption.
The key to brand-driven login, of course, is Directed Identity. It’s the feature of OpenID in which the user does not enter his OpenID URI, but instead, tells the site who he would like to login with (the provider’s identifier, not the user’s). Yahoo! was the first major supporter of Directed Identity and it is the primary feature of its OpenID service.
See where I am going with this?
If Directed Identity is the technology, and Brand-recognition the philosophy to move OpenID forward, isn’t that equal to declaring bankruptcy to the vision of self-controlled and hosted identity? Microsoft, Google, Yahoo!, and Facebook don’t need a community. They can meet in a room and decide how they want to inter-operate. Technically, they don’t even need to inter-operate because developers can just drop 4 libraries into their sites that will do all the heavy lifting for them (Facebook-style).
Is OpenID becoming noting more than a fig-leaf for big corporations, protecting them from anti-trust, and making their locked-in products look Open?