[OpenID] query regarding OP migration

[SitG Admin]

I can't help but laugh, Babu - you appear to be bursting onto the 
scene to exclaim "Let's reframe the goals of OpenID!", but 
counter-propose a system that is at odds with the current goals. 
Perhaps you'd like to borrow the current (open-source) code and use 
it as the foundation of a *new* project which meets your goals? Just 
don't call it OpenID ;)

>Babu> Migration, De-registration should be the functions that are 
>expected from an OP. So a user will choose only such OPs which abide 
>by the standards.

I'm not clear how we can expect users to know that OP's are not 
abiding by the standards. Don't they find out when they *try* to 
de-register but can't? Or should it be reputation-based, with 
newcomers naturally being shut out of the innovative process?

>As Shade was mentioning, such de-registration is not possible when 
>OP server is compromised. But this is an issue even other functions 
>(not just de-registration) and with OP-specific-digital-identities 
>supported by OpenID today.

But how many RP's keep track of *OP-specific* digital identities 
these days? I'm not seeing this as a big issue.

>So this issue doesn't hinder us to support global digital identity, 
>selection of an OP based on some central digital indentity server, 
>data migration across OPs.

There's nothing to stop us from jumping off the nearest bridge, 
either. But what's our *incentive*? Why do we *want* a central 
digital identity server in the first place? Consider that it's not 
really *necessary* for data migration across OP's *or* a global 
digital identity, both of which we already have ;p

>Babu> The problem with today's reality is that my "digital identity" 
>is lost if the OP shuts down his services or I would like to migrate.

Actually, this is not the case. In fact - ironically, this is 
*exactly* the centralization problem that OpenID solves. You can 
migrate to *another* OP because RP's keep track of your *identity*, 
NOT your Provider.

>Babu> Even with today's OP-specific-digital-identities, we have 
>phishing issue. What does an user do if he is phished. After this if 
>the attacker changes the password, does the user not loose all the 
>webiste accounts at which this OP-specific-digital-identity was used 
>?

What, exactly, is the attacker after? If it's a mere DoS, there are 
other ways to accomplish that. If we assume that the attacker wants 
to log into other sites with the user's digital identity, this should 
stop working the moment that user changes their URI to stop pointing 
at the old OP - and all they need to do for this is *remove* a line 
or two from their headers. They don't need to know who the new OP 
will be, or even intend to *have* an OpenID anymore. They just need 
to stop RP's from seeing that the attacker/OP combination is 
authoritative for your digital identity. The attacker can still do 
things in the sites they have *already* logged into, but should find 
it difficult to gain access anywhere else.

But if all the attacker wants is a DoS, the user can regain access to 
those website accounts by simply setting up an account with another 
OP.

>So, again, I dont see phishing as a hindrance to "support global 
>digital identity, selection of an OP based on some central digital 
>identity server, data migration across OPs".

And, again, I just don't see where centralization is necessary for any of this.

-Shade