Re: [dss] REFORMULATED ISSUE#2: SIGNATURECONTENTS (SIGN REQUEST DISCUSSION)

[Trevor Perrin <trevp@trevp.net>]

At 11:06 AM 9/9/2003 +0200, Juan Carlos Cruellas wrote:


>Dear all, after sending my previous email on Issue#2 I realized I had
>forgotten to make one proposal. See below the final formulation of Issue#3.
>
>
>ISSUE#2: SignatureContent element in Trevor's proposal.
>
>Short description: This is a root child element in your proposal.
>It contains:
>         -A list of DocumentSelector element
>         In its turn each DocumentSelector contains:
>
>                 -WhichInputDocument: integer allows to select one of the 
> input documents
>to the server
>
>                 -ds:Transforms (optional): this element contains the 
> transforms that the
>requester may
>                 request the server to apply to the sent document.
>
>                 -EnvelopeThisDocument: boolean. Indicates if the 
> resulting document has
>to be
>                 enveloped in the resulting signature.
>
>Short rationale: you say that:
>
>         "The client passes a list of
>         Input Documents, and also passes a list of Document Selectors, 
> which apply
>         transforms to particular of these input documents.  Then when the 
> client
>         says what he wants to envelope, or what transformed data he wants 
> returned,
>         he refers to a DocumentSelector instead of an Input Document.  By 
> using
>         Document Selectors as a layer of indirection, a client could send 
> a single
>         document, then have multiple Document Selectors apply different 
> transforms
>         to it (to select different elements, for example), and then sign 
> all these
>         different references, and envelope some of them in the signature, 
> and not
>         others."
>
>My comments and proposal:
>
>         1. I see that this mechanism gives lot of flexibility in terms of 
> document
>         manipulation, which is good. So, I would tend to accept it with some
>         minor changes, which I detail below:
>
>         2. I do not like the name  "SignatureContents": it does not 
> anticipate
>         the purpose of the element. I would propose "DocumentManipulations"
>         or something similar: in the end you are selecting documents or parts
>         of the documents and instruct the server how to manipulate them.
>
>         3. As you propose to indicate in the DocumentSelector whether the
>         resulting doc of the transformations has to be enveloped or not, 
> I propose
>         to give all the details here; ie, I propose that this element 
> includes
>         indication of where the resulting document of the transformations 
> will come:
>         detached of the signature, enveloping it or being enveloped by it.

I don't understand the last sentence.  But I think what you're describing I 
call "SignaturePlacement".

Here's what I was thinking.  I really need to write this up.  I think this 
is a good model though -
  - SignatureContents determines what the signature covers, and whether 
each thing is included in the signature ("enveloped") or not
  - SignaturePlacement determines where the signature is placed in one of 
the Input Documents (or SignaturePlacement can be omitted, if this is just 
a detached signature)
  - OutputOptions determines what outputs are returned:
    - StandAloneSignature (the signature by itself)
    - DocumentWithSignature (the signature as embedded in the document it 
was "placed" in)
    - TransformedDocuments (any of the post-transformed documents)
    - UntransformedDocuments (any of the pre-transformed documents)

So basically, when specifying each "DocumentSelector", the client says 
envelope/don't envelope.  Then the client says where the resulting 
signature is "placed".  This determines everything wrt 
enveloped/enveloping/detached.

Then as a separate aspect, the client asks for outputs - and he can ask for 
any combination of outputs he wants, each output is just a different "view" 
into the processing that was performed by the server.

What I've left unspecified is how to specify "SignaturePlacement".  That 
is, how to point to a place in an XML document and say "stick the signature 
here".  In your schema, you do this with:

<xs:element name="AfterElement" type="ds:TransformsType" />

Could you explain how this works?


>         I propose then to add the element EnvelopingDoc (and we can discuss
>afterwards
>         how to indicate where to envelop the signature within one 
> document), within
>         an optional choice that contains both, EnvelopeThisDocument and
>Enveloping. If none of them
>         appears, then the server asumes that the requester wants it detached.

I don't like this - the signature can envelope lots of docs, but it can 
only by enveloped once, right?  So we shouldn't tempt people to specify 
"EnvelopeThisDocument" on different DocumentSelectors.  In any case, I 
think the questions:
  - what does the signature contain
  - where is the signature placed

are best viewed separately, not smushed together.


>         4. I propose to make EnvelopeThisDocument an empty element. Its 
> presence
>indicates
>         that. Its absence clearly indicates that it will not envelope the 
> signature.
>
>         5. WhichInputDocument. Could it be an attribute? It is an integer 
> pointing to
>         the document passed to the server...this would make it shorter. 
> And we do not
>         expect it will be required a structure for doing that...
>
>         6. I propose to change the name of ds:Transforms element to
>"RequestedTransforms",
>         that would be of type ds:TransformsType, because it indicates 
> that these
>         are transforms that the sender requests the server to perform (in 
> the sign
>request
>         there can be indications of already performed transforms done by the
>sender and
>         it is good to differentiate them).
>
>         7. I propose to put this information WITHIN the root child that 
> contains the
>         documents sent to the server (your InputDocuments element). This
>         element would have two children:
>                 - SubmittedDocuments
>                 -DocumentManipulations (or whatever name we select).

The rationale for putting InputDocuments at the end was that these 
documents could be large, so if they come after everything else, then it 
would be easier to visually inspect protocol messages.  So I would at least 
reverse the order of those elements.

Trevor