Redirect & Ref Processing Revision #5

["Drummond Reed" <drummond.reed@cordance.net>]

I just posted Revision #5 of the Redirect & Reference Processing proposal at:

 

            http://wiki.oasis-open.org/xri/XriCd02/RefProcessing

 

This is the version we will go over on tomorrow’s call.

 

There is only one key change in this revision. Based on multiple discussions today around Kermit’s proposal, it changes CanonicalID verification during Ref processing to follow a consistent rule:

 

            CanonicalID verification within any XRDS document follows the chain of XRDs within that XRDS document.

 

In other words, in the Ref Example #1 on http://wiki.oasis-open.org/xri/XriCd02/RefProcessing, the XRDS document for @a*b*c forms one CanonicalID verification chain, and the Ref at @a*b to @x*y forms another. The child *c, being a child of @a*b, is in the CanonicalID verification hierarchy and thus @x*y must return an CanonicalID in the XRD for *c that falls in the @a*b hierarchy.

 

For a while today that looked like a problem because it would prevent, for example, multiple i-names from different authorities all using the same OpenID SEP with the same CanonicalID. However by tonight we realized that this could still be accomplished using a Ref *after authority resolution was complete*, i.e., after the outermost XRDS document is finished. A Ref encountered at that point will open a new nested XRDS document and the final XRD in that document will have the CanonicalID (and SEP) of this nested XRDS document. So any number of i-names from different authorities can fully resolve (to different CanonicalIDs) and then use a Ref to delegate any service to the same XRDS with its own CanonicalID. (Or they can use a Redirect at the Service level to delegate to a different XRDS and *keep* the CanonicalID of the Redirect source).

 

A few other notes regarding Revision #5:

 

1) It keeps the consistent behaviour that:

            a) Both Redirect and Ref may appear at both the XRD and Service levels.

            b) Both Redirect and Ref always result in nested XRDS documents for error reporting and auditing purposes.

 

The latter follows Wil’s proposed rule that, when the Resolution Output Format is application/xrds+xml, “no successfully resolved XRDS document (and XRD it contains) goes unreported by the resolver”. This provides visibility into all errors discovered in the resolution chain.

 

2) I have not added a redirect= resolution parameter as Victor suggested because I’d like to discuss that on tomorrow’s telecon first. The case for controlling Refs with a resolution parameter has long been a strong one, because they can lead to multiple resolution calls. IMHO the case for controlling Redirects is much weaker. They do not begin a new resolution chain, and if you are going to trust the URIs you get in an XRDS from an XRI authority, you’re going to trust the Redirects you get from that XRI authority, because it’s the same XRI authority, just a different location (not a different XRI authority as with a Ref).

 

Another way to put it is that we don’t provide any control over HTTP(S) redirects received by a resolver during resolution. Victor is correct that an XRDS redirect is a different animal, since it is controlled by an XRDS author vs. a network administrator. But since it still represents a response from the same XRI authority, I’m not sure it makes any more sense to provide control over it than it would to provide control over an HTTP(S) redirect.

 

All of these we’ll discuss on the agenda for tomorrow’s telecon, which I’ll send out next.

 

=Drummond