Hey Peter W., I think you replied to the wrong thread. This message belongs elsewhere. :)<br clear="all">--<br>Andrew Arnott<br>"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - Voltaire<br>
<br><br><div class="gmail_quote">On Wed, Jan 14, 2009 at 7:43 AM, Peter Watkins <span dir="ltr"><<a href="mailto:peterw@tux.org">peterw@tux.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="Ih2E3d">On Wed, Jan 14, 2009 at 05:34:46AM -0800, Andrew Arnott wrote:<br>
<br>
> fact, I've become convinced that there is no way to allow a user to maintain<br>
> his own OpenID identity independent of any OP or ISP given the profile of a<br>
> common Internet user today.<br>
><br>
> But then it dawned on me: InfoCard! I mean, yes of course I knew what it<br>
> was before, but after fully appreciating how difficult it could be to<br>
> achieve this self-hosting identity in OpenID, I came to more fully<br>
> appreciate how elegantly simple and exactly right InfoCard is. The user<br>
> truly is completely hosting their own self-issued cards. To the point where<br>
> there is no OP or ISP in the mix at all. Sounds pretty good to me.<br>
<br>
</div>But CardSpace adoption still isn't very good (IE7 has about a 50% share<br>
of our users). And roaming with self-issued cards sounds pretty awful.<br>
OP-managed InfoCards sound alright, but doesn't that bring us right back<br>
to the problem of depending on an OP?<br>
<br>
I've suggested before how RPs could facilitate individual users' planned<br>
moves to different OPs (essentially, in the same RP app session, authenticate<br>
with the old and new OP and tell the RP you want to make them equivalent,<br>
or that you want to repudiate/revoke the old identity). The trouble with<br>
that model is having to do it for every RP. Here's a business opportunity:<br>
an "identity transfer" service, let's call it MyNewOpenID.com. Changing OPs?<br>
Go to MyNewOpenID.com, log in with the old and new identities, and tell<br>
MyNewOpenID.com which one you're leaving. No cost (yet). Next time you<br>
land on a site that you forgot to inform about your new identity, you<br>
could log in with a directed identity URL of <a href="https://MyNewOpenID.com" target="_blank">https://MyNewOpenID.com</a>.<br>
MyNewOpenID.com would ask you to authenticate with your new identity.<br>
It'd then ask you for something like $0.50 USD in order to vouch for your<br>
new identity. Pay it and MyNewOpenID.com would tell the site you forgot<br>
to inform about your new ID that your local_id is something like<br>
MyNewOpenID.com/was=<a href="https://me.yahoo.com/hashetc&now=https://id.live.com/foo" target="_blank">https://me.yahoo.com/hashetc&now=https://id.live.com/foo</a><br>
That RP would need to understand how to interpret that local_id, and<br>
would need to trust MyNewOpenID.com to make such assertions (here we go<br>
into CA/CPS land). The value of MyNewOpenID.com is that, if your RPs trusted<br>
it, you could use it to verify an identity transfer after the old identity<br>
became inaccessible to you.<br>
<br>
It'd be better if OpenID 3.0 included specs for identity transfer responses<br>
-- MyNewOpenID.com might set local_id to <a href="https://MyNewOpenID.com/somehash" target="_blank">https://MyNewOpenID.com/somehash</a>, and<br>
also include previous_id and current_id. It might be common then for RP<br>
libraries to support identity transfer responses (with a *whitelist* of<br>
trusted identity transfer providers). Recommended behavior would be to<br>
only trust whitelisted transfer providers (XPs?), and to require the user<br>
to authenticate as current_id after getting a trustworthy XP response.<br>
<br>
If an RP got an XP response from an XP it didn't trust, it could still<br>
accept the assertion if the user authenticated to both the previous_id<br>
and current_id. This would give the new OP a mechanism to help users<br>
migrate from the old one -- Live.com could include XP fields in the normal<br>
response so that if I logged in with Live.com for an RP that was accustomed<br>
to seeing <a href="http://yahoo.com" target="_blank">yahoo.com</a>, the RP would know to ask me to authenticate as my<br>
old <a href="http://yahoo.com" target="_blank">yahoo.com</a> identity in order to confirm my identity transfer.<br>
<br>
This would only help users with static URLs for their old identities -- if<br>
you're using an OP like Google that issues per-RP directed identities, you'd<br>
have to log in to the RP with both identities, as the new RP would not<br>
know what to set for previous_id in any XP fields.<br>
<font color="#888888"><br>
-Peter<br>
<br>
</font></blockquote></div><br>