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.
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? 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. 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. 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 -----Original Message----- From: Johnny Bufu [mailto:[EMAIL PROTECTED] Sent: Sunday, June 03, 2007 6:35 PM To: Recordon, David Cc: Johannes Ernst; OpenID specs list Subject: Re: Specifying identifier recycling On 3-Jun-07, at 1:46 AM, Recordon, David wrote: > I thought at IIW we agreed that if we could come to quick consensus > on a > way to resolve the problem it would be a part of 2.0, otherwise it > would > not... Agreed, nobody wants to delay 2.0 indefinitely if we can't agree on how to solve this issue. But the issue was deemed important enough to be one of the only two on the 2.0 agenda. > As concerns with the fragment proposal have been raised, which had the > most agreement at IIW, it seems we no longer have consensus. I haven't seen many actually; checking this thread for what can count as concerns reveals only: a) Josh's initial email b) Johannes' +1 to not adopting a solution that doesn't actually work c) David acknowledging the concerns This doesn't seem to me to carry enough weight to veto the fragment proposal, especially when a) has been / can still be addressed, and the fragment proposal made sense to a dozen people at that meeting. > As seen in > this thread, there are a wide variety of opinions as to how to resolve > this concern. I thus think merely picking one for the sake of putting > something into 2.0 would be misguided. True, there have been a few (I definitely wouldn't call it a wide variety) possible solutions mentioned, but none very well defined, and none had the support of 10+ people like the fragment did. I have argued that it will have to be core (whether 2.0 or 3.0). I guess we should ask ourselves then if we really want this addressed in 2.0, and if yes then try to make it work. So I ask again - does anyone see any issues with the fragments being used like this: http://openid.net/pipermail/specs/2007-May/001767.html If not, I have a hard time understanding where exactly the consensus was lost. Johnny _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
