Home > Concepts & Architecture > ADSS Signing Service Overview

ADSS Signing Service Overview

The purpose of the Signing Service module is to apply digital signatures to electronic documents. There are three different ways in which the ADSS Server Signing Service can be utilised to sign documents:

• On demand, server-side signing of documents using signing keys/certificates held at ADSS Server
• On demand, client-side signing of documents using keys/certificates held by the user on a smart card, secure USB token or in the browser’s software keystore
• Watched folder automated signing of documents using signing keys/certificates held at ADSS Server.

The three modes of signing are discussed briefly below:

On Demand Server-Side Signing

This mode is characterized by the fact that documents are digitally signed at ADSS Server. The workflow is as follows:

• The client application makes a call to the ADSS Signing Service and supplies the document to be signed and the details of the signing profile configured at ADSS Server to be used for this signature.  The signing profile identifies the type of signature to be produced, which signing key is to be used, which type of visible signature appearance to create etc.  Most of the configurations defined by the signing profile can be over-ridden by the client application during the call if required.
• ADSS Server then signs the document according to the requirements of the identified signing profile and returns the signed document back to the client application as illustrated below.
  
  

               

Note that ADSS Server can manage multiple signing keys and certificates and thus the Signing Service can sign documents using unique keys for multiple corporate or individual end-users. Also note that the signature may be attached (as shown), embedded (e.g. inside a PDF) or detached (i.e. the signature exists on its own, separate from the original document).

For example, the client application may be a web application responsible for registering Internet-based end customers and generating their keys/certificates using the ADSS Certification Service (explained in the section ADSS Server - Certification Service). Subsequently these customers can sign documents using the ADSS Signing Service with their unique keys held on the ADSS Server. The following illustration explains this workflow:

The following workflow description explains the process shown in the diagram above.

1. An end customer or a client business application performs an online transaction that results in a document to be signed by the end customer. The client application initiates the signing process by requesting the authorisation code from the end customer. The end customer provides the authorisation to sign the document, typically after having viewed the document to be signed in the customer’s browser.
2. The client business application then makes a signing request to the ADSS Signing Service requesting the signing of the transaction document on behalf of the end customer. The client application also provides the signing profile, details of the customer’s signing certificate and also the authorisation code supplied by the customer to unlock the customer’s private key. This request message from the client application to ADSS Server may optionally be signed and transported over a client-server authenticated TLS session. This communication is currently synchronous although asynchronous mode (e.g. using email-based signing requests) can also be supported upon request.
3. The ADSS Signing Service verifies the request message and checks that the customer’s authorisation code successfully unlocks that user's private key. If so the Signing Service then signs the document and returns it to the client application.
4. The client application can then archive the signed document locally and/or provide it to the customer.

This is just one example of a possible workflow – the ADSS Server is flexible enough to support multiple business workflow scenarios. 

In both the use cases (i.e. corporate signing and end-user signing) above, the ADSS Signing Service supports PDF-based signatures, PKCS#7 / CMS and XML DigSig signatures. The ADSS Signing Service can also optionally embed a cryptographic timestamp issued by an external Time Stamp Authority (TSA) to independently prove the exact time of signing. It is also possible for the ADSS Signing Service to embed an OCSP Validation Authority response to create an ETSI AdES long-term signature (this proves that the signer’s signing key was valid at the time of signing).  CRL based revocation information can also be embedded by ADSS Signing Service although this is only recommended if the size of CRLs is small, as otherwise the document size will become bloated because of the embedded CRL.

The ADSS Signing Service request /response protocol schema is described in the ADSS Developer Guide. Client application developers can build their own web services call handlers, or use the Ascertia provided Java or C# client wrappers.

On Demand Client-Side Signing (Zero Footprint Signing)

This mode of operation is characterised by the fact that end-users hold their signing keys locally within the Windows key store or perhaps on smartcards or USB secure tokens; and they wish to use these keys and certificates to sign documents on their desktop systems. The Ascertia Go>Sign applet has been created specifically to allow such end-users to sign documents without requiring any signing software to be installed on the client-side machine. In such cases the ADSS Signing Service can be called upon to produce a hash of the document to be signed, and then the hash value is actually signed by the Go>Sign applet within the customer’s browser environment. The ADSS Signing Service then receives the signed hash value and embeds this back into the document to form the final signed document. The following diagram illustrates this process:

 

1. The end customer and client business application participate in a business transaction resulting in the production of a document that needs to be signed by the end customer. The document is expected to be viewed within the browser (e.g. as a PDF document using Adobe® Reader) and the user is then requested to sign it.
2. If the end customer decides to proceed with the signing process, the client application requests ADSS Server to hash the document.
3. ADSS Server returns the hash value for the document.
4. The customer’s browser downloads the Ascertia Go>Sign applet and the hash value to be signed.
5. The Go>Sign applet requests the user to sign the hash value using their smartcard, and once signed the Go>Sign applet sends the signed hash value to the client application.
6. The client application sends the signed hash value to ADSS Server for embedding within the original document.
7. ADSS returns the assembled signed document back to the client application (i.e. the document with the signed hash value embedded inside it).
8. The client application can display the document in the browser, archive it or send it to the user.

The process above is only a high-level representation of the workflow and there can be variations. Ascertia also provides a range of applets for different business scenarios including one for hashing, signing and assembling document signatures locally without requiring the ADSS Server. Ascertia can also provide a version of the Go>Sign applet which allows PDF documents to be viewed locally within the secure applet viewer.  Furthermore, Ascertia can provide a version of the Go>Sign applet which uses roaming credentials (i.e. a secure key container delivered to the applet from the ADSS Server) to provide the ability to sign from any machine without need for a physical smartcard/token. For more details regarding different Go>Sign applet versions, please contact info@ascertia.com.

Watched Folder Signing - Using the Auto File Processor (AFP) Client Application

1. AFP then makes signing requests (using a pure optimised HTTP interface for high performance) to the ADSS Signing Service
2. ADSS Server signs the documents using an identified signing profile and returns the signed document to the AFP
3. The AFP then saves the signed document in a configured output folder.

For more details on ADSS AFP application, please see the separate manual for this product. Please note the supported signature formats are PDF signatures, PKCS#7/CMS and XML DigSig. For PKCS#7/CMS and XML DigSig you can select whether the signature should be “enveloping” or “detached”. ADSS Server can also produce long-term signatures with embedded cryptographic timestamps and OCSP/CRL revocation information.

See also