Proposal for XRD 1.0 signing to use constrained XML dSig

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

Eran, Brian, Dirk, Breno, Ben (and any other XRI TC members who were not
able to attend today's telecon):

Thanks to Scott Cantor's input, those of us who attended today's call (Will,
John, Peter, and myself) all ended out agreein that we should adopt a
constrained version of XML dSig enveloped signatures as the signing
mechanism in XRD 1.0.

Please read through the minutes on this topic (excerpted below) and let us
know: a) if you agree with this approach, and b) if you have any other
questions or concerns.

As this is the last big outstanding issue, we'd like to close this soon so
we can have a complete Working Draft 02 within the next week.

Thanks,

=Drummond 

******* EXCERPT FROM TODAY'S MINUTES *********

2) XML DSIG AND XRD SIGNING METHOD(S)

The thread on the mailing list that currently ends with...

	http://lists.oasis-open.org/archives/xri/200905/msg00045.html

...includes this excerpt from the last message:

"[Will has] been talking with Scott [Cantor] about this a bit the last
couple of days as well, and he's indicated a way of doing XML Signatures
without needing to do full c14n [canonicalization].  I didn't entirely
understand all of it (maybe some of you are already familiar with it), but
have pasted his response below.  He's volunteered to join the TC call
tomorrow if we want to pursue this further.  If we can find a way to do XML
DSig in a way that is reasonably supported among the major programming
languages, it would make this whole thing much cleaner (not having four
different ways to deliver the signature)."

Because he had to leave early, John began by advocating that we need as
simple and strong of a signature method as we can get.

Scott explained that the W3C XML dSig WG is looking at doing a 2.0 spec due
to performance and canonicalization issues. A new proposed spec has not been
drafted but the discussion is moving in a good direction. It looks like it
will be "plug-compatible" with existing implementations.

In this new 2.0 spec, there would be a subset of the XML dSig spec that
would be appropriate for simplified signing of XML documents like XRDs. 

Scott feels that if there are sufficient constraints in place on the XML
that is going to be signed, sufficient optimizations can be made to keep
implementations much less complex and support adequate performance. In
particular, he said that if you are just signing subtrees, canonicalization
can be very straightforward. 

Another advantage to this approach is that XRD signing would be compatable
with existing XML dSig implementations, requiring no new coding in
applications that used them. In places where XML dSig implementations are
not available, an implementation under these constrained conditions can be
much simpler than a generic XML dSig implementation.

Will asked whether these more narrow requirements are already profiled
somewhere. Scott said yes, the SAML profile of XML dSig, which uses the
enveloped signature option, already meets these constraints, and should be
able to be referenced as is by the XRD 1.0 spec. Scott also believes that
the IMI 1.0 (Information Card) spec uses a similar profile.

John noted that he was also in favor of this approach because compatability
with the SAML libraries is a benefit to adoption.

Will is in favor because this approach would reduce four methods for signing
an XRD to a single method, which has obvious benefits with regard to
interoperability and reduced implementation complexity.

Scott explained that biggest single factor in avoiding XML dSig complexity
is avoiding Q-Names in our schema. We can also further reduce signature
complexity by adding constraints such as requiring attribute ordering. He
also noted that we need to add an ID attribute on our root element. 

Drummond asked whether XRD extensibility will be an issue. Scott said no;
the fact that XRDs are extensible should not present a problem to achieving
this simplified XML dSig capability. We can still publish guidelines and
best practices for extensions.

There is consensus among all the attendees on this call that using the SAML
profile of XML dSig, together with constraints in the XRD spec that enable
this profile to avoid common XML dSig problems, appears to be the best
solution to XRD signing.

We then discussed how to move to full TC-wide consensus on this decision.
The general steps are:

	a) Publish these minutes.
	b) Send a special note to the list highlighting the proposal for TC
members who were not on the call.
	c) If we achieve TC-wide consensus, move to discussing it with other
related communities, such as OpenID and OAuth.
	d) If necessary, research support for simplified XML dSig in all the
relevant platforms (this is the step that might need explicit funding).

# DRUMMOND to post the minutes followed by a special email to the list
regarding this proposal.