Generalized solution to OpenID recycling (was RE: The "WordPress" User Problem)

[Martin Atkins]

=drummond.reed wrote:
> 
> As Martin has pointed out, the purpose of the CanonicalID element in XRDS is
> to support reassignable-to-persistent identifier mapping. Although this is a
> native function of XRI resolution (because XRI architecture was explicitly
> designed to address the reassignable-to-persistent synonym mapping problem
> and thus has explicit syntax for reassignable and persistent identifiers),
> there is nothing to prevent CanonicalID mapping from being done with URLs.
> Discussion on this thread so far has only entertained using this mechanism
> to handle reassignable-URL to persistent-XRI mapping, however there's
> nothing to prevent it being used for reassignable-URL to persistent-URL
> mapping, or even reassignable-URL to persistent-URN mapping (as long as the
> URN is resolveable, such as a Handle ID).
> 
> Everything is already in place in XRDS architecture except the Canonical ID
> verification rules. The OASIS XRI TC has already published the
> reassignable-XRI-to-persistent-XRI Canonical ID verification rules in the
> first editor's draft of XRI Resolution 2.0 Working Draft 11 (a more detailed
> explanation of those rules will be in the second editor's draft due out
> tomorrow). Per Martin's suggestion, in the second editor's draft will also
> add the Canonical ID verification rules for
> reassignable-URL-to-persistent-XRI mapping.
> 
> I see no reason we can't add the rules for
> reassignable-URL-to-persistent-URL mapping as well, since it's simply a
> matter of the RP confirming that the persistent identifier is also
> authoritative for the XRDS.

I think that URL-to-URL is more useful in the short term, because 
(unless something's changed since we last talked) you can't currently 
get an i-number without purchasing an i-name.

This does, however, raise a transitional issue: as soon as providers 
start publishing CanonicalID, all of the existing accounts are 
effectively broken because the "primary key" is being changed.[1]

If LiveJournal were to suddenly start publishing in the XRDS for 
http://frank.livejournal.com/ that the CanonicalID were 
http://www.livejournal.com/u/3449 (for example) frank would lose his 
account on any site he had already been using.

For this to work out, RPs would have to change to retaining a list of 
synonyms rather than simply keying off the CanonicalID, but then that 
defeats the object of creating the ability for identifiers to be recycled.

The only solution which springs immediately to mind is to get all of the 
big OP players to implement this and then have the burden be on RPs to 
handle the migration from the old display identifiers to the new 
CanonicalIDs as they transition from 1.1 to 2.0. This only works if 
things are changed in a particular order, though.

I'm attracted to the cleanliness of using the same CanonicalID mechanism 
for both URLs and XRIs and any combination of the pair, but unless the 
above can be resolved I don't think it's workable.

[1] This issue exists for the fragment approach too, but with the 
obvious solution that you simply don't starting appending a fragment 
until an identifier enters its second generation. This solution is not 
appropriate for CanonicalID because it has more broad semantics than 
simply identifying the "generation number" of the identifier.