Wallet Function: Qualified Electronic Signature (QES)¶

Introduction¶

Qualified Electronic Signatures (QES) provide legally binding signatures for digital documents. QES are regulated by the eIDAS 2 framework and recognized by all EU member states. They have the equivalent legal effect of a handwritten signature.

QES are technically based on digital signatures using certificates. Because of their legal value, there are additional requirements to a qualified signature:

QES are based on qualified signing certificates issued to a natural person.
Qualified signing certificates must be issued by certified Qualified Trust Service Providers (QTSP) after verifying the identity of the person.
A QES has to be created by a Qualified Signature Creation Device (QSCD) that protects the private signing key associated with the signature certificate.

References¶

Qualified electronic signatures and their creation using the EUDI Wallet are covered by a number of regulations, standards and informative references:

eIDAS Regulation No 910/2014 + amendments
eIDAS implementing acts
European Digital Identity Wallet Architecture and Reference Framework (ARF)
Cloud Signature Consortium CSC API v2.1.0.1
Cloud Signature Consortium CSC Data Model v0.2.0 (Pre-Release)
ETSI EN 319 102-1: "Electronic Signatures and Trust Infrastructures (ESI); Procedures for Creation and Validation of AdES Digital Signatures; Part 1: Creation and Validation"
CEN EN 419 241-1: Trustworthy Systems Supporting Server Signing – Part 1: General System Security Requirements

The following signature-specific terms and abbreviations are extensions to the main glossary and based on definitions given in ETSI [TR 119 001], ETSI [EN 319 102-1] and CEN [EN 419 241-1].

Signer’s Original Document (SOD): original document before any formatting.
Signer’s Original Document Representation (SODR): calculated from the Signer’s Original Document (SOD) using a cryptographic hash function.
Signer's Document (SD): document upon which the signature is generated and to which it is associated. In some cases, a Signer's Document Representation (SDR) of the SD can be presented to the signature processes instead of the complete SD. The SD may be a processed version of the Signer's Original Document (SOD).
Signer's Document Representation (SDR): used in the calculation of the signature as a representation of the SD. It is calculated from the SD using a cryptographic hash function.
Data To Be Signed (DTBS): constructed from the information objects that are to be covered by the signature. These are the SD or the SDR and the signature attributes selected to be signed together with the SD.
Data To Be Signed Representation (DTBSR): computed from the formatted DTBS by means of a cryptographic hash function and is used to compute the Digital Signature Value (DSV).
Signed Data Object (SDO): composed of a digital signature value and signed attributes, may additionally contain the SD / SDR.
Driving Application (DA): uses a signature creation system to create a signature. The DA provides the Signer Document (SD) or the Signer Document Representation (SDR) to the Signature Creation Application (SCA).
Signature Creation Application (SCA): prepares the Data To Be Signed Representation (DTBSR) from the Signer's document and additional attributes and creates the signed document / Signed Data Object (SDO).
Server Signing Application (SSA) creates the digital signature of the DTBSR on behalf of the signer that activated the signature using the SIC. It receives the signing requests, coordinates their activation and produces Digital Signature Values (DSV). The SSA is operated in the QTSP environment.
Signer Interaction Component (SIC): is under the control of the signer and used to support the signature activation protocol to the Server Signing Application. In the EUDI Wallet infrastructure the SIC is implemented as a part of the Wallet.
Signature Authorization: same as Signature Activation, see SIC
Signature Application: same as Signature Creation Application (SCA)

EUDI Wallet support for QES¶

The creation and verification of remote electronic signatures involves a number of software components and standardized data objects. These components can be assigned to different actors, depending on the QES implementation model:

Relying Party: wants a document to be signed
Wallet: signs a document and gets user's authorizations, e.g., for a QES
QTSP: issues signature certificates and creates cryptographic signatures (digital signature values) on behalf of a user
User: natural person signing a document

The eIDAS 2 regulation defines that users can sign documents using qualified signatures which are provided within their Wallet. There are different models to implement QES using the Wallet, depending on the control flows for signature and authorization requests. Wallets must support both models described below:

Wallet-centric model: the Wallet creates a signed document or just the signature, supported by a QTSP for the cryptographic signature value
QTSP-centric model: a user uses the Wallet to authorizes a QTSP to sign a document on behalf of the user

In both cases, OpenID4VP authorization requests for credential presentations are used to interact with the Wallet. In the case of a QES, the RP requests the user to authorize transactions described in the OpenID4VP request using so-called "transaction data". Hashes of the transaction data are part of the verifiable credential presentation to prove the authorization.

Depending on the QES implementation model, a presentation of the following credentials (including a confirmation of the respective transaction data) may be requested from the Wallet:

PID: to identify the user as a natural person and to allow a QTSP the issuance of a qualified signature certificate to this person. The certificate may then be used to sign a document on behalf of the PID owner. Short-lived qualified certificates based on a PID presentation are created to sign a specific document and expire or are revoked shortly after this operation, see [CSC].
Authentication credential (EAA): to authenticate the user, e.g., to a QTSP using a credential issued by the QTSP during a previous onboarding / QTSP profile creation. After a successful presentation, the QTSP may give access to users signature credentials during subsequent signature calls.
X.509: credential format (https://cloudsignatureconsortium.org/2025/x509) where the returned VP token contains the signed document. The original document (SOD) is provided with the presentation request.

A QTSP needs the user's authorization to perform certain actions. The following QES-related transaction data types have to be supported by wallets, see [OID4VP] and [CSC Data Model] (Pre-Release, still work in progress):

qc-request: (https://cloudsignatureconsortium.org/2025/qc-request) to get user consent for the creation of signature certificates according to the Terms and Conditions (T&C) of the QTSP
qes (https://cloudsignatureconsortium.org/2025/qes) to authorize the QTSP to create a QES for a document / batch of documents on behalf of the user. This includes showing information about the document(s) to be signed, e.g., document label, hash value, or the option to open the document via a provided protected link. The difference between giving consent for a certificate creation and authorizing a signature for a certain document must be clearly visible for the user.

Wallet-centric Model¶

User Experience¶

Non-normative example for a wallet-centric use case:

User opens the Wallet and picks a document to be signed or the document is provided by a Relying Party.
User selects the QTSP profile for the signature in the Wallet.
User is asked by the Wallet to authorize the signature for the chosen document.
User authorizes the signature by biometrics or PIN.
Wallet shows a confirmation about the successful signature.

Architecture Overview¶

In the Wallet-centric model, the user's Wallet is the central actor to sign a document and to control and approve necessary transactions with a QTSP. The Signature Creation Application (SCA) is part of the Wallet or of the Wallet backend.

Figure 1: Wallet-centric model

The Driving Application at a RP sends the request to sign a document to the user's Wallet. Alternatively, the user uses the Wallet to select a document on the users device to sign. The user then chooses a QTSP profile in the Wallet. The Wallet sends the signature request to the QTSP.

The QTSP starts a QES authorization flow with the Wallet (details see below).

After successful authorization, the QTSP generates the signature value and returns it to the Wallet. The signature is embedded into the document by the SCA in the Wallet.

QTSP profiles in the Wallet can be pre-configured or the result of previous user enrollments at a QTSP. If a user is not known to the QTSP when requesting a signature, the QTSP rejects the signature and requires an enrollment first.

Alternatively, the QTSP may integrate a PID presentation into the QES authorization to create a short-lived qualified certificate for one signature creation without creating a user account at the QTSP.

QTSP profiles are Wallet-internal and can contain information like:

name of the QTSP
access points for APIs
registered user ID (client_id) of the user at the QTSP
authentication credentials (EAA) issued by the QTSP to the user Wallet during enrollment

QTSPs may support multiple user profiles for the same natural person with optional additional attributes, e.g., for commercial and private use.

Interfaces and protocols used in the Wallet centric model:

Relying Party → Wallet: OpenID4VP with X.509 profile (see [CSC DM]) to request the users signature for a document and to receive the signed document
Wallet → QTSP: CSC API v2 to request QES authorization and document signature by the QTSP
QTSP → Wallet: OID4VP with transaction data for QES authorization by the user

The OID4VP credential presentation to the QTSP to authorize the QES is part of the processing of the CSC / OAuth signature request from the Wallet to the QTSP. This situation is similar to the "Presentation during Issuance" for credential issuing. For better user experience, the same OAuth 2.0 for First-Party Applications mechanism is used to pass the authorization request to the Wallet during the CSC signature flow.

Sample Flow: Wallet-centric model - RP provided document¶

Assumptions¶

Wallet-centric model, Signature Creation Application (SCA) is a part of the Wallet or Wallet backend
user is already enrolled to the QTSP: an EAA for user authentication is issued by the QTSP and stored in the QTSP profile in the Wallet, user gave consent to certificate creation, certificate is created or will be crated on demand
signature over document (SOD provided to the Wallet)

Outline¶

In this flow, the user selects a QTSP profile in the Wallet to request a QES for a document, provided to the Wallet by the DA. The Wallet sends an CSC / OAuth2 signature authorization request to the QTSP.

The QTSP uses the OAuth 2.0 for First-Party Applications Mechanism to request the users EAA presentation with transaction data for QES authorization from the Wallet.

the Wallet processes the authorization request, gets the user's authorization for the QES and presents the EAA from the QTSP enrollment with the transaction data hash.

After verifying the presentation, the QTSP returns the CSC authorization code for the signature to the Wallet and the Wallet gets the signature (DSV) from the QTSP.

Sequence diagram¶

Below is a non-normative diagram illustrating the flow (it includes only the components relevant to the illustration of the flow described in this document):

Sample data¶

Disclaimer: Some attribute names and types are still in standardization, e.g., in CSC, and can possibly be subject of future changes.

Request¶

RP -> Wallet

DCQL query¶

{
  "credentials":[
    {
      "id":"certificate_by_policy",
      "format":"https://cloudsignatureconsortium.org/2025/x509"
    }
  ]
}

Transaction data¶

{
  "type":"https://cloudsignatureconsortium.org/2025/qes",
  "credential_ids":[
    "certificate_by_policy"
  ],
  "numSignatures":1,
  "signatureQualifier":"eu_eidas_qes",
  "documentDigests":[
    {
      "signature_format":"P",
      "conformance_level":"Ades-B-B",
      "signed_envelope_property":"Certification",
      "label":"Example Contract",
      "href":"https://protected.rp.example.com/contract-01.pdf?token=HS9naJKWwp901hBcK348IUHiuH8374",
      "checksum":"sha256-sTOgwOm+474gFj0q0x1iSNspKqbcse4IeiqlDg/HWuI=",
      "access":{
        "type":"OTP",
        "oneTimePassword":"51623"
      }
    }
  ],
  "hashAlgorithmOID":"2.16.840.1.101.3.4.2.1"
}

Response¶

Wallet -> RP

sd-jwt¶

{
  "certificate_by_policy": {
    "documentWithSignature": [
      "<base64-encoded document with signature>"
    ]
  }
}

kb-jwt¶

{
  "aud": "https://qtsp.example.com/verifier",
  "iat": 1741269093,
  "nonce": "bUtJdjJESWdmTWNjb011YQ",
  "sd_hash": "Re-CtLZfjGLErKy3eSriZ4bBx3AtUH5Q5wsWiiWKIwY",
  "transaction_data_hashes": [
    "605c9551a3dc2ec7ca4510c05fa9ed319de61b006ff615a97dbb6f5223f64b3d"
  ],
  "transaction_data_hashes_alg": "sha-256"
}

QTSP-centric Model¶

User Experience¶

Non-normative example for a one-shot certificate use case:

The Relying Party asks the user to sign a document.
The user scans a QR code and logs into the Wallet.
The user is asked by the Wallet to authorize the signature and to accept the T&C of the QTSP for the creation of a qualified signature certificate.
The user is prompted by the Wallet for a PID presentation.
The RP informs the user about the successful signature.

Architecture Overview¶

In the QTSP-centric model, the QTSP is the central actor for the signature flow. The SCA may be part of the RP, the QTSP, or provided by a 3^rd party.

Remark: There are several actors in the role of a RP in the QTSP-centric model:

In the overall architecture, the party hosting the Driving Application acts as a "Signature-RP" to get a document signed using an eIDAS trusted service.
From the Wallet's viewpoint, the QTSP acts as a "Wallet-RP" to get a signature authorization.

A party hosting the DA may support both the Wallet-centric and QTSP-centric models. For consistency, the term RP is used for the DA environment in diagrams and flows.

Figure 2: QTSP-centric model

The QTSP for a QES is chosen by the Relying Party. The user can be enrolled beforehand, including identification and the consent for certificate creation. Alternatively, the user identification by PID presentation can be part of the signature flow to create a short-lived qualified certificate for one signature creation without creating a user account at the QTSP.

The RP sends the request to sign a document to the QTSP. The QTSP requests the signers authentication / identification and the QES authorization from the Wallet user.

After authorization, the QTSP generates the signature value, which is then integrated into the document by SCA at QTSP or RP.

Interfaces used in this model:

Relying Party → QTSP: CSC API v2 or QTSP specific to request the users signature for one / multiple documents and to return the Signed Data Object
QTSP → Wallet: OID4VP with transaction data to authenticate / identify the user and activate the signature

Sample Flow: QTSP-centric model with PID Presentation¶

Assumptions¶

QTSP-centric model
Signature Creation Application (SCA) is part of the QTSP environment
On-the-fly signature without prior user enrollment
short-lived certificate created after PID presentation
user's consent is gathered using transaction data and the Wallet UI, not via the QTSP's web UI
signature over document (SOD provided to the QTSP)

Outline¶

In this flow, the QES is created using an authorization request with PID presentation. This request serves several purposes:

authorization of the user to sign a document (signature authorization)
user's consent to present the PID to the QTSP, which is necessary to create a qualified certificate
users consent for the QTSP to use this information to create a signing certificate

The authorization request for PID presentation therefore includes two sets of transaction data that were created by the QTSP.

When the Wallet processes the authorization request, the user gives consent to PID presentation and certificate creation and authorizes the signature based on the Signers Original Document (SOD) provided by the DA. No prior user enrollment is necessary.

The transaction data hashes are included in the PID presentation to the QTSP. The QTSP issues a short-lived certificate to the user and uses it for the document signature.

Sequence diagram¶

Below is a non-normative diagram illustrating the flow (it includes only the components relevant to the illustration of the flow described in this document):

Sample data¶

Disclaimer: Some attribute names and types are still in standardization, e.g., in CSC, and can possibly be subject of future changes.

OpenID4VP flow for PID Presentation with transaction data for user consent and QES activation

Request¶

QTSP -> Wallet

DCQL query¶

{
  "credentials": [
    {
      "id": "my_credential",
      "format": "dc+sd-jwt",
      "meta": {
        "vct_values": [ "urn:eudi:pid:1" ]
      },
      "claims": [
        {"path": ["given_name"]},
        {"path": ["family_name"]},
        {"path": ["birthdate"]},
        {"path": ["place_of_birth"]["country"]},
        {"path": ["place_of_birth"]["locality"]},
        {"path": ["expiry_date"]}
      ]
    }
  ]
}

Transaction data¶

Remark: The attribute processIDmy be used by the QTSP for a cryptographic binding between the requested QES authorization and the corresponding SDR at the QTSP.

[
  {
    "type":"https://cloudsignatureconsortium.org/2025/qes",
    "credential_ids":["my_credential"],
    "numSignatures":1,
    "signatureQualifier":"eu_eidas_qes",
    "documentDigests":[
      {
        "label":"Example Contract",
        "hashType":"sodr",
        "hash":"HZQzZmMAIWekfGH0/ZKW1nsdt0xg3H6bZYztgsMTLw0="
      }
    ],
    "processID":"eOZ6UwXyeFLK98Do51x33fmuv4OqAz5Zc4lshKNtEgQ=",
    "transaction_data_hashes_alg":"sha-256"
  },
  {
    "type":"https://cloudsignatureconsortium.org/2025/qc-request",
    "credential_ids":["my_credential"],
    "QC_terms_conditions_uri":"https://qtsp.example.com/policies/terms_and_conditions.pdf",
    "QC_hash":"ohxKcClPp/J1dI1iv5x519BpjduGZC794x4ABFeb+Ds=",
    "QC_hashAlgorithmOID":"2.16.840.1.101.3.4.2.1",
    "transaction_data_hashes_alg":"sha-256"
  }
]

Response¶

Wallet -> QTSP

sd-jwt¶

{
   "exp": 1898949016,
   "iat": 1741269016,
   "iss": "https://pid-issuer.example.com",
   "nbf": 1741269016,
   "vct": "urn:eu.europa.ec.eudi:pid:1",
   "_sd": [
       "ewgzkNuXusuMhykjisSRT4w-Oj2NVC9gvOFRbJ4X-OI",
       "zFxDfNErVeVKm9z9ctTyTLQ83lrD49T4gbJEMoGn3pc",
       "4fCywfbrmm6UgBmpmi-bxP466HJd-5O7WzYDf2v1RzM",
       "OQKiYuGyqcoeNnqnhpqqU2q6PJX8YpmxULs7rVB1ElU"
   ],
   "_sd_alg": "sha-256",
   "cnf": {
       "jwk": {
           "alg": "ES384",
           "crv": "P-384",
           "kty": "EC",
           "use": "sig",
           "x": "jpIk_Hc51OPM-8u4DZSHtocWZAtHJ7r9plYJu-NNW-kPhv1L-ige2k8X2rBNom-F",
           "y": "jV1CHkNSJ0Xa6K5an_28BD9Ivme4L7iXPRxWzTlyzQxg6VS9NCPc4xWUu-IcpZFO"
       }
   }
}

kb-jwt¶

{
   "aud": "https://qtsp.example.com/verifier",
   "iat": 1741269093,
   "nonce": "bUtJdjJESWdmTWNjb011YQ",
   "sd_hash": "Re-CtLZfjGLErKy3eSriZ4bBx3AtUH5Q5wsWiiWKIwY",
   "transaction_data_hashes": [
       "605c9551a3dc2ec7ca4510c05fa9ed319de61b006ff615a97dbb6f5223f64b3d",
       "df485d584a07583414dec577e3601d2925ec6fdbb7d188419cb5894266e0ea2e"
   ],
   "transaction_data_hashes_alg": "sha-256"
}

Wallet Function: Qualified Electronic Signature (QES)¶

Introduction¶

References¶

Glossary of QES-related terminology¶

EUDI Wallet support for QES¶

Wallet-centric Model¶

User Experience¶

Architecture Overview¶

Sample Flow: Wallet-centric model - RP provided document¶

Assumptions¶

Outline¶

Sequence diagram¶

Sample data¶

Request¶

DCQL query¶

Transaction data¶

Response¶

sd-jwt¶

kb-jwt¶

QTSP-centric Model¶

User Experience¶

Architecture Overview¶

Sample Flow: QTSP-centric model with PID Presentation¶

Assumptions¶

Outline¶

Sequence diagram¶

Sample data¶

Request¶

DCQL query¶

Transaction data¶

Response¶

sd-jwt¶

kb-jwt¶