Hi Shape,<br><br>Please see inline..<br><br><br><div class="gmail_quote">On Sat, May 31, 2008 at 9:45 PM, SitG Admin <<a href="mailto:sysadmin@shadowsinthegarden.com">sysadmin@shadowsinthegarden.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div class="Ih2E3d">
<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><div>There was a link posted to this list recently:</div>
<div><a href="http://idcorner.org/2007/08/22/the-problems-with-openid/" target="_blank">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><a href="http://www.techcrunch.com/2007/02/20" target="_blank">http://www.techcrunch.com/2007/02/20</a></div>
<div>
/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 class="Ih2E3d">
<div></div></div></div></blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div class="Ih2E3d"><div><br></div>
<div>>Babu> There is not going to be any cache in RPs.</div>
<div><br></div>
</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><a href="http://wiki.openid.net/Stateless_Mode" target="_blank">http://wiki.openid.net/Stateless_Mode</a></div>
<div><a href="http://openid.net/developers/specs/" target="_blank">http://openid.net/developers/specs/</a></div><div class="Ih2E3d">
<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><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 class="Ih2E3d">
<div><br></div>
<div>>The central database is always going to say who my current OP
is.</div>
<div><br></div>
</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></div></div></blockquote><div><br>Babu> <br><br>Let me quote again the steps I wrote in my earlier email:<br><br>quote start "<br> 1. Let there be some central digitalID server
to issue a digital identity, which is not attached to any URL (say I go this
server, register myself & ask for a digital identity "babu_n"). And in this
same server, I would also associate my digital identity with "OP
details".<br> 2. I would select an OP & register with
OP. Provide my digital id here & associate my digital ID with "my details"
(like password, personal/profession details, etc etc..). It should be mandated
how OPs should store "my details".<br> 3. I go to some
OpenID enabled website & provide my id as "babu_n". Here the OpenID enabled
website now contacts the "central digitalID server" & gets the OP details of
the user (here "babu_n"). After that it allows the user to get authenticated via
OP.<br>" quote end<br><br>Here URIs are not used for digital identification. How many of general internet users have URIs ? How can we ask some general internet user to have an URI & then mangle the headers and so on ? So suggesting user to always maintain some live URI for purposes of digitalID may not be appropriate. <br>
Instead, digitalID is obtained by the user in step1 at central digitalID server.<br><br>Coming to the question of when the update is going to happen in cetral digitalID server:<br>So, in this context, whenever the user decides to switch from one OP to another, he goes through the following steps:<br>
1. Exports all his details from his current OP<br> 2. register with new OP, provide digital ID ("babu_n") & import all the details exported in step1.<br> 3. Logs into to "central digitalID server" & change the OP of the digital id "babu_n" to new OP<br>
<br>There is no URIs involved. A user registers at central digitalID server & gets his digital ID. <br><br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<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></div></div></blockquote><div><br>Babu> Sounds very interesting. Is this already in specs ?<br><br><br>Thanks,<br>Babu<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div><br></div>
<div>-Shade</div>
</div>
</blockquote></div><br>