W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > July to September 1999

Re: XML-Signatures Requirements Last Call

From: by way of <pgrosso@arbortext.com>
Date: Tue, 24 Aug 1999 15:54:31 -0400
Message-Id: <>
To: "IETF/W3C XML-DSig WG" <w3c-ietf-xmldsig@w3.org>
At 16:35 1999 08 20 -0400, Joseph M. Reagle Jr. wrote:
>This is not a typical specification Last Call, but a requirements document
>Last Call. 

>    2. To ensure that all requirements within this document are
>       adequately addressed, the XML Signature specification must be
>       reviewed by a designated member of the following communities:

>         7. XML Fragement Working Group: signing portions of XML content.

I have a few comments as chair of the XML Fragment WG (and proposed
co-chair of the proposed future XML Packaging WG):

Under 3. Requirements, 2. Format, point 4 reads (in part):

4.  ...This WG must specify a simple method of packaging and encapsulation 
    if no W3C Recommendation is available. 

Though the XML Activity Phase III [1] proposal includes an XML Packaging
WG, it is not scheduled to start for some time, so it is fairly likely
that the XML Sig WG will not have a W3C Rec for packaging in time.  I
certainly sympathize, as this is the same situation in which the XML 
Fragment WG found itself.  The XML Fragment WG attempted to develop as
minimal a "packaging" mechanism as possible in the hopes that it would
be a subset of whatever future packaging scheme is developed.  I would
hope the XML Sig WG could do likewise, perhaps using something as similar
as possible to what the XML Frag WG did normatively and/or demonstrated
non-normatively in its spec [2].

[1] http://www.w3.org/1999/05/xml5436
[2] http://www.w3.org/TR/WD-xml-fragment and, more specifically,

Under 3. Requirements, 4. Coordination, there is the phrase:

  XML Fragement Working Group: signing portions of XML content

[side-note: "Fragement" -> "Fragment" in the above] and the Comment:

 Members of the WG are very interested in signing and processing 
 XML fragments and packaged components. Boyer asserts that [XML-fragment]
 does not "identify non-contiguous portions of a document in such a 
 way that the relative positions of the connected components is 
 preserved." Packaging is a capability critical to XML-Signature 
 applications, but it is clearly dependent on clear trust/semantic
 definitions, package application requirements, and even cache-like 
 application requirements. It is not clear how this work will be addressed. 

These comments raise some concerns for me that some folks may either
misunderstand XML Fragments or expect them to be doing more than 
they are.  In short, packaging was deemed--insofar as possible--to be
outside the scope of the XML Fragment work. 

As an important aside, it turns out that everyone tends to mean something
different when they say "fragment," and careful terminology is very
important.  Please see the terminology section of the XML Fragment
Interchange spec [3] for the terms the XML Fragment WG came up with.

[3] http://www.w3.org/TR/WD-xml-fragment#terminology

The XML Fragment Interchange spec (1) defines what can be a fragment body,
(2) describes a way to specify context information about it, and (3) suggests
a very simple (for lack of a better term) "packaging" method only because 
there was no existing work on XML packaging, but the XML Fragment WG
would be loath to go any further in the direction of packaging in light
of the expected XML Packaging WG.

As far as "signing and processing XML fragments," since an XML fragment
package (and a fragment context specification document) is a well-formed
XML document, signing it should be no different than signing any XML
document (though I could be missing something about signing, that not
being something on which I've got expertise).

Currently, the very simplistic "packaging" only allows one fragment
body per fragment package.  Therefore, it is true that "[XML-fragment]
does not 'identify non-contiguous portions of a document in such a 
way that the relative positions of the connected components is 
preserved'."  The goal of XML Fragment was to provide enough context
for a single fragment body to allow it to be parsed and processed,
not to represent relationships among parts of documents or to package
multiple parts together.  Also note that the XML Fragment spec puts
constraints on what "portions of a document" can be considered
fragments; basically, a fragment must be "well-balanced" (similar to
what XML allows as the content of a "well-formed external parsed entity").

It sounds to me like there are several important requirements 
coming out of XML Sig that need to feed into the XML Packaging WG.  I
think these requirements need to be stated clearly in terms of reqs
for the XML Packaging WG, not the XML Fragment WG.  While it is likely
that the XML Sig will need to make progress in advance of the start of 
the XML Packaging WG, I think specifying the requirements now would
still be beneficial. 

The scope of the XML Fragment WG is pretty much limited to interchanging
information about the context (in the XML parsing sense) of a single
fragment body.  Though I could be missing something, I suspect the existing
XML Fragment Interchange spec covers all the needs of XML Sig in this area,
and most of the XML Sig requirements will be more properly in the scope of
an XML Packaging WG.  I'll be glad to give my input to the XML Sig WG to
help sort out which requirements are which.

Received on Tuesday, 24 August 1999 15:54:34 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:09:55 UTC