[OpenID] persistent, non-recycleable identifiers

Tue Dec 1 17:51:52 UTC 2009

Good points.

I agree that the one URL model needs to be revisited for v.Next.

Tying the persistent identifier to a URI may warrant reconsideration as well.

We have seen self signed certificates and other creative proposals.  

I think this is a key part of v.Next.

John B.
On 2009-12-01, at 2:42 PM, Breno de Medeiros wrote:

> 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)
> _______________________________________________
> general mailing list
> general at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-general

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2468 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20091201/72bed374/attachment.bin>