[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dss] Signature Gateway Profile
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?
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]