Simplified Syntax

Hi Joseph, Don, and Dave,

I would like to ask you to consider at length the merits of completely
throwing out any notion that core behavior should dig up resources external
to the document containing the Signature element.  The proposal below
basically takes what we have now and throws out all of the stuff that most
people really dislike, so it is not terribly different from what we have
now.

The benefits appear below the proposal, and they should be considered
seriously.

<Signature>
	<CanonicalizationMethod/>
	<XPathFilter/>
	<Object>+
	<KeyInfo/>
	<SignatureMethod/>
	<SignatureValue/>
</Signature>

Processing Rules:
1) All of the elements except SignatureValue must be created by the
application prior to generating the signature
2) The Canonicalization method will be applied.
3) The XPath filter will be applied, marking which elements should be kept
and which should be omitted
4) The filter markers in the Signature element will be turned on, except for
SignatureValue, which will be turned off.
5) The marked portions of the document will be rendered to text.
6) The text will be digested by the algorithm given in the SignatureMethod
7) The signature will be created using the SignatureMethod and KeyInfo

For verification, follow steps 2 through 6, then

7) Compare the digest from step 6 with the one in SignatureValue, using the
SignatureMethod and KeyInfo for decoding purposes.

===========================================
ADVANTAGES:
1) Nowhere do we see the need for core behavior to perform network access.
Our task has been greatly simplified by signing an XML document (in whole or
part) rather than trying to sign some arbitrarily large subgraph of the web
with core (or mostly core) behavior.

2) We acknowledge that obtaining the bag of bits from a non-local source is
an application-specific task.  An application that needs to associate a
stylesheet, for example, with the XML should either put a copy of the
stylesheet in an Object or it should push the whole problem out to a
Manifest.  This ties an application-specific behavior to an
application-specific need.

3) The hash in SignatureValue is applied directly to the data. Sure it can
be argued

4) We have no need of the base64 transform.  If an app wants to sign
something in non-XML format, it must either be a signature over a base 64
(or similar) encoding, or the app must do it through a Manifest and use
application-specific logic.

5) This design gets rid of the need for that awful XSLT transform.  I've
only ever wanted the XPath transform to perform precision omission from the
current document.  The ability to completely transform into something else
is weird.  Yes, we often take some XML and transform it by XSLT before
showing it to the user, but in my opinion, it is not necessary to sign the
result of that transform.  We only need to sign a bag of bits that includes
precisely the information necessary to reconstruct what the user saw.
Following "what you see is what you sign" too closely results in the maxim
that the only thing we should sign is a bitmap of the screen (which clearly
is not useful).

6) Simplicity of specification and implementation.

7) Complete ability to have core behavior be self-contained.
===========================================

The only thing we can safely count on being available is the document we are
currently working with. To create a tight, complete core behavior, we should
only be signing stuff in that document and pushing the resource location
issues to the application.

This proposal is by no means perfected, and it is heavily reliant on a
subset of what we already have.  Really all I'm proposing is getting rid of
the unnecessary baggage that has been added by the fact that we want to sign
external resources with core behavior when clearly we cannot.

Can you please consider and respond to this proposal.  Maybe we want to keep
on doing what we're doing, or maybe we want to get something out ASAP that
truly reflects what core behavior can reasonably do and truly delegates to
application behavior those things (like resource location) that MUST be the
responsibility of the application.

To be honest, I like the thing we have now, and it's fine by me if we go
forward with it, but we started this process from scratch last July with the
idea that we would shave out many extraneous features of the proposal we had
at the time, and I think it is only fair to apply the same effort to our own
work.  Did we just get it right on the first hit, or have we again fallen
into a trap of trying to cover too much in the core behavior such that core
cannot be accomplished without help from the application?

John Boyer
Software Development Manager
UWI.Com -- The Internet Forms Company

Received on Saturday, 20 November 1999 13:47:07 UTC