[OpenID] OpenId recycling and trust

tom tom at barnraiser.org
Mon Oct 1 08:12:51 UTC 2007


Hi Mark et all,

We thought along the same lines (actually we started passing the account 
create datetime at discovery), however Peters input led us to believe 
the that best approach to solving "trust" once and for all is to work on 
key-pairs.

If you have a private key held in your OP account and a public key 
available I (the consumer) can just store the public key and compare 
that at discovery. For the OpenID community this has the added value for 
encrypted messaging and so forth.

I was very optimistic to discover that this is already addressed in 
http://openid.net/specs/openid-service-key-discovery-1_0-01.html
however I now rely on two things:

1. The OpenID community reaching general consensus on "key-pairs is 
approach we take to tackling the trust problem".
2. The OPenID community rallies around implementing XRDS with public key 
included.

Today just to take a random OP poll we have no key support and random 
XRDS support......

    * ClaimID.com - XRDS supported; no public key.
    * myopenid.com - No XRDS
    * verisign - XRDS supported; no public key.


So what's next? There is no point in me implementing public key 
discovery if no OP is implementing support and there is no point in my 
going after that goal if the community takes another direction with "trust".

Any comment? .... input from OP's would be very beneficial here;)

Tom







Mark Fowler wrote:
> On 30 Sep 2007, at 08:32, tom calthrop wrote:
>
>> 1. I'd like to have a solution at the consumer which is easy for us to 
>>
>> implement and does not require explanation to the user.
>>
>
> I've got a little preposal;  Allow the standard to indicate recycling 
> has occured.
>
> <teach who="grandma" what="to suck eggs">
> From an OpenID consumer's point of view OpenID is a standard that lets 
> you verify that a partiular person using a webbrowser is associated 
> with a paricular URL.  This is very much like sending a email with a 
> secret to an email address can be used to verify that someone owns an 
> address.  If I get control of an OpenID, much the same way that if I 
> get control of an email address, as far as most services out there are 
> concerned I *am* that person and I have all the rights associated with 
> them.  This is the inherent weakness in OpenID (and email) 
> verification, but is the thing that makes it scalable and, well, open.
> </teach>
>
> So we have is the situation where if a domain is taken over then the 
> person who now runs the domain can assume all the identities of the 
> OpenID URLs under that domain.  There's very little we can do about 
> that.  But what about the situation where a domain isn't taken over?  
> What if there's a situation where a OpenID URL itself is taken over 
> but the domain remains in the original controller's hands (e.g. when 
> someone signs up for an account using a recycled username?)
>
> In this situation we've potentially got someone like AOL or some other 
> trusted party still running the domain (and presumably, controlling 
> what goes on the pages.)  Wouldn't it be nice to provide them with 
> some way of indicating that the person who is now associating with 
> this OpenID URL is not the same person who originally associated with 
> this URL? 
>
> This could be as simple as adding another tag into the HTML for the 
> OpenID to indicate when they signed up
>
> <link 
> rel="openid.server" href="http://www.livejournal.com/openid/server.bml">
> <link rel="openid.delegate"  href="http://2shortplanks.livejournal.com/">
> <link rel="openid.timestamp" 
> href="http://www.openid.net/timestamps/1191140090">
>
> So, this means that when a consumer first associates someone with an 
> OpenID URL they can also (optionally) record the timestamp (if 
> present.)  As long as the OpenID URL contains the same timestamp the 
> consumer knows that the account hasn't been recycled and it can 
> continue to trust the OpenID URL.  But as soon as that timestamp 
> changes, they know that the OpenID is no longer under the control of 
> the original user and they can stop trusting it.
>
> Of course, this proposal doesn't do anything about the fact that 
> OpenIDs are also used as unique identifiers for people (e.g. Jyte.)  
> If someone makes an assertion against someone who controls an openid 
> and the person controlling that openid changes then the assertion is 
> now being made about the wrong person.  This sucks, but the only 
> solution I can see to this is saying "OpenIDs are never, ever, going 
> to be reused" which while a wonderful idea, probably isn't going to 
> happen.  At least my suggestion doesn't make this any worse.
>
> Comments?  Suggestions?  Warnocking?
>
> Mark.
> ------------------------------------------------------------------------
>
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
>   


-- 
Tom Calthrop
Founder, Barnraiser.

Dedicated to giving people the tools they need to share 
knowledge and advance society through social software.

Web site: http://www.barnraiser.org/
OpenID: http://tom.barnraiser.info/




More information about the general mailing list