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




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.





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]