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...
As concerns with the fragment proposal have been raised, which had the most agreement at IIW, it seems we no longer have consensus. 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. --David -----Original Message----- From: Johnny Bufu [mailto:[EMAIL PROTECTED] Sent: Saturday, June 02, 2007 10:12 PM To: Recordon, David Cc: Johannes Ernst; OpenID specs list Subject: Re: Specifying identifier recycling On 2-Jun-07, at 5:14 PM, Recordon, David wrote: > I'd like to see this written as an > extension so that if the first approach doesn't work, the Auth spec > itself doesn't have to be "reverted. Rather we can finish 2.0 and try > implementing different approaches before deciding on the final way to > solve this problem. I thought we had agreed at IIW (for good reason) to address this in 2.0. Other than the actual solution not being 100% clear, has anything changed? Arguments for not putting it into an extension: - users of provider's X who employs 'identifier recycling extension' would not be able to log into RP Y who doesn't understand the extension - it's likely that whatever solution we come up with affects the discovery / verification processes, in which case it couldn't be pushed to an extension (we're trying to patch something about the _identifier_ itself, which is the center of each openid transaction). Also, I believe the fragment approach can actually work, as detailed here: http://openid.net/pipermail/specs/2007-May/001767.html I haven't seen any replies to this, so would appreciate if others would go through the proposed changes and see if they all makes sense of I've overlooked something. Thanks, Johnny _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
