There is a huge difference between the OP/RP shared secret and using a shared secret as an identifier.
The secret between the OP and RP has a mechanism for it to be recycled. If it happens to be lost, then the pair can set up a new secret. If the user's secret is lost, then that identifier and any accounts that it was used for are lost. -- Dick On 31-May-07, at 7:30 AM, Johannes Ernst wrote: > 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
