<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
--></style><title>Re: [OpenID] query regarding OP
migration</title></head><body>
<div>>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 ?<br>
</div>
<div>There was a link posted to this list recently:</div>
<div><a
href="http://idcorner.org/2007/08/22/the-problems-with-openid/"
>http://idcorner.org/2007/08/22/the-problems-with-openid/</a></div>
<div>Only four days ago, in fact :)</div>
<div><br></div>
<div>Read the "Privacy" section. Then, for good
measure:</div>
<div>http://www.techcrunch.com/2007/02/20</div>
<div><x-tab>
</x-tab>/kevin-rose-at-fowa-digg-adopts-openid/</div>
<div>(I've split the URL onto two lines to prevent it being
wrapped.)</div>
<div><br></div>
<div>Honorable mention goes to "mathew" for comment
#34.</div>
<div><br></div>
<div>>Babu> There is not going to be any cache in RPs.</div>
<div><br></div>
<div>But according to the specs (since v1.0, even!), there *is*.</div>
<div><br></div>
<div>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.</div>
<div><br></div>
<div>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?</div>
<div><br></div>
<div>http://wiki.openid.net/Stateless_Mode</div>
<div>http://openid.net/developers/specs/</div>
<div><br></div>
<div>>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.</div>
<div><br></div>
<div>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.</div>
<div><br></div>
<div>>The central database is always going to say who my current OP
is.</div>
<div><br></div>
<div>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?</div>
<div><br></div>
<div>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.</div>
<div><br></div>
<div>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.)</div>
<div><br></div>
<div>-Shade</div>
</body>
</html>