[OpenID] query regarding OP migration

[SitG Admin]

>Babu> Could you please elaborate more on the harsh criticisms we 
>face ? Do we have any link where we can see why "centralization" was 
>not preferred ?

There was a link posted to this list recently:
<http://idcorner.org/2007/08/22/the-problems-with-openid/>http://idcorner.org/2007/08/22/the-problems-with-openid/
Only four days ago, in fact :)

Read the "Privacy" section. Then, for good measure:
http://www.techcrunch.com/2007/02/20
	/kevin-rose-at-fowa-digg-adopts-openid/
(I've split the URL onto two lines to prevent it being wrapped.)

Honorable mention goes to "mathew" for comment #34.

>Babu> There is not going to be any cache in RPs.

But according to the specs (since v1.0, even!), there *is*.

Actually, the term used is "MAY", but developers are warned against 
using this "stateless" mode because it may (that word again) be 
vulnerable to replay attacks. There are other reasons, but you can 
read them yourself at the URL's I'll provide in a moment.

First, it's important to note that, if RP's *did* cache the OP 
address from a user's claimed URI, an attacker could compromise the 
OP, tell the RP "this NEVER expires", and log in as that user 
indefinitely. I haven't been able to read the specs well enough to 
figure out exactly where or how this is addressed, but I've been 
reading from lots of other sources too, and I generally gather that a 
user can tell the RP to re-check their claimed Identity, manually. 
The only thing that still bothers me is what happens when the user 
isn't *aware* that anyone else is logging in with their Identity to a 
RP; for comments posted to public (and indexed by search engines) 
sites this can work out, but what about a bank that accepted the 
user's personal details as provided by the OP?

http://wiki.openid.net/Stateless_Mode
http://openid.net/developers/specs/

>Whenever user logs in, an RP should contact the "central digital 
>identity" server to find out the OP serving this digital ID & then 
>only redirect the user to appropriate OP for the authentication.

Sounds like you're inserting an extra layer of centralization. As the 
process currently stands, an RP contacts the user's claimed URI to 
find out the OP serving that user's digital ID, and then redirects 
the user to that OP for the authentication, sending them there with a 
few extra pieces of information to get things started.

>The central database is always going to say who my current OP is.

If you keep the central database updated, that is. How is this update 
going to take place? Will it run a check every so often at your URI 
to see if anything has changed? Why not just look at that URI and 
leave it at that?

If we're going to try adding more security to our personal info, why 
not keep all these details at the user's URI? Just add an extra line 
in the headers containing the URL of an XML file (probably also at 
the user's site) that, in turn, contains *encrypted* information. The 
cipher, unique for each item, is a full bitmask that your OP holds, 
and can send to RP's when you okay this to happen. The unencrypted 
information is with you (possibly on a computer not connected to the 
internet), and you can make up new keys when you switch to a new OP.

Sure, the OP can request this XML file themselves, and use the keys 
you provided them with to gain all this information, but when you 
switch to a new OP and use new keys, the old OP's data is at risk of 
becoming dated (though probably not with eye or hair color). Yes, the 
length of an encrypted stream can provide clues as to its content, 
but you can easily pad it with other characters that decrypt to null 
or to blank spaces. And anyone eavesdropping on the communications 
between these nodes will be able to lift the keys, but only if those 
are transmitted without some encryption of their own. (I'm supportive 
of this whether COPPA applies to the user or not.)

-Shade
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20080531/e38a7cbf/attachment-0002.htm>