REFORMULATED ISSUE#2: SIGNATURECONTENTS (SIGN REQUEST DISCUSSION)

[Juan Carlos Cruellas <cruellas@ac.upc.es>]

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 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.

	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).

	In this way, everything dealing with the manipulation of the documents
	and their relationship with signature (enveloping, enveloped, detached) would
	appear in the same element.


Regards

Juan Carlos.




Regards

Juan Carlos.