[dss] DSS Use Cases...

[Carlisle Adams <carlisle.adams@entrust.com>]

Title: DSS Use Cases...

Hi all,

In order to get the ball rolling on use cases, I would like to submit to the DSS Use Case subcommittee three use-case scenarios for the digital signature service: corporate seal, SOAP signing, and identified requester.

It is not expected that a single private key would be used to support all three scenarios (e.g., that the same key would be used to sign both corporate documents and SOAP XML messages).

Comments on these use cases are welcome!

Carlisle.

8<--------------------------------------------------

Corporate Seal

This scenario has a corporation using the Digital Signature Service interface to sign documents before the publication of these documents to external entities (either as hosted HTML or as distributed Word or PDF docs). The assumption is that the published document contains some statement that the corporation is making to its business partners, customers, investors, analysts, etc. - the nature of which is important and sensitive. The primary motivation for the signature is to ensure the integrity of the published document so that relying parties can be confident that the material within has not been modified. (The signature will also serve to reinforce the identity of the corporation that published the document - this information presumably also asserted through the internal content such as logo, titles, copyright notices, and so on.)

The benefit of this use case derives from the assumption that in practice it will be easier to securely distribute a corporate public key for verification of such signatures than the private keys of a dynamic list of individuals within the corporation who might create the documents that require these signatures.

<<...OLE_Obj...>>

SOAP Signing

This scenario has a 3rd party Web service requester or service provider calling out to the Digital Signature Service interface for the application of a signature to some SOAP payload (and potentially envelope elements) before sending the signed SOAP message to the other participant.  This scenario is identical to the Corporate Seal scenario except for the entities involved.  In particular, it is not expected that the Digital Signature Server will need to understand, parse, or formulate SOAP-compliant messages:  as with the Corporate Seal scenario, the data it receives will be an opaque binary "blob" and the data it returns will be an XML Signature on that "blob".

A variant of this scenario has the request coming not directly from the application itself but from a so-called SOAP gateway sitting in front of the application. The Digital Signature Server (and any future Relying Parties) will be unaffected by such a modification to the architecture.

<<...OLE_Obj...>>

Identified Requester

In this scenario, the Digital Signature Server is signing on behalf of an individual requester and makes an assertion to that effect in the returned response. This scenario differs from those of Corporate Seal and SOAP Signing in that the identity of the requester is not returned in the response in those scenarios.

Where the actual Service Requester is itself acting on behalf of some other entity (e.g., a browser-based application requesting a digital signature for the individual), it may be relevant for the Digital Signature Server to assert the complete request chain in the response it returns.

The Digital Signature Server may sign all data with its own private key and simply include the name or identifier of the requester(s) within the scope of the data that is signed.  Alternatively, the Digital Signature Server may sign on behalf of a requester using the requester's private key, which is stored at the Server.  In either design, this use case may be motivated by assumptions regarding efficiency (e.g., hardware-assisted cryptography), centralized policy management and enforcement, and assurances with respect to safeguarding of private keys.

Identified Requester can be regarded as a variant of the other two use-case scenarios.