<!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>>Here URIs are not used for digital identification. How many
of general internet users have URIs ?</div>
<div><br></div>
<div>Good question. Let's take a look!</div>
<div><br></div>
<div>http://wiki.openid.net/OpenIDServers</div>
<div><br></div>
<div>But sorry, I'm not really answering your question. These are just
the millions of URL's that can *already* be used as OpenID's - it
doesn't even *hint* at how many URL's can be tied to specific internet
users!</div>
<div><br></div>
<div>So let's look at Facebook, Friendster, and all those other social
networking sites that *don't* yet offer OpenID; let's look at forums
where users have a public Profile, and maybe we'll start to get an
idea.</div>
<div><br></div>
<div>While we're at it, let's set aside that word "specific"
(I added it, anyway) and look at Sun Microsystems, which vouches for
its employees *without* identifying who they are; how long before
ISP's begin to follow in their footsteps? This is a URI, but shared
between members of a particular group of internet users.</div>
<div><br></div>
<div>Here are a couple of other pages you may find of interest:</div>
<div
>http://factoryjoe.com/blog/2008/01/03/its-high-time-we-moved-to-url-<span
></span>based-identifiers/</div>
<div>http://8stars.org/a/2008/02/07/social-networking-as-an-api/</div>
<div><br></div>
<div>>How can we ask some general internet user to have an URI &
then mangle the headers and so on ?</div>
<div><br></div>
<div>This point does have some merit. Thank goodness we have sites
such as AOL, Blogger, Flickr, LiveJournal, Yahoo, Smugmug, Technorati,
and Wordpress to take care of all this *automatically* for their
users.</div>
<div><br></div>
<div>Seriously, though, it's not easy to mangle the headers - in most
cases we're talking about just one line:</div>
<div><br></div>
<div><link rel="openid.server"
href="http://myopenidserver.com"></div>
<div><br></div>
<div>>So suggesting user to always maintain some live URI for
purposes of digitalID may not be appropriate.</div>
<div><br></div>
<div>I agree, but for different reasons - it *wouldn't* be appropriate
for a general internet user to maintain the uptime of AOL's servers
;)</div>
<div><br></div>
<div>>There is no URIs involved. A user registers at central
digitalID server & gets his digital ID.<br>
</div>
<div>Then we can be certain of one thing - what you are describing is
NOT OpenID.</div>
<div><br></div>
<div>>Babu> Sounds very interesting. Is this already in specs
?</div>
<div><br></div>
<div>Not to my knowledge. I was just trying to demonstrate that, when
it comes to data portability, it is possible to come up with ideas
that give an OP *temporary* power over your data without compromising
any of the other tenets of OpenID.</div>
<div><br></div>
<div>Which isn't to say that I didn't mean it as a legitimate idea. I
like it; even if an OP freely shares the decrypted data, and both
their keys and the original encrypted data, they can't establish
trust. Anyone could simply *make up* false data and assign it an
arbitrary encryption key, but once the user changes that XML file to
contain data encrypted with a new key, the OP can't prove anymore that
the data they are offering ever really belonged to the user. To the
extent that this information can be easily cross-referenced for
confirmation, it could be argued that the OP simply acquired this
information in the same manner and is deliberately mixing their false
data with the real data to grant their whole set that appearance. None
of which would stop attackers from, say, *trying* the information to
set up a credit card or whatever, but it does cast enough doubt on the
accuracy of the information available from that OP to exclude it from
well-designed trust systems.</div>
<div><br></div>
<div>-Shade</div>
</body>
</html>