Core spec: client-side transforms, etc.

[Trevor Perrin <trevp@trevp.net>]

Guys,

I'm trying to understand how the core doc has evolved in the last few 
months.  Since the document is in flux, I may not understand things 
correctly, but I have some questions:


It seems we're disallowing clients from applying client-side transforms. 
  Are we also disallowing clients from sending "Input Documents" which 
are fragments of larger XML documents?

Is the goal of these changes to simplify/enable application of 
server-side transforms?

As I recall, the most important server-side transform, canonicalization, 
can easily be made to work with client-side transforms (including 
extraction of fragments) as long as clients send all relevant namespace 
context (i.e., clients add inherited namespace prefixes as attributes of 
the root node of an Input Document) [1].

So I presume the rationale for the above changes is that more complex 
server-side transforms might require XML document context which is not 
present in a transformed or extracted Input Document.  This was a 
problem with the core spec as of wd-30.  In hindsight, I think it could 
be solved one of two ways:
   A) Limit the server-side transforms the server can apply as part of 
basic processing
   B) Require a client to always send full, untransformed documents so 
the server can apply any server-side transforms.

In my opinion, the ability to send partial and/or transformed input 
documents is crucial.  It allows a client to request a signature on a 
small portion of a larger document, or access a generic server which 
lets clients request signatures on any sort of transformed document.

In contrast, the risk of a server not being able to apply a transform 
because the client has applied an incompatible transform seems easily 
managed with Profiles.  Profiles will specify rules about the Input 
Documents clients can send.  If clients break these rules (by applying 
an incompatible transform, by sending the wrong XML document, by sending 
a fragment when they should have sent a whole document or vice versa), 
then they are noncompliant, and there's nothing to be done.

So it seems to me that (A) would have been a minimal change to core 
preserving important functionality.  The path we're on, (B), seem to me 
an unnecessary re-engineering of the signing protocol which loses much 
functionality.

One argument from the archives for (B) is this: "the only case where 
client transformation seems to make sense is where the client sends the 
document hash instead of the document" [2].

However, consider these cases:
  - the server wants to apply additional transforms to an Input Document 
which is a fragment of a much larger XML document
  - the server wants to review or archive what it is signing
  - the client doesn't know which hashing algorithms are acceptable for 
the signature
  - the client is a lightweight device which doesn't want to implement 
canonicalization and hashing


Perhaps this is a related issue, perhaps not, but I'm also concerned by 
the proposal to remove 3.2 and 3.3, which describe simple algorithms 
clients can use to produce enveloping and enveloped signatures with a 
server that implements basic processing.

These algorithms are efficient and simple for the clients and have zero 
impact on servers.  The alternative is for clients to send all 
enveloping and enveloped documents to servers along with instructions on 
how to compose them.  There is no need to perform such simple operations 
on servers, and much disadvantage in terms of bandwith, the server 
complexity of implementing <SignaturePlacement> and 
<EnvelopingSignature>, and security (exposing data to the server you may 
not want it to see).


This gets back to the distinction between a signature-based vs. 
document-based protocol [3].  The DSS signing protocol was primarily 
signature-based: it took the inputs to a signature and returned a signature.

This gave a minimal core protocol, where the server handles signature 
creation, and the client handles all application issues around preparing 
signature inputs, and doing something with the signature after its 
creation.  However, optional inputs were provided so that profiles can 
shift some of these burdens to the server, thus providing document-based 
functionality as enhancements to the core protocol.

Now, we seem to be moving away from the signature-based aspect, towards 
a protocol that always sends and receives entire XML documents.  While I 
saw mention in the archives of moving things like client-side transforms 
to profiles, I think it makes more sense for core basic processing to be 
the *simplest* level of functionality, i.e. simply "produce a 
signature", while leaving the complexity of pre-signature operations 
(i.e. server-side transforms) and post-signature operations (i.e. 
enveloped / enveloping signatures) to Optional Inputs and profiles, as 
much as possible.


Trevor


[1] http://lists.oasis-open.org/archives/dss/200505/msg00058.html

[2] http://lists.oasis-open.org/archives/dss/200506/msg00020.html

[3] http://www.oasis-open.org/archives/dss/200505/msg00034.html