Equals Drummond

Something else so good I just have to blog it: Eran Hammer-Lahav’s Discovery Coordination Report on the new metadata-discovery list he set up. Eran’s turning into a one-man hub of all things discovery as he drives forward together with the rest of the OASIS XRI TC towards the pushing out the new XRD 1.0 spec.

I have high hopes for this spec and Eran is one of the key reasons (plus the efforts of his co-editor Nat Sakimura of NRI, who is working OpenID miracles in Japan, and other new TC members who have joined to finally make simple, safe, uniform metadata discovery a reality on the Web).

For most people, watching the evolution of technical specifications is like watching a glacier move. To those of us living the process, though, there can be a great deal of drama to it — in fact it’s much more like climbing an icefall inside the glacier (anyone doubting how much adrenaline that takes should read John Krakauer’s description in Into Thin Air of climbing Mt. Everest’s Khumbu Icefall). For example, the failure of the OASIS Standard vote on the XRI 2.0 specifications last May — the first ever in 40+ OASIS Standard votes — was a watershed in the interaction of two standards bodies (W3C and OASIS).

The repercussions from that event have been equally unpredictable. Who would have thought that just four months later the XRI TC and W3C TAG would have rough consensus on how to resolve their differences? Or that the discussions would spill over to the much larger topic of uniform metadata discovery on the Web? Or that discovery could turn out to be the key to building identity into the browser? Or that interest in the XRDS discovery format would boil up enough to beget a new spec intended for uniform metadata discovery for any type of URI or XRI?

But that’s just what has happened. Two weeks ago at the Internet Identity Workshop, Eran Hammer-Lahav, author of the OAuth Discovery spec and founder of the XRDS-Simple list, led a marathon session on a new uniform metadata discovery specification to be called XRD 1.0. With 20 to 40 people in attendance all afternoon, Eran first ran through his exhaustively-researched blog post on HTTP and discovery, then through the proposed simplifications to the current XRDS/XRD schema. By the end there was rough consensus on XRD as a mechanism for uniform metadata discovery across all the different Internet identity and data sharing specs that need it (XRI, OpenID, OAuth, OpenSocial, XDI, Data Portability, etc.)

The name “XRD” is itself quite revealing of the evolutionary path to this point. When the OASIS XRI TC first developed the XML-based metadata discovery format we needed for XRI resolution back in 2003, we called it XRID (XRI Descriptor). We made it as simple and generalized as we could simply because any resource could have an XRI, so there was no telling what type of metadata might be needed over time. We focused primarily on one clear requirement: given input identifier x and service type y, define how to discover service endpoint URI z.

By 2005, when OpenID grew to the point of needing a discovery format, the authors of the Yadis (Yet Another Discovery spec) authors looked at XRID and saw something very close to what they needed. But XRID assumed you needed a sequence of descriptors corresponding to an XRI resolution chain. With OpenID a sequence wasn’t needed because an http(s) URI would have just one descriptor. So the XRI TC renamed the metadata format to XRD (Extensible Resource Descriptor) and created a separate XML wrapper element called XRDS (XRD Sequence) for cases like XRI resolution where you needed to wrap a sequence of XRDs.

However for cross-compatibility between XRI and OpenID, OpenID discovery just assumed the outer XRDS wrapper element even if it contained only one XRD. So the discovery format became widely known by the wrapper element, XRDS.

It wasn’t until Eran’s deep-dive on uniform metadata discovery that he recognized that the base case should be the other way around, i.e., for most URIs the the base discovery document should be an XRD, and only in cases like XRI resolution do you need the XRDS wrapper element.

Since the XRI TC had already made the decision in our next round of specs to split off XRDS from XRI Resolution, it was easy to just call this new specification XRD 1.0 (”1.0″ reflecting that it is the first standalone specification for XRD). However what we didn’t realize until the XRI TC F2F meeting the day after IIW was that XRD as both a metadata discovery format and protocol would be comprehensive enough that XRI 3.0 Resolution could become simply a “profile” of XRD 1.0 — and thus dramatically shorter.

We also didn’t realize how badly many different stakeholders want a Web-wide metadata discovery mechanism. Within a week after IIW we had six new people join the XRI TC to be part of the XRD work, and as of this writing nine more are in the queue.

So the roadmap of the next generation of XRI TC outputs is clear now. We will produce two OASIS Standard-track specifications:

• XRI 3.0 (including Syntax, Resolution, and Bindings) as a uniform syntax and resolution protocol for shared semantics across hierarchical URI schemes.
• XRD 1.0 for uniform metadata discovery for any URI or XRI.

Stay tuned for updates – hopefully this set of specs will set a glacier speed record.

I just added XRDS (Extensible Resource Descriptor Sequence) as a new category on my blog because this simple XML document format, created by the OASIS XRI Technical Committee to provide XRI resolution metadata and subsequently adopted by Yadis, is starting to gain attention as the discovery format for OpenID.

Phil Windley just posted a good overview of XRDS today. For even more detail about XRDS (and OpenID in general) see this article written for the Java community — perhaps the single best technical article on OpenID I’ve read.

Johannes Ernst just created an excellent blog post out of an email dialog he and I had about the “big picture” of XRI resolution. It’s true that the concept of an identifier resolution network based on HTTP that parallels the DNS resolution nework based on UDP is unusual at first. But for RESTful architects like Johannes, the lightbulb goes on when look at the power of using the HTTP layer to do for digital identification what the DNS layer did for host naming — especially leveraging the simplicity and extensibility of XRDS documents (the XML format returned by an XRI resolution request, and also the format used by the Yadis URL service discovery protocol of which Johannes was the co-instigator.)

As the XRI Resolution editor’s team starts work this month on what we hope is the final working draft of XRI Resolution 2.0 (currently at working draft 10), I plan to blog more about other key features of XRDS documents — CanonicalIDs, Refs, ProviderIDs, and Service Endpoints – that all help solve higher-level identity and trust problems at a layer higher than DNS was intended to function, much like DNS solved a set of problems of logical naming and redirection at a layer higher than IP addressing was intended to function.