Subject: RE: [xri] CID changes in wd11
What I am hearing from Steve and Les essentially boils down to this: a CanonicalID value should not be allowed to be polyarchical, because if it is polyarchical, it might need to change. If a CanonicalID value MUST be hierachical (which in had to be in order to be verified in WD11 ED02 -- the draft I believe Les is proposing we revert CanonicalID to), then indeed verification is indeed simpler, as a CanonicalID MUST be issued by the same authority authoritative for the XRD in which it appears. And if an authority uses a persistent hierachical identifier as a CanonicalID, it never needs to change, because a hierachical identifier is always under the control of the authority that issues it, whereas a polyarchical identifier is not.
Lastly it follows that if a CanonicalID value MUST be hierarchical (which was the proposed definition of the GlobalID element), then the primary rationale for GlobalID goes away (there may still another secondary rationale for it, but that’s another subject).
However if we go this direction, it leaves us with a different problem: how can a real-world resource (such as a person) prove that they are the same resource represented by two different XRDs with two different CanonicalIDs issued by two different parent authorities?
We’d need to move the burden of this proof to our polyarchical synonyms, i.e., Refs and Backrefs. In this approach, XRD #1 from parent authority #1 could assert that it represented the same resource as XRD #2 from parent authority #2 by including a Ref element whose value was an identifier that resolved to XRD #2 (preferably the CanonicalID for XRD #2, but any absolute identifier for XRD #2 would work).
To verify that this synonym assertion was true, an XRI resolver would need to do the same thing proposed in ED03 section 12.2, i.e., confirm that a corresponding Backref element exists in XRD #2 pointing back to an identifier for XRD #2 (again, preferably the CanonicalID for XRD #1). I would argue that we should also allow a Ref element to be used for verification, i.e., if XRD #1 contains a Ref element pointing to XRD #2, and XRD #2 contains a Ref element pointing back to XRD #1, the synonyms are verified in *both* directions.
Since this “Ref verification” only works polyarchically on Ref elements, it is a separate process that “CanonicalID verification” which only works hierarchically on CanonicalID elements. This means we’d need to add another XRI resolution parameter for requesting Ref verification (I’d propose to call it “ref” but we already have the “refs” parameter which is used to control whether refs are followed in service endpoint selection, so another name would be better).
The key thing we lose by going this direction is the ability for the resource represented by an XRD to assert a polyarchical identifier as its canonical identifier. Let me give an example.
If I want to go into twelve different businesses today to establish an account and I want to prove to each of them that I have the same identity (for example, so they all give me good credit), I can show all twelve of them the same credential with the same identifier (say it’s my WA state driver’s license #). If they believe this credential (which they can verify), they can record this identifier in their databases and they don’t need to assign me their own local identifier (they may still want to do that, but they don’t HAVE to do that). This is the CanonicalID-can-be-polyarchical model proposed in ED03.
By contrast, if none of the twelve businesses will accept my my WA state driver’s license # (or another external identifier) as their identifier for me, they all MUST assign me their own local identifiers. To prove I am the same person, they can all put in their records that I have a WA state driver’s license #, but to do this they MUST store at least two identifiers: the one they assigned me, and my WA state driver’s license #. This is the CanonicalID-must-be-hierarchical model that I believe Les and Steve are proposing.
Either model will work. They have contrasting advantages/disadvantages:
- XRI authority can assert the same identifier everywhere if it wants
- Separate Ref verification process is not needed to prove cross-domain identity
- Consuming applications do not need to store more than one identifier to support cross-domain identification
- CanonicalID can change
- Verification of polyarchical CanonicalID value involves an extra resolution step
- GlobalID is needed for verification of polyarchical CanonicalIDs
- CanonicalID never needs to change
- Verification of polyarchical CanonicalID values is more efficient
- GlobalID is not needed for verification
- XRI authority cannot assert the same identifier everywhere if it wants
- Separate Ref verification process is needed to prove cross-domain identity
- Consuming applications need to store more than one identifier to support cross-domain identification