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

[Trevor Perrin <trevp@trevp.net>]

At 05:13 AM 3/19/2004 -0500, Pieter Kasselman wrote:

>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.


Trevor