Conflict in Canonical ID verification behavioral models.

The following outlines the two behavioral definitions for CanonicalID verification. The first one is the “current” definition. The second is the new proposal.

1. Under Canonical ID Verification, the resolver promises (under the rules of its identity model) that the final XRD returned when resolving a given XRI will have been produced along its canonical identifier path.

2. Under Canonical ID Verification, the resolver promises (under the rules of its identity model) that the final XRD returned when resolving a given XRI will have been produced along the path of the resolved XRI.

Reconciling this behavioral conflict is going to be a specification nightmare. And its going to be really hard to get our heads around it before we attempt to do so.

On requirements and motivations:

Behavioral definition (1) has been with us for at least 8 months. The motivations/requirements for this are obvious: changes in input parameters (for example resolving a given XRI for a different service type) produce different XRDs with different Canonical IDs. If an RP is using that Canonical ID as its primary key, then that RP needs a guarantee that the XRD metadata has not been spoofed.

Behavioral definition (2) has arisen in the last few weeks due to a thread in the OpenID mailing list. The proposal is that we introduce a new behavioral model (2) to the existing Resolver and that we specify how a URI-based resolving agent should behave. The notion that the folks in the OpenID camp will adopt “resolving agent” behavior specified in the XRI Resolution Specification is a long shot at best.

In any case, if we were to define behavior for a resolving agent, then it should be consistent with the XRI Resolver and it should perform service selection. If it performs service selection, then its behavioral model is “stuck” with (1) above.

~ Steve

xri message