[OpenID] query regarding OP migration

[SitG Admin]

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 ;)

>we should call it as "OpenProfile" ( as it contains more details 
>than just ID :) ).

Sounds a lot like "Attribute Exchange" to me, actually :)

>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.

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.

This wouldn't work if downtime or other unuseability was the problem 
with your old OP, though.

>I believe that "digital identity" problem should have been solved in 
>this fashion:
>         1. Let there be some central

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.

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.)

>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.

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!

On a related, but more amusing, note;
http://www.bash.org/?104052

>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.

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.

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.)

-Shade