[OpenID] Is OpenID truly user-centric and OP-independent? (WAS: Bug in OpenID RP implementations)

[Peter Watkins]

On Wed, Jan 14, 2009 at 05:34:46AM -0800, Andrew Arnott wrote:

> fact, I've become convinced that there is no way to allow a user to maintain
> his own OpenID identity independent of any OP or ISP given the profile of a
> common Internet user today.
> 
> But then it dawned on me: InfoCard!  I mean, yes of course I knew what it
> was before, but after fully appreciating how difficult it could be to
> achieve this self-hosting identity in OpenID, I came to more fully
> appreciate how elegantly simple and exactly right InfoCard is.  The user
> truly is completely hosting their own self-issued cards.  To the point where
> there is no OP or ISP in the mix at all.  Sounds pretty good to me.

But CardSpace adoption still isn't very good (IE7 has about a 50% share
of our users). And roaming with self-issued cards sounds pretty awful.
OP-managed InfoCards sound alright, but doesn't that bring us right back
to the problem of depending on an OP?

I've suggested before how RPs could facilitate individual users' planned
moves to different OPs (essentially, in the same RP app session, authenticate
with the old and new OP and tell the RP you want to make them equivalent,
or that you want to repudiate/revoke the old identity). The trouble with 
that model is having to do it for every RP. Here's a business opportunity:
an "identity transfer" service, let's call it MyNewOpenID.com. Changing OPs?
Go to MyNewOpenID.com, log in with the old and new identities, and tell
MyNewOpenID.com which one you're leaving. No cost (yet). Next time you 
land on a site that you forgot to inform about your new identity, you
could log in with a directed identity URL of https://MyNewOpenID.com.
MyNewOpenID.com would ask you to authenticate with your new identity.
It'd then ask you for something like $0.50 USD in order to vouch for your
new identity. Pay it and MyNewOpenID.com would tell the site you forgot
to inform about your new ID that your local_id is something like
MyNewOpenID.com/was=https://me.yahoo.com/hashetc&now=https://id.live.com/foo
That RP would need to understand how to interpret that local_id, and
would need to trust MyNewOpenID.com to make such assertions (here we go
into CA/CPS land). The value of MyNewOpenID.com is that, if your RPs trusted
it, you could use it to verify an identity transfer after the old identity
became inaccessible to you.

It'd be better if OpenID 3.0 included specs for identity transfer responses
-- MyNewOpenID.com might set local_id to https://MyNewOpenID.com/somehash, and
also include previous_id and current_id. It might be common then for RP
libraries to support identity transfer responses (with a *whitelist* of
trusted identity transfer providers). Recommended behavior would be to
only trust whitelisted transfer providers (XPs?), and to require the user
to authenticate as current_id after getting a trustworthy XP response.

If an RP got an XP response from an XP it didn't trust, it could still 
accept the assertion if the user authenticated to both the previous_id
and current_id. This would give the new OP a mechanism to help users
migrate from the old one -- Live.com could include XP fields in the normal
response so that if I logged in with Live.com for an RP that was accustomed
to seeing yahoo.com, the RP would know to ask me to authenticate as my
old yahoo.com identity in order to confirm my identity transfer.

This would only help users with static URLs for their old identities -- if
you're using an OP like Google that issues per-RP directed identities, you'd 
have to log in to the RP with both identities, as the new RP would not
know what to set for previous_id in any XP fields. 

-Peter