[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [no subject]
> - 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. > <JC>No, again, it does not say everything wrt because it does not say where to envelope the signature in the enveloping document, and this is the reason for my proposal. </JC> >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. <JC>Look to it in another way: using the approach I propose, in the ToBeDefinedElement you define THE MAIN OUTPUT corresponding to the request:ie, how the ds:Signature will be delivered to the requester, and in the OutputOptions you indicate additional things the requester wants to get: transformed documents, and so on.... I think that this is also a coherent view... </JC> > >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? <JC> As I said, the XPath defines a language allowing you to identify a certain element within one document using not very dificult expressions. If you want more details I could give you some examples..but now I am in a bit hurry...From this point of view, by identifying an element within a document the server could conclude, OK, this is he element after whose end I have to insert the ds:Signature. Now, a potential problem: I have been working with some XPath processor, but I am not an expert. What I know is that given an expression, these processors return the contents of the element identified, but do not give you a hook to the place where this element is in the document ....which puts some programming problems on the table, unless we use two transformations in the SignaturePlacementTYpe: the first one returning the part of the XML document that comes BEFORE the ds:Signature and the second one returning the part of the XML enveloping document that will come AFTER the ds:Signature once it i will have been inserted!. Once again, this is somethign that I say before looking more closely to the features of the XPath processors.... </JC> > > >> 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. <JC> Wait a moment, is not the reason why you propose to use a DocumentSelector to allow to generate different documents to be signed from one? if this is the case, you should allow to envelop in a ds:Signature whatever you want. I think that you are talking about the enveloping document. And you are right: only one should be able to envelope the ds:Signature, but this can be done refactoring the schema I showed above. <JC> In any case, I >think the questions: > - what does the signature contain > - where is the signature placed > >are best viewed separately, not smushed together. <JC> Again we disagree: -First the signature CONTAINS LOTS of things, and strictly speaking it can happen that some of the objects are not CONTAINED in the signature. Perhaps the word you are looking for is SECURE: what the signature secures is a collection of documents...but the signature contains more information... -Second even in that case I contend that by including in the DocumentSelector the indication whether the document is enveloped or not, you are giving information of the relative position of signed docs and signature. -Third, from this point of view and for the sake of a compact, simpler and more robust before unwanted mistakes, I still think that the proposal I made has advantages that we should not throw out... </JC> > > >> 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. <JC> I understand the reason for puting InputDocuments at the end...Yes, I think that proposal 7. can be revisited afterwards.... let us concentrate on my comments on how to manage the enveloped/enveloping issue... </JC> > >Trevor >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]