RE: Generalized solution to OpenID recycling (was RE: The "WordPress"User Problem)
>> =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. XDI.org is planning to change that policy. Also, effective June 1, the wholesale annual price of personal i-names is USD $5, and personal i-numbers is USD $1. >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 agree that migration of RPs is necessary (it seems necessary for any solution to the OpenID recycling issue), but is order really a problem? Isn't it just the following sequence of migration steps: 1) RP today uses only Table #1 of reassignable OpenID identifiers (and so is vulnerable to OpenID recycling issue). 2) When RP upgrades to OpenID libraries supporting mapping to Canonical IDs, RP creates Table #2 (Canonical ID table) to go alongside current Table #1 (reassignable OpenID identifier table). 3) Until an RP discovers a Canonical ID for an OpenID user, RP continues to use Table #1. 4) As RP discovers Canonical ID value for an OpenID user, RP starts populating Table #2, now protecting each user in Table #2 from OpenID recycling problem. The result would be a smooth migration of the RP from supporting only reassignable OpenIDs to supporting Canonical IDs. Note that this two-table approach is documented on the dev.inames.net site at: http://dev.inames.net/wiki/Tech_FAQs#What_are_the_recommended_modifications_ OpenID_Relying_Parties_.28RPs.29_should_make_to_their_user_tables.3F >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. Agreed. But I'm with you that these broader semantics are well worth it because, as pointed out earlier, the fragment approach only works in the limited set of cases where you can trust the identifier authority issuing the fragment never to reassign it. The Canonical ID mapping approach works for all combinations of persistent and reassignable identi
Re: Generalized solution to OpenID recycling (was RE: The "WordPress" User Problem)
Hi Drummond, On 5-Jun-07, at 9:44 AM, =drummond.reed wrote: > 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. Not knowing how you plan to have the canonical ID verification for URLs (really looking forward to reading tomorrow's draft), I'm not sure it's a simpler approach or even a generalization of the fragment proposal. Yes, it would be simpler to specify in the OpenID spec, but it would include a pointer to a section of the XRI spec, which scares so many people away. From your comments I understand that the persistent identifier has to be discoverable; in the fragment approach, the fragment itself (which is the actual persistent part) is stripped out at discovery time, and only comes into play at the auth response / verification stages (hence not sure the generalization applies). Keying your identity on a new / different URL also brings in the management effort required to maintain that second, persistent URL (and making sure it stays persistent). If that is an absolute URL, the cost is considerably higher than just keeping track of your persistent fragment. (In this respect the fragment approach is simpler.) Johnny ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Generalized solution to OpenID recycling (was RE: The "WordPress" User Problem)
=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. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
