[OpenID] persistent, non-recycleable identifiers

Tue Dec 1 16:46:52 UTC 2009

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.

=Drummond

On Tue, Dec 1, 2009 at 7:09 AM, Nat Sakimura <sakimura at gmail.com> wrote:

> +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/20091201/44d5bc4d/attachment.htm>