I agree that at least for performance reasons, implementations will not expand out every namespace node for each element.

But it possible to construct some esoteric XPath expressions which will not work unless all the namespace nodes are expanded, so an implementation which wants to be absolutely compatible with the spec, at the expense of performance will need to expand all the nodes.

Here is the example that I was talking about. This is a test case contributed by Merlin Hughes for the original Signature interop matrix. It should be available for download in the old working group web site.

Input document:
-----------------
<foo:Root xmlns:bar="http://example.org/bar" xmlns:baz="http://example.org/baz" xmlns:foo="http://example.org/foo" xmlns="http://example.org/" xml:lang="en-ie">
<bar:Something>
    <foo:Nothing>
      <foo:Something>
        <bar:Something>
          <foo:Something>
            <foo:Nothing>
              <foo:Something>
                <baz:Something />
              </foo:Something>
            </foo:Nothing>
          </foo:Something>
        </bar:Something>
      </foo:Something>
    </foo:Nothing>
</bar:Something>

XPath expression
----------------------
<Reference URI="">
        <Transforms>
          <Transform Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116">
            <XPath>

              ancestor-or-self::bar:Something and
              ((name() != "bar") or parent::bar:Something) and
              ((name() != "foo") or parent::foo:Something) and
              ((name() != "baz") or parent::baz:Something) and
              ((name() != "") or self::text())
            </XPath>
          </Transform>
        </Transforms>
        <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
        <DigestValue>c6/BJXIi3MjZG8+1xfVv0U0OF/s=</DigestValue>
   </Reference>

Expected inclusive C14N output
-------------------------------------------
<bar:Something xmlns:bar="http://example.org/bar" xml:lang="en-ie">
    <foo:Nothing>
      <foo:Something xmlns:foo="http://example.org/foo">
        <bar:Something xmlns:bar="http://example.org/bar">
          <foo:Something xmlns:foo="http://example.org/foo">
            <foo:Nothing>
              <foo:Something xmlns:foo="http://example.org/foo">
                <baz:Something xmlns:baz="http://example.org/baz"></baz:Something>
              </foo:Something>
            </foo:Nothing>
          </foo:Something>
        </bar:Something>
      </foo:Something>
    </foo:Nothing>
</bar:Something

Pratik

Sean Mullan wrote:

Hirsch Frederick (Nokia-OCTO/Boston) wrote:

All

We have some items to complete before publishing the Best Practices as a first working draft.
If we can complete these items before 7 October, then we can agree at that meeting to the changes, incorporate them before the F2F and agree to publish during the F2F (unless we are able to agree to publish on 7 October).

1) Please review the current Best Practices draft so that we can approve as working draft for publication. Please post any comments to the list by next week.

http://www.w3.org/2007/xmlsec/Drafts/xmldsig-bestpractices/

A couple of comments on section section 2.1.2 (Best Practice 5).

I think it would be a fairly immature XML Signature implementation that would still duplicate every namespace node for each element in the document. Yes, some early implementations did do that. I suggest adjusting the wording in this section as to not imply that every implementation does that.

Also, the example uses relative namespace URIs which should be rejected by C14N implementations [1]. So the example needs to be changed to use absolute URIs. This comment applies to all of the other examples as well.

--Sean

[1] http://www.w3.org/TR/xml-c14n11/#DataModel

Note: This specification supports the recent XML plenary decision to deprecate relative namespace URIs as follows: implementations of XML canonicalization MUST report an operation failure on documents containing relative namespace URIs. XML canonicalization MUST NOT be implemented with an XML parser that converts relative URIs to absolute URIs.