[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] Identifiers and identity (part 1)
Steve, While I have great respect for the work
you have done developing and explaining your views, and while I think you make
many valid points, my opinion has not changed that: 1) I believe the XRI TC should
avoid the term “identity” at all costs, and 2) I believe the XRI TC
already has sufficient terminology that is: a) simpler, b) relies on precedents
established by the W3C and IETF, and c) has been use by the XRI specifications
for several years. To be precise, I believe everything we
need is embodied in the following statements: 1) A resource identifier identifies a
resource (RFC 3986 dating back to RFC 2389). 2) Resource identifiers are assigned to
resources by identifier authorities (XRI 1.0). 3) A resource identifier (if resolvable) resolves
to a descriptor of the resource containing metadata describing the resource
(XRI 1.0). 4) Two resource identifiers are synonyms
if they are not character-by-character equivalent but they identify the same
resource (XRI Resolution 2.0 Committee Draft 01). 5) The metadata in a resource descriptor may
include synonyms for the resource (XRI Resolution 2.0 Committee Draft 01). 6) If two synonyms identifying the same
resource are assigned by the same identifier authority and appear in the same
resource descriptor, they are verified by definition. 7) If two synonyms identifying the same
resource are assigned by different identifier authorities, they can be verified
through correlation of the synonyms appearing in the resource descriptors to
which each of synonyms resolves. Do you agree that this is sufficient? If
not, what do you believe is either incorrect or missing? I ask you to really stop and think about
this because, regardless of how much you might prefer the vocabulary you advocate,
the ultimate goal of the TC must be to try to harmonize our terminology with
that of the rest of the world, particular those specifications on which we rely
and build upon. Specifically, our foundational specification,
RFC 3986, uses the term “identity” only once, in the following
definition of “identifier”: Identifier
An identifier embodies the information required to distinguish what is being identified from all other things within its scope of identification. Our use of the terms "identify" and "identifying" refer to this purpose of distinguishing one resource from all other resources, regardless of how that purpose is accomplished (e.g., by name, address, or context). These terms should not be mistaken as an assumption that an identifier defines or embodies the identity of what is referenced, though that may be the case for some identifiers. Nor should it be assumed that a system using URIs will access the resource identified: in many cases, URIs are used to denote resources without any intention that they be accessed. Likewise, the "one" resource identified might not be singular in nature (e.g., a resource might be a named set or a mapping that varies over time).
The very reasons that RFC 3986 avoids the
term “identity” are the reasons I believe the XRI TC should do the
same. Also, as regards the term “authority”,
we have always been specific that an identifier authority is itself a resource.
Our definition from the XRI Glossary (in XRI Resolution 2.0 Committee
Specification, http://www.oasis-open.org/committees/download.php/15377):
Authority (or Identifier Authority) In the context of identifiers, an authority is a
resource that assigns identifiers to other resources. Note that in URI syntax
as defined in [URI], the
“authority” production refers explicitly to the top-level authority
identified by the segment beginning with “//”. Since XRI syntax
supports unlimited federation, the term “authority” can technically
refer to an identifier authority at any level. However, in the
“xri-authority” and “iauthority” productions (section
2.2.1), it explicitly refers to the top-level identifier authority. See also
“IRI Authority” and “XRI Authority” In the context of
identifier resolution, an authority is a resource (typically a server) that
responds to resolution requests from another resource (typically a client).
From this perspective, each sub-segment in the authority segment of an XRI
identifies a separate authority. So an authority is a resource that is
responsible for assigning identifiers for other resources. This fits very well
with the RFC 3986 definition of “resource”: Resource
This specification does not limit the scope of what might be a resource; rather, the term "resource" is used in a general sense for whatever might be identified by a URI. Familiar examples include an electronic document, an image, a source of information with a consistent purpose (e.g., "today's weather report for Los Angeles"), a service (e.g., an HTTP-to-SMS gateway), and a collection of other resources. A resource is not necessarily accessible via the Internet; e.g., human beings, corporations, and bound books in a library can also be resources. Likewise, abstract concepts can be resources, such as the operators and operands of a mathematical equation, the types of a relationship (e.g., "parent" or "employee"), or numeric values (e.g., zero, one, and infinity).
If after studying this you feel that the
terms “identifier”, “identifier authority”, “resource”,
“descriptor”, and “synonym”, and the seven statements
above, are not sufficient for the XRI resolution spec to be very clear about
its purpose, please explain to us what you think is incorrect or missing and
how you recommend we can improve it. Thanks, =Drummond From: Steven Churchill
[mailto:steven.churchill@xdi.org] Introduction 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]