Summary of Closure Argument

Summary of "Closure" from my Point of View:

I think I now understand John's closure. While a document might be
well-formed and valid XML and while that particular document meets the
grammatical constraints of its schema definition, it is not yet complete in
the eyes of the application. For example, consider an application that
requires two signature on a blob. The first signer creates a valid and
well-formed signed XML document (D1) that abides by the production rules of
its schema definition. The first signer then sends it to the second party
who also signs it creating (D2). Somehow there was a "closure specification"
that effects the following property: only transformations of type
(X.permitted) will transform (D1) into (D2). XPath can be used to write
(X.permitted). "Thus, if person A signs an unfinished document, then the
signature filters can be set up to describe precisely what is allowed to
change after Person A's signature in order to achieve closure on the
document." [1] (I could imagine one trying to do this in the data model or
schema definition language, defining transformations between the data
models. Ralph?)

Don's disagreement seems to be that this can be a useful property and XPath
is a way to do it, but that a complement to XPath (not a exclusive option)
is to use dsig:target to set the boundaries of the scope XPath will use. It
doesn't give you closure but it does define the scope of the signature: "so
why do you argue so much against optional markers which just provide another
way to use XPath, a way that is not appropriate for closure applications but
is appropriate for other applications and in particular for a different
requirement that there seems to be no other way to met? " [2]

John does not seem convinced that the use of the dsig:target makes anything
simpler. In fact, to express that scope within XPath requires the sibling
axes, which might be easier to not bother with regardless and asks: "But how
does this substantiate the point that we should have two different semantics
for how the message to be signed and verified is generated?"

Consequently, I think the issue is: is XPath required?:

(1) if we require XPath, we might as well use the XPath to do the job and
not confuse it (or bring in the sibling axis) with dsig:target.

(2) if XPath is only optional, others might want to use regexp type stuff
and dsig:target. However, those that use XPath won't have their signatures
readable by those who opted not to use it, and they now might use the
sibling axis to implement dsig:target.

[1] http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/1999JulSep/0295.html
[2] http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/1999JulSep/0300.html
[3] http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/1999JulSep/0299.html


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

Received on Tuesday, 21 September 1999 15:39:16 UTC