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

RE: XML-Signatures Requirements Last Call

From: Paul Grosso <pgrosso@arbortext.com>
Date: Thu, 26 Aug 1999 18:19:18 -0500
Message-Id: <3.0.32.19990826181859.01011ea4@pophost.arbortext.com>
To: "John Boyer" <jboyer@uwi.com>, "Joseph M. Reagle Jr." <reagle@w3.org>
Cc: "IETF/W3C XML-DSig WG" <w3c-ietf-xmldsig@w3.org>, <w3c-xml-plenary@w3.org>
At 15:40 1999 08 26 -0700, John Boyer wrote:
>Have a look at Section C.1 of the fragment spec.

For the sake of others, see [1].

>Note that in the FCS, the attribute of the transaction element is missing.
>Is this a mistake?  I hope so.  

No, it's not a mistake.  The entire FCS is optional as are all parts
of it. 

>My understanding was that the FCS would be
>able to capture the entire body of ancestor information, which should
>include the attributes leading up to the document root.

Your understanding is correct.  The FCS is *able* to capture
all ancestor info, but none of it is required.  The attribute
of the transaction element could have been included in the FCS,
it just wasn't in this example.

>Regarding well-balanced regions, you've almost got it.  We need the ability
>to specify a well-balanced region minus a set of well-balanced subregions
>(possibly given by some sort of XPointer exclusion list).  The result still
>conforms to rule 43, but the fragment element may have fewer descendant
>elements than it had in the original document.

I've never heard the phrase "XPointer exclusion list" before. 
It's not anything we've discussed in the XLink WG.

I'm not positive what you mean by "fragment element" since
that isn't a term used in the Fragment spec.

But I think I can guess what you're getting at, and I have two comments:

1.  What I think you're talking about would still be something that is
    well-balanced, and I think lots of people will be glad to know you
    aren't talking about something that is not well-balanced.  I think
    we've dodged a big can of worms here (to mix metaphors).

2.  But what I think you're talking about isn't something covered in
    the XML Fragment spec.  That spec only considers a fragment body
    to be a well-balanced consecutive sequence of characters of an
    XML document; that is, a single "subtree" of the original document
    tree.  The definition of a fragment body does not include subtrees
    with holes.

>As long as the possible mistake mentioned above is in fact a mistake, then
>what you have right now is the ability to give me a single element from a
>document along with the ancestor information that adds context to that
>element.  Your section C.1 is a great example, actually, so I hope you don't
>mind if it ends up in the scenarios document!

It's not a mistake, but an option.  You do have the ability to send a
single element with any amount of ancestor info you choose to include.
In fact, you can have more than a single element--you can have several
consecutive siblings (as shown in section 5.4 [2] and C.2 [1]) and even 
mixed content as a fragment body.

You are welcome to use the C.1 example as is or with more context
info (e.g., transaction's attribute) provided you don't imply that
the XML Fragment spec requires any part of the FCS.  XML Sig may
put additional requirements on top of those in the XML Fragment spec
for signing applications, but XML Fragment will have other users, and
for maximum flexibility, no part of the FCS is required.

>However, suppose you have an element consisting of three subelements, of
>which the first and last must appear in a signature, and the middle one must
>be omitted from the signature.  For that, I seem to need to specify two
>fragments in my manifest.  

I understand, but the only way to do that with the current XML Frag spec
would be to have two separate fragment packages (specifically, FCS documents).
These could be packaged together somehow, and perhaps the package signed.

I understand this is suboptimal.  The XML Frag WG even considered allowing
multiple fragment bodies per FCS document, but decided not to do that in
our version 1.0, and we got no comments to the contrary during last call.
Since we have not yet gone to PR, we could review our decision and go
through last call again, but that would hold up our work.  Currently,
the XML Frag WG is effectively closed and any further XML Frag work is
scheduled to be handled by the XML Core WG being proposed as part of
the XML Activity III Proposal [3].  We have to date had no input that
we need to do more, but a strong statement from XML Sig at this time
might lead the XML Core WG to consider re-opening this issue before
sending the XML Frag spec on to PR.  Please provide your input to [3],
as that is the current vehicle for this.

Note that, even if accepted as a new requirement at this date, the 
XML Frag work would only *allow* an FCS document to consist of multiple
fragment bodies.  It would not address how one would specify "a 
well-balanced region with holes."  That would have to be a requirement
on XPointer or something else (I'm not sure what).

paul

[1] URI ref http://www.w3.org/TR/WD-xml-fragment#examples
[2] http://www.w3.org/TR/WD-xml-fragment#fcs-example
[3] http://www.w3.org/1999/05/xml5436
Received on Thursday, 26 August 1999 19:19:21 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.29 : Thursday, 13 January 2005 12:10:07 GMT