David, just want to reinforce that the CanonicalID element in XRDS has always been defined as containing anyURI, so it's been there to support mapping of any reassignable identifier to any persistent identifier (or, technically, any canonical identifier, even if not persistent, though persistence is the main use case for it).
I'm happy to help with the writeup -- I've already spent a not-insignificant portion of my lifespan dealing with this issue ;-) =Drummond -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Recordon, David Sent: Tuesday, June 05, 2007 3:50 PM To: Johnny Bufu Cc: OpenID specs list Subject: RE: The "WordPress" User Problem (WAS: RE: Specifying identifierrecycling) At that point I'd be concerned as to solving the "big OP issue" while not solving the "lost domain issue" when some of the proposals could possible solve both. This largely focuses around using an XRI-style canonical id, whether that be an i-number or just another "ugly" URL which points back at the pretty one. I know I need to write this up more... --David -----Original Message----- From: Johnny Bufu [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 05, 2007 3:18 PM To: Recordon, David Cc: Josh Hoyt; Johannes Ernst; OpenID specs list Subject: Re: The "WordPress" User Problem (WAS: RE: Specifying identifier recycling) On 5-Jun-07, at 11:58 AM, Josh Hoyt wrote: > The relying parties SHOULD make the fragment available to software > agents, at least, so that it's possible to compare identifiers across > sites. If the fragment is never available, then there is confusion > about which user of an identifier is responsible for content that has > been posted. One use case where software agents having access to the > fragment is particularly important is if the identifier is used for > access control, and the access control list is retrieved from off-site > (e.g. from a social networking site). > > The implementation that seems most sane is for places that display the > identifier for human reading look like: > > <a href="http://josh.example.com/#this-is-intended-for-machine- > consumption" > >http://josh.example.com/</a> > > so that the software agent would see the fragment, but the user > wouldn't have to. On 5-Jun-07, at 2:55 PM, Recordon, David wrote: > I thought the fragment was to be secret so that for the case of using > a personal domain you don't have to own joshhoyt.com forever. Rather > as long as your fragments are secret, someone else can buy > joshhoyt.com and not be you. If this is no longer a requirement then > it certainly changes the game, though also doesn't solve one of the > other aspects of identifier recycling. I thought so too, but I believe Josh is right - the "lost domain" cell with an X in it (for URL + public fragment) supports Josh's statement: http://openid.net/wiki/index.php/IIW2007a/Identifier_Recycling So if we're not dealing with this use case, it becomes actually simpler to address just the identifier recycling for big OPs, where loosing the domain is not an issue. Johnny _______________________________________________ specs mailing list firstname.lastname@example.org http://openid.net/mailman/listinfo/specs _______________________________________________ specs mailing list email@example.com http://openid.net/mailman/listinfo/specs