XRDS-Simple 1.0 Draft 1

Abstract

XRDS-Simple provides a format and workflow for the discovery of resources metadata, and other linked resources. As web services continue to grow, applications utilize a wider range of web services and resources across multiple providers. XRDS-Simple allows providers to document their resources in a machine-readable way, which can be automatically discovered by consumer applications.

The XRDS-Simple specification builds on top of existing practices first introduced by the XRI community and later adopted and further developed by Yadis, a discovery protocol widely used by the OpenID community. XRDS-Simple goal is to provide an easy to implement solution that is focused on solving the most common discovery use cases.

Table of Contents

1.  Notation and Conventions
2.  Definitions
3.  Introduction
4.  Workflow Overview
5.  Document Retrieval
    5.1.  Obtaining Location
        5.1.1.  HEAD Protocol
        5.1.2.  GET Protocol
    5.2.  Requesting Document
6.  Document Structure
    6.1.  Declarations and Requirements
    6.2.  XRD Element
    6.3.  Service Element
    6.4.  priority Attribute
    6.5.  Non-XRDS Elements and Attributes
        6.5.1.  simple:httpMethod Attribute
        6.5.2.  simple:MustSupport Element
    6.6.  Extension and Deviation
7.  Resource Descriptions Selection
    7.1.  XRD Identification
    7.2.  Service Selection
Appendix A.  Example
Appendix B.  History of XRDS
Appendix C.  Security Considerations
Appendix D.  Acknowledgments
8.  References
§  Author's Address

1.  Notation and Conventions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] (Bradner, B., “Key words for use in RFCs to Indicate Requirement Levels,” .). Domain name examples use [RFC2606] (Eastlake, D. and A. Panitz, “Reserved Top Level DNS Names,” .).

2.  Definitions

Resource:

A URI-addressable network document or service.

Endpoint:

An absolute URI at which a Resource is available on the network.

Resource Description Document

An XML-formatted document providing a machine-readable list of Resources descriptions and their Endpoints.

Service Provider:

A web application offering XRDS-Simple discovery information about its Resources and related Resources offered by other providers.

Consumer:

A website or application that uses XRDS-Simple to discovery information about Resources offered by a Service Provider.

3.  Introduction

XRDS-Simple defines a subset of the XRDS format defined in [XRI Resolution 2.0] (Wachob, G., Reed, D., Chasen, L., Tan, W., and S. Churchill, “Extensible Resource Identifier (XRI) Resolution V2.0,” .), with a small set of extensions. In this specification, XRDS refers to the full format defined in [XRI Resolution 2.0] (Wachob, G., Reed, D., Chasen, L., Tan, W., and S. Churchill, “Extensible Resource Identifier (XRI) Resolution V2.0,” .), while XRDS-Simple refers to the subset of XRDS and the extensions defined in Section 6 (Document Structure).

The goal of XRDS-Simple is to provide a lightweight version of XRDS that simplifies the implementation of parsers while maintaining full compatibility with XRDS and any XRDS-compliant parsers and resolvers. It also serves as an introduction to XRDS, giving implementers an upgrade path to other XRDS features when appropriate.

By defining XRDS-Simple, implementers can both declare the scope of their application and capabilities, as well as perform tests to assert that their application is capable of processing input documents exactly as they were intended. This is of particular importance when processing documents with security or identity information, where misinterpretation of the document can lead to a breach of security.

4.  Workflow Overview

XRDS-Simple provides a bi-directional method for mapping between a Resource and the Resource Description Document describing it. This allows finding Resource information from either starting point, a Resource or a Resource Description Document.

In one direction, the Resource Endpoint is used to retrieve the Resource Description Document - a machine-readable document containing information about the Resource, as well as links to other associated Resources. In the opposite direction, a Resource Description Document provides a list of Resource descriptions which are matched against the desired selection criteria leading to a Resource Endpoint.

This can also be viewed as a circular workflow in which a Resource Endpoint leads to the Resource Description Document which in turns leads back to the Resource Endpoint via the Resource description, as well as points to other Resource Endpoints. The entry point in which a Consumer enters the workflow depends on what is available to it.

The discovery workflow centers on the retrieval and parsing of the Resource Description Document and includes two steps, each representing one of the entry point to the workflow:

• Retrieve the Resource Description Document.
• Parse the Resource Description Document and select the desired Endpoints.

5.  Document Retrieval

The Consumer obtains the Resource Description Document by following the workflow defined in this section, starting with the Resource Endpoint. XRDS-Simple only defines a retrieval method for HTTP(S) Endpoints. While XRDS-Simple supports descriptions of non-HTTP(S) Endpoints, the method in which their associated Resource Description Document is retrieved is beyond the scope of this specification.

Document retrieval is performed in two steps. First the document's location is obtained from the Endpoint, then the location obtained is used to request the Resource Description Document.

5.1.  Obtaining Location

The document's location can be obtained using two protocols, originally specified in [Yadis] (Miller, J., “Yadis Specification 1.0,” .) and later adapted in [XRI Resolution 2.0] (Wachob, G., Reed, D., Chasen, L., Tan, W., and S. Churchill, “Extensible Resource Identifier (XRI) Resolution V2.0,” .), one uses HTTP HEAD while the other uses HTTP GET.

In both protocols, if the Endpoint contains a fragment, it MUST be removed prior to querying for the document's location. This is important as the document's location HTTP(S) URI MAY contain a fragment which carried a special meaning, and MUST NOT be confused with the Endpoint fragment (which is discarded for the purpose of performing discovery).

Service Providers MUST support the GET protocol and MAY support the HEAD protocol. Consumers MAY attempt the HEAD protocol but MUST attempt the GET protocol if the HEAD protocol fails. There is no difference between the retrieval workflow of XRDS documents and that of XRDS-Simple documents.

In all cases the HTTP(S) status messages and error codes defined in [RFC2616] (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” .) SHALL apply. Consumers MUST be able to handle HTTP redirects when requesting the document's location and the Resource Description Document.

If the Service Provider supports HTTP content negotiation, its responses SHOULD include a Vary header to allow caches to properly interpret future requests. This header SHOULD be present even in the case where an HTML page is returned (instead of an XRDS document).

5.1.1.  HEAD Protocol

Using the HEAD protocol, the Consumer MUST issue an HTTP(S) HEAD request to the Endpoint. The request SHOULD include an Accept header specifying content type application/xrds+xml. The response from the Service Provider MUST include only headers, which MUST contain one of the following:

1. An X-XRDS-Location header where the value of the header MUST be an HTTP(S) URI which gives the document's location.
2. A Content-Type header specifying the content type application/xrds+xml. In this case the document's location is identical to the Endpoint, excluding any fragment.

If both headers are present, the X-XRDS-Location header is used and the Content-Type header ignored. If neither header is present, the protocol fails and the Consumer MUST attempt the GET protocol (GET Protocol).

5.1.2.  GET Protocol

Using the GET protocol, the Consumer MUST issue an HTTP(S) GET request to the Endpoint. The request SHOULD include an Accept header specifying content type application/xrds+xml. The Service Provider response MUST be one of three options:

1. A Valid XRDS document in the response body. The Response SHOULD include the Content-Type header with value application/xrds+xml. In this case, the response body contains the Resource Description Document and the workflow ends successfully skipping the step described in Section 5.2 (Requesting Document).
2. An X-XRDS-Location header where the value of the header MUST be an HTTP(S) URI which gives the document's location.
3. A valid HTML document in the response body, with a <head> element that includes a <meta> element with an http-equiv attribute equals to X-XRDS-Location. The value of the <meta> element content attribute MUST be an HTTP(S) URI which gives the document's location.

The Consumer MUST check the Service Provider's response for one of the three options in the order they are listed above, and MUST stop as soon as a match is found. If no match is found, the protocol fails and the discovery workflow ends unsuccessfully.

5.2.  Requesting Document

Once the document's location has been obtains, the Consumer MUST check if it is identical to the Endpoint to avoid a loop (ignoring any differences in the URI fragments), in which case the discovery workflow ends unsuccessfully. Otherwise, the Consumer MUST request the XRDS document from the location URI using an HTTP(S) GET. This request SHOULD an Accept header specifying content type application/xrds+xml.

The Service Provider MUST reply with a Valid XRDS document in the response body. The Response SHOULD include the Content-Type header with value application/xrds+xml. If the response is not a valid XRDS document, the discovery workflow ends unsuccessfully.

If the document's location URI contains a fragment, it is used as an XRD identifier pointing to a specific element with an xml:id attribute of identical value. The XRD identifier is described in Section 7.1 (XRD Identification).

6.  Document Structure

The Resource Description Document is an XML-formatted document providing machine-readable descriptions of one or more Resources. Grouping descriptions together is usually done to indicate some common purpose, for example, a collection of services offered by a company or an individual's online assets and identifiers. XRDS-Simple defines only the most fundamental properties needed for requesting specific representations of the Resource (e.g., specific media types), or for interacting directly with the Resource.

In its simplest form, the Resource Description Document is a list of Resources and their Endpoints grouped together. The document structure consists of three primary elements (listed in reverse hierarchical order):

<Service>

Describes a Resource by assigning it a type and media-type, declaring its Endpoints, and provides any additional information relevant to the utilization of the Resource. For example, it describes a photo album, identity provider, or social network account.

<XRD>

Container element used to group together any number of Service elements, usually with some commonality. For example, a group of identity Resources or a list of sites holding someone's photos.

<XRDS>

Container element used to group together any number of XRD elements with elements from other namespaces, usually with some common context. For example, documenting multiple groups of an individual's social networking accounts, grouped together based on persona (work, home, etc.).

6.1.  Declarations and Requirements

The Resource Description Document MUST be a valid XRDS document, contain a single XRDS root element, and define the xri://$xrds namespace. While a valid XRDS-Simple document MAY include any number of XRD elements as well as elements from other namespaces, only XRDS-Simple compliant XRD elements are used in the discovery process.

XRDS-Simple compliant XRD elements MUST define the xri://$XRD*($v*2.0) namespace as well as include the version attribute with value 2.0. They MUST include a Type child with value xri://$xrds*simple. For the remainder of this specification, XRD elements refer only to XRDS-Simple compliant XRD elements. For example:

      <XRDS xmlns="xri://$xrds">
        <XRD xmlns="xri://$XRD*($v*2.0)" version="2.0">
          <Type>xri://$xrds*simple</Type>
        </XRD>
      </XRDS>

If an XRDS-Simple document contains more than one XRDS-Simple compliant XRD element, they SHOULD all be assigned unique identifiers using the xml:id attribute. XRDS-Simple only provides a limited selection method of choosing between XRD elements, in which case, if a document contains more than one XRD element, the unique XRD identifier is used to point to a specific element as described in Section 7.1 (XRD Identification).

The Consumer MAY ignore any other child element of the root XRDS element, including non-compliant XRD elements or elements from other namespaces. The presence of such element MUST NOT alter the way in which the document is processed as defined in this specification.

6.2.  XRD Element

The XRD element is a container used to group together any number of Resources. The XRD element supports the following attributes:

xml:id

OPTIONAL with type xs:ID, used to uniquely identify this element within the containing XRDS root element. The attribute is RECOMMENDED if the document contains more than one XRD element and its usage is defined in Section 7.1 (XRD Identification). Note that this attribute is an implicit XML attribute defined in [xml:id] (Marsh, J., Veillard, D., and N. Walsh, “xml:id Version 1.0, World Wide Web Consortium,” .).

version

REQUIRED with type xs:string and a value of 2.0.

The XRD element supports the following child elements:

<Type>

1 or more per XRD element with type xs:anyURI. The Type element describes the nature of the XRD element, how it should be processed, and the context in which it is used. Each XRD element MUST include one and only one Type element with the value xri://$xrds*simple, and MAY include any number of other Type elements. The element MAY also be used to describe the group of Resources included within.

<Expires>

0 or 1 per XRD element with type xs:dateTime. The date and time without fractional seconds in UTC "Z" time zone, after which the XRD element MUST NOT be used. If the Resource Description Document was obtained via HTTP, and the HTTP headers specified an expiry time per section 13.2 of [RFC2616] (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” .), the XRD element MUST NOT be used after the earlier of the two times passes.

<Service>

0 or more per XRD element as defined in Section 6.3 (Service Element).

6.3.  Service Element

The Service element describes a Resource and provides elements to declare its Endpoints and other attributes. The Service element supports the following attributes:

priority

OPTIONAL with type xs:nonNegativeInteger as defined by Section 6.4 (priority Attribute). Used to set the order of preference between Resources that would otherwise be considered of equal purpose. RECOMMENDED when an XRD element contains multiple Service elements with identical types or media-types association.

The Service element supports the following child elements:

<Type>

0 or more per Service element with type xs:anyURI. The Type element describes the nature of the Resource, how it should be accessed, and the context in which it is selected. The value of the Type element MUST be an absolute URI. Each Service element MUST include at least one of either Type element or MediaType element, but MAY include any number of both.

<MediaType>

0 or more per Service element with type xs:string. Describes the media-type of the content available at this Resource. The value MUST be a valid media-type as defined in [RFC2046] (Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types,” .). Each Service element MUST include at least one of either Type element or MediaType element, but MAY include any number of both.

<URI>

0 or more per Service element with type xs:anyURI. Provides the Endpoint where the Resource can be found and used or retrieved. If no URI element is defined, it is assumed the URI can be obtained by other means not specified in this specification. Supports the OPTIONAL priority attribute as defined by Section 6.4 (priority Attribute), and the OPTIONAL extension attribute simple:httpMethod as defined by Section 6.5.1 (simple:httpMethod Attribute)

<LocalID>

0 or more per Service element with type xs:anyURI. Provides a standard way to indicate the identifier associated with the Resource at the Endpoint where it is located. The value and meaning of the element is specific to the Resource and its type, and is beyond the scope of this specification. Supports the OPTIONAL priority attribute as defined by Section 6.4 (priority Attribute). For example, this element is useful when the local identifier such as username, is not part of the Endpoint, but is provided as a parameter.

<simple:MustSupport>

0 or more per Service element with type xs:anyURI as defined by Section 6.5.2 (simple:MustSupport Element). Defines requirements the Consumer MUST meet in order to utilize the Resource described.

When selecting between multiple Service elements, the types and media-types of each Resource are used together with the relative priorities, to find the most appropriate Resource.

6.4.  priority Attribute

XRDS-Simple allows the Service, URI, and LocalID elements to appear multiple times within the same parent element to provide redundancy, flexibility, or other purposes. When these elements appear more than once within the same parent, Service Providers SHOULD use the priority attribute to prioritize selection of these element instances.

The priority attribute type is xs:nonNegativeInteger - its value MUST be a non-negative integer value. The attribute works in a similar manner to DNS records priority, where the lowest value has the highest priority. This means zero has the highest priority and infinity - represented as the value null - carries the lowest priority. If omitted, the element's priority value defaults to null, however, instead of omitting the attribute, it is RECOMMENDED to set the priority value to 10. When a Service Provider wishes to indicate a very low priority, it is RECOMMENDED to use a large finite value (100 or higher) rather than explicitly use the value null.

Consumers SHOULD select the element with the highest priority - the lowest numeric value of the priority attribute. In the following example, the URIs decreasing order of priority is 0, 10, 11, 25, and last null and the element with the omitted attribute (equally low).

      <Service>
          <URI priority="10">http://example.com/second</URI>
          <URI priority="null">http://example.com/lowest</URI>
          <URI priority="25">http://example.com/fourth</URI>
          <URI priority="11">http://example.com/third</URI>
          <URI priority="0">http://example.com/highest</URI>
          <URI>http://example.com/lowest</URI>
      </Service>

If two or more instances of the same element type have identical priority attribute values (including the null value), the Consumer SHOULD select one of the instances at random. The Consumer SHOULD NOT choose the first instance that appears in XML document order. This is needed to support the Service Provider's redundancy or load balancing intentions.

The element selected according to these rules is referred to as the highest priority element. If this element is subsequently disqualified from the set of qualified elements, the Consumer SHOULD attempt to select the next highest priority element. This process SHOULD be continued for all other instances of the qualified elements until success is achieved or all instances are exhausted.

6.5.  Non-XRDS Elements and Attributes

XRDS-Simple introduces a few new elements and attributes not defined in XRDS which are needed for an easier adoption of the format with HTTP Resources. In order to maintain full compatibility, these are defined under a separate namespace, and do not change the discovery workflow.

To use the extensions the http://xrds-simple.net/core/1.0 namespace MUST be defined. The namespace alias simple is shown as an example, and can be set to any valid XML namespace alias. For example:

      <XRDS xmlns="xri://$xrds">
          <XRD xmlns:simple="http://xrds-simple.net/core/1.0" xmlns="xri://$XRD*($v*2.0)" version="2.0">
              <Type>xri://$xrds*simple</Type>
              <Service>
                <Type>http://example.net/some_type</Type>
                <URI simple:httpMethod="POST">http://example.com/resource</URI>
              </Service>
          </XRD>
      </XRDS>

6.5.1.  simple:httpMethod Attribute

The simple:httpMethod attribute provides the HTTP method needed to request the Resource provided at the Endpoint specified by the URI element. The attribute value type is xs:string, is case-sensitive, and is any accepted HTTP verb by the provider of the Resource (for example, the HTTP methods defined in [RFC2616] (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” .) section 9). If omitted, the method is assumed to be specified by other means, such as implicitly defined by the type or media-type of the Resource.

6.5.2.  simple:MustSupport Element

The simple:MustSupport element indicates that a Resource has certain requirements that MUST be supported by the Consumer in order to be utilized. Similar to the Type element, the simple:MustSupport element uses namespace URIs to describe the Resource. It instructs Consumer that the Resource requires some additional understanding beyond matching some of the types or media-types. Consumers SHOULD always check for unknown simple:MustSupport element values before selecting or utilizing the Resource description.

The element can be considered a sub-type, but carries the additional functionality of instructing the Consumer of a hard requirement. Generally, Resources can have many types and media-types, and are selected by ensuring the desired types and media-types are present, while ignoring others of no value or unknown. simple:MustSupport provides a way in which parsers can check to see if they are at all capable of interacting with a Resource, even if they are familiar with some of its types and media-types.

In some cases, an overlap exists between the Type and simple:MustSupport elements. In those cases, both elements SHOULD be included to maintain consistency with existing practices. For example, OpenID uses Type elements to document both the type of the Endpoint, as well as the OpenID extensions it supports. If one of these extensions is REQUIRED, its namespace identifier SHOULD appear in both a Type and simple:MustSupport elements, within the same Service element.

While this element can be defined in a seperate specification, it is included as part of XRDS-Simple to establish a mechanism for Consumers to detect when they are unable to utilize a discovered Resource.

6.6.  Extension and Deviation

XRDS-Simple inherits the extendibility of XRDS but places strict limitations on the ability to extend the format. Any extension used MUST NOT define or cause any deviation from the meaning and workflow defined in this specification with regard to the discovery process. Extensions MUST be restricted to add only Resource-specific descriptions.

This is particularly true to XRDS elements and attributes not explicitly listed and allowed in this specification, as they might significantly alter the way in which a document is parsed and Endpoints selected. For a document to legally declare itself as XRDS-Simple, it must be fully compatible with any compliant XRDS-Simple parser, as well as any compliant XRDS parser.

XRDS-Simple parsers SHOULD look for the existence of a valid XRDS-Simple declaration before parsing any XRDS documents, as they MAY otherwise produce incorrect results. It is also RECOMMENDED that XRDS-Simple parsers attempting to parse XRDS documents, include logic to check for elements excluded from XRDS-Simple which are known to significantly alter the discovery process. This includes but not limited to the Redirect and Ref elements, and the match and select attributes, defined in [XRI Resolution 2.0] (Wachob, G., Reed, D., Chasen, L., Tan, W., and S. Churchill, “Extensible Resource Identifier (XRI) Resolution V2.0,” .).

7.  Resource Descriptions Selection

The Resource Description Document provides lists of Resource descriptions grouped together. Once the document has been obtained, the Consumer typically performs Resource descriptions selection, to extract the descriptions of the Resources relevant to it. The selection process centers around iterating through the list of Resource descriptions, filtering them based on their type and media-type, and selecting them based on their relative priorities.

The Resource descriptions selection process includes two steps:

1. Identify the XRD element describing the desired Resource or group of Resources.
2. Select the Service elements matching against the Consumer's desired criteria.

7.1.  XRD Identification

Identifying an XRD element within an XRDS-Simple document is done by following the identification rules:

1. The Consumer MUST find all the XRDS-Simple compliant XRD elements as defined in Section 6.1 (Declarations and Requirements), excluding any expired elements as defined by the Expired child element (XRD Element). Any other elements SHALL be ignored in the steps that follow. The Consumer MAY choose to filter the list of XRD elements further by looking for additional Type elements matches at the XRD level.
2. If the document's location includes a URI fragment as defined in Section 5.2 (Requesting Document), the Consumer MUST look for an XRD element with an xml:id attribute value matching the XRD identifier indicated by the URI fragment. If a match is found, the XRD element is used as defined in Section 7.2 (Service Selection), otherwise the discovery process ends unsuccessfully.
3. If the document contains a single XRD element, it is used as defined in Section 7.2 (Service Selection).
4. If the document contains multiple XRD elements, the last element is used as defined in Section 7.2 (Service Selection).

7.2.  Service Selection

Based on the Consumer's needs, the Consumer defines a selection criteria based on the presence (or lack of) certain Resource types and media-types. The selection criteria can be any combination of type and media-type values desired by the Consumer, as well as looking for specific Endpoint URIs. For example, a Consumer can look for all Resource descriptions with an image media-type, an Endpoint with OpenID authentication type, or the description of a specific Resource given its Endpoint URI.

If the selection criteria places higher preference on the presence of certain types or media-types over others, it is handled by performing multiple selections. Each selection is assigned preference order based on the Consumer needs and the selection results are compared to determine the most desired set. For example, if a Consumer is looking for all image Resources, giving higher preference to the JPEG formats over PNG, it will perform two selection processes, one for each media-type, and assign the Resources in the JPEG set a higher preference value.

Once an XRD element has been identified, the Consumer performs the following steps in order to select the desired Resource descriptions:

1. Each Service element is compared against the selection criteria by comparing the values of the Type, MediaType, and URI elements to those defined by the selection criteria.
2. The Consumer SHOULD inspect the matching Service elements for simple:MustSupport elements, and remove from the list any Service elements with unknown simple:MustSupport values.
3. If more than one Service element is matched, the Consumer MUST use the priority attribute values to find the highest priority element as defined in Section 6.4 (priority Attribute).
4. Within the priority sorted list of matching Service elements, if more than one URI or LocalID elements are present, the Consumer MUST use the priority attribute values of each element type to find the highest priority element as defined in Section 6.4 (priority Attribute).

At the conclusion of the selection process, if any of the Resource descriptions matched the selection criteria, the Consumer will obtain a list of Resource descriptions, sorted by their matching preference and priorities.

Appendix A.  Example

The following example list the stores in which an individual name Jane Doe created wish-lists for her friends to use to buy her presents. The examples assumes an open standard has been established for wish-list representation, which is identified by the namespace URI http://specs.example.com/wish_list/1.0. According to the wish-list specification, requests for a user's wish list include the user's screen name in a URL-encoded parameter.

      <XRDS xmlns="xri://$xrds">
          <XRD xmlns:simple="http://xrds-simple.net/core/1.0" xmlns="xri://$XRD*($v*2.0)" version="2.0">
              <Type>xri://$xrds*simple</Type>
              <Service priority="10">
                <Type>http://specs.example.com/wish_list/1.0</Type>
                <URI simple:httpMethod="GET">http://books.example.com/wishlist</URI>
                <LocalID>jane<LocalID>
              </Service>
              <Service priority="20">
                <Type>http://specs.example.com/wish_list/1.0</Type>
                <URI simple:httpMethod="GET" priority="10">https://dvds.example.org/lists/wishes</URI>
                <URI simple:httpMethod="GET" priority="20">http://dvds.example.org/lists/wishes</URI>
                <LocalID>janedoe<LocalID>
              </Service>
          </XRD>
      </XRDS>

Appendix B.  History of XRDS

The XRDS discovery document format originated at the OASIS XRI (Extensible Resource Identifier) Technical Committee working in conjunction with the early OpenID community. The acronym XRDS - Extensible Resource Descriptor Sequence - was coined out of discussions between XRI TC members and OpenID developers at first Internet Identity Workshop held in Berkeley, CA in October 2005.

[OpenID Authentication 1.1] (Recordon, D. and B. Fitzpatrick, “OpenID Authentication 1.1,” .) needed an HTTP(S)-based service discovery mechanism for URLs, and the XRI TC had already defined an HTTP(S)-based resolution mechanism and a general-purpose service discovery format for XRIs (a new type of abstract structured identifier). With a few changes, a subset of the XRDS functionality defined by the XRI Resolution specification would work with both URLs and XRIs. This subset was formalized as the [Yadis] (Miller, J., “Yadis Specification 1.0,” .) specification published by Yadis.org in March 2006, and Yadis subsequently became the service discovery format for OpenID 1.1.

A single discovery service for both URLs and XRIs proved to be so popular that in November 2007 the [XRI Resolution 2.0] (Wachob, G., Reed, D., Chasen, L., Tan, W., and S. Churchill, “Extensible Resource Identifier (XRI) Resolution V2.0,” .) specification formally added the Yadis method for URL-based XRDS discovery (Section 6). The [OpenID Authentication 2.0] (OpenID, O., “OpenID Authentication 2.0,” .) specification released in December 2007 referenced this updated specification. Since other applications and protocols needed only a subset of XRDS functionality, work begin on formally defining this subset as XRDS-Simple.

Appendix C.  Security Considerations

Appendix D.  Acknowledgments

XRDS-Simple is for the most part, an evolution of many existing specifications, most notably [XRI Resolution 2.0] (Wachob, G., Reed, D., Chasen, L., Tan, W., and S. Churchill, “Extensible Resource Identifier (XRI) Resolution V2.0,” .) and [Yadis] (Miller, J., “Yadis Specification 1.0,” .). Much of the text in this specification has been adopted directly from these two specifications in an attempt to provide implementers an accessible reference for resource discovery.

The editor would like to thank the members of the OASIS XRI TC for their dedicated work bringing the XRDS format to its current state, and for accommodating the XRDS-Simple use case within XRDS and the [XRI Resolution 2.0] (Wachob, G., Reed, D., Chasen, L., Tan, W., and S. Churchill, “Extensible Resource Identifier (XRI) Resolution V2.0,” .) specification. In particular, the editor would like to thank Drummond Reed and Gabe Wachob for their active role in the creation of XRDS-Simple, as well as Markus Sabadello and William Tan for their participation.

The editor would like to thank Chris Messina, John Panzer, and David Recordon for their continued support and assistance.

8. References

Author's Address