[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Identifiers and identity (part 2)
This email looks at recent proposals for GlobalID, EquivID,
MapToID, and MapFromID from the perspective of the identity model described in
part 1. First let’s look at the use case that motivated these new
proposals. The original use case It started with a thread on the OpenID list was discussing
the “reuse” problem: say John loses his OpenID (URL) and the later
Fred acquires it. Fred can go around to all the RPs where John had established
accounts and effectively “hijack” John’s accounts. Some sort
on non re-assignable identifier was needed. If the RPs instead stored the non
re-assignable identifier, then John would not need to worry about ever losing
his accounts—even if he loses his OpenID identifier. So the proposal went like this: given an OpenID URL, YADIS
metadata discovery would return an XRD containing the OpenID endpoint but now
it would contain a new construct telling the client RP “go ahead and use
the OpenID OP endpoint specified within this metadata, but instead of using the
OpenID URL as your account’s PK, use this other non re-assignable
identifier instead”. There would also need to be a mechanism to allow for
the verification that the non re-assignable identifier had been provisioned to
allow the OpenID URL to use it. Drummond decided that XRI resolution could also benefit from
this new feature, so the new requirement was born. An XRI client would perform
resolution and get back the XRD, and now a new element would indicate “go
ahead and use the metadata in this XRD (such as the service endpoints) but if
you are interested in using the identity of this authority, then please use
CanonicalID indicated in this new element (rather than using the value in the
original CanonicalID element.) In brief, the semantics are “use the metadata for the
returned authority A, but use the identity of this other authority B.” Identifier or identity? As you can see, I’ve already framed the above
semantics in terms of CanonicalID. It follows, then, that I have framed the
semantics in terms of identity. In
other words, the concept here is one of “use this other identity”
and not one of “use this other identifier.” As explained in part 1,
CanonicalID is the characteristic that distinguishes an authorities identity,
so these semantics must be talking about identity. GlobalID The first proposal was to add a construct called
“GlobalID” to the XRI authority data and XRD metadata, and then to
allow the authority’s CanonicalID data value to become provisionable.
This proposal was not acceptable from the standpoint of the underlying identity
model, because (see part 1) if the CanonicalID is used to establish an
authority’s identity, then how can this data value be provisionable? This
would be akin to a RDBMS allowing a PK to be provisioned. There’s a good
reason why a RDBMS doesn’t allow this—and it’s not because
some arbitrary coder felt a bit anal one day. It is because the Relational
model doesn’t support the notion. You can delete a record, you can add a
record, but you cannot change the identity of a record. When the GlobalID was first proposed (a couple months ago) I
immediately counter-proposed two replacement constructs: UseCID and
AllowUseCID. These would be provisionable data values within the XRI authority
and they would appear as metadata elements in the XRD. The UseCID element would
tell the XRI client to use the metadata in the returned XRD (such as the
service endpoints) but to please use this other
CanonicalID as the authority’s identity. This precisely matches the
semantics described above. The AllowUseCID element would provide for a
resolution-based mechanism to verify that the second authority had allowed the
first to use its identity. UseCID and AllowUseCID have now reappeared in the latest
proposal in the form of MapToID and MapFromID. MapToID and MapFromID Since these are a repackaging of UseCID and AllowUseCID, I
suppose that I shouldn’t be complaining. However Drummond’s (1)
change of the name to reflect “ID” and (2) specification that
CanonicalID is a “SHOULD” is just one more example of what happens
when you ignore the “precious distinction”. You cannot (successfully) overload the notions of
“use this other identity” with “use this other
identifier”. (Explaining why is far outside my energy level
now, so I’ll leave that as an exercise.) Thus the original terms UseCID and AllowUseCID much more
accurately reflect the actual semantics described above. They also eliminate
the whole “SHOULD/MUST” miasma. Note that it is the lack of understanding the distinction
between identifier and identity that has led to the introduction of terms such
as “identification equivalence”, which appeared in the latest
proposal. Yikes. EquivID I don’t have much to say about this new construct,
except that unless someone can define the semantics (clearly, and in terms of
the “use of another identity”), and even more importantly, unless
someone can explain the motivating requirements, then I’d say we should
leave this out. (At least I can say that I understand both the requirements and
the semantics for the MapToID and MapFromID constructs…) In part 3, I’ll use the identity model explained in
part 1 to show why the term “synonym” in the XRI specification is
misused. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]