[OpenID] persistent, non-recycleable identifiers

Tue Dec 1 17:42:11 UTC 2009

One of the reasons this issue keeps cropping again is that OpenID is
not faithful to the 'Tripartite Identity' concept:
http://habitatchronicles.com/2008/10/the-tripartite-identity-pattern/

Identity in the web has typically 3 representations: An internal
representation (fixed, unchangeable index), a friendly representation
(for user display purposes), and a globally unique identifier that the
user can provide for login purposes.

In OpenID there is the assumption that a single URL can play both
roles. I think there is sufficient evidence now that it can't.

1. If the user provides a URL to login, it needs to be friendly which
typically prevents it from being suitable as an internal
representation (it will be subject to recycling)

2. If the user provides an OP identifier (or an email address), and
the OP asserts a machine-generated value, it will be suitable for
internal representation but it will not be friendly.

3. If we allow acct: URIs to be claimed_ids in the future, then can
serve as a global identifier but they may not be either persistent or
friendly.

Food for thought.

On Tue, Dec 1, 2009 at 8:46 AM, Drummond Reed
<drummond.reed at cordance.net> wrote:
> 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/
>
>
> _______________________________________________
> general mailing list
> general at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-general
>
>

-- 
--Breno

+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)