Re: XML-Signatures Requirements Last Call

At 11:17 99/08/23 -0500, Paul Grosso wrote:
 >I have a few comments as chair of the XML Fragment WG (and proposed
 >co-chair of the proposed future XML Packaging WG):

Paul, thank you for your comments. Others from the Signature WG should feel
free to comment since they most likely understand the application
requirements better than me, but a couple of quick responses below:

 >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.

Understood. We hope to have a stable and mostly implemented spec by end of
year. Our packaging requirements are likely to be focused more on the
meaning of the relationship of an included document and the ref it allegedly
came from. Or to put it in f: terms, 
between the <f:parentref> and <f:fragbody/> as an assertion of a
relationship vouched by some party at some time, given the context of
fetching or processing the content.

 >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,
 > http://www.w3.org/TR/WD-xml-fragment#packaging

Ok.

 >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. 

Well, if you define the work as fragment as a single fragment in relation to
its context, you are quite right. But we know our applications need more
than that, and were hunting for a home for that issue. <smile>

 >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).

Signatures simply sign some octets. There are innumerable applications
semantics that might be represented in that pile of octets. XML Signatures
wants to keep it as simple and formal as possible while including a minimal
set of the XML stuff out there (like fragments) such that we have a critical
mass of functionality. So if we sign an XML fragment as a bunch of bytes, I
agree. If Signed XML is a XML fragment application itself and using it to do
some application/trust functionality (even if only minimally) things get
hairy. This also applies to transformation or XLink. Particularly, the
latter if XML Signature uses XLink to reference the things it signs, does
that mean it has to know XPtr too (it'd be nice, but then all applications
have to know it show they have shared semantics), but then there are many
complexities involved that would take a great deal of time to think through.

 >It sounds to me like there are several important requirements 
 >coming out of XML 

Here are a couple that I've identified:

Dependency: logical/assertion semantics of package must be explicit. 

Dependency: expectations regarding the processing/c14n (e.g., white space)
of content within a package must not violate signature or XML content
semantics. 

Dependency: signed content in/over packages. how to combine element IDs such
that they do not collide but also do not get changed? 

Dependency: how to show the relative relationships of package parts. For
example, how to include XML content with stylesheets and related resources
used for rendering.

Dependency: signing non-contigous portions of XML content in a way that
retains their relative positions/context.


_________________________________________________________
Joseph Reagle Jr.   
Policy Analyst           mailto:reagle@w3.org
XML-Signature Co-Chair   http://w3.org/People/Reagle/

Received on Wednesday, 25 August 1999 16:53:14 UTC