RE: [dss] Signature Gateway Profile

[Glenn.Benson@chase.com]

The RequestUpdatedSignature optional input instructs the DSS server to
return a new or updated signature.  The type defines “exactly what it means
to update the signature”.  The resultant UpdatedSignature may contain “the
original signature with some additional unsigned signature properties…”, or
alternatively, it may contain “an entirely new signature calculated on the
same input documents as the input signature”.  When considering the
Signature Gateway Profile, I am concerned that these semantics may be a bit
too restrictive.  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 answer
to this question depends upon whether or not the original VerifyRequest
contained the ValidateManifest element.  The third party cannot answer this
question unless it trusts the requester.  However, one would prefer that
the third party only needs to trust the DSS Server.  I think that this
issue is a general with respect to the DSS core.  However, it would be
acutely critical in the Signature Gateway Profile because intent of the
profile is to produce information to be consumed by a third party.

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.  If I missed some aspect
that is already present in DSS, then I would be glad to solicit assistance
so that I can proceed with the task of specifying the Signature Gateway
Profile.  Otherwise, I would like to submit for consideration the following
sketch of a solution.

We may expand the syntax and semantics of ReturnUpdatedSignature so that it
includes optional ds:References.  If ReturnUpdatedSignature contains
ds:References, then we change the semantics so that the DSS server
overrides the currently described processing options, and instead signs the
ds:References.  We probably need to restrict the ds:References permitted in
a ReturnUpdatedSignature so that they only reference specific elements of
the VerifyRequest and/or the originally signed document.  We probably need
these restrictions in order to avoid the case of the DSS server signing
information that it never sees.  In addition, we would need to add an
optional ID attribute affixed to most of the elements in a VerifyRequest.
For example, we would need to add an optional ID attribute to
VerifyManifests.

We would additionally require further flexibility in the resultant
UpdatedSignature.  Since the requester asks for a signature of multiple
different items, the UpdatedSignature should provide the option to locate
the signed items in a contiguous location.  The DSS server should also have
an additional option to include ds:References in the contiguous location.

Comments?