Extensible Resource Identifier
An Extensible Resource Identifier is a scheme and resolution protocol for abstract identifiers compatible with Uniform Resource Identifiers and Internationalized Resource Identifiers, developed by the XRI Technical Committee at OASIS. The goal of XRI was a standard syntax and discovery format for abstract, structured identifiers that are domain-, location-, application-, and transport-independent, so they can be shared across any number of domains, directories, and interaction protocols.
The XRI 2.0 specifications were rejected by OASIS, a failure attributed to the intervention of the W3C Technical Architecture Group which recommended against using XRIs or taking the XRI specifications forward. The core of the dispute is whether the widely interoperable HTTP URIs are capable of fulfilling the role of abstract, structured identifiers, as the TAG believes, but whose limitations the XRI Technical Committee was formed specifically to address.
The designers of XRI believed that, due to the growth of XML, web services, and other ways of adapting the Web to automated, machine-to-machine communications, it was increasingly important to be able to identify a resource independent of any specific physical network path, location, or protocol in order to:
- Create structured identifiers with self-describing "tags" that can be understood across domains.
- Maintain a persistent link to the resource regardless of whether its network location changes.
- Delegate identifier management not just in the authority segment but anywhere in the identifier path.
- Map identifiers used to identify a resource in one domain to other synonyms used to identify the same resource in the same domain, or in other domains.
Features
; URI- and IRI-compatibility; Cross-references
; Global context symbols
; Peer-to-peer addressing
; Decentralization
; Delegation
; Federation
; Persistence
; Human- and machine-friendly formats
; Simple, extensible resolution
; Trusted resolution
; Multiple resolution options
; Fully internationalizable
; Transport independent
Composition of an Extensible Resource Identifier
An XRI starting with "=
" is thought of identifying a person. An XRI starting with "@
" identifies a company or organization. A starting "+
" indicates a generic concept, subject or topic.A "
*
" marks a delegation. For example with =family*name
, =family
delegates the resolving of its sub-XRI name
to another resolver. This is analogous to DNS' delegating the subdomain resolution to other nameservers.Resolving an Extensible Resource Identifier
XRIs are resolved to XRDS documents using the HTTP protocol in the same way as URLs are resolved to resource records using the DNS protocol. This lookup process can be configured by passing parameters.Proxy resolvers and the HXRI
An XRI can be transformed into a URI by adding "http: //xri.net/
" at the beginning and appending the XRI. Internally, the URI now refers to a proxy resolver, which resolves a URI of this kind to an XRDS document. The proxy resolver found under http://xri.net for example can be used to resolve an XRI. So =example
becomes http: //xri.net/=example
. The second form is called an HTTP XRI or HXRI for short. The owner of the XRI =example
can tell the proxy resolver what to do, if the HXRI is called. One possible reaction is to do a 302 HTTP redirect to a stored URI.Further parameters to specify the resolution can be appended to the HXRI, e.g. to get the whole XRDS document or to get service descriptions for this XRI. E.g. if you attach
?_xrd_r=application/xrds+xml
to the HXRI, the whole XRDS document is returned. So http: //xri.net/=example?_xrd_r=application/xrds+xml
returns the whole XRDS for the XRI =example
.Examples of XRI cross-reference syntax
Say a library system uses URNs in the ISBN namespace to identify books and DNS subdomains to identify its library branches. HTTP URI syntax does not provide a standard way to express the URN for the book title in the context of the DNS name for the library branch. XRI cross-reference syntax solves this problem by allowing the library to programmatically construct the XRIs necessary to address any book at any branch. Examples:
xri://broadview.library.example.com/
xri://shoreline.library.example.com/
xri://northgate.library.example.com/
This ability to create structured, self-describing identifiers can be extended to many other uses. For example, say the library wanted to indicate the type of each book available. By establishing a simple XRI dictionary of book types, it can now programmatically construct XRIs that include this metadata,
xri://broadview.library.example.com//
xri://broadview.library.example.com//
xri://broadview.library.example.com//
Other examples of XRI 2.0 syntax
Example XRIs composed entirely of reassignable segments:
=Mary.Jones
@Jones.and.Company
+phone.number
+phone.number/
=Mary.Jones/
@Jones.and.Company/
@Jones.and.Company//)
Example XRIs composed entirely of persistent segments:
=!13cf.4da5.9371.a7c5
@!280d.3822.17bf.ca48!78d2/!12
Example of XRIs with mixes of persistent and reassignable segments :
=!13cf.4da5.9371.a7c5/
@Jones.and.Company!78d2/!12/
Applications
Examples of applications being developed using XRI infrastructure include:- OpenID 2.0 includes support for XRIs and uses XRDS for OpenID identifier discovery.
- The Higgins Project uses XRIs and XRDS to address and discover Higgins context providers.
- I-name and I-number digital identity addressing services.
- The XDI data sharing protocol under development by the OASIS .
Licensing
Dr Phillip Hallam-Baker, the VeriSign representative in OASIS argued that the use of the technologies employed in XRI are subject to patent claims, that the licensing rights to these patents has been vested in , a non-profit organization which had in turn licensed a non-exclusive interest in the use of the patents to companies associated with the original patent holders, despite the above IPR statement. Opposition from VeriSign and companies that had connections to Hallam-Baker was instrumental in ensuring the defeat of the proposal to adopt the specifications.