I just returned from an inspiring meeting with a number of Identity Gang folks about the legal, social, and policy foundations of an identity metasystem. One of the most eye-catching presentations was Dick Hardt’s video of his OSCON talk on Identity 2.0. I think he does the best job yet of explaining what user-centric identity is really about: letting users, not systems/directories, control how they want they want to identify themselves and share data.

In his presentation, however, Dick hits one false note about XRI/XDI– he says “it’s not web services”. As Andy Dale notes in his Tao of XDI blog, XRI (as a syntax and resolution protocol for abstract identifiers) and XDI (as an XRI-based data sharing protocol) are both binding independent—they can be bound to any transport protocol. Both are starting with HTTP bindings only as a simple matter of expedience – HTTP is ubiquitous and lightweight, so there’s no reason not to use it.

But given the roots of XRI and XDI in XML, a SOAP binding makes just as much sense (and is in fact what some implementors are already using). And, as Kim Cameron keeps reminding me, this is also what’s needed for XRI and XDI to fully integrate with the world of web services. In fact, in the modular WS-* architecture, XRI and XDI should fit well, because they offer nicely compartmentalized functionality: XML-based abstract resource identification and data sharing, respectively.

Net net: XRI and XDI are neither POX- nor SOAP-centric. They are resource-centric (that’s “resource” as used in in Uniform Resource Identifier — anything that can be identified). (I could go on at great length about how “user-centric” is really “resource-centric”, but that’s another post.) And as resource-centric services, they are ideal for service-oriented architectures (SOAs) of any kind, including web services.