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
