The CanonicalID Approach

[Drummond Reed]

>> On 6/8/07, Martin Atkins <mart at degeneration.co.uk> wrote:
>> I figure that you could potentially use the same mechanism as delegation
>> to avoid the extra discovery iteration.
>>
>> The problem, as with delegation, is that you need to duplicate the
>> endpoint URL in the source identifier's XRDS document. The canonical
>> identifier must also support OpenID, which I believe is something they
>> were trying to avoid.
>
>Josh Hoyt wrote:
>
>I'm assuming that by saying it's "like delegation", you mean that the
>canonical identifier is discovered from the entered identifier, and
>sent to the server, but discovery is never done.
>
>Let's say that you use "http://mart-atkins.com/" as your identifier,
>with a canonical id of "http://inconvenient.example.com/0000001"
>
>I can set up a URL "http://impersonation.example.com/mart" that points
>to an OpenID provider that I control, and give it the same canonical
>ID, "http://inconvenient.example.com/0000001".
>
>Unless we make sure that the canonical ID is intended to be used with
>this OpenID server, I can sign in to your account anywhere, since the
>canonical ID is used as the database key.
>
>Were you thinking of a different mechanism?

Good example of why you need Canonical ID verification, thus why the XRI TC
is adding that function to XRI Resolution. However for some
reassignable/persistent identifier pairs there is an optimization that
eliminates the need for an extra round trip. The principle is identical to
OpenID realm authorization
(http://openid.net/specs/openid-authentication-2_0-11.html#realms), which is
simply if the client can verify that the same provider is authoritative for
both the reassignable and persistent identifier, then an extra round-trip
for discovery is not required.

A good example is fragments. To use Johnny's example:

http://openid.aol.com/daveman692 - reassignable
http://openid.aol.com/daveman692#1234 - persistent

If an XRDS for the reassignable identifier asserts the persistent identifier
as a Canonical ID, a second round trip is not required because the client
can verify that http://openid.aol.com/ is authoritative for both daveman692
and daveman692#1234. 

XRI architecture simply generalizes this approach to any level of
delegation. XRI authorities at any level can assert both reassignable
i-names and persistent i-numbers that are also distinguished syntactically
(i-numbers -- all begin with !).

So for example, following is is one of my i-names and my i-number:

=drummond				- reassignable i-name
=!F83.62B1.44F.2813		- persistent i-number

An XRDS discovered from resolving "=drummond" asserts my i-number as my
Canonical ID, and an XRI resolver can verify that = is authoritative for
both "drummond" and "!F83.62B1.44F.2813" without doing an extra round trip.
Thus they are "verified synonyms". 

This works for my delegates as well. For example:

=drummond*gardner			- reassignable i-name
=!F83.62B1.44F.2813!4		- persistent i-number

In the first iteration of XRI resolution, an XRI resolver verifies that
=drummond and =!F83.62B1.44F.2813 are synonyms as above. In the second
interation, it verifies that =drummond*gardner and =!F83.62B1.44F.2813!4 are
synonyms. In neither case is an extra round trip needed.

This optimization does not work for either URLs or XRIs when the
reassignable and persistent identifiers come from different authorities. In
other words, both of the following pairs of identifiers...

http:// http://www.davidrecordon.com - reassignable
http://openid.aol.com/daveman692#1234 - persistent

@cordance*drummond		- reassignable i-name
=!F83.62B1.44F.2813!4		- persistent i-number

...would require an extra roundtrip at least the first time this identifier
pair needs to be verified as synonyms (there are optimizations for
subsequent verifications).

=Drummond