Re: [dss] Core spec: client-side transforms, etc.

[Trevor Perrin <trevp@trevp.net>]

Konrad and I had a good talk, which narrowed my concerns.  We discussed 
two things -


1) Client-side transforms

Konrad pointed out that client-side transforms can produce octet streams 
or even node sets which are not XML, and thus cannot be transmitted in 
<InlineXML>, <Base64XML>, or <EscapedXML>.  Thus, *transmission*  of 
intermediate transform results causes difficulties.

Konrad also pointed out that intermediate transform results may not 
contain enough context from the document to allow certain server-side 
transforms to be applied.  Thus, *server processing* of intermediate 
transform results causes difficulties.

After thinking about this, I think these aren't really problems, just 
acceptable limitations:

If your client-side transform produces non-XML, then it's obvious you 
can't send the result as XML.  But you should still be able to send it 
as a hash or <Base64Data>.

If your client-side transform is incompatible with certain server-side 
transforms, then the server can't apply those transforms.  It should be 
up to profiles to allow/disallow client-side or server-side transforms 
as appropriate.  There are use-cases where you only want client-side 
transforms, only want server-side transforms, or want mixes of both.

Anyways, protocol and server support of "client-side transforms" is 
simple - the server just copies the received <ds:Transforms> element 
into a <ds:Reference> element.

For these reasons I propose <ds:Transforms> be reinstated in 
<dss:DocumentBaseType> instead of banished to <dss:DocumentHash>.


2) "Document splicing" for enveloped/enveloping signature (3.3.2, 3.3.3)

Konrad expressed a desire for the server to always return verifiable 
signatures (i.e. signatures with all enveloping and enveloped documents 
attached), so the client would not have to do splicing itself, or 
trigger an optional input to request server-side splicing.

I believe this would mean eliminating 3.3.2 and 3.3.3, and moving the 
functionality currently described in <SignaturePlacement> and 
<EnvelopingSignature> into core basic processing, while adding an 
optional inputs that requests returning an "unspliced signature" instead 
of the spliced one.

One of Konrad's concerns with the current approach is that it might be 
error-prone for clients to do splicing, as they might forget or do it 
incorrectly.

Another concern was "datatype normalization".  I'm probably not 
explaining this right, but the idea was that "datatype normalization" 
might cause the value the server signs to be different from what the 
client thought it sent, so that the client splices the signature with a 
slightly different document than was actually signed.

I'm not convinced by these arguments.  Clients might forget or do many 
things incorrectly; that's why we write good specs and do testing!  I 
agree the specs could be more detailed here, but I don't see why this is 
intrinsically error-prone.

As for datatype normalization, I don't understand.  Is this a problem 
with an unreliable transport, or incorrect server parsing, or the 
presence/absence/difference of schemas on the client and server ends? 
Won't all these cause other catastrophic problems?

In any case, the signing protocol was designed around the notion of 
creating and returning a signature.  If you want the server to do 
something additional, like document splicing, you access it through 
options which leave basic processing mostly untouched.  This was in 
accord with the "minimal core" philosophy, where the core provides a 
simple, mostly unchanging base which options add to, instead of 
replacing or redefining.  I think the belief was that such a core is 
easiest to build off of when spec'ing, implementing, and interoperating.

That's a fuzzy argument but it's getting late.  Well, the more important 
point is this:  We need extremely good reasons, and a well-analyzed 
proposal, before making changes this big.

Anyways, I hope this makes my concerns clearer.  Konrad, I'd much 
appreciate it if you can weigh in with what I'm missing or further 
arguments.


Trevor