« May 2008 "snapshot" of UK HE and FE development in SL | Main | A "layered" model for interoperability using Dublin Core metadata »

May 22, 2008

W3C Technical Architecture Group recommends against XRI

I've previously noted my concerns about the introduction of the XRI into the OpenID 2.0 specification.

In a message to the W3C Technical Architecture Group list yesterday Tim Berners-Lee and Stuart Williams, co-chairs of the TAG, state categorically:

We are not satisfied that XRIs provide functionality not readily available from http: URIs.  Accordingly the TAG recommends against taking the XRI specifications forward, or supporting the use of XRIs as identifiers in other specifications.

This statement leaves OpenID in an uncomfortable position, or so it seems to me.  Much of the value proposition of OpenID lies in its simplicity and its close fit with the Web architecture - unfortunately, the introduction of XRI into version 2.0 of the spec did damage on both counts.

The statement from the TAG could hardly be clearer - I'm intrigued as to how OpenID people are going to respond.


TrackBack URL for this entry:

Listed below are links to weblogs that reference W3C Technical Architecture Group recommends against XRI:


For the record, this was my follow-up response to the OpenID mailing list:

I realise now that by posting my question here I've opened the list up to the kind of "http URIs can't be used to identify non-Web resources" vs. "Oh yes they can" kinds of arguments that we've seen going on in other fora for the last N years. Apologies for that!

It seems to me that the W3C TAG is now absolutely clear on this point - http URIs can and should be used to identify all resources (physical, digital and conceptual). Frankly, I don't see who else one would ask. So at a technical level I don't think there is a debate to be had. XRIs don't add value over what we have in http URIs, they potentially do some harm, and they should therefore be avoided.

For me, the success of OpenID (and pretty much everything else for that matter) is tightly coupled to its fit with the Web Architecture - XRI now clearly damages that fit. On that basis, from a Web architecture point of view, I think that the introduction of XRI into the 2.0 spec was a mistake and the quicker we recognise that and do something about it the better.

That leaves us with the "human factors" issues that others have noted - are ordinary people willing to treat an http URI as an identifier for people? I don't know. I'd like to see more real evidence of this one way or another. It requires some level of cultural shift - but we've seen such things in the past. The more people who shout "this will never work" the more self-fulfilling the prophecy becomes. On the other hand I also appreciate that the TAG could simply be wrong - they are a *technical* group after all. I happen to agree with them, but... well...

So, I suppose what I'm saying is

- we should acknowledge that adoption of XRI into 2.0 was a mistake (which I appreciate is a non-trivial thing to say)

- we should be unequivocal and unapologetic about saying that http URIs can and should be used to identify people

- we should work on the usability issues around OpenID on that basis

Seems natural that "the http people" would disagree with using something other than http. I think that a lot more thought has been put into XRI than you give them credit for.

The XRI developers didn't decide to bypass http lightly, as http is clearly a ubiquitous and available technology. I believe that in some cases there are very good reasons to not "just use http" and the TAG seems to be ignoring those reasons.

The comments to this entry are closed.



eFoundations is powered by TypePad