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.