[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: REFORMULATED ISSUE#2: SIGNATURECONTENTS (SIGN REQUEST DISCUSSION)
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]