<div dir="ltr">Maybe one way to mitigate this issue would be to have something like a Certificate Revocation List, except for OpenID URLs. Imagine...<div><br></div><div>I'm about to give up my identity URL. I've registered it on too many RPs to remember, but the ones I care about I've updated my account to whatever my new OpenID identifier is. Now I just want to "wipe out" any remaining RP accounts that may be hooked to my delegated URI so that no one who may claim it in the future may use the same URI and log in assuming my identity.</div>
<div><br></div><div>So, while I still retain possession of my URI (before I give it up), I "log in" with my old URI to a universal OpenID revocation list. Then I go ahead and give up control of that Identifier. End of story for the end user.</div>
<div><br></div><div>RPs would check logins against the URI revocation list and should deny login to any that show up there. That way, if I owned, for example, <a href="http://www.mydomain.com/andrew">www.mydomain.com/andrew</a> as my OpenID, then I let <a href="http://mydomain.com">mydomain.com</a> expire, my identity as <a href="http://mydomain.com/andrew">mydomain.com/andrew</a> is forever protected against a future owner.</div>
<div><br></div><div>What about OPs, you might wonder? If I control <a href="http://andrewarnott.myopenid.com">andrewarnott.myopenid.com</a> and register it on the revocation list, doesn't that diminish <a href="http://myopenid.com">myopenid.com</a>'s worth? No, because of identifier recycling. The URI I register for revocation includes whatever fragment may have been assigned to me. And any future <a href="http://andrewarnott.myopenid.com">andrewarnott.myopenid.com</a> assignment <a href="http://myopenid.com">myopenid.com</a> may hand to someone else will have to use a different fragment. So it doesn't diminish the OP's ability to recycle URIs, and in fact protects me because I don't have to just trust that the OP will recycle using fragments appropriately.</div>
<div><br></div><div>Perhaps OpenID v.next can include a provision that requires RPs to check some <a href="http://openid.net/revocationlist">openid.net/revocationlist</a> URI periodically to download a list of URIs to never allow login for. And <a href="http://openid.net">openid.net</a> can have some page where people who log in there can get added to it. Yes it's something more for the RPs to do, but they can just do this once a week or something, like the CRL is today. And yes, OpenID is supposed to be decentralized. I haven't figured that one out yet. </div>
<div><br></div><div>Thoughts?</div><div><br><div class="gmail_quote">On Thu, Sep 4, 2008 at 5:50 PM, SitG Admin <span dir="ltr"><<a href="mailto:sysadmin@shadowsinthegarden.com">sysadmin@shadowsinthegarden.com</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">>As it currently stands, if a user is hosting his own identifier,<br>
>whether by delegation or by running his own OP, it becomes his<br>
>responsiblity to protect that identifier from being compromised by<br>
>others.<br>
<br>
</div>And we all know how tech-savvy and security-aware the typical user is ;)<br>
<br>
One of the selling (adoption) points for OpenID has been how easily<br>
you can set it up, just adding one or two headers to a page. If we<br>
have to add a caveat to this like "But you'd better be tech-savvy<br>
enough to understand and address these security risks or you'll be<br>
leaving yourself open to Identity theft and, as far as the rest of us<br>
are concerned, it'll be all your fault." we might be better off just<br>
not saying that. But if the typical (*not* tech-savvy) user has to<br>
rely on large-scale Identity providers to securely host their URI,<br>
the decentralization factor loses credibility, since those large<br>
sites effectively *own* all OpenID's between them, and only a small<br>
number of people have anywhere to go besides another of the large<br>
sites.<br>
<br>
Donning my Relying Party hat for a moment (and pretending that I'm<br>
already prepared to accept arbitrary users), this is very worrisome<br>
for letting users input anything that wouldn't be public anyway, and<br>
then grant them later access to this same data on the merit of<br>
nothing more than having the same URI (and since that's practically<br>
the basis of OpenID, this is a very bad thing to be worried about).<br>
<br>
Perhaps an informal polling of various places offering web services,<br>
to see how many are web 2.0 aware, and get an idea of their policy<br>
for how long (if ever) before old account names can be recycled? The<br>
latter could be used to help the Foundation decide on a safe time<br>
limit for RP's to automatically recycle unused URI's within, in their<br>
OP/RP best practices list. The former looks to be a herculean task<br>
(how many small-time hosting companies could there be?), and wouldn't<br>
matter if the companies practiced good username-recycling policies,<br>
but perhaps a space for volunteer-only efforts would strike a<br>
comfortable balance between enabling it and not wasting too much work<br>
on it? I see a flow of,<br>
<br>
1) I go to the OpenID website and check a page in the wiki listing<br>
companies whose status we know.<br>
2) I don't see the one I'm currently paying for service on that list,<br>
so I call mine up and question them.<br>
3) I go back to the wiki and report my findings, or, if I don't have<br>
an OpenID yet, E-mail someone who does have one.<br>
<br>
The latter would only need a large sampling of various companies to<br>
fairly reflect the current state of affairs, the former would be an<br>
ongoing effort. Thoughts on either?<br>
<br>
-Shade<br>
<div><div></div><div class="Wj3C7c">_______________________________________________<br>
general mailing list<br>
<a href="mailto:general@openid.net">general@openid.net</a><br>
<a href="http://openid.net/mailman/listinfo/general" target="_blank">http://openid.net/mailman/listinfo/general</a><br>
</div></div></blockquote></div><br></div></div>