Proposed processing model for Reference and Transforms

Hello all,

Attached is a copy of the latest editors' copy of the XML DSig
specification, except that I have added and deleted the text necessary to
implement the new Reference/Transform processing model discussed in the most
recent teleconference.

The sections of HTML surrounded by <u></u> and <strike></strike> were added
by the editors prior to my receiving the document.  The sections surrounded
by <u john="john"></u> and <strike john="john"></strike> reflect the
modifications I made.  There turns out to be quite a large number of
changes, so I would ask as many of you as possible to really read over the
new document, esp. the content appearing in underlined red (though that text
is a mix of my additions and the former additions by the editors).

Despite the large number of changes, I have tried to change the behavior of
as few things as humanly possible.  Below is a manifest of the things I can
recall changing:

1) Obviously the changes have fixed the enveloped signature transform.

2) Removed requirement for barename XPointer support from external
resources.  We nevery really had this support, we just really haven't
acknowledged it before.  Also, I glommed onto the definition of
same-document reference from RFC2396 as the way to distinguish when we do
require barename XPointer support.  Same-document reference covers the null
URI plus URIs that essentially start with a #.

NOTE: We could recover id processing by adding a REQUIRED 'id' transform
that performs the same function as the xpointer I defined in the text.  If
we do that, then I'd say for the sake of consistency that the other xpointer
I defined should be done as a transform too, as well as the notion of null
URI (which excludes comments).  The point of these other two is to make sure
we can convert from octet streams to node-sets with or without comments.  As
well, the three ideas may be expressible as a single Transform with a
parameter. I'd be happy to take a stab at writing this up if the WG would
like.

3) Added idea that same-document URIs in the Reference would result in a
location-set, then defined how to boil the location-set down to an XPath
node-set (which is pretty easy considering an XPointer location set is a
node-set except for the addition of point and range ndoes).  BTW, the new
text is careful to say 'XPath node-set (or sufficiently functional
alternative)' or words to that effect throughout the document.

4) Rewrote text of all Transforms such that they indicate whether they input
and output an octet stream or a node-set.  Rewrote text surrounding
DigestMethod so that it is clear that if the input is not an octet stream,
then the node-set gets canonicalized.

5) Rewrote material around how to generate textual input for
SignatureMethod.  Basically, made it clear that SignedInfo is canonicalized
within the context of the surrounding document, which was not previously
stated.

6) As a result of the new processing model, it was possible to upgrade the
behavior of the base 64 transform so that it automatically strips away the
start and end tags if the base 64 content is within XML. (Being able to do
this on XML elements derived from external resources would be a great reason
to have a transform that does 'id' resolution).

7) Changed XPath so that it iterates on all nodes in a full node-set rather
than simply setting the context node to be the document root.  This was
necessary to the new transform processing model because the output is
expected to be a full node-set (minus a few carefully omitted elements), so
XPaths chained together (or an XPath after an enveloped signature transform)
needed to take full node-sets as input.  However, the result is quite lovely
in that the required XPath expressions are simpler and almost always
identical to the expressions one would write for an XSLT template match.

8) I now distinguish between Canonical XML and Canonical XML with Comments.
This was really quite necessary to get everything to work and keep all of
the features we used to have.  Canonical XML with Comments is recommended,
not required.  As well, it seemed like it wouldn't hurt anything because
Minimal canonicalization would be quite difficult if comments had to be
omitted.

9) The C14N Draft needs to be changed. Rather than taking an octet stream
representing the document plus taking an optional XPath expression to filter
the document, it will now take an octet stream or node-set as input, along
with an optional flag that tells whether or not comments should be omitted
from the output.  For the octet stream case (which is the one everyone's
really focused on right now), the stream will be converted to a node-set AS
CURRENTLY DEFINED as long as the comment flag is FALSE.  The identifier (URL
for C14N)#WithComments will be created within the C14N document.

Thanks,

     John Boyer
      Development Team Leader,
      Distributed Processing and XML
      PureEdge Solutions Inc.
      Creating Binding E-Commerce
      v: 250-479-8334, ext. 143  f: 250-479-3772
      1-888-517-2675   http://www.PureEdge.com