RE: [dss] Groups - oasis-dss-1.0-profiles-codesigning-spec-wd-01. doc up

-----Original Message-----
From: Pieter Kasselman [mailto:PKasselman@betrusted.com]
Sent: 22 March 2004 08:50
To: 'Trevor Perrin'; Pieter Kasselman; Pieter Kasselman; dss@lists.oasis-open.org
Subject: RE: [dss] Groups - oasis-dss-1.0-profiles-codesigning-spec-wd-01. doc uploaded

Hi Trevor, we can keep the async behaviour in the profile, but I would prefer to have the TryAgainLater in the core (there are other reasons why the server may ask the client to try again later - i.e. it may be very busy). The TryagainLater can then be further qualified through a ResultMinor error code (ServerBusy etc). It is small enough and I doubt if it influences anything else. Using the ResponderError when there is no error is as abusive as responding with Success when there is no signature.

We can also allow profiles to define their own <Result> codes, in which case everything goes into the profile, although I would prefer the option where it is kept in the

-----Original Message-----
From: Trevor Perrin [mailto:trevp@trevp.net]
Sent: 19 March 2004 23:12
To: Pieter Kasselman; Pieter Kasselman; dss@lists.oasis-open.org
Subject: RE: [dss] Groups -
oasis-dss-1.0-profiles-codesigning-spec-wd-01. doc uploaded

>Thanks Trevor, in general I like the idea of fitting as much as possible
>into the exisiting framework. I guess a key question is if the
>code-signing profile is the only profile that will require asynchronous
>support, or if there are other profiles that require this as well?

At the F2F we decided this wouldn't be a V1 requirement, and I don't recall
much objection, so I suspect there isn't a strong immediate demand for
this. But I could be wrong.

I like Nick's idea of experimenting with this in the code-signing profile,
and moving it to the core later if the demand arises.

>So I still like re-submission, since it accomplishes much of
>the functionality of <RequestReference> at less cost.
>
>[Pieter Kasselman] Maybe from an implementation perspective, but the
>server has to do more work and more bandwidth is consumed. Looking at the
>proposed benefits in detail: - "allows the server to quickly track the
>status of the request" - it seems not too hard for the server to
>canonicalize and hash the request, and use that as a "request reference".
>
>[Pieter Kasselman] This is still more work than taking a reference and
>checking it. On a busy server this will add up.
I still weigh simplicity/reusability of client code as more important, but
I see your point.

> - "conserve bandwidth" - Bandwidth can be reduced by using
> <DocumentHash> input documents. If it's important for the server to
> have the whole application to review, you could use <Document> for the
> 1st request, and <DocumentHash> for the 2nd.
>
>[Pieter Kasselman] OK, in this model the request reference is fixed as
>the hash of the document, which precludes other types of request
>references that may include additional information (e.g. authorization
>assertions etc). Granted these can also be found by indexing of the hash
>value. If we take this approach, can we include some kind of an
><OptionalInput> element to indicate that this is a retrieval request
>rather than a new request?
We could also let the server infer it (it would check if the request
matches any pending request). Either way seems doable.

[...]
>[Pieter Kasselman] OK, so lets go for the small token (such as using the
>DocumentHash) and see how we can fit it into the exisiting framework :).

Sure. My 2 objections were to:
- signature "successes" that don't return a signature
- sending requests with no input documents

So using a special failure value ("TryAgainLater" or something) instead of
"Success", and using a re-submitted <DocumentHash> instead of
<RequestReference>, eliminates those issues.

I guess we should discuss whether the "TryAgainLater" value should be
defined in the core document or not. It seems okay to put it in the core
now, since it's fairly generic. Though maybe we don't want to tweak the
core at this late date. In which case we could do it as a ResultMinor
code for ResultMajor=ResponderError, or something.

dss message