XRI CanonicalID Verification

From I-names Development Wiki

By Steven Churchill 01/07/07 Last modified: 04/28/08

CanonicalIDs can be used to identify an XRI authority in a manner that is independent of its XRI synonyms. This means that XRI-aware applications can take advantage of CanonicalIDs to support XRI synonyms without the need to explicitly register each synonym with the application. But these applications must be cautious to use CanonicalID Verification in order to ensure that the CanonicalID has not been tampered with.

Local Synonyms:

@ootao is an XRI authority that acts as a namespace containing child authorities such as @ootao*andy, @ootao*brad, and @ootao*steven, each with their own CanonicalIDs. Let's focus on one of these authorities: @ootao*steven. This authority might have a variety of local synonyms (steven, steven.churchill, steveo) but it has just a single CanonicalID. (An XRI authority acting as such a namespace defines an Authority Server which is used by the resolver to map a given local identifier to it's child authority.)

Authority XRI	<Query>	<CanonicalID>	Resolve it!
@ootao*steven	*steven	nnnnnnCA16	Service Selection: OFF
@ootao*steven.churchill	*steven.churchill	nnnnnnCA16	Service Selection: OFF
@ootao*steveo	*steveo	nnnnnnCA16	Service Selection: OFF

Table 1: Child authority has three local synonyms: steven, steven.churchill, and steveo.

Clicking the right-most column will perform XRI Resolution to produce the XRD for the XRI in the first column. The fact that each XRD contains the same <CanonicalID> value (the value ending in CA16) shows that each of the three XRIs are synonyms for the same XRI authority.

In your browser's address bar you can examine the URI that was sent to the XRI Proxy Resolver to produce each given XRD. Note that "sep=false" turns off service selection. Note also that you can change the value of the _xrd_r argument to "application/xrds+xml" in order to see the information for the @ootao authority that ultimately produced the XRD for its child (the one with the CanonicalID ending in CA16.)

Polyarchical Synonyms:

Whereas local synonyms allow multiple local names for an individual child authority within its parent's namespace, polyarchical synonyms occur when one XRI authority uses a Ref to form a polyarchical relationship with another distinct XRI authority. With the strategic use of a Ref, for example, resolving @ootao*steven for its OpenID service will result in the same XRI authority as resolving =steven.churchill for its OpenID service. (The two identifiers are said to be synonyms for the resultant authority with respect to selecting the OpenID service.)

Authority XRI	<CanonicalID>	Resolve it!
@ootao*steven	nnnnnn824	Service Selection: OpenID Service
=steven.churchill	nnnnnn824	Service Selection: OpenID Service

Table 2: Two XRIs are synonymous with respect to selecting the OpenID service

Because @ootao*steven contains a OpenID service Ref to =steven.churchill, the Resolver will return the same authority as when resolving =steven.churchill for the OpenID service. Using this approach, I can have my @ootao*steven authority share the OpenID service used by my global authority =steven.churchill. Now there is only one OpenID account, and one password for both authorities.

Whereas the two XRIs in table 2 are synonymous with respect to selecting the OpenID service, it should be noted that they are not synonymous with respect to selecting other services, such as the Contact service. This is because @ootao*steven's Contact service does not contain a Ref.

Authority XRI	<CanonicalID>	Resolve it!
@ootao*steven	nnnnnnCA16	Service Selection: Contact Service
=steven.churchill	nnnnnn824	Service Selection: Contact Service

Table 3: Two XRIs are not synonymous with respect to selecting the Contact service

---

CanonicalID Verification

XRI-aware applications can use CanonicalIDs, for example, to allow me to authenticate using any of my local or polyarchical synonyms (@ootao*steven, @ootao*steven.churchill, @ootao*steveo, =steven.churchill) -- all without the need to explicitly register each synonym with the application.

I have written an article on the XRI Polyarchy that discusses how an application does this and the importance of the application performing CanonicalID Verification to ensure that the CanonicalID has not been tampered with.

Advisory:

The XRI Resolution 2.0 Specification WD11 introduces CanonicalID Verification to fix the vulnerability (described in detail in the above mentioned article) that was originally identified a few months back by Kevin Turner at JanRain. (See "Final Proposal" at CanonicalID Verification)

HOWEVER, CID verification is currently not implemented by the XRI proxy resolver at xri.net. [Note 04/08: It is now implemented in beta.xri.net!] In the interim, OpenID relying parties (and other XRI-aware applications) that use CanonicalIDs as primary keys may indeed be vulnerable.

The workaround that we use at ooTao for our OpenID RPs is to perform CID verification "by hand" (rather than having it done in by the XRI Resolver.) To do this, the CID obtained by the initial (RP client library) resolution call must again be independently resolved (yes, the CID itself is passed back to the proxy resolver.) The CID resulting from that second resolution step is safe from the attack described in the article. [Note 04/08: If you use beta.xri.net, then you do not need this workaround.]