[OpenID] persistent, non-recycleable identifiers

Tue Dec 1 15:09:15 UTC 2009

+1 to both Drummond's and Andrew's point.

I have done a blog post a while ago:

http://www.sakimura.org/en/modules/wordpress/identity-loss-with-openid-20/

If nothing else, what OpenID v.next should do is to deal with this problem.

Simply put, the persistent identifier must be returned by the Discovery
Service, not Authentication Service.

Note: This as an impact to the UX of identifer_select, and a way to cope
with it is desired.

On Tue, Dec 1, 2009 at 3:32 PM, Drummond Reed <drummond.reed at cordance.net>wrote:

> +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.
>
> 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.
>
> 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.
>
> (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.)
>
> Net net: it's not an easy solution. But it must be tackled if OpenID is
> going to grow to the next level.
>
> =Drummond
>
>
> On Mon, Nov 30, 2009 at 6:15 AM, Andrew Arnott <andrewarnott at gmail.com>wrote:
>
>> James,
>>
>> 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 *huge*.
>>
>> 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.
>>
>> 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.
>>
>> --
>> Andrew Arnott
>> "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
>>
>>
>> On Mon, Nov 30, 2009 at 6:01 AM, Manger, James H <
>> James.H.Manger at team.telstra.com> wrote:
>>
>>>  =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*
>>>
>>> _______________________________________________
>>> general mailing list
>>> general at lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-general
>>>
>>>
>>
>
> _______________________________________________
> general mailing list
> general at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-general
>
>

-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20091202/58fb013f/attachment-0001.htm>