RE: The "WordPress" User Problem (WAS: RE: Specifying identifierrecycling)
Yes, I think this would be worthwhile to write-up. --David -Original Message- From: =drummond.reed [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 05, 2007 4:55 PM To: Recordon, David; 'Johnny Bufu' Cc: 'OpenID specs list' Subject: RE: The "WordPress" User Problem (WAS: RE: Specifying identifierrecycling) 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: > > http://josh.example.com/#this-is-intended-for-machine- > consumption" > >http://josh.example.com/ > > 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 specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: The "WordPress" User Problem (WAS: RE: Specifying identifierrecycling)
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: > > http://josh.example.com/#this-is-intended-for-machine- > consumption" > >http://josh.example.com/ > > 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 specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: The "WordPress" User Problem (WAS: RE: Specifying identifierrecycling)
On 6/5/07, Drummond Reed <[EMAIL PROTECTED]> wrote: > I supposed this doesn't apply to large sites, where all identifiers are > managed "in trust" for users and they can enforce non-access to previous > fragments. But for personal URLs it doesn't appear to work at all. Am I > missing anything? Enabling recycling for large sites that control their own identifiers was the use case that was declared mandatory to cover for the OpenID 2.0 specification. I would personally like to have a solution that protects identifiers without a central manager, but that is not the case that is holding up OpenID 2.0. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: The "WordPress" User Problem (WAS: RE: Specifying identifierrecycling)
>Josh Hoyt wrote: > >The fragment is not secret. It is not "protecting" your OpenID. You >should be able to get the fragment from any relying party that you >visited. You might choose to use a fragment if you have acquired a >recycled identifier, but you can choose the fragment. It protects >*nothing* if you control the base identifier (to the point that you >can choose an OpenID provider). Isn't this a core flaw with the fragment approach? That if you lose control of the base identifier, you lose control of any fragment? Wouldn't it be fairly easy -- precisely because the fragment is not secret -- for the party that takes over the base identifer to discover the fragment(s) that have been used earlier, and thus for the new owner to then be able to spoof any fragment that has been issued? I supposed this doesn't apply to large sites, where all identifiers are managed "in trust" for users and they can enforce non-access to previous fragments. But for personal URLs it doesn't appear to work at all. Am I missing anything? =Drummond ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs