[OpenID] persistent, non-recycleable identifiers

[Drummond Reed]

+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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20091130/063d3f4b/attachment.htm>