> 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