Contents

  1. Intro
  2. Status
  3. Background and Motivations
  4. Canonical ID Verification Rules
    1. For HTTP(S) URIs
    2. For XRIs
  5. Status Codes
  6. Reference Processing
  7. Examples
    1. HTTP(S) URI
    2. XRI

Intro

This page contains the proposed rules for CanonicalID verification in XRI Resolution 2.0 ED04. It will replace the definitions and rules currently defined in sections 11 and 12 of ED03.

Status

This page was completely rewritten on 2007-08-22 to reflect extensive discussion on the XRI TC mailing list. This version contains the proposed rules to be incorporated into Editor's Draft 04 (ED04). Note that these are much simpler than earlier versions because asserts of polyarchical (cross-authority) synonyms are no longer in-scope for the XRD CanonicalID element, but will be handled by other XRD elements.

Background and Motivations

XRDS architecture includes the concept of a canonical ID: the identifier that an identifier authority asserts is the canonical identifier used to identify the resource in the scope of that identifier authority. This identifier may be expressed in an XRD using the CanonicalID element.

(Note: in earlier versions of this page, CanonicalID was proposed as being the canonical identifier for the target resource 'across all identifier authorities'. Since this definition was contrary to established practice in XRDs already in use, where the CanonicalID was only canonical in the scope of the identifier authority that assigned it, the TC concluded it would be best to stick with the earlier, tighter definition, and assert cross-authority synonyms using different XRD synonym elements.)

Canonical IDs are useful because they establish a persistent primary key for a resource that, once asserted by an identifier authority, will always be used by that identifier authority to identify the resource. (Note that because persistence is an operational and not a technical characteristic of an identifier, the XRI Resolution 2.0 specification will say that a CanonicalID identifier SHOULD be persistent and, once assigned, SHOULD always appear in any XRD from the parent authority describing the target resource.)

CanonicalIDs are particularly useful for mapping from one or more reassignable identifiers for a resource to a persistent identifier for the resource. Such a capability can prevent long-term security and trust issues associated with reassignable identifiers. A good example is OpenID recycling -- the risk that an OpenID identifier such as a DNS name or a URL may be reassigned from one user to another, thus potentially granting the second user access to the first user's OpenID-enabled account(s).

To take advantage of CanonicalIDs, it is vital from a security standpoint to prevent "CanonicalID spoofing", i.e., identifier authority A asserting in an XRD that identifier A has a CanonicalID B when in fact CanonicalID B is not issued by identify authority A and may not be not an authorized synonym for identifier A.

The process of verifying that the CanonicalID asserted in the XRDS document for an identifier has been issued by the same identifier authority as the initial identifier is called CanonicalID verification.

Canonical ID Verification Rules

The following verification tests MUST be applied by a resolver to each XRD in a resolution chain if the resolution parameter cid=true and MUST NOT be applied if the parameter is absent or has any other value.

For HTTP(S) URIs

For HTTP(S) URIs, CanonicalID verification is supported only for fragments. By definition, an HTTP(S) URI that includes a fragment is a verified CanonicalID synonym for the same HTTP(S) URI without the fragment. This rule follows directly from RFC 3986, which establishes that all fragments MUST be relative to a base URI.

Note that it is not possible to resolve a HTTP(S) URI containing a fragment to obtain a different XRD for the target resource.

For XRIs

  1. The value of the xrd:XRD/xrd:ProviderID element in the XRD from the community root authority MUST match the value expected from the configuration of the resolver for that community root authority.

  2. The value of the xrd:XRD/xrd:ProviderID element in any subsequent XRD MUST match the value of the xrd:XRD/xrd:Service/xrd:ProviderID element in the authority resolution service endpoint of its parent XRD.

  3. The value of each subsegment of the CanonicalID MUST match either the Query identifier or a valid LocalID identifier in each corresponding XRD in the resolution chain.

In other words, the set of all possible XRIs that could be asserted as a CanonicalID synonym for a QXRI can be constructed hierachically from the sets of all valid LocalID synonyms asserted in each leg of the QXRI resolution chain.

Status Codes

  1. If cid=true, for each XRD in the resolution chain, if CanonicalID verification is successful (and there are no other errors in the XRD), the resolver MUST return a status of 100 SUCCESS in that XRD.

  2. If cid=true and CanonicalID verification fails, the resolver MUST return a status of 102 CID_NOT_VERIFIED in that XRD.

  3. If cid=true and no CanonicalID element appears in an XRD, the resolver MUST return a status of 103 CID_NOT_PRESENT in that XRD.

Reference Processing

If cid=true, a resolver MUST always perform CanonicalID verification on each XRD in the resolution chain regardless of whether reference processing is performed or not, i.e., whether refs=true or not and whether sep=true or not. This means cid=true will never affect the final XRD returned by resolution, only the status code returned in that XRD.

Also, if CanonicalID verification fails but resolution (either authority resolution or service endpoint selection) is not complete, the resolver MUST continue. Note that this means that an XRD higher in the resolution chain could fail CanonicalID verification while other XRDs lower in the chain succeed.

Examples

HTTP(S) URI

Example #1: Fragment 

<XRDS>
  <XRD>
    <Status code="100">SUCCESS</Status>
    <CanonicalID>http://example.com/user#1234</CanonicalID>
    <Service priority="1">
       ...
    </Service>
    ...
  </XRD>
</XRDS>

XRI

Example #1: Global I-Name 

<XRDS>
  <XRD>
    <Query>*example.name</Query>
    <Status code="100">SUCCESS</Status>
    <ProviderID>xri://=</ProviderID>
    <CanonicalID>=!f831.62b1.44fd.2855</CanonicalID>
    <Service priority="1">
       ...
    </Service>
    ...
  </XRD>
</XRDS>

Example #2: Community I-Name 

<XRDS>
  <XRD>
    <Query>*example.name</Query>
    <Status code="100">SUCCESS</Status>
    <ProviderID>xri://=</ProviderID>
    <CanonicalID>=!f831.62b1.44fd.2855</CanonicalID>
    <Service>
       <ProviderID>xri://=!f831.62b1.44fd.2855</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>
    ...
  </XRD>
  <XRD>
    <Query>*delegate.name</Query>
    <Status code="100">SUCCESS</Status>
    <ProviderID>xri://=!f831.62b1.44fd.2855</ProviderID>
    <CanonicalID>=!f831.62b1.44fd.2855!1234</CanonicalID>
    <Service priority="1">
       ...
    </Service>
    ...
  </XRD>
</XRDS>

XriCd02/CanonicalIdVerification (last edited 2009-08-12 18:07:18 by localhost)