Hi Shade,<br><br>
Please see inline..<br><br>
<br><div class="gmail_quote">On Sat, May 31, 2008 at 5:04 AM, 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;">
I've decided to combine my replies instead of making two separate posts. Nate, deregistration is at the end. Peter, you've received honorable mention ;)<div class="Ih2E3d"><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
we should call it as "OpenProfile" ( as it contains more details than just ID :) ).<br>
</blockquote>
<br></div>
Sounds a lot like "Attribute Exchange" to me, actually :)<div class="Ih2E3d"></div></blockquote><div><br>Babu> Okay.<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 class="Ih2E3d"><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Now assuming OpenID has these too in its roadmap, whats does it mean to end user when he switches from one OP to another (say using the delagation feature) ? He looses all the details that he has been maintaining at the earlier OP. This is undesirable.<br>
</blockquote>
<br></div>
One possible solution is to log in to the new OP while still using the old OP to confirm your assertion of identity; in the process of establishing your account, the new OP would request *all* your data with AX, and then, upon receiving it, the new OP would store all this data in its own formats.<br>
<br>
This wouldn't work if downtime or other unuseability was the problem with your old OP, though.<div class="Ih2E3d"><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I believe that "digital identity" problem should have been solved in this fashion:<br>
1. Let there be some central<br>
</blockquote>
<br></div>
There were very good reasons for *not* handling it this way, though - LACK of centralization is one of the most exciting aspects of OpenID (compared to earlier, and similar, approaches), and reducing that in the way you describe would render OpenID vulnerable to some very harsh criticisms that have, so far, garnered support (against OpenID) even *despite* not really being issues.<br>
</blockquote><div><br>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><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
There is *some* centralization inherent to the system, though, and this is the OpenID Identity itself, which must remain consistent to preserve the single-sign-on feature. (With the current specs, that is.)<div class="Ih2E3d">
<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
It should be mandated that OPs store user details in some standard format. And when user likes to migrate, the OP should let these details be exported. The details exported this way may be used by the user in importing at his new OP.<br>
</blockquote>
<br></div>
In addition to the "let each OP use their own format for internal storage, and only *exchange* data with a mandated format, using the already-established Attribute Exchange" alternative, why can't a user simply store their *own* personal data in an XML (standardized format!) file on their hard drive, uploading it to a new OP at will? This removes the power from an OP to "let" these details be exported, because the details have never left the user's possession in the first place!<br>
<br>
On a related, but more amusing, note;<br>
<a href="http://www.bash.org/?104052" target="_blank">http://www.bash.org/?104052</a><div class="Ih2E3d"><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
There's a second half: your details maintained at the earlier OP are still controlled by that OP unless you contact the RP to have them removed. I don't think there's any way in the OpenID protocols to do deregistration.<br>
</blockquote>
<br></div>
I don't think there's any way to do that, *period*. If site A wants to say something about the user (as identified by their URI), it can. If it wants to collect details about the user, it can add that data to the mix. If the user *cooperates* (say, by volunteering their personal information because the program/service/game "requires" that to function, or to inform them of updates, or whatever), it can add that data to the mix. Most importantly, though - if site A wants to, it can *make up* information about the user and report this to anyone that asks.<br>
<br>
The *real* trick is in getting anyone else to *trust* what site A says. As noted in Peter's message, RP's that decide "Well, the user *used to* trust site A - last time we checked, anyway." to override "The user is telling us NOW that they do NOT trust site A." aren't following the security protocols. We can address this trust issue in the specs (I thought it was already?), and laws against libel may be applicable in making the site stop "saying" it (at least, so outspokenly), but I don't think there's any way of making a site *remove* data/details about someone. (A lot of royally pissed-off trolls whose various identities were exposed and the proof posted on the internet, can attest to this through their inability to have that evidence removed.)<br>
</blockquote><div><br>Babu> There is not going to be any cache in RPs. 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.<br>
<br>
The central database is always going to say who my current OP is. So there is no question of multiple identities. Even though the data still stays at my earlier OP, it is never used. <br><br>
After changing to new OP, it is expected that the user changes his password so that the password stroed at his earlier OP is useless. As for rest of details (like personal, professional details) are concerned, whether my earlier OP uses tham for malicious puposes (becauases I'm not his subscriber anymore) can be covered by legal agreements ?<br>
<br>
<br>
Thanks,<br>
Babu<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
-Shade<br>
</blockquote></div><br>