RE: [dss] RE: ProcessingOptions example and discussion

[Tim Moses <tim.moses@entrust.com>]

Colleagues - OK.  Let's get a list of compound operations before we decide
how to deal with them.  If there are three primitives (V,S & T) and if it is
not valid to repeat an operation and if it makes no sense to do V anywhere
but as the first operation, then there are four possible dual-operations and
two possible triple-operations (see below).  I don't think it makes sense
for us to say which of these are invalid: someone may one day want to do any
one of them.  We should simply provide the framework in which one could do
any one of them.  All the best.  Tim.

Here they are ...

VS, VT, ST, TS, VST, VTS.

This list omits archival (and other things) because they are outside the
scope of our charter.


-----Original Message-----
From: Trevor Perrin [mailto:trevp@trevp.net]
Sent: Tuesday, September 02, 2003 1:51 PM
To: Tim Moses; 'Nick Pope'; OASIS DSS TC
Cc: Ed Shallow
Subject: RE: [dss] RE: ProcessingOptions example and discussion


At 10:39 AM 9/2/2003 -0400, Tim Moses wrote:

>Colleagues - Forgive me if I have missed a step in this discussion. But,
for
>my part, I would like to see an enumeration of all anticipated compound
>operations,

That would be a big step forward.  The compound operations I see are:
  - sign-with-timestamp
  - verify-then-sign (i.e. "update" or "refresh")

Do we want to support others?  There was a little talk at the f2f of doing 
multiple signatures or verifications in a single request/response, but I 
think we decided against that.


>an enumeration of the technical options for supporting compound
>operations and a discussion of the pros and cons of each approach.
>
>Without giving it too much thought, it seems to me that there are at least
>four possible approaches ...
>
>1. All operations are atomic.  Compound operations are built by clients
>making multiple calls to different services.  Some technique for linking
the
>output of one operation to the input of the next would have to be defined.
>
>2. Request messages can be concatenated, with an option to indicate that
the
>input token in one request is to be the output token from the previous
>request.
>
>3. All operations (including compound ones) are identified by their own
>request type identifier.  We would define a few useful ones.  Others could
>define their own in profiles.  Each compound-operation message should be
>derived from the general message syntax defined in the core document.
>
>4. Compound operations are variants of our existing sign, timestamp and
>verify request types.  All variations in syntax would have to be captured
in
>the basic syntax.

That's a good list.  I'd like to first understand what compound operations 
are in scope, and then return to the list in deciding what mechanisms are 
needed.

Trevor