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

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

At 14:33 15/09/2003 -0700, Trevor Perrin wrote:
>At 11:05 PM 9/15/2003 +0200, Andreas Kuehne wrote:
>>Content-Transfer-Encoding: 7bit
>>
>>Hi Trevor !
>>
>>>I think the idea is we'd envelope B, in the case where B is the starting 
>>>point for the "signature transforms".
>>
>>
>>Yes, B is what I like to call the 'document' !
>>
>>
>>>So the question is whether the server needs to be able to do an A->B 
>>>transform, such as selecting a particular element from one of the Input 
>>>Documents.  Alternatively, we would require the client to do any 
>>>"selection transforms" on the client side, and send the resulting B 
>>>elements as just other Input Documents.
>>
>>It seems to that we are just building an additional transformation 
>>service. This can be convenient, but I think it makes harder to understand 
>>what the DSS actually does. Or we should call it 'digital signing and 
>>other handy things'-service.
>
>The A->B "selection transform" wouldn't have to be a general purpose 
>transform.  It could just allow selection of a single XML element from one 
>the Input Documents.
>
>But I agree with you that the client could do this work, if desired.  So I 
>don't see a compelling reason to support this.
>
>Trevor 

<JC>
Well, it seems that we are going towards a service that signs and does
other things
(compound operations, etc).
I do not remember now what were the reasons why the text dealing with the
possibility
of getting parts of the documents was added to the req. doc, but I guess
that they should
be found in the use cases submmitted....Perhaps before making a decision of
going ahead
with what is easiest we should try to identify the use case from which this
requirement was 
derived, and think of the usefulness of this feature. 
Another consideration: even if we contemplate this possibility, we would
not force anybody
to use it!, and we could also build up services as simple as you want and
yet leave the doors
open to those manufactures that would like to offer their clients with the
possibility of exonerating
them of having to install XPath or XSLT processors and managing them by
themselves....
</JC>

>
>
>To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/dss/members/leave_workgroup.php.
>