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: RE: [dss] Compound operation Verify & Sign


Hi Trevor,

   Our first EPM version had compound operations such as "VerifyAndSign". We
dropped it in favor of a more extensible structure. It may not be an issue
in the core protocol, but it will make it murder for extended profiles. I
would rather use the same basic structure as the core is using and just
"extensions" on "base".

   I can't think of an example (especially in DSS' limited scope) where the
primary operation is not evident.

   As discussed at great length several months ago, I'd rather stick with
the "Options" vehicle in conjunction with server-designated "Outputs" when
and as required to handle compound operations.

Ed  

-----Original Message-----
From: Trevor Perrin [mailto:trevp@trevp.net] 
Sent: October 30, 2003 3:32 AM
To: Edward Shallow; dss@lists.oasis-open.org
Subject: RE: [dss] Compound operation Verify & Sign

At 01:49 PM 10/26/2003 -0500, Edward Shallow wrote:

>Nick and Co,
>
>    The last suggested position I remember getting consensus on was 
>that the request for the secondary or ancilliary operation should be 
>expressed in the "Options" or "ProcessingOptions" structure as it was then
called.

I agree with you when there's clearly a primary operation, and a secondary
one, such as "sign with time-stamp".  But in Nick's case, we've gone back
and forth over whether the Verify or the Sign is primary.


>    So in your example below, the principle operation is the "Verify". 
>The client requestor must express their desire through use of (for 
>example) an "AddContentTimeStamp" option or something similar.

That's one way to do it - another way is to have a hybrid <VerifyAndSign>
operation, with a request message similar to <VerifyRequest> (which sends a
signature) and a response message similar to <SignResponse> (which returns a
signature).

I haven't looked into this enough to be able to really defend it, it just
feels "righter" to me that trying to shoe-horn this into either the Signing
or Verifying protocol.  How does this grab you?

Trevor 




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]