Nat actually makes a very important point here with regard to the persistent non-recyclable identifier issue: in order for it to fully protect the OpenID user, this identifier must be returned to the RP via the discovery process, not the authentication process. I encourage folks to read Nat's blog post. Yet another reason why I personally believe Discovery should be its own independent modular specification for OpenID v.next.<br>
<br>=Drummond<br><br><div class="gmail_quote">On Tue, Dec 1, 2009 at 7:09 AM, Nat Sakimura <span dir="ltr"><<a href="mailto:sakimura@gmail.com">sakimura@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>+1 to both Drummond's and Andrew's point. </div><div><br></div>I have done a blog post a while ago: <div><br></div><div><a href="http://www.sakimura.org/en/modules/wordpress/identity-loss-with-openid-20/" target="_blank">http://www.sakimura.org/en/modules/wordpress/identity-loss-with-openid-20/</a></div>
<div><br></div><div>If nothing else, what OpenID v.next should do is to deal with this problem. </div><div><br></div><div>Simply put, the persistent identifier must be returned by the Discovery Service, not Authentication Service. </div>
<div><br></div><div>Note: This as an impact to the UX of identifer_select, and a way to cope with it is desired. <div><div></div><div class="h5"><br><br><div class="gmail_quote">On Tue, Dec 1, 2009 at 3:32 PM, Drummond Reed <span dir="ltr"><<a href="mailto:drummond.reed@cordance.net" target="_blank">drummond.reed@cordance.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">+1 to all the points Andrew makes for all the security reasons about why every human-friendly recycleable OpenID identifier should be paired with a persistent non-recycleable identifier, and why RPs should use ONLY the latter as the persistent identifier for the user's account at the RP. <br>
<br>As Andrew says, it's not about users being able to switch recyclable identifiers - they can do that today. It's about the huge security hole that opens up when they LOSE CONTROL of a recyclable identifier - their domain name lapses and is reassigned, or their URL is reassigned. By the definition of OpenID, this means the new owner/controlled of that identifier can now fully and completely impersonate the previous owner/controller everywhere they had an OpenID account -- without detection or recourse.<br>
<br>Don't misunderstand - I'm not saying OpenID has to adopt XRI i-names/i-numbers as the only solution to this problem (though XRI synonym architecture was developed for this very purpose). Regular URLs and hash-URLs are another option (weaker but still valid). And still other solutions could be developed. What I am saying is that unless OpenID v.next builds the capacity for automatic synonym mapping - from one or more human-friendly recyclable identifiers to a persistent non-recyclable identifier, and RPs adopt the practice of storing the former as the friendly name and the latter as the persistent external account identifier -- will the problem truly be solved.<br>
<br>(Note: this solution is othogonal to directed identity - the persistent non-recyclable identifer can be pairwise-unique or not depending on the user's privacy preferences - but in the former case it is of course important not to turn around and share a non-pairwise unique human-friendly recylable identifier as a synonym.)<br>
<br>Net net: it's not an easy solution. But it must be tackled if OpenID is going to grow to the next level.<br><font color="#888888"><br>=Drummond</font><div><div></div><div><br><br><div class="gmail_quote">
On Mon, Nov 30, 2009 at 6:15 AM, Andrew Arnott <span dir="ltr"><<a href="mailto:andrewarnott@gmail.com" target="_blank">andrewarnott@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div>James,</div><div><br></div><div>You make a good point about using "=drummond" everyone eventually leading to out-of-date identifiers. But I think the biggest value to non-recycleable persistent identifiers is the security that losing control of that identifier cannot lead to someone else eventually spoofing your identity at an RP. That's <i>huge</i>. </div>
<div><br></div><div>The second most important value (IMO) of this is that after "=drummond" is recycled, Drummond can still either log into the RP with his i-number, or acquire a new recyclable identifier and attach it to his i-number and log in with that. I don't know how re-attaching a new i-name to an existing i-number works, or even if it does today. But it seems like a logical thing to be able to do.</div>
<div><br></div><div>The convenient, but least important IMO, is what you bring up, James, which is that others who recognize the i-name are still able to find the original owner, even if that owner doesn't own that alias any more. I don't know how to make this work, but given the two earlier points, I think achieving the first two without the third would still be hugely worthwhile.</div>
<div>
<div><br></div>--<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." - S. G. Tallentyre<br>
<br><br></div><div class="gmail_quote"><div><div></div><div>On Mon, Nov 30, 2009 at 6:01 AM, Manger, James H <span dir="ltr"><<a href="mailto:James.H.Manger@team.telstra.com" target="_blank">James.H.Manger@team.telstra.com</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div></div><div>
<div link="blue" vlink="purple" lang="EN-AU">
<div>
<p class="MsoNormal"><span style="font-size: 11pt; color: rgb(31, 73, 125);">=Drummond,</span></p>
<p class="MsoNormal"><span style="font-size: 11pt; color: rgb(31, 73, 125);"> </span></p>
<p class="MsoNormal">> In any case, I feel very very strongly that whatever OpenID v.next does about identifiers,</p>
<p class="MsoNormal">> it MUST address the issue of consistent handling and mapping of persistent, non-recycleable identifiers and</p>
<p class="MsoNormal">> non-persistent, reassignable human-friendly synonyms for those identifiers.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">A “persistent, non-recycleable identifier” (eg an i-number) sounds like a useful concept, but I am always struck by how much more useful “=drummond” seems to be than whatever your i-number happens to be.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">“=drummond” (eg an i-name) is supposed to be a “non-persistent, reassignable synonym” for your i-number. However, only your i-name appears in e-mails (like this thread), your blog domain name, web pages, and other online resources. If =drummond
gets reassigned, these resources will not change so they become “wrong”. Having an i-number doesn’t seem to help here.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Perhaps these are aspects of reputation, and perhaps reputation is a special case that needs human-friendly i-names not persistent i-numbers.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">I guess accounts at online service providers that use your i-number as the account id will “fail safely” if your i-name is reassigned. Even in this situation, though, it is not clear that non-recycleable identifiers are crucial. You can
notify a service when your identifier changes, which just leaves the services you didn’t care enough about to notify that benefit from non-recycleable identifiers.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Finally, if someone has let their non-persistent, reassignable synonym lapse, are they likely to be able to (securely) reclaim their persistent, non-recycleable identifier in the future? How do you prove you own an i-number (some time after
you have stopped paying for an i-name that used to resolve to it)? I am not that familiar with i-number practises, but it sounds like an awkward business problem. Does the process for re-claiming a non-recycleable identifier (eg an i-number) become a little-known
backdoor that can undermine the security of systems?<span style="font-size: 11pt; color: rgb(31, 73, 125);"></span></p>
<p class="MsoNormal"><span style="font-size: 11pt; color: rgb(31, 73, 125);"> </span></p><font color="#888888">
<p class="MsoNormal"><span style="font-size: 11pt; color: rgb(31, 73, 125);"> </span></p>
<p class="MsoNormal"><span style="font-size: 11pt; color: rgb(31, 73, 125);"> </span></p>
<p class="MsoNormal"><b><span style="color: rgb(31, 73, 125);" lang="FR">James Manger</span></b></p>
</font></div>
</div>
<br></div></div><div>_______________________________________________<br>
general mailing list<br>
<a href="mailto:general@lists.openid.net" target="_blank">general@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-general" target="_blank">http://lists.openid.net/mailman/listinfo/openid-general</a><br>
<br></div></blockquote></div><br>
</blockquote></div><br>
</div></div><br>_______________________________________________<br>
general mailing list<br>
<a href="mailto:general@lists.openid.net" target="_blank">general@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-general" target="_blank">http://lists.openid.net/mailman/listinfo/openid-general</a><br>
<br></blockquote></div><br><br clear="all"><br></div></div>-- <br>Nat Sakimura (=nat)<br><a href="http://www.sakimura.org/en/" target="_blank">http://www.sakimura.org/en/</a><br>
</div>
</blockquote></div><br>