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).
WebFinger is an updated take on the Name/Finger protocol using HTTP, XRD, and host-meta (instead of a direct TCP connection on port 79) to obtain information about user accounts. It works by defining a new account URI scheme and a protocol for resolving it into an extensible descriptor of the account and its owner.
The account URI, using the newly proposed ‘acct‘ scheme, is used to identify user accounts at a given host which are typically used for the purpose of resource management and establishing local identity (at the host). User accounts include a local identifier (username, screenname, or handle), and a host which can resolve and (usually) authenticate the local identifier.
The protocol consists of:
- A URI scheme to identify accounts using a familiar syntax.
- A simple protocol for resolving account URIs into an extensible descriptor.
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.
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.