[OpenID] Identifier persistence (was RE: Don't you think digital identity URIs should have aspecific TLD?)

[Drummond Reed]

>> On 12/27/06, Drummond Reed <drummond.reed at cordance.net> wrote:

>> XRI infrastructure solves this problem by explicitly supporting 
>> reassignable identifiers (i-names) and persistent identifiers
>> (i-numbers) and permitting the resolution of any reassignable
>> i-name to be mapped immedidately to a synonymous
>> never-reassigned i-number which can be safely stored by an 
>> OpenID Relying Party without exposing the identity owner to the
>> risk of having their i-name "taken over".
>

>Bob Wyman wrote:

>
>The XRI Syntax specification says that a Persistent Identifier is "An
identifier that is permanently assigned to a >resource and intended never to
be reassigned to another resource." While it may well be the "intention"
that >such persistent identifiers are never to be reassigned, one must
accept that an "identity owner" is, in fact, >exposed to some "risk of
having their i-name 'taken over'" in the case of unintended events. There is
nothing >technical which prevents the taking over of XRI persistent
identifiers. The only thing that reduces risk here is >people's and
organization's willingness and ability to follow the rules. Such trust may
well be reasonably held, but >there remains an ineradicable risk of
entities' failure to perform as intended... (Note: The previous comments
>should not be taken as a criticism of  XRI. This 'risk' is an inevitable
characteristic of this class of system and of >this type of "solution".) 

The point Bob makes is so important that I want to reinforce it further.
He's absolutely right that there is nothing inherent in the technical
aspects of XRI architecture -- nor was there in the URN (Uniform Resource
Name) architecture that came before it - to prevent the reassignment of an
identifier intended to be persistent (which both XRI i-numbers and URNs
are). Such protection is afforded *entirely* by the operational policies of
the authority assigning the identifier, i.e., the registry. 

Part of the reason URNs did not catch on (besides the fact they are
typically very un-human-friendly identifiers) is that the operational
requirements of a URN registry are so dramatically different than a DNS
registry. A URN is assigned once and never reassigned, where as a domain
name is registered for a specified period and then either renewed or the
registration expires and it is returned to the pool of names available for
registration.

As I explained in the previous thread, one of the primary motivations for
the development of XRI architecture was to bring both reassignable and
persistent identifiers together under one unified registration and
resolution architecture that could not only solve the usability issues of
persistent identifiers (by permitting them to be discovered via
human-friendly synonyms), but to enable a new type of registry that supports
policies for *both* reassignable and persistent identifiers.

XDI.org is (to my knowledge) the first global identifier registry
infrastructure developed using this model. Although the details are probably
far too esoteric for most members of this list, if you find yourself
interested in the policies of a global registry infrastructure that supports
the registration of both reassignable and persistent identifiers, by all
means visit the XDI.org Global Services Specifications site
(http://gss.xdi.org <http://gss.xdi.org/> ) and review the main GSS document
at http://gss.xdi.org/moin.cgi/FrontPage?action=AttachFile
<http://gss.xdi.org/moin.cgi/FrontPage?action=AttachFile&do=get&target=gss-v
1.0.pdf> &do=get&target=gss-v1.0.pdf, in particular the section on
I-Numbers.

Net net: as OpenID spreads, so will recognition of the value of having a
persistent identifier at the root of an OpenID identity - and so will
appreciation of an identifier infrastructure designed from top to bottom to
support the policies necessary to make reliance on these persistent
identifiers a reasonable risk.

Note: This issue is important enough that I blogged it at
http://www.equalsdrummond.name/?p=89. 

=Drummond

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20061230/257d667c/attachment-0001.htm>