[OpenID] query regarding OP migration

[SitG Admin]

>Here URIs are not used for digital identification. How many of 
>general internet users have URIs ?

Good question. Let's take a look!

http://wiki.openid.net/OpenIDServers

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!

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.

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.

Here are a couple of other pages you may find of interest:
http://factoryjoe.com/blog/2008/01/03/its-high-time-we-moved-to-url-based-identifiers/
http://8stars.org/a/2008/02/07/social-networking-as-an-api/

>How can we ask some general internet user to have an URI & then 
>mangle the headers and so on ?

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.

Seriously, though, it's not easy to mangle the headers - in most 
cases we're talking about just one line:

<link rel="openid.server" href="http://myopenidserver.com">

>So suggesting user to always maintain some live URI for purposes of 
>digitalID may not be appropriate.

I agree, but for different reasons - it *wouldn't* be appropriate for 
a general internet user to maintain the uptime of AOL's servers ;)

>There is no URIs involved. A user registers at central digitalID 
>server & gets his digital ID.

Then we can be certain of one thing - what you are describing is NOT OpenID.

>Babu> Sounds very interesting. Is this already in specs ?

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.

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.

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