The ADSS Verification Service is a server-side solution for both verifying digitally signed documents and validating certificates (checking the certificate is not expired, not revoked, signed by a trusted CA, etc.). A typical workflow is as follows:


  1. An end customer sends a signed document to a client application (e.g. a signed purchase order, an invoice, a report etc.). The end customer’s signature may be one of the following types: PDF signatures, PDF Timestamped Signatures, PDF Signatures with Timestamp and revocation information for the signer's certificate chain, PKCS#7/CMS, PKCS#7/CMS Timestamp Signatures (CAdES-T), PKCS#7/CMS Timestamp Signatures with revocation information for the signer's certificate chain (CAdES-X-Long), XML DigSig, XML DigSig with Timestamp (XAdES-T), XML DigSig with Timestamp and revocation information for the signer's certificate chain (XAdES-X-Long) or S/MIME formats. The document may have been signed multiple times (as part of an approval process). The signers’ certificates may have been issued by various different CAs.
  2. The client application wishes to delegate all the complexity of signature verification to the ADSS Server, hence it makes a signature verification request to ADSS Server and passes the signed document within this request. Note Ascertia also provides an ADSS Gateway component that removes the need to transmit the entire signed document to the ADSS Server (for instance in cases when it is being operated by an external service provider).
  3. The ADSS Verification Service performs all the standard signature verification checks to ensure that the signature has been signed correctly, that the signer’s certificate was issued by a recognised and trusted CA and is not expired, etc. As part of this signature verification algorithm, ADSS Server will also request certificate status information from the relevant certificate status provider; either in the form of CRLs which it retrieves regularly based on a particular polling policy or a real-time OCSP call
  4. The certificate status service provider will return the certificate status information.
  5. ADSS Server will then provide a signature verification response showing the overall status of each signature in the document as “trusted”, “not trusted” or “indeterminate”. Note ADSS Server can also return various items as evidential information, including the OCSP response if specifically requested by the client application.

Note it is possible for the client application to perform signature verification itself and only delegate certificate validation to the ADSS Verification Service; in this case ADSS Server only performs the subset of the above checks relating to certificate validation.

Creating long-term signatures from basic signatures as part of the ADSS Verification process

In some environments there could be a requirement that the Client Application enhances the end-customer's basic signature to become a long-term signature, so that its validity can be proven in the future.  The Client Application can request this from ADSS Server as part of the verification request message.  In such a scenario the ADSS Verification Service will verify the signature, including the status of the signer's certificate chain, and if successful then actually embed this evidential information inside the user's signature, for future reference. The ADSS Verification Service will also embed a timestamp from a configured Time Stamp Authority (TSA) within the end-customer's signature, so that a long-term signature is formed. This long-term signature will be returned to the Client Application.

See also

Identity Proven, Trust Delivered
ADSS Server Features and Benefits
ADSS Server Trust Services
ADSS Server Architecture & Interfaces
ADSS Signing Service Overview
ADSS Verification Service Overview
ADSS Certification Service Overview
ADSS OCSP Service Overview
ADSS TSA Service Overview
ADSS XKMS Service Overview
ADSS SCVP Service Overview
ADSS LTANS Service Overview
ADSS Decryption Service Overview
ADSS CRL Monitor Overview