The little guys keep building the future of the web in little steps.
Well, okay, I shouldn’t use such hubris, but I’m pretty proud of our little squad of do-gooders, developing quality technology that I think IS advancing the state of the web, and doing so without any budget whatsoever, and without any kind of centralized resources (can you tell I’ve been hanging out in Redmond at Microsoft’s campus the last couple days?).
Anyway, yesterday Eran Hammer-Lahav, the primary author of the OAuth spec, released the first draft of XRDS-Simple format for public review.
Acronyms aside, what we’re defining here is a data format that allows web authors to link to — in a consistent, ordered way — the various services that they use across the web. What’s important about this format is that 1) we’re not inventing anything new and that 2) it’s already widely implemented, thanks in large part to OpenID 2.0’s discovery mechanism (discovery, in this case, can be loosely defined as the means by which a computer determines where a service exists — for example, where someone stores their photos or blog posts — very useful, of course, in the case of URL-based identities).
Microformats folks will ask why we don’t just use rel-me, and that’s a very valid question. Sure, you could use rel-me to link to an XRDS-Simple document, but that doesn’t answer the question. Specifically, there are three main technical features that, taken together, are superior to rel-me from a service discovery perspective:
- Media types: essentially the MIME type that the service provides, as defined by RFC-2046 (in layman terms: photos, videos, text, etc).
- Local IDs: the identifier (i.e. a username or email address) associated with the requested resource; think of your Facebook email address (and clearly not something you’d necessarily want to publish publicly on your blog!)
- Service priority: useful for determining the selection order should there be more than one of a given type of service (for example, use my Vimeo account videos before my Viddler collection, etc)
Promoted by similar questions from Danny Ayers, Eran elaborated on this and similar topics (I’d encourage you to read this response for a good technical and philosophical backgrounder).
I’ll finish briefly by putting XRDS-Simple into a broader context of the work we’re doing, and point out how this fits into DiSo. First, we now have OpenID for URL-based identity on the web so we can identify people between web sites; second, we have OAuth for specifically controlling who has access to your data; and third, we now have a mechanism for discovering the services and data brokers that you use in a consistent, fairly widely supported format. These three building blocks are critical to advancing the smooth and secure flow of people and their data between web sites, web services and changing contexts.
For DiSo, we will enable someone to sign in to a web service for the first time and, at their discretion, have their contacts looked up (eventually this should be more like a buddy list reference), have feeds of her photos or videos or whatever other media she publishes automatically discovered and imported (would be really useful for Adobe Photoshop Express, for example!), to then provide her the option to allow the web service to send information back to her identity provider or data broker (for example, inserting events into her activity stream) which would then be able to be subscribed to or followed by any of her friends running their own sites, or who delegate to some third party aggregator service (a la FriendFeed).
This is actually a pretty simple flow, but the difference is that we can now assemble this entire stack with open tools, open protocols and open formats. Discovery is one of the few remaining components that we need to nail down to get into the next stage of building out this model. So, to that end, I encourage and invite your comments (the list is moderated and requires you to state your interest to sign up). We’ll be ending the Draft 1 review period April 10, so get your comments in sooner than later!
Factory Joe 