Minutes: XRI TC Telecon 2-3PM PT Thursday 2009-06-04

Following are the minutes of unofficial telecon of the XRI TC at:

Date: Thursday, 04 June 2009 USA

Time: 2:00PM - 3:00PM Pacific Time (21:00-22:00 UTC)

ATTENDING

Dirk Balfanz

Breno de Medeiros

Brian Eaton

Will Norris

Nat Sakimura

Drummond Reed

George Fletcher

John Bradley

Bob Morgan

Markus Sabadello

REGRETS

Eran Hammer-Lahav

AGENDA

1) ADOPTION OF CONSTRAINED XML DSIG AS XRD SIGNING METHOD

We continued discussion from last week's call and the email list (see the thread working backwards from http://lists.oasis-open.org/archives/xri/200905/msg00076.html).

Will began by summing up the discussion of XRD signing methods over the last two weeks. He concluded by emphasizing that having one way of signing an XRD, that includes the signature in the document (which George pointed out is a requirement in some use cases), will simplify it for everyone. He believes the constrained XML dSig profile proposed by Scott Cantor will provide this.

Drummond asked for clarification on whether the signature MAY be referenced rather than enveloped. It was still unclear whether the constrained XML dSig profile allows this or not - what we are sure of is that it supports enveloped signatures. (Dirk made the point that adding an element to XML dSig should not break it because the added element should be able to be excluded.)

Drummond next summarized Scott's argument that making the XRD signing method compatible with XML dSig means implementations that already support XML dSig will already work without changes.

Nat and others asked for a precised definition of the "constrained XML dSig profile" that Will and Scott have proposed. Will said that it is defined in SAML Core 2.0 Section 5, and that we should copy the wording from there (rather than try to reference it) so that readers do not need to go to another specification.

Will explained this this profile references a W3C spec for "exclusive XML canonicalization" adds a few additional constraints, most notably a strong recommendation against using Q-names. (George shared that one major vendor he dealt with improperly implemented Q-names and therefore had a persistent bug in all its XML dSig products.) Will explained that normal XML dSig canonicalization inherits from parent elements. Exclusive does not do that, and does not require XPath referencing, because all you can reference is a single element by its ID attribute.

John suggested that in the specification we call this constrained XML dSig profile "XRD Signature" to avoid any confusion with SAML. There was consensus that this is a good, easy term which will help from a marketing and adoption standpoint.

Dirk asked if we have evidence that there are enough libraries that have support for this constrained XML dSig profile. Will said he has checked out Java and PHP. Java has the support, and PHP 5.2 also has it built in via the Simple SAML PHP library.

Drummond summarized the decision tree this way:

Option A: constrained XML dSig ("XRD Signature")

Option B: Our own homegrown super-simple sig option (whatever it is)

Option C: Both

Given that B would sacrifice XML dSig compatability, and C would only make implementations and interoperation more difficult, Drummond asked whether there was anyone on the call who has serious heartburn about A?

Nat replied that his concern was still mostly one of perception -- would there be potential implementers that will avoid XRD just because it uses XML dSig, even a constrained version?

George pointed out that even with SAML SimpleSign, signatures can be pulling teeth. John made the same point.

Dirk felt that the potential threshold is that it shouldn't take more than an hour to implement. The simple XRD signing proposal that we had probably meets that test. Dirk is not sure that this approach does. However the question is whether the delta between these implementations and those that do the extra work to do constrained XML dSig are important enough to avoid XML dSig compatability.

John also pointed out that Sxip plans for the next iteration of OpenID attribute exchange (i.e., AX v2) were to use XML dSig because the attributes needed to be signed. George agreed that the attributes are going to need to be signed somehow.

Nat suggested that we should check and see what level of support exists across different libraries. Will suggested that we be more proactive and actually target these libraries for improvements.

Brain summarized it this way: he's okay with using constrained XML dSig ("XRD Signature"), but we shouldn't think that this will solve interoperability issues. OAuth had this same set of issues, chose the simplest signature option it could, and is still working to achieve interop.

Brian suggested that we have either use an existing set of XML dSig libraries for testing or develop our own. There was strong consensus that this is essential.

George suggested that having a reference library as well as "teaching tools" such as Eran's blog entries on XRD that teach the base points plus the best practices and most common pitfalls. There was strong concensus that blogging by multiple TC members and other XRD proponents/teachers is the best way to assist successful adoption.

# DECISION: For XRD signing, we will proceed with option A, "XRD Signatures", a constrained profile of XML dSig as defined by SAML Core Section 5.

# WILL to include this in the next Working Draft.

2) OTHER XRD 1.0 ISSUES AND TIMING

Will said he knows there is still one open issue pending from the list discussion and will address that on the list this week and try to reflect the decision in this next Working Draft.

We also discussed timing. We want to stick with the goal of having a Committee Draft for public review by the end of this month. That means the next two telecons will be particularly important.

3) LINK HEADER/HOST META/LRDD STATUS/ISSUES

http://tools.ietf.org/html/draft-nottingham-http-link-header

http://tools.ietf.org/html/draft-nottingham-site-meta

http://tools.ietf.org/html/draft-hammer-discovery

Eran was not able to attend (nor will he be able to attend next week), so we'll aim for an update on these in two weeks.

4) XRI SYNTAX 3.0 WORKING DRAFT 02 STATUS/ISSUES

Drummond has done some more work but has not yet posted a second Working Draft.

5) NEXT CALL

Standard time next week.

xri message