RE: The "WordPress" User Problem (WAS: RE: Specifying identifier recycling)
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
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
RE: The "WordPress" User Problem (WAS: RE: Specifying identifier recycling)
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. --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Josh Hoyt Sent: Tuesday, June 05, 2007 11:58 AM To: Johnny Bufu Cc: Recordon, David; Johannes Ernst; OpenID specs list Subject: Re: The "WordPress" User Problem (WAS: RE: Specifying identifier recycling) On 6/5/07, Johnny Bufu <[EMAIL PROTECTED]> 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. > > I believe David's point is that you cannot retrieve the fragment from > the RP if you have lost it and are no longer able to log into any RPs. > (Unless there's an account recovery mechanism either on the RP or the > OP.) The RPs know it, but are not supposed to display / disclose it. 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. Using this approach, the fragment is trivially available anywhere you signed in. There is also no reason that a relying party should hide the fragment if a user asks for it. Since it is not sensitive information, it does not require "account recovery." Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: The "WordPress" User Problem (WAS: RE: Specifying identifier recycling)
On 6/5/07, Johnny Bufu <[EMAIL PROTECTED]> 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. > > I believe David's point is that you cannot retrieve the fragment from > the RP if you have lost it and are no longer able to log into any > RPs. (Unless there's an account recovery mechanism either on the RP > or the OP.) The RPs know it, but are not supposed to display / > disclose it. 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. Using this approach, the fragment is trivially available anywhere you signed in. There is also no reason that a relying party should hide the fragment if a user asks for it. Since it is not sensitive information, it does not require "account recovery." Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: The "WordPress" User Problem (WAS: RE: Specifying identifier recycling)
On 5-Jun-07, at 11:12 AM, Josh Hoyt wrote: > On 6/5/07, Recordon, David <[EMAIL PROTECTED]> wrote: >> Imagine if I install WordPress (or insert other app here) on >> https://davidrecordon.com and check the "Use fragments to protect my >> OpenID" box. A few months later I decide to remove WordPress, or an >> upgrade blows away my OpenID extension data, or I'm using an >> extension >> which stores the fragments in /tmp/ and they get blown away. I >> now no >> longer have access to my accounts on all the relying parties I've >> visited. Now what do I do? > > 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. I believe David's point is that you cannot retrieve the fragment from the RP if you have lost it and are no longer able to log into any RPs. (Unless there's an account recovery mechanism either on the RP or the OP.) The RPs know it, but are not supposed to display / disclose it. > 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). Agreed - if you loose control over the URL, you can no longer use your old online identity. However, the issue / feature this does address is "protect your RP accounts if you loose your identity". (The new owner of davidrecordon.com would not be able to sign into the old davidrecordon.com's digg account.) Johnny ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: The "WordPress" User Problem (WAS: RE: Specifying identifier recycling)
On 6/5/07, Recordon, David <[EMAIL PROTECTED]> wrote: > Imagine if I install WordPress (or insert other app here) on > https://davidrecordon.com and check the "Use fragments to protect my > OpenID" box. A few months later I decide to remove WordPress, or an > upgrade blows away my OpenID extension data, or I'm using an extension > which stores the fragments in /tmp/ and they get blown away. I now no > longer have access to my accounts on all the relying parties I've > visited. Now what do I do? 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). I'm not arguing for or against a particular approach here, but I think your argument is flawed. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: The "WordPress" User Problem (WAS: RE: Specifying identifier recycling)
On 5-Jun-07, at 8:00 AM, Recordon, David wrote: > I think the largest concern I have with fragments, or really any > pair-wise shared secret which can't be renegotiated, is that while it > solves issues for the large service providers it actually inhibits > OpenID within the grassroots community. This concern is definitely something new; I haven't seen it expressed before. > Imagine if I install WordPress (or insert other app here) on > https://davidrecordon.com and check the "Use fragments to protect my > OpenID" box. A few months later I decide to remove WordPress, or an > upgrade blows away my OpenID extension data, or I'm using an extension > which stores the fragments in /tmp/ and they get blown away. I now no > longer have access to my accounts on all the relying parties I've > visited. Now what do I do? What do you do today, if you forget your slashdot password and slashdot didn't implement account recovery? Most (if not all) RPs today do implement account recovery - they don't want to loose users, and they know users make mistakes and forget passwords. > We can't count on each RP implementing an account recovery mechanism; > remember OpenID outsources account management so you can focus on > building you application. I can't call up my service provider and ask > them to fix it, since well I was using my own provider. You should call up your OP then. > I could try to > call up my webhost and see if they can restore from a backup, but I'd > guess by the time I realize what that check box in my WordPress > extension settings did there may not even be backups anymore. In the > end, I'd be extremely frustrated that OpenID didn't work for me > and I'd > write a really obnoxious blog post about how much OpenID sucks. > > So while we solve one aspect of the recycling problem, we end up > creating a larger problem from the opposite side of the equation. I'm > certainly not arguing that we shouldn't solve this problem, nor that > participation from large providers isn't vital, but would hate to > see us > create a problem for all of the people out there that have really > helped > gain OpenID traction. > > 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. I believe it could work with REQUIREments in the core for RPs (discovery, verification), and OPTIONAL / extension for the OPs. Though the gained simplicity I think would be minimal. But if the other advantage is that OPs don't carelessly implement this feature without knowing what they are doing, then it may be better overall. Totally agree with the warnings / raising awareness that identifier recycling is an advanced feature. I believe this is part of a more general problem: by being decentralized, OpenID gives power to everyone (anyone can be an OP); while being an RP is / should be simple, doing the OP job right is not. > 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 "" to do this and setup an easy way to create > identifier equality. > I think my preference is #3, though I'm sure it has its own issues. Do you have a more detailed proposal on how this would work? I do see a couple important / possibly show-stopper issues here, but I haven't really explored this direction for a solution. If you have, I would definitely be interested to learn more. However, I still believe #1 is our best bet, if we can focus our efforts to make it work in such a way to address your grassroots adoption concerns. #1 did have (and still has, I hope) the support of a good many people, and has a concrete and detailed proposal. If we agree that _some_ changes to the core are required, then #1 has also the time advantage. > 4) W
