OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [xri] Identifiers and identity (part 1)

Hey Steve,

(I read all 3, not just this one, and I meant to respond earlier.) Many times when I read what you write, I'm intimidated because I feel it's way too smart for me to be reasonably able to comment on it :) But I want to try anyway!

You are definitely right when you say we often confuse terms and that we should be more precise about terminology (I wrote my own e-mail a few days ago trying to point this out).

I think one the main differences in the way of thinking is the following sentence in your text:
"The means of associating the identifiers to the identity is that of XRI Resolution" (and judging by your examples, what you mean is resolution WITH sep selection)

Noone else seems to see it this way. What we want is associate identifiers to the identity WITHOUT sep selection.

Your text explicitly says that the process of associating identifier with identity depends on input parameters. But that would be like considering "Steve" and "Steven Churchill" to be different people depending on what I want to ask Steve when I meet him!

And that's what all the recent discussions in the TC and the new element proposals are about. How do you express identifier synonymity (hope nothing is wrong with that term) before you do sep selection and follow Refs.

I don't think that right now I can explain all the detailled motivations that led to the individual elements, but does what I wrote make sense?

Are you coming to that Data Sharing Summit in two weeks? Hope I can meet you some day..


On 8/21/07, Steven Churchill < steven.churchill@xdi.org > wrote:



Much of the continuing delays and confusion in the XRI Resolution Specification stem from a fundamental lack of understanding of the underlying identity model. Much of this arises from the failure to make the important distinction between the notions of identifier and identity.


I have not succeeded in my attempts to persuade the XRI editors in this area, nor to guide them toward a meaningful set of terminology and constructs. The TC now finds itself in the regrettable position of asking questions such as "what is an authority?", "what is a resource?", and "what is the relationship between an XRD and the former constructs?" I call this regrettable, because at this date so very late in the process, there is simply no excuse for this.


The bad thing is that due to this failure of understanding, the underlying model has suffered continuing attempts (in the form of misguided proposals in the TC) to undermine its foundation. The truly amazing thing is that despite these attempts, the XRI Resolution Specification today still stands strong upon the foundation of its identity model. This makes XRI resolution an elegant and exceptionally strong framework for solving many real-world problems for years to come. [Thanks to the efforts of folks such as Les Chasen for helping to preserve the integrity of the underlying model.]


Because my attempts at persuasion within the editors team have failed, I have discontinued those, and I have pretty much sat on the sidelines for the last couple months. Because the TC appears to be nearing (hopefully) the actual release of XRI Resolution 2.0 document, I have decided to pop out of the woodwork and present my thoughts on this public list. It is not my intention to further delay what has already become a grossly delayed specification. But, in all fairness, that damage has already been done, and much of that is due to the lack of understanding of which I speak above.


In this first email, I will lay out the core constructs of the identity model that underlies XRI resolution. Without this foundation, parts 2 and 3 will not make sense. In part 2, I'll discuss the GlobalID proposal and the new proposal of EquivID, MapToID, and MapFromID, from the viewpoint of this identity model. In the third part, I'll explain why term "synonym" in the XRI specification is misused.


Identifiers and identity


The identity model of which I speak is quite simple: identifiers have a means of associating them with some entity, where identity is the set of characteristics which distinguish one entity from another.


For example, the two identifiers "Steven Churchill" and "Steve Churchill" can be associated with the entity (the human being) who is typing out this email. My identity is the set of characteristics which distinguish one human being from another (my DNA, my "soul"). The means of associating my names to my identity might simply be a social convention where people refer to me using these names (my social identity model), or it might me a more formal means, such as that used by my bank (the bank's identity model.)


XRI has an identity model illustrated in this example: the two identifiers =steven.churchill and @ootao*steven can be associated with the XRI authority that has the CanonicalID value of  =!C5FB.53B6.6E94.824. The identity under this model is determined by the value of the CanonicalID—this is the characteristic of the XRI authority that distinguishes it from all other XRI authorities. The means of associating the identifiers to the identity is that of XRI Resolution—or more specifically, the act of performing XRI resolution with a given set of input parameters.


For example, if you click on the first two links below, you will be using XRI resolution as the means of associating the two identifiers to an identity (an XRI authority.) You can see here that the two identifiers =steven.churchill and @ootao*steven have been associated with an XRI authority with the CanonicalID value (identity) of  =!C5FB.53B6.6E94.824 . The third link is to show that, indeed, the means of association is tied to the resolution input parameters—clicking on it renders a different identity than does clicking on the second link. Same identifier, different identity.






(See the article at http://dev.inames.net/wiki/XRI_CanonicalID_Verification for more information about why this is so.)


So what?


The important thing to take away from this discussion is this "precious distinction" between identifier and identity. "=steven.churchill" and "@ootao*steven" are both identifiers. XRI resolution provides a means of associating them with an entity that we call an XRI authority. Each XRI authority has an identity which is the characteristic that separates it from all other XRI authorities—in our case, it is the value of its CanonicalID.


I have been told that this "precious distinction" does not exist. Here's how Drummond puts it: "but a CanonicalID is itself an identifier… thus there is really not a distinction between identifier and identity." I would advise not to allow yourself to fall prey to this thinking. The fact that the CanonicalID also happens to be used as an identifier in some contexts does not in any way alter the fact that the CanonicalID is the characteristic that distinguishes one XRI authority from another.  The model has a clear and real notion of identity and thus a clear and real distinction between identifier and identity. [I know that Drummond still strenuously disagrees with me on this fundamental precept.]


By formalizing the CanonicalID (and its verification), XRI Resolution can be said to formally support only a single identity model. This is the identity model that uses CanonicalIDs to distinguish the identity of XRI authorities. It should be stressed, however, that this identity model (where CanonicalID determines identity) is only one of a multitude of identity models allowed (although not formally supported) by XRI resolution. XRI clients need not ever care about CanonicalIDs, and conformant authority resolution services may not ever return a CanonicalID—yet this does not prevent a client from using other quite valuable and meaningful ways of associating XRI identifiers with some notion of identity.



Authorities, XRDs, Resources, Registries


Unfortunately, the XRI TC still suffers confusion regarding these concepts.


What is an XRI authority? It is the entity in the above XRI identity model to which we ascribe identity. It is the real-world entity (living in a real namespace registry) encapsulating the data for local identifiers, Refs, service endpoints, and so forth—those things that often appear as metadata in an XRD. It is the record in Les' "global database" and the node in my hierarchical graph. (These are metaphors discussed in previous emails.) Whereas the XRI authority encapsulates the actual data, metadata about the XRI authority is described using an XRD as explained next.


What is an XRD? It is a bit of XML used to describe metadata about some "resource". Under XRI Resolution, the XRD provides metadata describing the actual data of the XRI authority. (So I guess this makes an XRI authority a type of resource.) But an XRD is also used to describe other types of resources: consider its usage under YADIS.


So when I go to provision the data for my XRI authority that is distinguished by the CanonicalID =!C5FB.53B6.6E94.824 (that entity for which I shell out a few bucks every year) I know that my provisioning will show up as metadata in an XRD used to describe my authority under XRI resolution. (To be sure, not all my authority's data will show up in the metadata. For example if I provision my authority with a new local identifier *steve.churchill, and if I obtain an XRD by resolving =steven.churchill, then I will not see that new local identifier, even though that is a real part of my authority's data.)


Like failing to make the distinction between identifier and identity, the TC also commonly fails to make the clear distinction between an authority's actual data and an XRD's metadata.


A final important construct is what I refer to as the XRI namespace registry. Each non-leaf node in my hierarchical graph represents such a registry—a namespace for its child authorities. Les' global database metaphor can be thought of as being partitioned into these namespace registries. For example, the = and @ namespace registries are hosted at NeuStar. The attached diagram explains the role of the namespace registry in relation to the other model constructs already presented above.



Part 2 in this series looks at recent proposals for GlobalID, EquivID, MapToID, and MapFromID from the perspective of the identity model explained above.




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]