[OpenID] persistent, non-recycleable identifiers

[Manger, James H]

=Drummond,



> In any case, I feel very very strongly that whatever OpenID v.next does about identifiers,

> it MUST address the issue of consistent handling and mapping of persistent, non-recycleable identifiers and

> non-persistent, reassignable human-friendly synonyms for those identifiers.



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.



“=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.



Perhaps these are aspects of reputation, and perhaps reputation is a special case that needs human-friendly i-names not persistent i-numbers.



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.



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?







James Manger

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20091201/87aa9d5c/attachment.htm>