Specifying identifier recycling

[Recordon, David]

> 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: specs-bounces at openid.net [mailto:specs-bounces at openid.net] 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: specs-bounces at openid.net [mailto:specs-bounces at openid.net] 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 at openid.net
> http://openid.net/mailman/listinfo/specs

_______________________________________________
specs mailing list
specs at openid.net
http://openid.net/mailman/listinfo/specs