OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dss message

[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]