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: Minutes:Joint XRI & XDI TC Telecon Thursday 2007-06-14


Following are minutes of the joint unofficial telecon of the XRI and XDI
TCs at:

Date:  Thursday, 14 June 2007 USA
Time:  10:00AM - 12:00PM Pacific Time

PRESENT

Steve Churchill
Les Chasen
Drummond Reed
Wil Tan
Gabe Wachob (second half)


REGRETS
Markus Sabadello 


1) EXTENDING CANONICAL ID VERIFICATION TO HTTP(S) URIS

After the special telecon on this subject held on Monday (see minutes at
http://lists.oasis-open.org/archives/xri/200706/msg00050.html), a formal
writeup was posted on the XRI TC wiki at:

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

Feedback on this proposal has been requested from the OpenID Specs mailing
List. One reply had been posted today, which found no problems with it from
an OpenID perspective.

On the telecon, we began by walking through Steve's email to the list:

	http://lists.oasis-open.org/archives/xri/200706/msg00062.html

Steve made the following points:

* In order to avoid Canonical ID spoof, the existing Canonical ID
verification model (as reflected in section 11 of ED02) is that a resolver
is verifying that the authority for each XRD is also authoritative for the
Canonical ID in each XRD.

* The new proposal is not consistent with this model because under the new
proposal, two authorities that do not have the same hierarchical "authority
path" can still have the same Canonical ID by virtue of using Backrefs for
verification.

* Steve's question is: what is the motivation for introducting a new model
that allows Backrefs?

* Drummond explained the motivation is that Backref processing allows an
authority to assert a Canonical ID for which it is not authoritative. One
problem this solves is how multiple XRDS documents from different
authorities can all assert the same Canonical ID.

* This led to a long discussion comparing the properties of the "Backref
model" with the current "Ref model". The Ref model enables verification of
Canonical IDs along hierarchical paths. When it is necessary to traverse a
polyarchical (cross-hierarchy) path to locate a desired service endpoint, it
requires following a Ref. One consequence of this is that whenever a Ref is
followed, the target XRD CANNOT have the same Canonical ID as the source
XRD.

* When the Ref model is extended to include the Backref model, this
limitation is removed. Any XRD can assert any Canonical ID. If the authority
for the Canonical ID is also authoritative for the XRD, no further
verification is necessary (this is the current Canonical ID verification
model in section 11 of ED02). If the authority for the Canonical ID is NOT
authoritative for the XRD, a resolver can do a "Backref check" to verify
with the authority for the Canonical ID that the Backref is an authorized
synonym.

* We ran out of time to discuss any further, but agreed that this issue is
important enough that we would schedule another special telecon at 10AM
PT/1PM ET next Tuesday, June 19 to try to close on this topic. In the
meantime all XRI Resolution editors and interested TC members are requested
to study http://wiki.oasis-open.org/xri/XriCd02/CanonicalIdVerification
closely and see if they can identify any issues with adding Backref
processing to the current Canonical ID verification model.


2) STATUS OF XRI RESOLUTION 2.O WORKING DRAFT 11

The goal is to post Editor's Draft 03 by Wednesday of next week, and to have
this draft be substantially complete (provided we have the Canonical ID
verification issue closed). There are still ~30 smaller action items from
the WD11 issues page...

	http://wiki.oasis-open.org/xri/Xri2Cd02/ResWorkingDraft11

... and the ED02 action list...

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

...left to complete. Drummond will try to coordinate assignments with the
other editors.


















[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]