Constrained XML dSig decision (was RE: [xri] Minutes: XRI TC Telecon 2-3PM PT Thursday 2009-06-04)

["Drummond Reed" <drummond.reed@cordance.net>]

> > Drummond Reed wrote;
> >
> > 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)
> >
> [...snip...]
> 
> >
> > # 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.
> >
> Nat wrote:
>
> I actually did not fully agree to this one.
> I still think that we need to test the water at various communities for
> both "complexity" and "performance" before making this decision.
> 
> [...snip...]

Nat, I understand that not everyone is completely comfortable with this
decision yet, and I was careful to note that the next step is Will adding
this text to the next Working Draft, which still needs review before a
Committee Draft vote.

But the point I made several times on the call is that we have been
discussing this for six months now and it's time to "fish or cut bait". In
other words, the case for picking one method -- the constrained XML dSig
profile -- and going with currently enjoys the most support of any
alternative we have looked at. If anyone wants to make a different proposal
for something simpler, then the decision tree becomes:

  A) Adopt new proposal only (and give up XML dSig compatability)
  B) Adopt BOTH new proposal and constrained XML dSig profile
  C) Reject new proposal and just stick with constrained XML dSig profile

The cost of (A) is that everyone who wants to process XRD signatures will
need to implement the new signing method, even if they already support XML
dSig. That's a pretty high cost.

The cost of (B) is that now there will be two ways to to XRD signatures, and
now everyone adoption XRD signatures will need to deal with the increased
complexity and interoperability issues of multiple signature options. That's
a pretty high cost.

By itself, this don't automatically mean we should choose (C). But it does
mean that the new proposal MUST be so compelling that it is worth going down
either path (A) or (B).

So far, I haven't heard anyone saying that the constrained XML dSig profile
is inherently either too complex, or has serious performance issues. I've
only heard that it is possible that implementations with adequate
performance MAY not be available in certain communities yet. If so, Will's
point on Thursday's call was we don't so much need to "test the waters" as
simply help figure out how the necessary libraries that provide sufficient
performance can be provided in those communities.

Do you agree with this analysis? Or do you think we should continue to look
at options (A) or (B)?

=Drummond