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

2007-06-05 Thread =drummond.reed

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


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

2007-06-05 Thread 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.


___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


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

2007-06-05 Thread Johnny Bufu
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