Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

In our context, E-Signature will mean cryptographically validatable signatures.

Scope:

  • Government The government signing the document G2P – Priority

  • The end user signs the document. P2G - Priority

  • Business signing the document. B2B or B2C, G2B, B2G - last

  • Quantum resistance - Not in scope as of now.

...

  1. Agent opens up the consent form.

  2. Describes the services to the resident.

  3. Resident authenticates to the ID Building Block

  4. The resident is redirected to the Application

  5. The Application gets the necessary consent form and shows it to the agent/resident.

  6. The resident chooses to sign the consent form with a button click.

  7. The Application sends the consent form and the bearer token of the user to the e-signature building block API.

  8. The e-signature building block validates (introspects RFC 7662) the bearer token with the ID building block.

  9. Creates the key on the fly and timestamps & signs the document. (different types of signatures are allowed). The key is valid only for a short duration.

  10. The e-signature building block sends back the signature in the requested format (XAdES, CAdES, ASIC, JWS)

  11. The Application decides to embed or attach the signature data.

  12. The workflows building block sends the signature to the consent building block.

  13. The Application shows the user that consent is signed and he can download it from a link given.

Steps for approach offline:

Onboarding:

  1. The resident visits the e-signature portal.

  2. Authenticates & gets ekyc data using ID building block with biometrics, smart card, password + MFA.

  3. The resident/agent provides the USB token or smart card or Mobile phone to create a secure key pair and send the CSR to the e-signature building block.

  4. The CSR is signed with the resident ekyc on the resident’s e-kyc details and sent back the certificate (X509v3) to the USB token.

    1. The e-signature building block will use a certificate authority to get the certificate.

...

  • Qualified Certificate (EIDAS term) - a certificate that allows users the user's digital signature to be equal to a handwritten signature. Can It can be issued only according to legally accepted procedureprocedures.

  • Qualified Signature Creation Device (EIDAS term) - device that allows user users to give signatures. Technically follows legally accepted procedure. There are different types:

    • Physical token (ID card, Smart card, USB token)

    • Remote token/EIDAS remote QSCD/Split key ( Cloud + App, Cloud + App + Secure element, Cloud + SIM card, Cloud + App + eSIM)

  • Signing Application - 3rd party or Government Application that implements the document signing.

    • Standalone application (Desktop, mobile Mobile App)

    • Embedded application - embedded into another service, e.g web portal, online self-service, product

  • Onboarding - the process of issuing a Qualified Certificate and binding it to a Qualified Signature Creation Device, can involve different ways, subject to legislation:

    • Face to face

    • Online + authenticated with existing token

    • Online re-onboarding only

    • Full online

Prerequisites

  • User The user has been onboarded, has been issued a Qualified Certificate and owns or controls a Qualified Signature Creation Device.

Signing using Application

  • User The user uses the Application directly by choosing documents to be signed (standalone) or through another service, in which case the service will compile the Document needed to be signed by the user

  • Application The application will present the documents or data to be signed

  • Application The application will authenticate to e-signature BB, using an embedded token that allows for fixed e.g 10 requests/month

  • Application The application will create a signature

    • With Physical token

      • Application will communicate with physical token directly connected to the deviceget list of Qualified Certificates from Physical token, and allows user to choose

      • Application will read the User’s certificate from physical Physical token

      • Application will perform User verification

        • Application will ask User’s PIN code and/or perform a Biometric check

        • After user enters the PIN and/or performs the biometric check, physical Physical token is ready to perform the signing operation

      • Application will forward hash to be signed to physical Physical token

      • Physical token will return the signed hash

    • With Remote token

      • Application will contact an e-signature BB

      • e-signature BB will contact a Remote token platform to send notification to User, containing with hash to be signed and text to display

      • User’s remote Remote token will perform verification and signing

        • User’s remote Remote token will ask User’s PIN code or perform biometric verification

        • After User verification is completed, User’s remote Remote token will sign the hash

        • Signed hash, with users certificate will be sent back to e-signature BB

  • e-signature BB will confirm certificate validity

  • e-signature BB will issue timestamp

  • e-signature BB will send back a signature with certificate validity and timestamp

  • Application will save the signature, validity information and timestamp together with document, so that document with this embedded information can be validated later

  • Application The application will present results to user

Sequence Diagram:

Mermaid cloud
filenamesigning2
revision1

Related use cases

Use case 4: Signing a consent form

...