Developed by Sasikumar Ganesan, Jurgen Niinre, Dr. P. S. Ramkumar, Kassy Kadio, in cooperation with GIZ, ITU, and DIAL

To facilitate the eSignature service as described in section 2, the Building Block must have specific Key Digital Functionalities.

4.1 Hardware Security Module

The Hardware Security Module (HSM) is an integral part of the eSignature Building Block. The HSM ensures the protection of a key with utmost safety. Without an HSM the key can potentially fall into the wrong hands and could result in huge mistrust. All keys used in our one-time signatures are created, used, and destroyed within the HSM. The HSM should be configured with FIPS 140-2 Level 3. This device will follow PKCS11 or JCE standards.

4.2 Signature Creation/Seal Device

The eSignature creation device (SCD) is the component where the user's private key would be stored. The SCD could be a Smart card, Mobile App, Sim card App, or equivalent. The SCD interacts with the eSignature Building Block using its own internal protocol. Every eSignature Building Block will support one or many such SCDs. Most of the SCD would be protected with a secure PIN/Biometrics.

The SCD should be qualified with at least one of the following FIPS 140-2/3 Level 3 or Annex II of Regulation (EU) No 910/2014 (eIDAS) or equivalent common criteria certification.

4.3 Timestamp

The time of a sign is an important part of the signature. Without a proper time of the signature, we can never trust the signature, as one can not find if the signature happened before its expiry or after expiry. Most often this functionality is provided by the timestamping server hosted by the CA. This service follows RFC 3161

4.4 One-Time Signing Service

This is one of the most important functionality of eSignature. This service is responsible for providing the One Time Signature API and interacts with the Hardware Security Module (HSM). This service validates the user against the Authorization Building Block. A valid user is allowed to create a key in HSM and sign it. Every key created here will also need an X509 certificate. The certificate management module will publish this created X509 certificate.

Keys created during One Time Signature should be deleted after the signature process. Logs SHOULD be kept in a database of the details of the deletion. Logs MUST include timestamps and identify the user and affiliation that performed the transaction.

4.5 Signature Creation Device On-Boarding

eSignature creation device (SCD) On-Boarding is the module responsible for binding the SCD and user. The module interacts with the Identity Building Block and will validate the user's presence before issuing the Certificate. This module is responsible for talking to the SCD for all types of key management and administrative needs. This module is hosted on a server and would ensure the keeping of clear audit records and Know Your Customer/Client (KYC) records.

4.6 Signature Creation Device Signing

The SCD Signing is one of the vital functions of the eSignature Building Block. When a user holds its key in an SCD then this module is responsible for interacting with the SCD to sign any required document. This module works in asynchronous mode. A signature is requested on demand using the API. However, the module interacts with the SCD asynchronously. The module is responsible for connecting to SCD for all signing purposes.

4.7 Certificate Management

All certificates that are created within the SCD will be hosted in this module. The module lets everyone have their X509 public certificate hosted for any verification. The module should have an administrative ability to allow people to revoke the keys on demand. The module has to maintain the OCSP & CRL-based revocations. Key revocation is not available in Onetime Signatures as the certificate is short-lived.

4.8 Notification

This module is responsible for notifying the SCD device when a signature is needed. This helps the SCD to alert the user. The user can look through the notification and accept to sign the document. The module is also responsible for notification of a signature to the user's mobile phone/email/SCD. The notification to the user can be used as an audit record by the user. This interface abstracts the messaging with an omnichannel interface. The notification Building Block can be used to send notifications to the end user/device.

4.9 Public Observation Interface

This interface handles the necessary health, metrics, traceability and legal needs for the given Building Block. While there are no certain standards to this, it is recommended to follow the OpenTelemetry design to address some of the challenges. Issuance of signature certificates is usually backed by several legal regulations. The requirements can range from KYC details available upon Judicial intervention, Revocation and Transparency of the revoked certificate as per OCSP/CRL (Similar to RFC 6961/RFC 5280) and Dispute Resolution.

4.10 Signature Backend

Once the signature is completed the signature backend keeps the signature until the eService server makes a request. Once the eService has received the Signature Token (SignatureId), It can request the eSignature BB to send the final signature. Once the Signature Token is validated the BB sends the signature. This happens over a backend-protected channel.

4.11 eService Callback

This is the callback service available in eService. Once the signature is complete the user will be redirected to the eService. This module is responsible for understanding the redirect request and the HTTP parameters that are passed during this redirection.

4.12 Signature Validation

This module is responsible for validating a digital signature. This is provided as a library. A format-specific validation library should be provided. The majority of the format adopted in this specification provides a clear explanation of how to validate the signature. But in a few specified formats like ASC, it may be necessary for the signature service to explicitly state the validation mechanism. It is also expected that the service provider will provide a library, application (optional), and online service(optional) to validate the signature.

The Cross-cutting requirements described in this section are an extension of the cross-cutting requirements defined in the architecture specification document.

5.1 Hardware Security Module Compliance (REQUIRED)

HSM must be compliant to a minimum of FIPS 140-2 Level 3. This guarantees the protection of private keys. HSM/Key Management application shall not print any information about the end-use details. Keys should be created only within the HSM. This may apply to all other Building Blocks when dealing with cryptographic keys.

5.2 Audit (REQUIRED)

All audit logs shall be integrity-protected against tampering. The eSignature Building Block shall follow the data policy and audit logging requirements as laid out in the GovStack architecture.

5.3 Privacy (REQUIRED)

Signing using a single key can compromise the user's privacy in the long run. For example, a single key used to sign the consent of health form and agreement of the medical insurance could reveal that the consent and the agreement are from the same person. Generally available signed documents could be used to perform 360-degree profiling. This violates the Generic Architectural Privacy recommendation. Privacy-preserving techniques can be used in signature schemes, document storage, or reducing the key's lifespan to protect the user's privacy.

5.4 Logging

• The system shall provide traceability across services using trace ID or similar design patterns. (REQUIRED)

• The system shall provide logs to help debug the problems. (REQUIRED)

• The system shall not print sensitive information. (REQUIRED)

  • Private Key

  • User details

  • Authentication Token

  • Payment Token

  • Signature of the document

  • Full Certificate (Thumbprint is allowed to be printed)

  • User PIN

  • OTP

• In case a user/mobile app is involved, then logging shall provide traceability from the app to the server. (REQUIRED)

eSignature Building Block provides the necessary functionalities to bring handwritten signatures to the digital world. Handwritten signatures have served as a way to agree/witness a given document, yet, in today's digital world most documents are in digital form. The digital form varies between structured (XML, JSON) and unstructured documents (PDF, Word, Image, CSV, Spreadsheet). eSignatures can be added to digital documents similar to handwritten signatures achieving the same functionality.

Additionally, eSignatures improve user experience in managing the signing process as the same can be embedded directly in e-Services, leaving out the need to print out forms, sign on paper, scan, and upload/send.

eSignature provides a considerable advantage over handwritten signatures because of the availability for verification at any point in time. This allows for remote validation of signatures, content (content being the same as that during signing), identity, and time. This assurance allows us to trust a signed document remotely and can be used for legally binding agreements. Sample use cases include:

• Submitting applications to Government agencies (e.g. Child Care, Residence Registration, Marriage, etc.)

• Purchase and use banking services (i.e. making transfers, adding transfer limits, applying for loans)

• Purchasing telecom services (i.e. purchase SIM/eSIM, change contract, add a TV subscription)

• Purchase utility services (i.e. new contract for electricity, gas)

• Purchase insurance contract

With eSignature there is no need to print documents on paper anymore, saving a lot of paper and promoting a green lifestyle. This can also save money and can be calculated with andesigned for the eSignature practice.

2.1 Current scope

• Ability to support eSignature for everyone.

• Ability to support eSignature through a specialized user device/card.

• The ability for third-party services (including other Building Blocks) to interact, sign, and verify the eSignatures in a standardized model.

2.1.1 Actors

• Users: people or applications (delegated by a user) who use the eSignature Building Block to give eSignatures.

• Services: third-party services that require a user eSignature to provide the service.

• Auditor: individual or organization that reviews the platform for any misuse (intentional or unintentional)

• Administrator: individual or team that configures the eSignature Building Block and is responsible for ensuring the functioning of the Building Block.

• Certification Authority: a certification authority that can issue a certificate as X509.

• Timestamp Authority: a trusted third party who can provide certified time.

2.2 eSignature Lifecycle

There are two lifecycles available for the eSignature Building Block. Both mechanisms have their own unique advantages, therefore it is recommended to follow both for an inclusive approach.

2.2.1 One-Time Signature Approach

One-time signatures are one of the easiest ways to get large-scale adoption of eSignatures. This approach does not require any device to be owned by the end user. This approach relies on the work done by the ID Building Block to authenticate an end user.

• User authenticates against the ID Building Block

• The user is redirected to the eSignatures Building Block

• A new key pair is created in the HSM (Hardware Security Module)

• An X509 Certificate is issued with the details from the ID Building Block (Name, Age, Gender, Location)

• The new key is used to timestamp and sign the document

• The X509 certificate is set to expire 1 minute from the time of creation

• The signed document is sent

• The private key is deleted from the HSM

2.2.2 SCD-based approach

The SCD (Signature Creation Device) is a personal device of the user. It could be a Mobile Phone, SIM card, Smart Card, Secure SD Card, USB Storage device, NFC Card, etc. The SCD device can be used to store the keys for long-term usage. This allows the user to interact with the ID Building Block once and create a key on the SCD. This key then can be used for signing any document without interacting with the ID Building block.

The binding of the private key with the user is called On-boarding. In this process, a user is authenticated and his key is created on the SCD.

• User authenticates against the ID Building Block

• The user is redirected to the eSignature page where his SCD device is detected

• The user is asked to select a valid SCD device and enter its security PIN/Biometric/One Time Password

• The eSignature Building Block interacts with the SCD (protocols are left open for implementation) to create a Key Pair

• A CSR (Certificate Signing Request) is created

• This request is sent to the eSignature Building Block

• The Building Block verified the ID Building Block token and the data in the CSR

• If they match then the CSR is converted to an X509 certificate and the same is issued back to the device

The key created on the SCD device can be used by the user to digitally sign any of the documents.

• The third-party who needs to sign the document will be redirected to the eSignature Building Block

• The eSignature Building Block will ask for the pseudonym (eSignature handle) from the user

• The user provides the pseudonym to the eSignature Building Block

• The eSignature Building Block sends a notification to the SCD (Internal Protocol)

• The user is shown his choice to sign or not to sign

• Once the user signs the SCD will send the signature to the third-party

• The Digital Signature will then be attached to the given document in one of the supported formats as described by the eSignature Building Block

2.3 Current Scope

2.3.1 This Building Block must enable the user to

• View and provide consent to the document that is about to be signed

• Register the user's Signature Creation Device (SCD)

• Confirm the signature with a PIN code on the user's SCD

• View user's SCD-s and certificates

• Digitally sign the documents (PDF, Word, Excel, JSON, XML, Image)

• Use a personal device to store the keys safely

• Ability to sign the document where the user has no device

• Ability to sign a document without the involvement of ID Building Block

• Ability to sign a document using only the ID issued by the ID Building Block

  User

• Ability to view the list of signings performed

2.3.2 This Building Block must enable other eServices to

• Invoke eSignatures to obtain a digital signature

• Sign the digital document in the desired eSignature format

• Allow a safe async way to obtain signatures

• A simple-to-use library to validate the eSignature

2.3.3 This Building Block must enable an auditor to

• Retrieve and review specific audit data

• Validate and get signatures on any audit data

• Audit cryptographic functioning and compliance for auditing and key security

2.3.4 This Building Block must enable the administrator to

• Configure the system without intervening with the signature process

• Administer without modification or tampering with the data or key security

2.4 eSignature library

eSignature Building Block will provide a helper library for the Services. The helper library could be used to integrate eSignatures faster.

• Get digital document digest to be sent to eSignature Building Block. Obtaining just the hash reduces the storage overhead and also avoids the privacy concern of sending the original document.

• Embedding received eSignature back into the document or attaching it in case of detached signatures.

• Validate digitally signed documents and the validity of the certificate.

2.5 eSignature formats

Supports the following signature formats:

2.6 Authentication and Security

In order for eSignatures to be secure and adhere to privacy regulations the eSignature Building Block uses the following levels of authentication,

• Authentication via ID Building Block: the service that uses eSignature will have to authenticate the user against the ID Building Block.

• Unique pseudonym: the service is redirected to a webpage on the eSignature portal where the user can enter a unique pseudonym known only to the user to start the signing process (without a pin, the signing will not be complete).

• Asking for a PIN code on the user's device: eSignature Building Block will send a request to the user's device so that the user can confirm the signing request with a PIN.

• The signature will be returned using an internal API protected by the Information Mediation Building Block.

2.7 Audit Trail and Compliance

eSignature Building Block must log all signing transactions to be compliant with current regulations. The minimum details to be logged are:

• User's identity without revealing personally identifiable information.

• Document digest.

• Timestamp of the signing.

The eSignature Building Block has several functional layers within it. Some functional layers follow the existing set of protocols and custom protocols, While the other functional requirements are defined within this specification. In this section, we will provide a clear indication to state what blocks follow what kind of protocols.

6.1 Hardware Security Module

• In the case of the One-Time Signature, a Hardware Security Module (HSM) must be used to create cryptographic keys. (REQUIRED)

• It must be used to sign a certificate. (REQUIRED)

• Keys shall not be exported. (REQUIRED)

• MUST be protected well with best security practices. (REQUIRED)

6.2 Signature Creation/Seal Device

• Signature Creation Device (SCD) should have secure storage to protect private keys. (REQUIRED)

• SCD may have proprietary APIs with the eSignature Building Block. (REQUIRED)

• SCD is assumed to be with the user. (REQUIRED)

• A user's PIN is a must for the SCD. (REQUIRED)

• Keys shall not be exportable. (REQUIRED)

6.3 Timestamp

• For a valid signature, a timestamp server is a must. (REQUIRED)

• The timestamp server shall follow RFC3161. (REQUIRED)

6.4 Certifying Authority

• eSignature Building Block may be a certifying authority. (REQUIRED)

• If not, the Building Block shall have access to a certifying authority and be able to issue certificates or be a subordinate certification authority. (REQUIRED)

6.5 eSignature Service

• Service shall support the onboarding of the Signature Creation Device (SCD). (REQUIRED)

• Service shall support both the key functionalities of signing using SCD and One-Time Signature. (REQUIRED)

• The user shall be authenticated through the ID Building Block for the One-Time Signature. (REQUIRED)

• The user shall be allowed to perform a signature through a pseudonym without user login. (REQUIRED)

• Optionally can support payments through a payment gateway. (OPTIONAL)

• Shall support all the listed signature types. (REQUIRED)

• Shall support redirection and callback as per the specification. (REQUIRED)

6.6 Audit

• All user activities should be available for audit. (REQUIRED)

• May have the feature to tamper-proof the audit records. (REQUIRED)

• Auditors shall have the ability to get audit-proof of a transaction. (REQUIRED)

6.7 Certificate Management

• Shall provide the ability to list and revoke a certificate. (REQUIRED)

• The user shall have the ability to revoke their keys (API-based or through customer care). (REQUIRED)

• Certificates shall have any of the following statuses (REQUIRED):

  • Active – The certificate is active and can be used for signing.

  • Expired – certificates are expired and should be renewed.

  • Suspended – certificate is suspended. The reason for suspension shall be provided together with status information.

  • Revoked – certificate is revoked. The reason for revoking shall be provided together with status information.

• Users shall be able to view their certificates and corresponding statuses. (REQUIRED)

6.8 Notification

• Shall provide the ability to notify the user over email, SMS, app notification, or any other equivalent. (REQUIRED)

• The user shall be notified of failed and successful transactions. (REQUIRED)

6.9 Messaging Interface

• The Messaging interface should send relevant information to the logging sub-block to maintain the history of all messages sent from this Building Block, which are useful for audit purposes. (RECOMMENDED)

• The messaging interface should provide the necessary protocol, data format, and information and interface to interact with the Messaging Building Block for sending notifications to a specific target Signature Creation Device or user through a variety of channels (SMS/email/etc.) (RECOMMENDED)

Note: The keywords "must", "must not", "required", "shall", "shall not", "should", "should not", "recommended", "may", and "optional" in this document are to be interpreted as described in RFC 2119

6.11 Metrics

A Set of microservices is defined to receive requests from other GovStack-compatible Building Blocks and third-party Services with relevant inputs and return processed results from key digital functionalities of this Building Block. This section provides a reference for APIs that should be implemented by this Building Block. The APIs defined here establish a blueprint for how the Building Block will interact with other Building Blocks or third-party services. Additional APIs may be implemented by the Building Block, but the listed APIs define a minimal set of functionality that should be provided by any implementation of this Building Block.

eSignature Building Block must expose its microservices through RESTful API interfaces as defined by OpenAPI v3+ standards. A summary of the APIS exposed by this Building Block is summarized in the table below.

8.1 eSignature with one-time certificate

8.2 eSignature with user's eSignature creation device (SCD)

8.2.1 Certificate creation

8.2.2 List certificates

8.2.3 Update certificate

The update API can be used to revoke the certificate. All revoked certificates will be available over OCSP.

8.2.4 eSignature with user's device

8.2.5 Webservice to enter user pseudonym

8.2.6 User pseudonym API

8.2.7 Get signature response

8.2.8 Callback service API

8.3 Audit log

9.1 Workflow for one-time signing

This internal workflow is used by the eSignature Building Block to provide one-time signature. In order to make the sequence diagram easier to follow the eSignature Building Block is divided into front-end and back-end parts. Frontend constitutes the functionality running in the user's internet browser and backend refers to the API running on a server.

Workflow is kicked off by a third party using the eSignature client library to get a digest of document to be signed. Using the digest (hash) the redirection request is made towards the eSignature Building Block front-end. If required by the Building Block configuration, it will also check if the Payment token supplied by the request is valid. In the eSignature Building Block front-end, the user selects the option to use National ID to do a one-time signature. Then the user is redirected to the Identity Building Block to authenticate and user data is returned back to the eSignature Building Block back-end after completion of all standard interaction API calls. Then a Host Security Module (HSM) hardware is used to generate a temporary keypair. From that keypair, the public part is exported as a Certificate Signing Request (CSR). CSR is submitted to a Certificate Authority (CA) instance that will generate and publish a short-lived (1-minute) certificate based on the supplied CA.

After the certificate has been created the private key in the Hardware Security Module (HSM) is used to sign a document digest. After the document digest is signed, a timestamp is requested on the signature from the timestamping service. After the timestamp is generated and received on a signature, the results are saved into a database, and a signature ID is generated to reference the signature data. The signature ID is then returned to the eSignature front-end, and the user's flow is redirected back to the e-Service provider using the callback URL and signature ID. After receiving the signature ID the e-Service provider can then receive the signature from the eSignature Building Block back-end. As an option, the eSignature Building Block back-end can verify the requests coming from the correct IP. After finally receiving the signature, eService can merge it with the original document to get a signed version of it using the client-side library received from the eSignature Building Block front-end.

9.2 Workflows for signing with the user's device

In case of signing in with the user's device, there are multiple workflows:

• Register the user's Signature Creation Device (SCD).

• Signing with the user's Signature Creation Device (SCD).

9.2.1 Register user's Signature Creation Device (SCD)

Registering starts with the user authenticating against the ID Building Block and getting the authentication token. After the user is authenticated, a Remote SCD service is called to onboard the user. There is a request sent to the user's device to create keys. After keys are generated the public part of the keypair is sent to the eSignature Building Block as a Certificate Signing Request (CSR). CSR is submitted to a certificate authority (CA) instance that will generate and publish a certificate based on the supplied CA.

9.2.2 Use the user's Signature Creation Device (SCD) for signing

This internal workflow is for signing with the user's Signature Creation Device (SCD). In order to make the sequence diagram easier to follow the eSignature Building Block is divided into front-end and back-end parts. Front-end constitutes the functionality running in the user's internet browser and back-end refers to the API running on a server.

First, eService fetches the client-side library from the eSignature Building Block front-end. The client library is used to create a digest of the document to be signed. Using the digest (hash) the redirection request is made towards the eSignature Building Block front-end. In the eSignature Building Block front-end, the user selects the option to use the SCD model. The pseudonym entry page is shown and the user enters the pseudonym, which is sent to the e-Signature Building Block back-end to receive the generated pseudonym token. After receiving a pseudonym token, eSignature Building Block back-end can be invoked to create the signature. eSignature Building Block back-end will then invoke Remote SCD Service to create the signature. Remote SCD service will send a notification to the user's SCD with a notification and request to put PIN code. After the user enters the PIN code, a signature is generated and sent back to the Remote SCD Service. Remote SCD Service will then send the signature back to the eSignature Building Block back-end.

After the Signature is received, eSignature Building Block back-end will send a request to the Timestamping Authority for a timestamp on the signature to be created. After the timestamp is generated and received on a signature, the results are saved into a database, and a signature ID is generated to reference the signature data. Signature ID is then returned to the eSignature front-end, and the user's flow is redirected back to the eService provider using the callback URL and signature ID. After receiving the signature ID the eService provider can then receive the signature from the eSignature Building Block back-end. As an option, the eSignature Building Block back-end can verify the requests coming from the correct IP. After finally receiving the signature, eService can merge it with the original document to get a signed version of it using the client-side library received from the eSignature Building Block front-end.

7.1 Data Elements

7.1.1 eSignature operation

7.1.2 eSignature operation header

7.1.3 User's Device Onboarding

10.1 Example Cross-Building Block Workflows

Some common workflows that leverage the eSignature Building Block can be found here:

10.2 Key Decision Log

10.3 Future Considerations

10.3 Out-of-Scope Assumptions

.