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

[Andrew Arnott]

Hey Peter W., I think you replied to the wrong thread.  This message belongs
elsewhere. :)
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death
your right to say it." - Voltaire


On Wed, Jan 14, 2009 at 7:43 AM, Peter Watkins <peterw at tux.org> wrote:

> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20090114/4b25fde1/attachment-0002.htm>