RE: [xri] Identifiers and identity (part 1)

Markus,

 

Thanks for the kind words.

 

Your questions are quite insightful. My
response is inline. 

 

~ Steve

From:
 [mailto:] On Behalf Of Markus Sabadello

Sent: Saturday, August 25, 2007
6:20 PM

To: Steven Churchill

Cc: 

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)

<steve>

XRI Resolution—via a compliant XRI resolver—provides the interoperable
means to associate XRI identifiers with their identities (XRI authorities.) Pictorially
the association looks like this:

[[XRI identifier plus other input parameters]]  ===> [[Compliant XRI
Resolver]] ===> (results in) [[XRD metadata describing a given XRI authority]]

This
represents the interoperable (standards-based) means of associating XRI identifiers
with identities. 

</steve>

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

<steve>

But for interoperability, this without-sep-selection
association must still take place via a compliant resolver. Okay, say someone doesn’t
want to use one of the existing resolvers. If they want compliant/interoperable
behavior, then they need to perform the association in such a way that it conforms
to the XRI Resolution Spec (in terms of the authority resolution phase, including
ref processing in that phase, and so forth.) To do this, they are implementing compliant
resolver behavior, even if they don’t want to perform service selection.
That is, for interoperability, their behavior would need to be the same as if
they *did* use a compliant
resolver with appropriate set of input parameters (such as sep=false.)

In other
words, any without-sep-selection association still conforms to the following
model (the same as shown above.) 

[[XRI
identifier plus other input parameters]]  ===> [[Compliant XRI Resolver]]
===> (results in) [[XRD metadata describing a given XRI authority]]

In this
case, one of the “other input parameters” would be sep=false.

</steve>

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! 

<steve>

I don’t think that *all*
identity models have input parameters effect the association. I would say that
my “social identity model” and the “bank’s identity
model” that I use in my example would not do this. The important thing is
that XRI resolution clearly *does*
do this. The behavior you get when you click on the following two links is
nowhere being challenged on the TC. The first link associates the identifier
@ootao*steven with one identity and the second associates it with another
identity. 

http://beta.xri.net/@ootao*steven?_xrd_t=http://openid.net/signon/1.0&&_xrd_r=application/xrd+xml;sep=false;         
http://beta.xri.net/@ootao*steven?_xrd_t=http://openid.net/signon/1.0&&_xrd_r=application/xrd+xml;sep=true;         

</steve>

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. 

<steve>

We just need to drill into the semantics around these new proposals. The UseCID
construct says this: go ahead and use the resolver’s output—that
is, the [[XRD metadata describing the given XRI authority]]—for example, go
ahead and use the SEPs that you find within this metadata. But for the purpose of
*identity*, please use this other CanonicalID.
This behavior is not about “before” or “after” service
selection, it is allowing a client to take the output of:

[[XRI
identifier plus other input parameters]]  ===> [[Compliant XRI Resolver]]
===> (results in) [[XRD metadata describing a given XRI authority]]

and to treat
the metadata as that describing an identity different than the one asserted in
the CanonicalID element found in the XRD.

EquivID is
taking an XRI authority (within its CanonicalID-based identity model) and
associating with it an identity in some external identity model. Like with UseCID,
this is not about “before” or “after” service
selection, it is about providing the client additional information about a
given XRI authority in the XRD metadata output from XRI resolution.

</steve>

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?

<steve>

I think that your questions are fantastic. Pointing out the difference in the
way people think about this stuff greatly serves to further progress.

</steve>

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

<steve>

Unfortunately I won’t be at the Summit. I’ll probably catch you at
the next event. Looking forward to it!

</steve>

Markus

 

On 8/21/07, Steven
Churchill <  > wrote:

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.

 

http://beta.xri.net/=steven.churchill?_xrd_t=http://openid.net/signon/1.0&&_xrd_r=application/xrd+xml;sep=true;      

http://beta.xri.net/@ootao*steven?_xrd_t=http://openid.net/signon/1.0&&_xrd_r=application/xrd+xml;sep=true;         

http://beta.xri.net/@ootao*steven?_xrd_t=xri://+i-service*(+contact)*($v*1.0)&&_xrd_r=application/xrd+xml;sep=true;

 

(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.