>David Recordon wrote: > <snip of explanation of problems with fragment solution to OpenID recycling> > >I don't want to say that I have the answers here, since I don't think I >do. I do however see the following possible solutions: > >1) The core specification only talks about fragments in relation to >Relying Parties, to the extent that they should be stripped from display >though used as a unique key. We do however need to address how a RP >should handle display and account management differences when a fragment >changes. I'm guessing it is unreasonable to expect every instance of >https://davidrecordon.com to be replaced with >https://davidrecordon.com/#231hwqai21jb when the fragment changes (not >to mention that the fragment *must* remain private between the OP and RP >to be effective). An extension is then written describing fragment >usage from the OP perspective with huge warnings about how it should >only be used by large service providers who know what they're doing. > >2) We use a centralized "canonical id" approach like i-numbers. >Basically somebody issues unique and never reassigned ids. > >3) We use a distributed "canonical id" approach. Providers issue an >ugly non-reassignable URL which points at the pretty one and vice-versa. >Thus https://davidrecordon.com says its canonical is >https://12jbd9210.pip.verisignlabs.com which in turn says it is >https://davidrecordon.com. We could even kill two birds with one stone >and use "<link rel='me' />" to do this and setup an easy way to create >identifier equality. > >4) We use public/private key pairs, though this has the traditional >private key revocation issues. > >I think my preference is #3, though I'm sure it has its own issues.
David, first I just want to point out that XRI i-numbers are no more "centralized" than DNS, so I don't think there's any difference between #2 and #3 other than #2 uses XRI registries and #3 uses DNS registries. Second, I agree with you that the better architectural approach to the OpenID recycling problem is to provide a standard reassignable-to-persistent synonym mapping capability that will work for both URLs and XRIs (and even URNs). This solves the problem by allowing *any* reassignable identifier (either a URL, or an XRI i-name) to be mapped to *any* persistent identifier (either a persistent URL, an XRI i-number, or even a resolvable URN). The fragment solution is in fact just a special case of this architecture, i.e., it maps a URL-without-a-fragment (reassignable) to the-same-URL-with-a-fragment (persistent). It does have some special issues due to the use of URL fragments vs. other components of a URI, but otherwise it is just one option that could be implemented to map a reassignable to a persistent identifier. 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. If we approached it this way, all the OpenID Authentication 2.0 spec would need to do is specify the use of Canonical ID verification as part of the OpenID discovery process, and then everyone -- users, OPs, and RPs, would be able to use any reassignable-OpenID-identifier-to-persistent-OpenID-identifier mapping process that worked best for them. Thoughts? =Drummond _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
