BCSS - person signing (eSigning)

Abstract

Buypass Remote eSignature Service implements parts of the REST API defined by the Cloud Signature Consortium (CSC) Protocol version 2.0 and supports the creation of advanced and qualified signatures using short-lived keys and certificates.

The intended audience for this documentation is service providers assuming the role of “Signature Application Provider” (SCASP) as defined in the CSC specification. This document should, together with the CSC specification, contain all the details needed to create a functioning client consuming the Buypass Remote eSignature Service API.

Another group of audience for this documentation is service providers assuming the role of “Identity Proofing Service Provider” (IPSP). An Identity Proofing Service Provider (IPSP) is responsible for authenticating the end user by using the eID means.  Identity proofing of trust service subjects (i.e. the end users) is considered to be a trust service component provided by this specialized Identity Proofing Service Provider acting as a subcontractor to Buypass as the TSP.

Child pages:

Table of Contents

Overview

For reference in the following text, the figure below shows

• The services involved in the creation of a signature, as well as the subsystems comprising Buypass Remote eSignature Service

• The overall control flow and data exchange in the solution

Open

Step description

1. User requests to sign a document

2. SCA sends an authentication request to the eSignature OIDC server

3. eSignature OIDC server delegates user authentication to an external IDP

4. The user presents an ID instrument and is authenticated

5. The external IDP returns tokens containing proof of authentication and ID claims to eSignature OIDC server

6. The eSignature OIDC server translates the (possibly IDP-specific) ID claims to a standard set of claims to be included in the signing certificate.
   The End-User accepts the creation of short-lived certificate and user agreement.
   An access token authorizing certificate issuance and signing is then returned to the SCA.
   The ID claims are retained in the OIDC server.

7. The SCA sends a request to issue the signing certificate to the SSA.
   The request uses the /credentials/list endpoint according to the CSC specification, and is authorized by the access token received by the SCA in the previous step.

8. SSA accesses the OIDC /userinfo endpoint to exchange the access token for a set of the user’s ID attributes.

9. SSA receives the ID claims in the response body from the OIDC server.

10. SSA requests the SAM to generate the user’s signing key pair.

11. SSA receives a blob with the key pair (public key and encrypted private key).

12. SSA constructs a CSR (Certificate Signing Request) containing

    • The ID attributes received from the OIDC server

    • The public key received from SAM
      The CSR is then signed with the user’s private signing key by the SAM (not explicitly shown in the drawing), and the CSR is submitted to the CA.

13. SSA receives the user’s short-lived, qualified signing certificate from the CA.
    The certificate and the (encrypted) signing key blob are then stored in a memory-based cache in the SSA.

14. SSA returns the certificate to the SCA.

15. The SCA then prepares a set of attributes to be signed, including the document hash, certificate reference, signing time and possibly others.
    The set of attributes is then hashed, and the resulting hash is submitted to SSA for signing through the CSC-specified /signature/signHash endpoint.
    The signing operation is authorized with

    • the access token previously issued, which must then have both the service and credential scopes, or

    • a new access token having the credential scope

16. SSA assembles a SAD (Signature Activation Data) structure which is needed to authorize the signing operation in SAM.
    The SAD is signed with an HSM-based key which is dedicated to this purpose.

17. SSA sends a signing request to SAM. The request contains the hash value(s) to be signed as well as the signing algorithm to be used.
    Use of the SAM’s signing endpoint is authorized by the SAD.

18. The SAM verifies the SAD and creates the digital signature with the user’s private signing key in the HSM.
    The signature is then returned to SSA.

19. SSA returns the signature to SCA according to the CSC API specification.

20. The SCA then

    • collects the necessary elements for LTV (Long Term Validation), typically revocation information and a certified time stamp,

    • assembles the complete signature according to the format required by the document type,

    • returns the signed document to the user.