XRDS

The XML format used by XRDS was originally developed in 2004 by the OASIS XRI (extensible resource identifier) Technical Committee as the resolution format for XRIs. The acronym XRDS was coined during subsequent discussions between XRI TC members and OpenID developers at first Internet Identity Workshop held in Berkeley, CA in October 2005.

The protocol for discovering an XRDS document from a URL was formalized as the Yadis specification published by Yadis.org in March 2006. Yadis became the service discovery format for OpenID 1.1.

A common discovery service for both URLs and XRIs proved so useful that in November 2007 the XRI Resolution 2.0 specification formally added the URL-based method of XRDS discovery (Section 6).[1] This format and discovery protocol subsequently became part of OpenID Authentication 2.0.[2]

In early 2008, work on OAuth discovery by Eran Hammer-Lahav led to the development of XRDS Simple, a profile of XRDS that restricts it to the most basic elements and introduces some extensions to support OAuth discovery and other protocols that use specific HTTP methods. In late 2008, XRDS Simple has been cancelled and merged back into the main XRDS specification resulting in the upcoming XRD 1.0 format.

Besides XRI resolution, examples of typical XRDS usage include:

• OpenID authentication for discovery and capabilities description of OpenID providers.
• OAuth discovery for locating OAuth service endpoints and capabilities.
• The Higgins Project for discovery of Higgins context providers.
• XDI.org I-name and I-number digital identity addressing services for generalized digital identity service discovery.
• The XDI data sharing protocol for discovery of XDI service endpoints and capabilities.

Following is an example of an XRDS document for the fictional XRI i-name =example. This document would typically be requested from a Web server via HTTP or HTTPS using the content type application/xrds+xml. Note that the outer container <XRDS> element serves as a container for one or more <XRD> (Extensible Resource Descriptor) elements. Most simple XRDS documents have only one XRD. Other services like XRI resolution may construct a sequence of XRDs within a single XRDS document to reflect a chain of metadata about linked resources.

<?xml version="1.0" encoding="UTF-8"?>
<xrds:XRDS xmlns:xrds="xri://$xrds" xmlns="xri://$xrd*($v*2.0)"
xmlns:openid="http://openid.net/xmlns/1.0">
  <XRD ref="xri://=example">
    <Query>*example</Query>
    <Status ceid="off" cid="verified" code="100"/>
    <Expires>2008-05-05T00:15:00.000Z</Expires>
    <ProviderID>xri://=</ProviderID>
    <!-- synonym section -->
    <LocalID priority="10">!4C72.6C81.D78F.90B2</LocalID>
    <EquivID priority="10">http://example.com/example-user</EquivID>
    <EquivID priority="15">http://example.net/blog</EquivID>
    <CanonicalID>xri://=!4C72.6C81.D78F.90B2</CanonicalID>
    <!-- service section -->
    <Service>
      <!-- XRI resolution service -->
      <ProviderID>xri://=!F83.62B1.44F.2813</ProviderID>
      <Type>xri://$res*auth*($v*2.0)</Type>
      <MediaType>application/xrds+xml</MediaType>
      <URI priority="10">http://resolve.example.com</URI>
      <URI priority="15">http://resolve2.example.com</URI>
      <URI>https://resolve.example.com</URI>
    </Service>
    <!-- OpenID 2.0 login service -->
    <Service priority="10">
      <Type>http://specs.openid.net/auth/2.0/signon</Type>
      <URI>http://www.myopenid.com/server</URI>
      <LocalID>http://example.myopenid.com/</LocalID>
    </Service>
    <!-- OpenID 1.0 login service -->
    <Service priority="20">
      <Type>http://openid.net/server/1.0</Type>
      <URI>http://www.livejournal.com/openid/server.bml</URI>
      <openid:Delegate>http://www.livejournal.com/users/example/</openid:Delegate>
    </Service>
    <!-- untyped service for access to files of media type JPEG -->
    <Service priority="10">
      <Type match="null" />
      <Path select="true">/media/pictures</Path>
      <MediaType select="true">image/jpeg</MediaType>
      <URI append="path" >http://pictures.example.com</URI>
    </Service>
  </XRD>
</xrds:XRDS>

XRDS documents can assert zero or more synonyms for a resource. In this context, a synonym is another identifier (a URI or XRI) that identifies the same target resource. For instance, the example XRDS document above asserts four synonyms:

1. The local synonym !4C72.6C81.D78F.90B2. This is a relative XRI synonym assigned by the provider of this XRDS document.
2. The equivalent URL http://example.com/example-user with a priority of 10 (1 is the highest priority).
3. The equivalent URL http://example.net/blog with a priority of 15 (a lower priority than the other equivalent URL above).
4. The canonical identifier xri://=!4C72.6C81.D78F.90B2. This is an absolute XRI i-number for the target resource—a persistent identifier that will never be reassigned (the functional equivalent of a Uniform Resource Name).

For full details of XRDS synonym support, see XRI Resolution 2.0, Section 5.

The other main purpose of XRDS documents is to assert the services associated with a resource, called service endpoints or SEPs. For instance, the example XRDS document above asserts four service endpoints for the represented resource:

1. An XRI resolution service (type xri://$res*auth*($v*2.0)).
2. An OpenID 2.0 authentication service (type http://openid.net/signon/2.0).
3. An OpenID 1.0 authentication service (type http://openid.net/server/1.0).
4. An untyped service for requesting resources with a media type image/jpeg.

For full details of XRDS service endpoints, see XRI Resolution 2.0, Sections 4.2 and 13.

In XRDS documents, a service is identified using a URI or XRI. Following are listings of well-known service types.[3]

XRDS is an open public royalty-free OASIS specification. The OASIS XRI Technical Committee has operated since its inception in 2003 under a royalty-free licensing policy as stated in its charter and IPR page.

• Light-weight Identity
• Social Web

• OASIS XRI Technical Committee