Re: Specifying identifier recycling
I wasn't in that session (as far as I recall ;-)) so I don't know either what was agreed on, or who agreed, or for what reasons ... the thread so far does not look like it was a very stable agreement ;-) On Jun 2, 2007, at 22:11, Johnny Bufu wrote: > > 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
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
RE: Specifying identifier recycling
> Overall, I'm not sure we are ready in this community to pick one > alternative over another as "the standards". I have my views, > (many) others have (many) others -- and I don't think that any > of this has to be in an Authentication 1.x (x>1) or 2.0 spec, > whatever it will be. This seems like a clean add-on. I also agree with Johannes here. 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. SREG shows how 1.1 can be extended, 2.0 clarifies this mechanism and makes it more robust, let's take advantage of it especially given that not all providers require this feature (whether via fragments or public keys). --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Johannes Ernst Sent: Wednesday, May 30, 2007 10:30 PM To: OpenID specs list Subject: Re: Specifying identifier recycling If we cannot assume that nobody manages to obtain a secret they should not have gotten in the first place, then OpenID as it stands is rather useless as we cannot trust its authentication scheme. Note that the surface through which the D-H shared secret can escape is about twice as large as the surface through which a private key can escape -- because an RP does not have access to the private key. In other words, if I was an attacker, I'd go after a lot of things first before I'd try to obtain a private key. Note also that public keys would make rather good i-numbers -- for those who would like to, they can ignore that they are public keys and do i-number-based verification only, because they are simply numbers. For those who don't care about i-numbers, they use their public key aspects. Win-win, perhaps? There is also the case -- which Stefan Brands would undoubtedly bring up if he was on this list -- that the IdP may be hostile, or may become hostile. (think of, say, a large OpenID provider going out of business, and being bought out by spammer.com -- or just the domain name whose registration lapsed) A scheme that is public key based is inherently more resilient towards this than one that is not. You certainly don't want to trust spammer.com to honor whatever conventions the previous owner of the domain put in place to disambiguate their users. -- Overall, I'm not sure we are ready in this community to pick one alternative over another as "the standards". I have my views, (many) others have (many) others -- and I don't think that any of this has to be in an Authentication 1.x (x>1) or 2.0 spec, whatever it will be. This seems like a clean add-on. On May 30, 2007, at 22:01, Drummond Reed wrote: > Johannes: > > What about the point Dick posted earlier in this thread, that the > problem > with using a public key is if the private key gets compromised? > Persistent > identifiers need to persist independent of any attribute changing > or being > revoked. > > =Drummond > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf > Of Johannes Ernst > Sent: Wednesday, May 30, 2007 9:54 PM > To: OpenID specs list > Subject: Re: Specifying identifier recycling > > > On May 30, 2007, at 21:02, Johnny Bufu wrote: > >> ...The bottom line is >> that it can't be done easily - a mechanism similar to XRI's canonical >> ID verification would have to be employed, to confirm that the i- >> number actually 'belongs' to the URL on which discovery was >> initiated. (Otherwise anyone could put any i-number in their URL- >> based XRDS files.) > > Public keys ... public keys ... with the added benefit that no > centralized or trusted verification service needs to be employed > whatsoever ... > > > > > Johannes Ernst > NetMesh Inc. > > > > ___ > specs mailing list > specs@openid.net > http://openid.net/mailman/listinfo/specs ___ 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: Specifying identifier recycling
Would have to agree with what Johannes has said. :) --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Johannes Ernst Sent: Wednesday, May 30, 2007 1:53 PM To: Josh Hoyt Cc: OpenID specs list Subject: Re: Specifying identifier recycling On May 30, 2007, at 13:28, Josh Hoyt wrote: > After thinking this over for a while, I'm no longer convinced that > using URI fragments as the uniquifying value is the right approach. I agree with you. Our reasons may differ slightly, but the result is the same. I have no problem in not solving this problem this time around. I would have a problem with adding a solution to the spec that turns out to not be a solution after all. ;-) Cheers, Johannes. Johannes Ernst NetMesh Inc. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Specifying identifier recycling
Nat Sakimura schrieb: > 1) Storing many users' private key on the server in decryptable format is > not very safe. > > In your proposal, it looks like that OP is going to hold the private key for > each user in decryptable format. Considering that most large scale privacy > leakage happens at the server side, I have got a feeling that such thing > like private key in a shared location. If you can't trust your OP to keep your secrets secret, there's nothing you can do about that. Of course, you would not use a key that's valid as a key for anything else than OpenID. It's also possible that the OP does not know the private key by using two key pairs: . pers_secret, pers_public (the identity) . temp_secret, temp_public The OpenID Povider only has the following: . pers_public . temp_secret, temp_public . cert = sign(temp_public, with_key=pers_secret) The _real_ private key, pers_secret, is kept by the user. If the server is compromised (or becomes rouge, trying to steal the identity), the user can still take his identity elsewhere by signing the tmp2_public key of another server. Claus ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
