RE: [dss] Signature Gateway Profile

[Trevor Perrin <trevp@trevp.net>]

At 11:26 AM 11/6/2004 -0500, Glenn.Benson@chase.com wrote:

>[...] When the VerifyRequest does not contain a
>RequestUpdatedSiganture, the requester communicates with the DSS server for
>the purpose of discovering ephemeral information.  The requester can use
>this information any way that it wishes.  However, if the request contains
>a RequestUpdatedSignature, the requester obtains a token of consequential
>evidence that can be re-validated by other parties.
>
>Unfortunately, the third party cannot unequivocally determine the intent of
>the DSS server.  For example, the third party does not know if the DSS
>server validated the manifest before producing the signature.

The updated signature can contain an indication of signature policy.  For 
example, if the updated signature is an XAdES signature, it can contain a 
SignaturePolicyIdentifier specifying whether or not Manifest Verification 
was performed.


>[...]I would also like to expand the requester's flexibility when it submits a
>request for the signature.  The requester should, for example, request a
>signature of (i) the original document, (ii) a countersignature of the
>original signature, or (iii) both of the above.

For (i) and (ii), simply define different URIs for the 
ReturnUpdatedSignature/@Type attribute.  For (iii), right now only one 
occurrence of ReturnUpdatedSignature can be sent per request (see section 
2.7, 4th paragraph).

We could change that, and have the returned <UpdatedSignature> elements 
contain a 'Type' attribute so clients can match outputs with inputs.  That 
seems like a worthwhile feature, what do you (or anyone else) think?


Trevor