[dss] Moving client-side transforms features to a "client-side transformsprofile"?

[Konrad Lanz <Konrad.Lanz@labs.cio.gv.at>]

Dear Juan Carlos and all,

Thanks Juan Carlos for pointing out the possibility to completely move client-side transforms features to a "client-side transforms profile".

I thought about this in the last few days and I think this is really what we should do, because it dramatically simplifies the core and allows to clearly discuss the issues involved for users actually needing this functionality in a special profile.
In the profile care could be taken to discuss issues like mentioned in the following emails: Martin 18.05.2005, Trevor 16.05.2005, Konrad 13.05.2005, JC 03.06.2005 etc... (search for transform) and exhaustively discuss the implications of client side transforms in it's specification.

And most important intermediate transformation results could be called what they really are (i.e. an optional Input in the "client-side transforms profile" which is called <dssctp:IntermediadeTransformationResult> and extends <dss:Document BaseType>).

Juan Carlos Cruellas wrote:

Konrad,

[...]

Right, the client side would have to exchange the ds:Objects content against the content that was
there before the first client side transform to have a verifiable signature.

I am not sure of understanding what you mean here... changing the ds:Object returned by the
server (if this is what you mean) would lead in certain situations to
failure of verification of the corresponding digest computed by the server,

What I meant was that the client exchanges everything in between  <ds:Object ...> and </ds:Object> against the content, that the client used as input for it's first client side transform. So the client actually keeps the <ds:Object> but exchanges its content or body if you like.
I'd advocate for moving this feature to a "client-side transforms profile".

I think the same is also true for dss:SignaturePlacement assuming that ds:Reference should be
generated for an InputDocument pointed at by dss:SignaturePlacement.

Concerning to SignaturePlacement, if the requested signature is dettached, I still see as
a good feature to process some transformations in the client side and request other transformations
to the server... it is client's responsability to ensure that the server will be able to generate
verifiable signatures.

If this is true this would mean that dss:SignaturePlacement would cause an exemption for the referred to input document from point 2. (Line 597) of Basic Processing for XML Signatures (section 3.3 in the core specification) and this should be mentioned somewhere in (section 3.5.7).

This further implies that for creating an enveloped signature a dss:SignedReference and a dss:SignaturePlacement would be required and this should be mentioned in the second paragraph of (section 3.3.2, Lines 626-628).

Is that what you meant?
Should a Document pointed to by dss:SignaturePlacement only produce a reference for this document if explicitly wanted by a dss:SignedReference having an enveloped transform and not by default.

If this is true and the document pointed to by dss:SignaturePlacement does not have a dss:SignedReference (with enveloped transform), how should we interpret client-side and server side transforms.
Where should the signature go? Where is the context node for the XPath expressions of dss:SignaturePlacement.
I fear that there is a lot of room for different interpretations.
Hence I'd also advocate for moving this feature to a "client-side transforms profile", whre clear processing rules could be specified for this.

However this might also be a feature and good for certain clients that have tight bandwidth limitations
and hence want to use client side transforms, but this should probably go into a profile.

So, is your suggestion to put client-side capabilities for generating transformations on the documents
and report on them to the server, within a profile, even for the dettached signatures cases?

Yes I think this a good Idea, because the core would be a lot simpler.

best regards

Konrad