Minutes: Special XRI TC telecon on Extended CanonicalID Verification 2007-06-19

["=drummond.reed" <drummond.reed@cordance.net>]

Following are the minutes of a special XRI TC telecon held at 10AM PT 2007-06-19 on the subject of Extended Canonical ID Verification. This proposal is summarized on the XRI TC wiki at:

 

            http://wiki.oasis-open.org/xri/XriCd02/CanonicalIdVerification

 

 

ATTENDING

 

Les Chasen

Steve Churchill

Wil Tan

Drummond Reed

Markus Sabadello

 

 

The purpose of the call was to continue discussion of extending Canonical ID verification from the first model, documented in section 11 of XRI Resolution 2.0 WD11 ED02 (http://www.oasis-open.org/committees/download.php/24286/xri-resolution-v2.0-wd-11-ed-02.doc) to a second model detailed at http://wiki.oasis-open.org/xri/XriCd02/CanonicalIdVerification.

 

We started out discussing the motivations for considering the second model Canonical ID verification. Drummond explained the state of discussion of the OpenID recycling issue has been captured by OpenID editor Josh Hoyt on the OpenID wiki at:

 

            http://openid.net/wiki/index.php/Identifier_Recycling

 

Steve proposed the following definition of Canonical ID verification under the first model:

 

            “Under Canonical ID Verification, the resolver promises (under the rules of its identity model) that the final XRD returned when resolving a given XRI with given resolution parameters will have been produced along its canonical identifier path, i.e., the authority for the XRD is also authoritative for all the Canonical IDs asserted in that XRD.”

 

We then collaborated on another way of stating this definition of Canonical ID verification for the first model:

 

            “Canonical ID Verification is the process of a resolver verifying that the authority for an XRD is also authoritative for all the Canonical IDs asserted in that XRD.”

 

Steve noted that the language above is equivalent to his phrase “produced in the canonical identifier path”, that is, the resolver is traversing the same set of nodes in the same order down a hierarchy.

 

We then discussed the following definition of identifier synonymity for the first model, which Steve believes follows from the first Canonical ID verification model:

 

            “If two XRIs resolved with the same input parameters including Canonical ID verification (cid=true) return the same verified Canonical ID in the final XRD, they are synonymous with each other and with all verified Canonical IDs returned in that XRD.”

 

Steve explained that the reason for requiring the input parameters is that the Ref processing that may take place to do service endpoint selection may, under the first model, affect the final XRD returned, and thus the set of verified Canonical IDs that may be returned.

 

Steve underscored that these definitions are motivated by a specific use case of preventing spoofing of the Canonical IDs asserted in the XRD returned for a specific XRI and a specific set of resolution input parameters.

 

We then had a long discussion about different use cases for synonymity and Canonical ID verification. Steve explained that his understanding is that the primary motivation for Canonical ID verification was the use case that selection of a particular service for a particular XRI will produce a particular Canonical ID, and that to prevent spoofing of this Canonical ID, the resolver must be able to verify that the authority for this XRD is authoritative for the Canonical ID. Steve feels that if we are to either abandon that model, or adopt a different model, we must: a) have a clear understanding of the first model, b) have compelling motivations for using a second model, and c) allow sufficient time for this second model to be understood and vetted.

 

Les described a use case that would require a different synonymity model and Canonical ID verification model than the first model. Before we went into deeper analysis of this use case and model, however, we decided we needed to clarify what we meant by “synonym” and “synonymity model”. At this point Les and Wil had to leave the call, but Steve and Drummond agreed to the following definition:

 

            A synonymity model is a defined means of associating a set of identifiers with a target resource.

 

It follows that whether two identifiers are synonyms or not cannot be defined outside of a synonymity model that defines the means of associating an identifier with a target resource. Steve points out that there can be any number of means of association in the real world, and even when the means of association is limited to XRI resolution and XRDS/XRD documents, there can be multiple models. As an example, Steve points to a suggestion (posted at one point an email thread to the list by Markus) that one XRD-based synonymity model would be to compare if two XRDs contain an equivalent set of service endpoints for a resource, with SEP equivalence determined by comparing the SEP URIs.

 

At that point we had to end the call. Steve and Drummond agreed on these next steps:

 

1) Based on the definitions in these minutes, Drummond would prepare strawman definitions for a second synonymity model and corresponding Canonical ID verification model reflected by proposal at http://wiki.oasis-open.org/xri/XriCd02/CanonicalIdVerification.

 

2) Steve will think through whether there can/will be conflicts between the first model and the second model.

 

3) Steve and Drummond will talk again tomorrow and see how much they can progress before the TC telecon on Thursday.