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  

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 -- 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 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-----
>> 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 mailing list

specs mailing list

Reply via email to