Signing Service Solution Design

Note: For the use of Developer Assets, these Terms and Conditions apply. Please also read the Requirements Notation and Conventions.

1. Abstract

This document specifies a solution for the creation of advanced (AES) and qualified (QES) electronic signatures in accordance with eIDAS which leverages capabilities of IDPs for strong end-user authentication and identification to create the respective (qualified) short-term certificates and authorize the actual signature creation.

The API for signature creation is based on ETSI TS 119 432, the authorization of the API access utilizes OAuth 2.0.

2. Introduction

is an ecosystem of trusted identity providers that can be used by sites and apps to login users, identify natural persons, obtain account information, and initiate payments.

The user interaction always follows the same pattern: The user first selects the bank (the IDP) to be used for the flow. At the IDP, the user is first authenticated and afterwards asked for consent to the requested action(s) by the bank’s Authorization Server (AS). As a technical result, the partner is issued an OAuth access token which in turn is used to perform the authorized action(s) at the respective API(s) (e.g., OpenID Connect UserInfo in case of identity data).

This pattern allows for a simple and uniform user experience across functions and leaves the decision of the particular authentication method(s) to be performed at the discretion and control of the particular bank within the scheme. Moreover, there is no need to setup and manage service-specific credentials nor to enter or process further (end-user) credentials in the course of transaction processing.

wants to offer the customers of the participating banks a way to conveniently sign digital documents using advanced and qualified electronic signatures based on the identity data and credentials associated with their online banking account. This function shall follow the uniform technical and interaction pattern described above.

This solution design document describes a way to utilize OAuth along with additional security measures to implement a remote signature creation process which is both secure and easy to use.

Acknowledgment: We thank the team of Swisscom’s “All-In Signing Service” for contributing to the initial development of the Signing Service Solution Design up to version 1.0.

2.1. Principles

This solution design is based on the following principles:

  • OAuth 2.0 (grant type authorization code) is used as technical foundation of the protocol for the authorization of remote electronic signatures. It is combined with further OAuth extensions, such as PKCE, OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens, OAuth 2.0 Rich Authorization Requests, and OAuth 2.0 Pushed Authorization Requests.

  • The API for creating electronic signatures is provided by a Qualified Trust Service Provider (QTSP). Those remote signatures are based on on-demand, short-term certificates created by the QTSP using data asserted by the AS. This API is based on ETSI TS 119 432.

  • The RP never exposes the documents to be signed to any of the other parties involved. The IDP gets to know the respective hashes and descriptive labels of those documents, the QTSP is provided with the document hashes only. The RP directly sends the hashes to be signed to the QTSP using the aforementioned API.

  • The QTSP relies on the AS for the purpose of user authentication and authorization. All data required to securely create certificates and initiate the remote signature creation are provided to the QTSP by the AS based on access tokens issued to the RP and in turn passed by the RP with the signing requests to the QTSP.

  • OAuth access tokens represent the authorization to obtain identity data and create signature on behalf of the respective user. The QTSP incorporates data exchanged in or based on access tokens into the so-called “Signature Activation Data”.

  • The access tokens used in this design are hybrid tokens, i.e., they are JSON Web Tokens containing a small portion of data required by the QTSP to early refuse fraudulent requests and to determine the IDP that provides the bulk of the token and user data on demand of the QTSP by utilizing the OAuth 2.0 Token Introspection endpoint of the respective AS.

  • All credentials issued by the authorization server after it successfully authenticated the user and gathered the user’s consent to perform the signing operation are cryptographically bound to the user, context, and the partner requesting access. This prevents leakage, replay, and generally spoken abuse of the technical credentials by the legitimate partner or any other attacker.

  • Special care was taken to prevent modification of authorization data and leakage of credentials in the redirect-based part of the flow through the user’s browser.

  • All connections are end-to-end TLS protected (server authentication and transport security).

  • Because of the security requirements, this flow supports OAuth confidential clients only. If a public client tries to initiate the signing authorization request, the request will be terminated with an error (error code access_denied).

2.2. References

This specification depends on the following specifications:

Specification

Purpose

IDP Core Specification

AS basic requirements

Identity Service

various claims to carry user and transaction data between AS and QTSP

Platform Documentation

plattform integration for provisoning and billing

3. Architecture

The components of the solution are shown in the following drawing:

QES Solution Architecture

The Relying Party is a website or app wanting to let its customers electronically sign a document (or a set of documents). It utilizes the account chooser of the platform to find the IDP of the bank the particular customer wants to use for signing the document(s).

In the architecture, the bank provides access authorization for APIs as well as several APIs for its customers. Remote Signature Creation is one of those APIs. The assumption is the bank will typically partner with an approved eIDAS QTSP who actually fulfills the service.

The reference architecture therefore assumes the bank’s authorization server (AS) provides authorization of the remote signature creation and provides the data required to create the respective ad-hoc certificate, whereas the QTSP provides the API for remote signature creation.

Every AS in the network represents a particular bank and leverages its existing online banking accounts and associated capabilities. After obtaining the user’s authorization and the required technical credentials (Access Token) from the AS, the Relying Party invokes API calls with the QTSP to create the signature (and the ad-hoc certificate).

The QTSP in turn uses the access token to obtain all data required to create the ad-hoc certificate and the electronic signature along with supporting data required for establishing the audit trail from the respective AS.

The technical mechanism for obtaining the token data from the AS is the OAuth 2.0 Token Introspection, i.e., the QTSP sends a request to obtain this data when the sign hash request hits its API.

The platform manages the trust relationships among all participants. It provides all ASs with data needed to recognize and to authenticate Relying Parties and QTSPs.

ASs and QTSPs use the platform to report back any service delivery in order to facilitate billing of the respective services.

The platform also provides a long-term archive for all public keys used by IDPs in order to enable long-term non-repudiation (see Long-Term Non-Repudiation).

For further information regarding the overall ecosystem architecture, please refer to Ecosystem Architecture.

4. Protocol Description

The following sequence diagram depicts the message flow for a remote signing process.

qes_flow_puml

The involved parties are:

  • Relying Party: the partner website utilizing and the QTSP to let users electronically sign contract documents.

  • Account Chooser: part of the platform allowing users to select the Bank they want to use for transactions.

  • Service Configuration: part of the platform providing RPs with all configuration data needed to use services in the context of a certain bank, e.g., endpoint URLs.

  • AS: an OAuth authorization server providing the authorization services to RPs on behalf of the customers of a certain bank. Every AS conforms to the Identity Service.

  • QTSP: A qualified trusted service provider. It allows relying parties to electronically sign documents on behalf of users.

  • Mediation Service: part of the platform used to collect records about services provided in the ecosystem as prerequisite for billing.

4.1. Signature Preparation Phase

The partner website (or app) presents the user a particular document (e.g., a contract proposal as PDF document) and asks whether the user accepts and wants to electronically sign it.

The user decides to sign it with and indicates this by pressing a button, e.g., “Sign with my Bank” (message #1). The partner website prepares the PDF document for signing and calculates the respective hash (message #2).

4.2. IDP Selection Phase

The partner website starts the signing process by first letting the user select the Bank to talk to. It does so by redirecting the user agent to the account chooser (messages #3 & #4).

There the user will select her bank (message #5 & #6). As a result, the RP is provided with the issuer URL of the respective bank (message #7 & #8), which is used to obtain the actual configuration (message #9 & #10) from the Service Configuration service. This configuration might look as follows:

Example 1. Service Configuration with Remote Signature Creation metadata 
{
   "identity":{
      "iss":"https://issuer.bankidp.com/5634"
   },
   ...
   "remote_signature_creation":[{
      "qtsp_id":"sp:yes.com:6a256bca-1e0b-4b0c-84fe-c9f78e0cb4a3",
      "signDoc":"https://qtsp.com/csc/v1/signatures/signDoc",
      "conformance_levels_supported":[
         "AdES-B-B",
         "AdES-B-T",
         "AdES-B-LT"
      ]
   }]
}

The section designated remote_signature_creation is a JSON array containing the metadata, e.g., the endpoint URL, of the QTSPs available in the context of the particular AS. Every QTSP is identified by its qtsp_id. The RP decides what QTSP to use for the upcoming transaction.

If remote_signature_creation is an empty array, the selected IDP does not support QES.

Since this section does not contain a dedicated OAuth configuration, the RP is supposed to use the identity module (the OpenID Connect implementation of the respective bank) as authorization server. The configuration of the authorization server is obtained by utilizing OAuth Server Metadata.

An AS supporting the authorization of remote signature creation transactions MUST include the value sign in the authorization_data_types_supported key of its OAuth configuration (.well-known/oauth-authorization-server).

Example 2. OAuth Configuration
{
   ...
   "authorization_data_types_supported":[
      ...
      "sign"
   ],
   ...
}

Every RP wanting to perform the QES process must be authorized to request those authorization_details types in its RP configuration with the platform.

4.3. Authorization Process

Now the RP can conduct the authorization process, which consists of messages exchanged between RP and AS.

In the preparation phase, the RP pushes the authorization request data to the IDP using OAuth 2.0 Pushed Authorization Requests, including details of the desired signing transaction in OAuth 2.0 Rich Authorization Requests format. The request_uri returned by the AS is used in the subsequent frontend part to carry the details into the authorization process.

Pushed authorization requests is the only mechanism to convey authorization request data to the AS in the signing flow. Traditional authorization requests for this flow MUST be rejected by the IDP.

In the frontend part, the AS directly interacts with the user to authenticate the user and obtain the user’s authorization for the particular transaction.

For security reasons, the exchange is then transferred to the backend in order to securely issue the access token required to create the remote signature(s).

4.3.1. Preparation (Pushed Authorization Request)

The website starts the process by obtaining the details of the AS, such as location of the pushed authorization endpoint. It utilizes the OAuth configuration of the AS, which is obtained by appending /.well-known/oauth-authorization-server to the issuer URL provided in the element identity/iss of the Service Configuration (messages #11 & #12).

In the next step (messages #13 & #14), the RP uses a pushed authorization request OAuth 2.0 Pushed Authorization Requests to send the authorization request data to the AS. The RP authenticates itself with its client certificate using OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens.

The pushed authorization endpoint location is obtained from pushed_authorization_request_endpoint parameter of the AS’s OAuth Configuration.

The signing transaction is specified in a JSON object as shown in the following example.

Example 3. Pushed Authorization Request 
POST /par HTTP/1.1
Host: as.example-bank.com
Content-Type: application/x-www-form-urlencoded

response_type=code
&client_id=s6BhdRkqt3&state=af0ifjsldkj
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
&authorization_details=%5B%7B%22type%22%3A%22sign%22%2C%22locations
   %22%3A%5B%22sp%3Ayes.com%3A6a256bca-1e0b-4b0c-84fe-c9f78e0cb4a3
   %22%5D%2C%22credentialID%22%3A%22qes_eidas%22%2C%22documentDigests
   %22%3A%5B%7B%22hash%22%3A%22sTOgwOm%2B474gFj0q0x1iSNspKqbcse4Ieiql
   Dg%2FHWuI%3D%22%2C%22label%22%3A%22Kreditvertrag%22%7D%2C%7B%22hash
   %22%3A%22HZQzZmMAIWekfGH0%2FZKW1nsdt0xg3H6bZYztgsMTLw0%3D%22%2C%22
   label%22%3A%22Vertrag%20Restschuldversicherung%22%7D%5D%2C%22
   hashAlgorithmOID%22%3A%222.16.840.1.101.3.4.2.1%22%7D%5D
Authorization Details

In this request, authorization_details is a JSON array with an element that contains information about the signing transaction (using OAuth 2.0 Rich Authorization Requests):

Example 4. Signature Creation Information in authorization_details 
[
   {
      "type":"sign",
      "locations":[
         "sp:yes.com:6a256bca-1e0b-4b0c-84fe-c9f78e0cb4a3"
      ],
      "credentialID":"qes_eidas",
      "documentDigests":[
         {
            "hash":"sTOgwOm+474gFj0q0x1iSNspKqbcse4IeiqlDg/HWuI=",
            "label":"Kreditvertrag"
         },
         {
            "hash":"HZQzZmMAIWekfGH0/ZKW1nsdt0xg3H6bZYztgsMTLw0=",
            "label":"Vertrag Restschuldversicherung"
         }
      ],
      "hashAlgorithmOID":"2.16.840.1.101.3.4.2.1"
   }
]

This authorization_details array MUST contain exactly one element of type sign but may also contain authorization details objects of other types.

The following elements are defined for the authorization_details object of type sign:

  • locations: (REQUIRED) JSON string array that MUST contain a single entry containing the id of the QTSP (qtsp_id from service discovery) the RP will use to create the signatures. This element MUST exactly match the client_id field of the SP configuration record of a QTSPs in the SP directory. If the locations element contains an unknown id or the service_type of the respective record is not remote_signature_creation, the AS MUST respond with an error (see below).

  • credentialID: REQUIRED The credentialID field determines the kind of signature to be created. This specification currently defines a single possible value qes_eidas, which indicates to the AS the RP wants the user to authorize a qualified electronic signature according to the eIDAS regulation.

  • documentDigests: (REQUIRED) An array composed of entries for every document the RP wants the user to sign. Every entry is composed of the following elements:

    • hash: (REQUIRED) String containing the actual Base64-encoded octet-representation of the hash of the document. The hash will be put in the access token data once the user consented to the transaction and used by the QTSP in the authorization of the signing API access.

    • label: (REQUIRED) String containing a human-readable description of the respective document. The AS will use the label element in the user consent to designate the document.

  • hashAlgorithmOID: (REQUIRED) String containing the OID of the hash algorithm (see ETSI TS 119 432) used to generate the hashes listed in documentDigests.

The AS will not get to see the actual documents in order to facilitate confidentiality and simplicity of the solution.

The following hash algorithms MUST be supported by IDPs (also for default documents in case of QES for Identity Assurance). QTSPs SHOULD support the following hash algorithms and MUST support those marked as "mandatory to implement":

Hash algorithm OID

Hash algorithm name

MTI for QTSPs

2.16.840.1.101.3.4.2.1

SHA-256

yes

2.16.840.1.101.3.4.2.2

SHA-384

no

2.16.840.1.101.3.4.2.3

SHA-512

no

2.16.840.1.101.3.4.2.8

SHA3-256

no

2.16.840.1.101.3.4.2.9

SHA3-384

no

2.16.840.1.101.3.4.2.10

SHA3-512

no
Other Contents of the Pushed Authorization Request

The pushed authorization request MUST contain a PKCE code_challenge, the hash of a cryptographic nonce (PKCE verifier) used to bind the actual transaction to the particular user agent. This design requires the code_challenge_method S256.

Alternatively, RPs using this flow in conjunction with an OpenID Connect Authentication Flow MAY also use the nonce parameter for code injection prevention.

If neither of those parameters is present in the request, the AS MUST terminate processing and send an error response to the RP with the error code invalid_request.

The AS receives the authorization request and validates the redirect_uri. It must exactly match one of the redirect URIs pre-registered for this particular client with . If this check fails, the respective error response must be sent to the RP (see below).

The RP MAY indicate the purpose of the signing request in the purpose request parameter (see IDP Core Specification). If this parameter is not present in the request, the IDP will use the default_consent_purpose from the RP’s configuration.

The AS checks whether the RP is allowed to use the type value sign by checking the allowed_authorization_data_types field of the respective RP record obtained from the platform. If this check fails, the AS MUST terminate processing and send an error response to the RP with the error code access_denied.

AS Response

The AS will respond with a JSON object containing the request_uri representing the newly created pushed authorization request information:

Example 5. AS Response with request_uri 
HTTP/1.1 201 Created
Cache-Control: no-cache, no-store
Content-Type: application/json

{
   "request_uri": "urn:example:bwc4JK-ESC0w8acc191e-Y1LTC2",
   "expires_in": 90
}

The request_uri purely serves as an identifier and can be a URI or a URN. In any case, it MUST contain a random value newly generated for each pushed authorization request. It MUST contain enough entropy to be infeasible to guess by an attacker. The request_uri MUST be bound to the client_id of the client that created the pushed authorization request.

The request_uri should be invalidated after an access token was created or, if the flow is interrupted, after a reasonable timeout.

When designing the request_uri, implementers should bear in mind the request_uri is used in URI request parameters, whose length is typically restricted by browsers and web servers.
Error Response

In case of an error the response will be structured as described in OAuth 2.0 Pushed Authorization Requests and shown in the following example:

Example 6. Error Response
HTTP/1.x 400 Bad Request

Content-Type: application/json

{
    "error": "invalid_request",
    "error_description": "the field credentialID must not be empty"
}

Possible errors:

HTTP status code

error

error_description (examples)

400

invalid_request

the field credentialID must not be empty

400

invalid_request

the field locations contains an unknown id

400

invalid_request

the field locations contains more than one entry

400

invalid_request

the field locations contains a service whose service_type is not "remote_signature_creation"

400

invalid_request

more than one hash of a default document provided (see QES for Identity Assurance)

415

invalid_request

wrong media type

422

invalid_request

request input validation failed

4.3.2. Authentication and Authorization (OAuth Frontend Part)

The RP initiates the OAuth authorization flow and passes the request_uri in the request_uri parameter to the AS (message #16) along with its client_id.

The AS authenticates the user (messages #17 & #18) using her Online Banking Credentials. If there already exists a user session with the AS, the user must be required to authenticate again, unless the session lifetime is sufficiently short to ensure that the same user as before is using the device (a few minutes).

In this case, the knowledge of the user (login credentials) is replaced by the cookie in her browser. The session lifetime MUST be short in order to prevent attacks where an attacker gains access to a user’s device and second factor device and is able to create signatures under the identity of the user.

The AS requests the user to consent to the RP’s signing request (message #19).

The user is presented with information about the QTSP used in this transaction and the data made accessible to the QTSP in order to allow the creation of the signing certificate. The data required by the QTSP is defined in its respective SP configuration (see Setup and Operations).

The AS determines the QTSP by matching the sole locations element value in the authorization_details with the client_id elements in the SP directory.

The claims a QTSP may acquire are defined in Identity Service.

A typical data set will include

  • the given name (claim given_name),

  • the family name (claim family_name),

  • the date of birth (claim birthdate),

  • the place of birth (claim place_of_birth), and

  • the identification data used to verify the person’s data (see verified_claims structure in Identity Service)

The QTSP’s SP configuration may also define restriction on the values provided for verification data, namely the acceptable identity documents and identity verification methods, as described in Identity Service.

If the AS is unable to provide any of the non-essential claims defined in the SP configuration, either because the claim is unknown to the AS or because data is not available, the AS MUST omit the respective claim from the response.

If the AS is unable to provide any of the claims defined in the SP configuration as essential or if the AS cannot fulfill the requirements imposed on identity documents and the identity verification process, it SHOULD attempt to obtain and verify this data using suitable measures. If it cannot obtain the requested data, it MUST refuse to process the authorization request and return an error unable_to_meet_service_requirements.

The error description should indicate that the AS was unable to provide all data (with the requested properties) to the service provider needed to fulfill the requested service. The IDP SHOULD indicate the problem to the user before it redirects the user agent back to the RP and clearly state that the transaction will be aborted and no data will be shared with RP or QTSP.

The AS MUST log the error event along with suitable metadata that enable subsequent attempts to improve the data quality.

The user is asked to consent to

  • the creation of the Qualified Electronic Signature (the label values are used to designate the respective documents to be signed),

  • the terms of service and privacy policy of the respective QTSP (The user’s consent to this document will also be attested towards the QTSP.),

  • the transfer of the required user and transaction data from the IDP to the QTSP, and

  • the terms of service (if applicable) and privacy policy of the respective RP (see IDP Core Specification for details).

User Interface Design

The AS MUST strictly separate presentation and gathering of

  1. The consent to create a Qualified Electronic Signature, which is given towards the Qualified Trust Service Provider and

  2. the consent to transfer the required user and transaction data to the QTSP, which is given towards the AS (the Bank).

The AS also MUST ensure the user understands she agrees to the terms of service of the QTSP.

Exemplary consent: “I demand the creation of a qualified electronic signature by <QTSP> and its subsequent transmission to the <Relying Party> for the purpose of: <Purpose>. I agree to the <Terms of Use> and <Privacy Policy> of QTSP AG and the <Terms of Use> and <Privacy Policy> of the <RP>."

The AS MUST ensure that special characters in document labels cannot be used to inject code into the web interface of the AS (cross-site scripting, defacing). Proper escaping MUST be applied for this purpose. The AS SHALL NOT remove characters from the document labels to this end.

The user consents (messages #20) and authorizes the transaction using her preferred TAN method/second authentication factor (e.g., chipTAN) (messages #21 & #22).

The AS is required to always perform transaction authorization utilizing the user’s second factor for signing transaction independent of any other parameter of the ongoing OAuth/OpenID Connect transaction (e.g., acr_values). The AS MAY merge the respective requirements, e.g., asking the user just once for a TAN to authorize a QES and the 2FA login to the RP.

The AS stores the consent for signature generation along with the intended purpose and the designation of the contract document(s) in the customer’s timeline.

The AS generates an OAuth authorization code, which is bound to the following parameters:

  • client_id of the relying party (message #13)

  • the user Id of the actual User

  • the code_challenge (message #13)

  • the authorization_details (message #13)

The AS sends the authorization response (message #23) including the code, the state value sent with the authorization request, and its own issuer URL in the iss parameter (see IDP Core Specification, section 2.1.1) to the RP as shown in this example:

Example 7. Authorization Response
HTTP/1.1 302 Found
Location: https://client.example.com/cb?
code=SplxlOBeZQQYbYS6WxSbIA
&state=xyz
&iss=https://accounts.testbank.com

The RP receives the request (message #24) and first verifies whether the state belongs to the session token (CSRF prevention) stored in the user agent and the issuer URL corresponds to the issuer URL discovered in the Bank Selection Phase.

This check serves to protect against the IDP mix-up attack, as discussed in OAuth 2.0 Mix-Up Mitigation, Section 3.

4.3.3. Authentication & Authorization (OAuth Backend Part)

The RP then (message #25) sends a request to the AS’s token endpoint to exchange the authorization code for an access token. This request is end-to-end TLS protected and the RP authenticates using OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens towards the AS.

The AS authenticates the RP and checks whether the code was issued to this particular client (client_id). The AS furthermore validates whether the PKCE code_verifier value matches the corresponding code_challenge value of the authorization request in accordance with RFC 7636. In case the RP used nonce instead of PKCE, the RP is required to check the nonce from its session with the nonce value from the respective ID Token. The request is refused if any of the checks fails.

Example 8. Token Response
HTTP/1.1 200
Content-Type: application/json;charset=UTF-8

{
   "access_token":"eyJraWQiOiJDWHVwIiwiYWxnI...",
   "token_type":"bearer",
   "expires_in":3600,
   "authorization_details": [ ... ]
}

The AS issues an access token which is digitally signed and bound to

  • all data the respective authorization code was bound to (see above), except the code_challenge, and

  • the fingerprint of the TLS Client Certificate used by the RP to authenticate towards the AS during the current token request.

The access token is a JWT (see RFC 7519) that contains (at least) the following JWT claims:

  • iss: identifies the AS that issued the access token using its issuer URL as defined in RFC 8414

  • cnf: a confirmation claim containing the sub claim x5t#S256, which contains the S256 fingerprint of the X.509 certificate the respective client used when obtaining the access token at the AS - as defined in OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens.

  • iat: indicates when this token was issued

  • exp: determines the expiration of the access token

This data is the bare minimum required for an early detection and prevention of attacks, as described below. The JWT must further contain unique data binding it to the data to which the respective authorization code was bound (see above) and allow the AS to identify the authorization transaction when processing the subsequent Token Introspection Request. One option is to use the jti claim as defined in RFC7519 for that purpose.

Example 9. Access Token
eyJraWQiOiJzWFdMIiwiYWxnIjoiUlMyNTYifQ.eyJpc3MiOiJodHRwczpcL1wvdGVzdGlkcC5zYW5kYm94Lnllcy5jb21cL2lzc3VlclwvMTAwMDAwMDEiLCJjbmYiOnsieDV0I1MyNTYiOiJMQUVZMjlTalNKLU9hOGx1cUtZbUhLZks4NFh6dVJzd0U0OGJOakd0QV9FIn0sImV4cCI6MTYyMjQ0OTcyMywiaWF0IjoxNjIyNDQ5MTIzLCJqdGkiOiJvcHdvdUM2M0FjMlpfaXVBWmhiX1ktNGpGcFdKazFEa2E0RVNYUFlqM2xNIn0.Uv0O7aza0BMF2Wy8dU3rgGkpL5isDSL8qRx6kZqBq2Rp4RAGeebe3R5KyKFvP32nOLwFdF8s2TFT6Mgz9oGZBuivvWom7dfYFm2hQY5vtDfl46DyybNySWy6ZYKMswAyQBzGjZoqlrqJBp4i44X6tqNwqQJhDX-F3vptiyG3t0uxV3Oz1K0pxy6ILNBeVlhGL_KqZ9bbJvpKhj0WtPHNY0Y5ZVXxVgnkoISE05Ci_POoT-i0YN9g_7oAZYA6Fe-ECz8h3bmskxwE5qVrlPeoXJfKTiQmgcPp8RHnFYMEKJlQ-stM3Q3Azk6L003f0J_-3Uawr7be-AJw3FyRDzR6SA

Where the payload decodes as follows:

{
  "iss": "https://testidp.sandbox.openbanking.verimi.cloud/issuer/10000001",
  "cnf": {
    "x5t#S256": "LAEY29SjSJ-Oa8luqKYmHKfK84XzuRswE48bNjGtA_E"
  },
  "exp": 1622449723,
  "iat": 1622449123,
  "jti": "opwouC63Ac2Z_iuAZhb_Y-4jFpWJk1Dka4ESXPYj3lM"
}
The access token MUST NOT contain any personal identifiable information for privacy and security reasons. The authorization of the QTSP to obtain user and transaction data in the context of the current transaction needs to be determined first by the AS while processing the Token Introspection request.

4.4. Signature Creation

The RP is now prepared to initiate the remote signature creation. It asks the user for her approval (#29 & #30) and then sends the signature request to the QTSP (#31).

4.4.1. signDoc Request

The signature request follows the definition given in ETSI TS 119 432 for the signDoc request.

In case of this specification, the signature request is always mutually authenticated using TLS. The QTSP MUST support TLS Client Authentication for self-signed certificates as defined in OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens, i.e., the TLS authentication must be performed without CA/Trust Chain validation. The security of the transaction is ensured by matching the client certificate from the TLS handshake with the fingerprint associated with the access token.

The QTSP MUST support the synchronous operation mode as defined in ETSI TS 119 432, which is also the default operation mode if not requested otherwise by the RP.

The QTSP MUST accept all request parameters listed in Table 36 of ETSI TS 119 432. Requests containing unknown parameters must be refused by returning an HTTP status code 400 to the RP.

The QTSP must support the following parameters:

  • SAD REQUIRED The request authorization data. In case of this specification, this parameter includes the access token obtained in the previous protocol step.

  • credentialID REQUIRED The identifier associated to the private key and corresponding certificate. In the context of this specification that uses ad-hoc certificates only, credentialID denotes the kind of signature the RP wants the QTSP to create. The only possible value in this specification is qes_eidas. The credentialID MUST match the credentialID value as specified in the corresponding authorization_details.

  • documentDigests REQUIRED is an object encapsulating an array of Base64-encoded hash values (hashes) and the OID of the hash algorithm (hashAlgorithmOID) (see ETSI TS 119 432) used to generate the respective hash values. The hashes array contains one hash value per document to be signed and MUST not be empty.

  • profile: REQUIRED String that identifies the protocol being used by the client to communicate to the signature creation endpoint. The value MUST be http://uri.etsi.org/19432/v1.1.1#/creationprofile#.

  • signature_format: REQUIRED The requested signature format, possible values are:

    • C shall be used to request the creation of a CAdES signature;

    • X shall be used to request the creation of a XAdES signature;

    • P shall be used to request the creation of a PAdES signature.

  • conformance_level OPTIONAL The required baseline level format:

    • AdES-B-B shall be used to request the creation of a baseline level B signature;

    • AdES-B-T shall be used to request the creation of a baseline level T signature;

    • AdES-B-LT shall be used to request the creation of a baseline level LT signature;

    • AdES-B-LTA shall be used to request the creation of a baseline level LTA signature.

  • signAlgo OPTIONAL String The OID of the algorithm to use for signing.

  • signAlgoParams REQUIRED Conditional String The Base64-encoded DER-encoded ASN.1 signature parameters, if required by the signature algorithm. Some algorithms like RSASSA-PSS, as defined in RFC 8017, may require additional parameters.

The signature formats and corresponding conformance levels relate to ETSI EN 319 122 and ETSI EN 319 142.

The parameter conformance_level is optional. The default baseline level according to ETSI EN 319 142 is AdES-B-B in case it is omitted. If a timestamp is needed, its request and inclusion is managed by the signature creation service according to signature creation service’s configuration and policies.

Since this solution design utilizes on-demand, short-lived certificates for signature creation, RPs SHOULD request signature creation using a conformance level that includes a timestamp into the signature, e.g., AdES-B-T. This ensures successful signature validation even after certificate expiration.

QTSPs MUST support signature_format values C and P and conformance_level values AdES-B-B and AdES-B-T and SHOULD support conformance_level AdES-B-LT.

Support for more signature formats and conformance levels may become a mandatory requirement for QTSPs in the scheme in the near future in order to fulfill market requirements.

Example 10. Example request
POST 5634/csc/v1/signatures/signDoc
Content-Type: application/json
host: qtsp.com

{
   "credentialID":"qes_eidas",
   "SAD":"eyJraWQiOiJDWHVwIiwiYWxnI...",
   "documentDigests":{
      "hashes":[
         "sTOgwOm+474gFj0q0x1iSNspKqbcse4IeiqlDg/HWuI=",
         "HZQzZmMAIWekfGH0/ZKW1nsdt0xg3H6bZYztgsMTLw0="
      ],
      "hashAlgorithmOID":"2.16.840.1.101.3.4.2.1"
   },
   "profile":"http://uri.etsi.org/19432/v1.1.1#/creationprofile#",
   "signature_format":"P",
   "conformance_level":"AdES-B-T"
}

The QTSP first validates the access token passed in the SAD parameter (#32). The access token is a JSON Web Token that is signed using JWS and the JWA algorithm RS256.

The access token check involves the following steps:

  • The QTSP checks whether the Issuer URL conveyed in the iss claim identifies a legit IDP. The QTSP obtains the list of all active IDPs from the IDP directory. The QTSP is supposed to locally cache this data. If the Issuer URL does not identify a legit IDP, processing is terminated and the request is refused by responding with an HTTP status code 401.

  • The QTSP checks the JWT’s exp element to determine if the JWT is still valid and if the iat element is in the past. If the check fails, the QTSP MUST abort processing and refuse the request by responding with an HTTP status code 401.

  • The QTSP checks the fingerprint in the cnf/x5t#S256 element against the fingerprint of the TLS Client Certificate used by the RP to authenticate at the connection to the QTSP endpoint. If the fingerprint does not match, processing is terminated and the request refused by responding with an HTTP status code 401.

  • The QTSP checks the digital signature of the access token. The QTSP checks that the access token was signed using RS256. The AS’s public key is obtained from the respective server’s JWKS in its OAuth configuration, the URL of which is obtained by appending /.well-known/oauth-authorization-server to the issuer URL (messages #31 and #32). If the signature validation fails, processing is terminated and the request is refused by responding with a HTTP status code 401.

4.4.2. Token Introspection Request

The QTSP then needs to obtain the user and token data from the AS’s Introspection Endpoint. The QTSP utilizes the OAuth configuration obtained in messages #31 and #32 to determine the Token Introspection Endpoint URL (see RFC 8414 - element introspection_endpoint).

The QTSP then sends an introspection request to this endpoint (#35).

The QTSP authenticates towards the AS using its client_id and certificate with this AS (see Setup and Operations) by utilizing OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens. Since the QTSP wants the AS to digitally sign the introspection response, it includes an HTTP Accept header with content type application/jwt (as specified in JWT Response for OAuth Token Introspection).

This is an example request

POST /token/introspect
Host: as.example-bank.com
Accept: application/jwt
content-type: application/x-www-form-urlencoded

client_id=client_id_qtsp
token=eyJraWQiOiJDWHVwIiwiYWxnIjoiUlMyNTYifQ.eyJpc3MiOiJodHRwOlwvXC8xMjcuMC4wLjE6ODA4MFwvYzJpZCIsImNuZiI6eyJ4NXQjUzI1NiI6Ill6RWNOdlVWM1FYQTVCaTlJQjY2Yjhwc3lxWkJRZ1c0NTAwWkd2TlJkaXMifSwianRpIjoiTDdIMHRNT1pBTVB3N3lnVjdsM1BoaktpWkttVkVBTDU5S0dDS2ZTVi1DayJ9.cGvISXmIfJFnV5GKBYG6C0x_bqsnzjcS3AcSVJgDfry5mfrSqzDlQqZn2DO_FyJQyxhiE6UNEWqBcC14OxPoYM0K-9QtJxfacQ9Dx9PUr2sixTQTDw3llCAB8TAIThOVJQ8a-g5WYhIGnOtJKN__DPYLZNm0cvWXh5bfcJIsbG-R7ZDIsut_kAmLL_-2Wm0LXd2ZiLagSk-n0nEdbGt46rUw7MNvsZ7mw3kkb9AT

The AS first authenticates the QTSP. It checks whether the certificate used for TLS client authentication matches one of the certificates valid for this client_id. If this check fails, the AS responds with an error response and HTTP status code 401.

In the next step, the AS checks whether the access token has expired.

The AS then validates whether the QTSP is permitted to obtain data about the access token. This is the list of checks:

  • The AS obtains the authorization data types the QTSP, identified by its client_id, is authorized for from the SP configuration (authorization_data_types_supported). This list MUST contain sign.

  • The AS then checks whether the particular access token’s authorization_details contain an element of type sign with locations containing the client_id of the QTSP.

  • In the last step, the AS validates that the calling QTSP is the same whose data were shown in the corresponding user consent (the qtsp_id used in the authorization process MUST be the same as the client_id of the caller).

4.4.3. Token Introspection Response

If any of these checks fails, the AS responds with an JWT containing the active claim with a status value false. The following example shows the respective JSON payload 

{
    "active": false
}

Otherwise, the AS responds with a signed JWT containing all relevant data associated with the access token and all user and RP data the service is authorized to learn (#37).

The data is determined from the QTSPs service provider configuration (see Setup and Operations). The AS MUST always include the following standard JWT claims: active, iss, aud, authorization_details, client_id, cnf.

In the case of a qualified electronic signature, the typical data set is

  • active (whether the access token is active)

  • iss (issuer - the AS)

  • aud (client id of the QTSP)

  • iat (introspection response issued at)

  • exp (expiration of the access token)

  • sub (user id)

  • client_id (identifier of the RP)

  • cnf/x5t#S256 (fingerprint of the RP’s TLS certificate), contained in cnf claim

  • acr attests the authentication policy utilized by the IDP to authenticate the user. It MUST be https://www.openbanking.verimi.cloud/acrs/online_banking_sca

  • verified_claims

    • This claim is documented in the Identity Service, section “Verified Person Data”

    • The claims sub-element (typically) contains the following user claims:

      • given name,

      • family_name,

      • birthdate,

      • place_of_birth

    • The verification sub-element contains the respective data documenting the person data verification process.

  • txn - referring to the transaction at the AS, in which the user was authenticated and initiated the remote signature creation as specified in the Identity Service, section "Verified Person Data"

  • authorization_details: the authorization_details from the pushed authorization request

  • https://www.openbanking.verimi.cloud/claims/documents_consented - URLs of the QTSP’s terms of service and privacy declaration the user consented with

  • client_state: Status of the RP as obtained by the IDP from the platform. The value can be active or demo. (Although RPs can be in the status inactive, this value cannot show up in an introspection response since IDPs MUST NOT process requests from inactive RPs.)

This is an example of a signed introspection response: 

HTTP/1.1 200 OK

eyJhbGciOiJIUzI1NiJ9.eyJhY3RpdmUiOnRydWUsImlzcyI6Imh0dHBzOi8vYXMuZXhhbXBsZS1iYW5rLmNvbSIsImF1ZCI6InNwOnllcy5jb206NmEyNTZiY2EtMWUwYi00YjBjLTg0ZmUtYzlmNzhlMGNiNGEzIiwic2NvcGUiOiJodHRwczovL3d3dy55ZXMuY29tL3Njb3Blcy9zaWduOjNBMzZmYzY3Nzc2IiwiaWF0IjoxNTMyNDUyMDg0LCJjbGllbnRfaWQiOiJjbGllbnRzLnllcy5jb206MzYzMEJGNzItRTk3OS00NzdBLUE4RkYtOEEzMzhGMDdDODUyIiwiY2xpZW50X3N0YXRlIjoiYWN0aXZlIiwiY25mIjp7Ing1dCNTMjU2IjoiWXpFY052VVYzUVhBNUJpOUlCNjZiOHBzeXFaQlFnVzQ1MDBaR3ZOUmRpcyJ9LCJzdWIiOiIxMjM0NTY3ODkwODc2MzIzNDU2NzgiLCJhY3IiOiJodHRwczovL3d3dy55ZXMuY29tL2FjcnMvb25saW5lX2Jhbmtpbmdfc2NhIiwidmVyaWZpZWRfY2xhaW1zIjp7InZlcmlmaWNhdGlvbiI6eyJ0cnVzdF9mcmFtZXdvcmsiOiJkZV9hbWwiLCJkYXRlIjoiMjAxMy0wMi0yMSIsInZlcmlmaWNhdGlvbl9wcm9jZXNzIjoiNjc2cTM2MzY0NjE0Njc2NDdxODQ5ODc4NTc0N3E0ODciLCJldmlkZW5jZSI6W3sidHlwZSI6ImlkX2RvY3VtZW50IiwibWV0aG9kIjoicGlwcCIsImRvY3VtZW50Ijp7InR5cGUiOiJpZGNhcmQiLCJpc3N1ZXIiOnsibmFtZSI6IlN0YWR0IEF1Z3NidXJnIiwiY291bnRyeSI6IkRFIn0sIm51bWJlciI6IjUzNTU0NTU0IiwiZGF0ZV9vZl9pc3N1YW5jZSI6IjIwMTItMDQtMjMiLCJkYXRlX29mX2V4cGlyeSI6IjIwMjItMDQtMjIifX1dfSwiY2xhaW1zIjp7ImdpdmVuX25hbWUiOiJNYXgiLCJmYW1pbHlfbmFtZSI6Ik1laWVyIiwiYmlydGhkYXRlIjoiMTk1Ni0wMS0yOCIsInBsYWNlX29mX2JpcnRoIjp7ImNvdW50cnkiOiJERSIsImxvY2FsaXR5IjoiTXVzdGVyc3RhZHQifX19LCJhdXRob3JpemF0aW9uX2RldGFpbHMiOlt7InR5cGUiOiJzaWduIiwibG9jYXRpb25zIjpbInNwOnllcy5jb206NmEyNTZiY2EtMWUwYi00YjBjLTg0ZmUtYzlmNzhlMGNiNGEzIl0sImNyZWRlbnRpYWxJRCI6InFlc19laWRhcyIsImRvY3VtZW50RGlnZXN0cyI6W3siaGFzaCI6InNUT2d3T20rNDc0Z0ZqMHEweDFpU05zcEtxYmNzZTRJZWlxbERnL0hXdUk9IiwibGFiZWwiOiJLcmVkaXR2ZXJ0cmFnIn0seyJoYXNoIjoiSFpRelptTUFJV2VrZkdIMC9aS1cxbnNkdDB4ZzNINmJaWXp0Z3NNVEx3MD0iLCJsYWJlbCI6IlZlcnRyYWcgUmVzdHNjaHVsZHZlcnNpY2hlcnVuZyJ9XSwiaGFzaEFsZ29yaXRobU9JRCI6IjIuMTYuODQwLjEuMTAxLjMuNC4yLjEifV0sImh0dHBzOi8vd3d3Lnllcy5jb20vY2xhaW1zL2RvY3VtZW50c19jb25zZW50ZWQiOnsicG9saWN5X3VyaSI6Imh0dHBzOi8vYWlzLnRlc3QvcG9saWN5X3YxXzIiLCJ0b3NfdXJpIjoiaHR0cHM6Ly9haXMudGVzdC90b3NfdjFfMSJ9LCJ0eG4iOiI5ZmUwZDA0ZC03MDk0LTRmMjgtOGMxYi02Nzc2ZDEzODE0YTQifQ.RfXXSFktkK28H8gt6i_T69jvRIExSfK95AWG3u9OLlQ
The QTSP stores this signed response as evidence for identification and signature initiation in its audit log.

The JSON payload of the example response is:

{
   "active":true,
   "iss":"https://as.example-bank.com",
   "aud":"sp:yes.com:6a256bca-1e0b-4b0c-84fe-c9f78e0cb4a3",
   "iat":1532452084,
   "client_id":"yes.com:3630BF72-E979-477A-A8FF-8A338F07C852",
   "client_state":"active",
   "cnf":{
      "x5t#S256":"YzEcNvUV3QXA5Bi9IB66b8psyqZBQgW4500ZGvNRdis"
   },
   "sub":"123456789087632345678",
   "acr":"https://www.openbanking.verimi.cloud/acrs/online_banking_sca",
   "verified_claims":{
      "verification":{
         "trust_framework":"de_aml",
         "evidence":[
            {
               "type":"id_document",
               "document":{
                  "type":"idcard",
                  "issuer":{
                     "name":"Stadt Augsburg",
                     "country":"DE"
                  },
                  "number":"53554554",
                  "date_of_issuance":"2012-04-23"
               }
            }
         ]
      },
      "claims":{
         "given_name":"Max",
         "family_name":"Meier",
         "birthdate":"1956-01-28",
         "place_of_birth":{
            "country":"DE",
            "locality":"Musterstadt"
         }
      }
   },
   "authorization_details":[
      {
         "type":"sign",
         "locations":[
            "sp:yes.com:6a256bca-1e0b-4b0c-84fe-c9f78e0cb4a3"
         ],
         "credentialID":"qes_eidas",
         "documentDigests":[
            {
               "hash":"sTOgwOm+474gFj0q0x1iSNspKqbcse4IeiqlDg/HWuI=",
               "label":"Kreditvertrag"
            },
            {
               "hash":"HZQzZmMAIWekfGH0/ZKW1nsdt0xg3H6bZYztgsMTLw0=",
               "label":"Vertrag Restschuldversicherung"
            }
         ],
         "hashAlgorithmOID":"2.16.840.1.101.3.4.2.1"
      }
   ],
   "https://www.openbanking.verimi.cloud/claims/documents_consented":{
      "policy_uri":"https://ais.test/policy_v1_2",
      "tos_uri":"https://ais.test/tos_v1_1"
   },
   "txn":"9fe0d04d-7094-4f28-8c1b-6776d13814a4"
}
Billing Mediation (IDP)

Before sending the introspection response, the AS sends a mediation record to the Mediation Service (#35) in order to document the delivery of user and other data to the QTSP.

The only exception are RPs in the state demo (client_state is demo in Introspection Response), which indicates that the client can participate in the ecosystem without mediation records being written. For more information, see the IDP Core Specification.

This mediation record contains the following data:

  • type is set to identity_for_service_provider

  • delivery_time: instant of time when the service was delivered by the AS

  • transaction_id: identifier of the transaction at the AS

  • owner_id: owner Id of the AS (assigned by us)

  • issuer: issuer URL of the AS

  • service_provider_id: client_id of the QTSP

  • client_id: client id of the ultimate RP the calling QTSP is supposed to be serving (client_id from authorization request)

  • requested_claims: A JSON-Objekt (based on the scheme of the OpenID Connect claims parameter) containing all requested claims along with the information whether the respective claim was marked as being essential. This element is a duplicate of the required_claims configuration parameter in the respective SP configuration.

  • provided_claim_names: array of the names of the claims the AS provided to the QTSP. In case of verified claims the entries are built as follows:

    • For every claim embedded in the verified_claims/claims element, the entry is built by concatenating verified_claims/claims/ and the respective claim name, e.g., verified_claims/claims/place_of_birth.

    • For every entry in the verified_claims/verification element that is not a container element, the entry is built by concatenating verified_claims/verification and the respective claim name, e.g., verified_claims/verification/trust_framework. For every element provided in a container underneath verified_claims/verification, the name is build by concatinating verified_claims/verification, the names of the container elements and the respective claim name, using the separator /. Exception: For the evidence container the type of the particular evidence is appended in the following format: evidence[type='id_document']. Example: verified_claims/verification/evidence[type='id_document']/document/date_of_issuance.

  • provided_acr_value: acr value as attested to the QTSP

  • endpoint: endpoint used to deliver the claims. Is set to introspection.

  • reference_id: OPTIONAL. String (1 to 100 characters restricted to a-z, A-Z, 0-9 and dashes ("-"), e.g., a uuid) generated by the IDP as unique mediation record id to prevent multiple mediation records for the same event. Uniqueness is considered per IDP (issuer+service_provider_id elements). If the field is provided in the mediation record, the mediation service checks whether a mediation record with the same reference_id for the same issuer already exists and will refuse processing in that case.

Custom claims are included in billing mediation data in the same way as regular claims.

This data is used for settlement and clearing between the participants of the transaction. Should the AS fail to deliver the mediation record, for example because of a network error, it is expected to persist the record and retry delivery at a later point in time. Such a failure should not have an impact on the delivery of the introspection response to the QTSP.

4.4.4. Creation of Certificate and Signatures

The QTSP validates (#38) that

  • the Introspection Response was issued by the expected AS (iss claim) for the QTSP (aud claim)

  • the access token is valid (active is true, value of claim iat is not in the future, value of claim exp is not in the past)

  • the Introspection Response has been signed by the AS (utilizing the kid of the JWT and the jwk_uri of the AS’s OAuth configuration)

  • every hash in the request matches one of the hashes in the array documentDigests in the authorization_details element and the corresponding hashAlgorithmOID values match.

  • the credentialID in the request matches the credentialID in the authorization_details element

The service provider creates a short-lived certificate (#39) based on the certificate profile identified by the credentialID using the data provided by the AS.

Using the new certificate, the QTSP creates a signature (#40). The private key corresponding to this certificate is invalidated afterwards.

Billing Mediation (QTSP)

Before the QTSP returns the signature data and the certificate to the RP it sends a mediation record to the Mediation Service (#41) in order to document the service it is about to provide to the RP.

The mediation record contains the following data:

  • type is set to remote_signature_creation

  • delivery_time: Instant of time when the service was delivered by the QTSP

  • transaction_id: transaction identifier obtained from the Introspection Response.

  • owner_id: Owner Id of the QTSP (assigned by us)

  • credentialID: same value as in the sign request, i.e. qes_eidas

  • count: number of signatures created

  • service_provider_id: client_id of the QTSP in the platform

  • client_id: client_id of the RP

  • issuer: issuer URL of the AS that provided the identity and transaction data for this transaction

  • reference_id: OPTIONAL. String (1 to 100 characters restricted to a-z, A-Z, 0-9 and dashes ("-"),e.g. a uuid) generated by the QTSP as unique mediation record id to prevent multiple mediation records for the same event. Uniqueness is considered per QTSP (service_provider_id+issuer elements). If the field is provided in the mediation record, the mediation service checks whether a mediation record with the same reference_id for the the same issuer already exists and will refuse processing in that case.

This data is used for settlement and clearing between the participants of the transaction. Should the QTSP fail to deliver the mediation record, for example because of a network error, it is expected to persist the record and retry delivery at a later point in time. Such a failure should not have an impact on the signature creation.

4.4.5. signDoc Response

The service provider returns certificate and signature data to the RP (#42).

The signing response MUST conform to the definition given ETSI TS 119 432, table 37.

In addition to ETSI TS 119 432 this specification also requires the QTSP to conditionally return revocation data in the additional revocationInfo response parameter (see below).

If an error occurs while processing the request, the QTSP shall return an HTTP status code 400 along with error information as specified in ETSI TS 119 432, Section 7.24.2.

In success case, the QTSP returns (at least) the following parameters:

  • SignatureObject is an array containing Base64-encoded signatures detached from the documents. If multiple hash values are signed in a single request, the order of the elements in the SignatureObject array follows the order of the entries in the documentDigests parameter of the request.

The structure of every signature element is built in accordance with RFC 5652.

In case the request parameter signature_format was set to C (CAdES), every object conforms to ETSI EN 319 122.

In case signature_format was P (PAdES), every object conforms to ETSI EN 319 142. The result can be embedded in a PDF signature object according to ETSI EN 319 142.

  • revocationInfo is a JSON Object containing revocation data that MUST be included in the signing response in case of signature_format P and conformance_level AdES-B-LT. It and is composed of the following elements:

    • ocsp array of base64 encoded strings containing the DER-encoded ASN.1 data structures of type OCSPResponse according to [RFC 6960].

    • crl array of base64 encoded strings containing the DER-encoded ASN.1 data structures of type CertificateList according to [RFC 5280]. This element is optional if the ocsp element is present.

This is an example response matching the example request given above: 

HTTP/1.1 200 OK +
{
   "SignatureObject":[
      "KedJuTob5gtvYx9qM3k3gm7kbLBwV…bEQRl26S2tmXjqNND7MRGtoew==",
      "AedJuTob5gtvYx9qM3k3gm7kbLBwV…bEQRl26S2tmXjqNND7MRGtoes=="
   ],
   "revocationInfo":{
      "ocsp":[
         "MIIJg...jSc="
      ],
      "crl":[
         "MIIC4...X7M="
      ]
   }
}

4.5. Document Finalization Phase

The RP adds all signature data to the document (#43) and presents it to the user (#44).

5. QES for Identity Assurance

Qualified electronic signatures can be enriched with identity data to (also) utilize them for identification purposes. This extension of the QES flow supports the following use cases:

  • QES with Identity Assurance: the QTSP (with support of the IDP) provides the RP with verified end-user claims in the signer’s certificate that is embedded in the electronic signatures for RP-provided documents (e.g., contracts).

  • QID: a simplified version of the "QES with Identity Assurance" where the RP is provided with claims in the same way, but without the need to sign RP-specific documents. This is useful for RPs that only have identification requirements but do not need to electronically sign a contract with the user. In this case, the user will be asked to sign a static document provided by the QTSP (designated as "default document") that functions as a bearer to convey the aforementioned end-user claims to an RP. The default document is just a plain text string that will be signed using the CAdES signature format.

In order to support these use cases, the standard QES flow as described above is extended to allow the RP to request certain end-user claims to be asserted by the QTSP. The QTSP will add these claims to the signer certificate that is embedded in every signature object returned in a signDoc response.

5.1. Service Configuration

The RP determines support for features related to QES for Identity Assurance from the service configuration of the respective IDP. The following parameters within remote_signature_creation element are relevant:

  • identity_assurance_claims_supported: JSON array containing the claims the QTSP supports

  • default_signing_documents: JSON array containing one or more objects that define the text of the default signing document. Each object contains two keys, lang and text, where lang contains a BCP47 language tag, e.g., de or en, and text contains the text of the default document in the respective language.

An example service configuration is shown in the following (line breaks for display purposes only):

Example 11. Service Configuration for QES for Identity Assurance 
{
  "identity":{
    "iss":"https://issuer.bankidp.com/5634"
  },
  ...
  "remote_signature_creation":[
    {
      "qtsp_id":"sp:yes.com:6a256bca-1e0b-4b0c-84fe-c9f78e0cb4a3",
      "signDoc":"https://qtsp.com/csc/v1/signatures/signDoc",
      "conformance_levels_supported":[
        "AdES-B-B",
        "AdES-B-T",
        "AdES-B-LT"
      ],
      "identity_assurance_claims_supported":[
        "given_name",
        "family_name",
        "birthdate",
        "place_of_birth",
        "nationalities",
        "address"
      ],
      "default_signing_documents":[
        {
          "lang":"de",
          "text":"Hiermit bestätige ich, dass ich die angegebenen Daten sorgfältig geprüft habe und diese auf meine Person zutreffen."
        },
        {
          "lang":"en",
          "text":"I hereby confirm that I have carefully checked the data provided and that they apply to my person."
        }
      ]
    }
  ]
}

5.1.1. Platform Configuration

The elements identity_assurance_claims_supported and default_signing_documents are determined by the respective elements in the QTSP’s SP configuration, as shown in the following example.

Example 12. Example QTSP SP Configuration with Default Documemt 
{
  "client_name":"Example Signing Service",
  "client_id":"sp:yes.com:6a256bca-1e0b-4b0c-84fe-c9f78e0cb4a3",
  "service_type":"remote_signature_creation",
  ...
  "identity_assurance_claims_supported":[
    "given_name",
    "family_name",
    "birthdate",
    "place_of_birth",
    "nationalities",
    "address"
  ],
  "default_signing_documents":[
    {
      "lang":"de",
      "text":"Hiermit bestätige ich, dass ich die angegebenen Daten sorgfältig geprüft habe und diese auf meine Person zutreffen."
    },
    {
      "lang":"en",
      "text":"I hereby confirm that I have carefully checked the data provided and that they apply to my person."
    }
  ]
}

5.2. Requesting Claims in authorization_details

The RP indicates the claims it wants to turn up in the signer certificate by adding an identity_assurance_claims element to the authorization_details element in the pushed authorization request. The syntax used to specify the RP’s requirements regarding the end-user claims follows the rules as defined in OpenID Connect. The RP MUST request each claim either using null or using setting {"essential": true}. The OP SHOULD ignore any other values, including restrictions using value/values/max_age.

The RP may request user claims from the following predefined set:

  • given_name

  • family_name

  • birthdate

  • place_of_birth

  • nationalities

  • address

This is also the list of claims that any OP MUST support. For address, the sub-fields street_address, locality, and postal_code MUST be supported.

Example 13. authorization_details with claims element 
{
   "type":"sign",
   "locations":[
      "sp:yes.com:6a256bca-1e0b-4b0c-84fe-c9f78e0cb4a3"
   ],
   "credentialID":"qes_eidas",
   "documentDigests":[
      {
         "hash":"sTOgwOm+474gFj0q0x1iSNspKqbcse4IeiqlDg/HWuI=",
         "label":"Kreditvertrag"
      },
      {
         "hash":"HZQzZmMAIWekfGH0/ZKW1nsdt0xg3H6bZYztgsMTLw0=",
         "label":"Vertrag Restschuldversicherung"
      }
   ],
   "hashAlgorithmOID":"2.16.840.1.101.3.4.2.1",
   "identity_assurance_claims":{
      "given_name":null,
      "family_name":null,
      "birthdate":null,
      "place_of_birth":null,
      "nationalities":null,
      "address":null
   }
}

5.3. Default Document (QID Service)

If the RP wants to use QID, it selects a default document in an appropriate language from default_signing_documents in the service configuration. The RP takes the hash of the respective default document from the UTF-8 encoding of the text element, Base-64 encoded as above. For example, with SHA-256, the string Hiermit bestätige ich, dass ich die angegebenen Daten sorgfältig geprüft habe und diese auf meine Person zutreffen. hashes to hhZiIQste6V0dvTsil1RMY07EIMgPEHFLQE2GvebWf4=.

If QID is not to be used, the RP can provide custom documents to be signed as described above.

Default documents (QID) are only supported within QES for Identity Assurance, i.e., if claims are requested for inclusion in the signer’s certificate as described above.

The RP MUST NOT provide more than one hash of a default document per request. The IDP MUST reject such requests using an invalid_authorization_details error (HTTP status code 400).

The label attribute of the documentDigest element is ignored by the IDP in case of QID. The label therefore MUST be empty. In case of mistakes (e.g., wrong string encoding before hashing), an empty label ensures that the process is aborted instead of proceeding with a document that is not a default document.
Example 14. authorization_details for QID 
{
   "type":"sign",
   "locations":[
      "sp:yes.com:6a256bca-1e0b-4b0c-84fe-c9f78e0cb4a3"
   ],
   "credentialID":"qes_eidas",
   "documentDigests":[
      {
         "hash":"hhZiIQste6V0dvTsil1RMY07EIMgPEHFLQE2GvebWf4=",
         "label":""
      }
   ],
   "hashAlgorithmOID":"2.16.840.1.101.3.4.2.1",
   "identity_assurance_claims":{
      "given_name":null,
      "family_name":null,
      "birthdate":null,
      "place_of_birth":null,
      "nationalities":null,
      "address":null
   }
}

5.4. Authorization Process

5.4.1. QTSP Support Check

The RP MUST NOT request claims for inclusion in the signer certificate that are not listed in the QTSP’s identity_assurance_claims_supported field. The IDP MUST reject such requests using the error code unable_to_meet_service_requirements. The IDP SHOULD send this error response already in response to the PAR request.

5.4.2. RP Permissions and Data Availability Check

The IDP checks what claims the RP is allowed to request to be included in the signer certificate. The claims an RP is allowed to request are determined by the element allowed_claims_qes of the RP’s platform configuration.

The RP configuration element is defined as follows:

  • allowed_claims_qes: JSON array containing the claims an RP is allowed to request.

Here is an example configuration snippet:

Example 15. RP Configuration for QID 
{
   ...
   "allowed_authorization_data_types": [
      "sign"
   ],
   "allowed_claims_qes":[
      "given_name",
      "family_name",
      "birthdate",
      "place_of_birth",
      "nationalities",
      "address"
   ]
}

The OP MUST act according to the following tables, with exceptions marked as (*) and described below:

When the claim is not marked as essential:

Claim in allowed_claims_qes not in allowed_claims_qes

Claim is defined and supported

deliver claim value

error response unauthorized_client

Claim is defined but not supported

omit claim

error response unauthorized_client

Claim is not defined and not supported

omit claim (*)

omit claim

(*) This case should never occur and the IDP MAY send an error response unable_to_meet_service_requirements instead.

When the claim is marked as essential:

Claim in allowed_claims_qes not in allowed_claims_qes

Claim is defined and supported

deliver claim value

error response unauthorized_client

Claim is defined but not supported

error response unable_to_meet_service_requirements

error response unauthorized_client

Claim is not defined and not supported

error response unable_to_meet_service_requirements (*)

omit claim

(*) This case should never occur and the IDP MAY omit the claim instead.

The IDP SHOULD send the error response unable_to_meet_service_requirements already in response to the PAR request if it has sufficient information to do so at this point.
In the lists above, a claim is called defined if it is defined in the set of identity assurance claims above. A claim is called supported if the IDP supports this claim and the respective data about the end-user is available. When a claim is to be omitted, it is not included in the claims section of the introspection response (see below) or consent screen, but will show up in the mediation record under requested_claims (see below). The error unauthorized_client refers to the OAuth error code.

If the IDP issues an error response to the RP, the error description SHOULD indicate that the IDP was unable to provide all data (with the requested properties) to the RP. If the problem cannot be detected already in the PAR request processing, the IDP SHOULD indicate the problem to the user before it redirects the user agent back to the RP and clearly state that the transaction will be aborted and no data will be shared with the RP or QTSP.

5.4.3. User Consent

In addition to the consent the IDP already gathers for the standard QES flow, the IDP also (on behalf of the QTSP) asks the user for the consent to provide the user claims to the RP in the signer certificate (including the purpose of this data transfer).

In the QID use case (signature over the default document), the IDP MUST show the full text of the default document in the user consent and ask the user for approval to sign this document.

The IDP determines the default document based on the hash provided by the RP and the list of default signing documents as configured for the respective QTSP. This requires the IDP to calculate the hashes of the available default documents.

5.5. Signing Request

The RP uses signDoc as defined in Signature Creation to request signature creation. The QTSP will automatically add the previously requested user claims to the signer certificate.

In the QID use case, the RP sends the hash of the default document, i.e., no special treatment is required from the QTSP’s perspective. The RP requests the creation of a CAdES signature (signature_format C) in this case.

This is shown in the following example.

Example 16. QID Example request
POST 5634/csc/v1/signatures/signDoc
Content-Type: application/json
host: qtsp.com

{
   "credentialID":"qes_eidas",
   "SAD":"eyJraWQiOiJDWHVwIiwiYWxnI...",
   "documentDigests":{
      "hashes":[
         "hhZiIQste6V0dvTsil1RMY07EIMgPEHFLQE2GvebWf4=",
      ],
      "hashAlgorithmOID":"2.16.840.1.101.3.4.2.1"
   },
   "profile":"http://uri.etsi.org/19432/v1.1.1#/creationprofile#",
   "signature_format":"C",
   "conformance_level":"AdES-B-T"
}

The IDP provides the QTSP with all user claims required for the creation of the Qualified Certificate as well as the additional data required to fulfill the inquiry for user claims in the qualified electronic signature.

The additional data is provided with the same verification requirements the QTSP has defined for the data required for the creation of the certificate; the data is returned in verified_claims/claims.
Example 17. Claims Returned by the IDP

For example, the QTSP might require first_name, given_name, birthdate, and place_of_birth according to its Certificate Practice Statement (and corresponding configuration in the SP Directory), but the RP also requests nationalities and address.

The set of user claims the IDP is providing the QTSP with would then consist of:

  • given_name

  • family_name

  • birthdate

  • place_of_birth

  • nationalities

  • address

The following introspection response example shows the full claim set: 

{
  "active":true,
  "iss":"https://as.example-bank.com",
  "aud":"sp:yes.com:6a256bca-1e0b-4b0c-84fe-c9f78e0cb4a3",
  ...
  "verified_claims":{
    "verification":{
      "trust_framework":"de_aml",
      "evidence":[
        {
          "type":"id_document",
          "document":{
            "type":"idcard",
            "issuer":{
              "name":"Stadt Augsburg"
            },
            "number":"53554554",
            "date_of_issuance":"2012-04-23"
          }
        }
      ]
    },
    "claims":{
      "given_name":"Max",
      "family_name":"Meier",
      "birthdate":"1956-01-28",
      "place_of_birth":{
        "country":"DE",
        "locality":"Musterstadt"
      },
      "nationalities":[
        "DE"
      ],
      "address":{
        "locality":"Maxstadt",
        "postal_code":"12344",
        "country":"DE",
        "street_address":"An der Sanddüne 22"
      }
    }
  },
  "authorization_details":[
    {
      "type":"sign",
      "locations":[
        "sp:yes.com:6a256bca-1e0b-4b0c-84fe-c9f78e0cb4a3"
      ],
      "credentialID":"qes_eidas",
      "documentDigests":[
        {
          "hash":"hhZiIQste6V0dvTsil1RMY07EIMgPEHFLQE2GvebWf4=",
          "label":""
        }
      ],
      "hashAlgorithmOID":"2.16.840.1.101.3.4.2.1",
      "identity_assurance_claims":{
        "given_name":null,
        "family_name":null,
        "birthdate":null,
        "place_of_birth":null,
        "nationalities":null,
        "address":null
      }
    }
  ]
}
If the IDP is unable to provide certain claims the RP requested, it will omit this data in the token introspection response. QTSPs MUST take into account that claims may be missing for this reason.

5.5.1. Billing Mediation

The IDP will add the names of all claims provided to the QTSP to the mediation record (type=identity_for_service_provider) before returning the Introspection Response to the QTSP.

The QTSP determines whether id data shall be added to the signer certificate based on the data provided in the pushed authorization request.

The QTSP will add the following data to the standard QES mediation record (type is remote_signature_creation):

  • requested_claims: A JSON object containing the names of all requested claims along with the information whether the respective claim was marked as being “essential”. This element is a duplicate of the identity_assurance_claims element in the authorization_details.

  • provided_claim_names: array of the names of the claims the QTSP provided to the RP.

The QTSP needs to compare every hash to the hashes of its default documents. In case the RP requested only the signing of a default document, this hash is not counted in the count element of the mediation record, i.e. count MUST be 0.

5.5.2. Document Signing

The QTSP signs the hashes of the documents, provided by the RP, using the user’s private key and creates corresponding signature objects as defined in ETSI EN 319 122 (CAdES) or ETSI EN 319 142 (PAdES), respectively.

These signature objects (also containing the signer certificate and respective CA’s certificate) are provided to the RP.

Claims Representation

The requested claims are delivered to the RP in the Signer certificate.

A formal description of the claims representation and verification is given in Formal Description.

The QTSP creates a fresh public/private key pair for the user and creates a corresponding X.509 signer certificate that is issued and signed by its respective Certification Authority (CA).

The QTSP adds the user claims to the X.509 signer certificate in the following places:

OpenID claim name X.509 container X.509 attribute name OID

family_name

SubjectDN

surName

2.5.4.4

given_name

SubjectDN

givenName

2.5.4.42

address/country

SubjectDN

countryName

2.5.4.6

address/postal_code

SubjectDN

postalCode

2.5.4.17

address/street_address

SubjectDN

streetAddress

2.5.4.9

birthdate

Subject Directory Attributes

dateOfBirth

1.3.6.1.5.5.7.9.1

place_of_birth

Subject Directory Attributes

placeOfBirth

1.3.6.1.5.5.7.9.2

nationalities

Subject Directory Attributes

countryOfCitizenship

1.3.6.1.5.5.7.9.4

For details on standard certificate attributes and usage of “Subject Directory Attributes” see RFC5280 and RFC3739.

The QTSP MUST add one countryOfCitizenship attribute per entry in the nationalities array (see also RFC3739, section 3.2.2).
If the IDP did not provide one or more claims the RP requested, or if claims unknown to the QTSP are requested by the RP or included in the introspection response, the QTSP will omit this data in the qualified certificate.

5.6. Verification

The RP verifying the signature and consuming the identity data must check that

  1. the signature is valid (using the signer certificate provided in the signature object),

  2. the signer certificate is valid including trust chain verification up to a trusted root CA,

  3. the identity data in the signer certificate is complete and equals the expected identity data.

5.7. Formal Description

The following symbolic formal description is provided as an overview of the identity assurance’s underlying security model.

qes4id formal
Figure 1. Symbolic formal description of the signing mechanism with identity assurance. Note that “QTSP” and “Signer” are only separated for presentation.

6. Setup and Operations

This section describes the concept for managing the trust relationships among QTSPs and IDPs as well as the management of the (RP-facing) service configurations.

The QTSP will maintain a single endpoint for processing signing requests on behalf of customers of the different financial institutions participating in .

The RP determines the endpoint URLs from a per-bank service configuration maintained by (see above). An example is shown in the following: 

{
   "identity":{
      "iss":"https://accounts.testbank.com"
   },
   ...
   "remote_signature_creation":[{
      "signDoc":"https://signing.example.com/csc/v1/signatures/signDoc",
      "conformance_levels_supported":[
         "AdES-B-B",
         "AdES-B-T",
         "AdES-B-LT"
      ]
   }]
}

6.1. Platform

The platform supports setup and maintenance of the service instances and their relationships with the Service Provider Directory (SP Directory).

Every QTSP is represented by a single entry in the SP Directory, containing the following data:

  • client_name: the name of the respective service provider. It will be used in the user consent by the IDP.

  • client_id: the universal id of the service provider in the scheme. It is used in the interactions of the service provider with the IDPs as well as to identify the service provider in the clearing and settlement process. The client_id is built according to the following rule:

sp:<stage.>yes.com:<uuidv4>

  • service_type: set to remote_signature_creation in case of an QTSP

  • authorization_data_types_supported: This field lists the authorization data types the particular service provider supports. The AS uses this data to filter introspection responses to data the service provider is entitled to receive.

  • required_claims: the claims the service provider wants to obtain from the AS in order to provide its service. The list of possible claims is determined by the definition in Identity Service. Additionally, the claims https://www.openbanking.verimi.cloud/claims/signing_consent and https://www.openbanking.verimi.cloud/claims/documents_consented as defined in this document can be used. The way the claims are referenced in this structure is the same as for the OpenID Connect Authentication Request Parameter claims within the userinfo or id_token sub-field.

service providers shall request the minimal data set required to fulfil their service in order to comply with the "privacy by design" principle.

  • conformance_levels_supported: This field contains a list of the baseline level formats supported by the QTSP.

  • subject_type: type of subject the service provider wants the AS to attest (same values as for RPs).

  • token_endpoint_auth_method: same as for RPs (self_signed_tls_client_auth only), this authentication method is used towards the Introspection Endpoint of authorization servers.

  • jwks: public key certificates of the service provider

  • jwks_uri: URI pointing to the public key certificates of the service provider

  • policy_uri: same as for RPs, shown in the user consent screen by the AS. NOTE: The QTSP SHOULD encode the version of the respective document into the URL. That way, the AS will attest the version of the terms of service the user consented with in the introspection response.

  • tos_uri: same as for RPs, shown in the user consent screen by the AS. NOTE: The QTSP SHOULD encode the version of the respective document into the URL. That way, the AS will attest the version of the terms of service the user consented with in the introspection response.

  • tos_uri_label: same as for RPs, shown in the user consent screen by the AS

  • status: same as for RPs, AS must only serve a service provider record if the status is active

  • endpoints: list of named endpoint URLs exposed by the SP

The following shows an example service provider configuration: 

{
    "client_name": "Example Signing Service",
    "client_id": "sp:yes.com:6a256bca-1e0b-4b0c-84fe-c9f78e0cb4a3",
    "service_type": "remote_signature_creation",
    "authorization_data_types_supported": [
        "sign"
    ],
    "required_claims": {
        "acr":{
           "essential":true,
           "value":"https://www.openbanking.verimi.cloud/acrs/online_banking_sca"
        },
        "txn":{
           "essential":true
        },
        "sub":{
           "essential":true
        },
        "https://www.openbanking.verimi.cloud/claims/documents_consented":{
           "essential":true
        },
        "verified_claims": {
            "verification": {
                "trust_framework": {
                    "value": "de_aml"
                },
                "evidence": [
                    {
                        "type": {
                            "value": "id_document"
                        },
                        "document": {
                            "type": {
                                "values": [
                                    "idcard",
                                    "passport",
                                    "de_idcard_foreigners",
                                    "de_emergency_idcard",
                                    "de_idcard_refugees",
                                    "de_idcard_apatrids",
                                    "de_certificate_of_suspension_of_deportation",
                                    "de_permission_to_reside",
                                    "de_replacement_idcard",
                                    "de_erp_replacement_idcard",
                                    "de_erp"
                                ]
                            },
                            "issuer": {
                                "country": null,
                                "name": {
                                    "essential": true
                                }
                            },
                            "number": {
                                "essential": true
                            },
                            "date_of_issuance": {
                                "essential": true
                            }
                        }
                    }
                ]
            },
            "claims": {
                "place_of_birth": {
                    "essential": true
                },
                "birthdate": {
                    "essential": true
                },
                "given_name": {
                    "essential": true
                },
                "family_name": {
                    "essential": true
                }
            }
        }
    },
    "conformance_levels_supported": [
        "AdES-B-B",
        "AdES-B-T",
        "AdES-B-LT"
    ],
    "subject_type": "public",
    "token_endpoint_auth_method": "self_signed_tls_client_auth",
    "jwks": {
        "keys": [
            {
                "kty": "RSA",
                "kid": "11131175873467368503",
                "x5c": [
                    "MIIEmDCCAoACCQCaeeF7PmvENzANBgkqhkiG9w0BAQsFADAOMQwwCgYDVQQDDANzZWIwHhcNMTgwNjI3MTIwOTQyWhcNMTkwNjI3MTIwOTQyWjAOMQwwCgYDVQQDDANzZWIwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCZk87sR04GOmHjOmqTXlhehJ4uKmwR/qHD0Og/zlnJLzBJxD3cmNaZvEAd9d1WpoZ8xwgPLaJSwkNztZi3zod9MqygFzJoSpsLF95q8wau83qwHYukSSo4mSNWW6fgcYdgG/VnKlfcugKAe3p3BkV1HXE153230ZITuhtvQV2zxvbYjuNO3rJQBftv9JN1awR6w7CrW8JIA3vvu4TtxFiaxMp381bOR4YQ6UfywnYwHVlX7wGo29K6vCeDpUOL/r1V0C/vE2mO14nhYblqgV8LRoslSw2ulI4xdApP9NOMY2P5zJwRRWUxe7P+PbfK7peQlPihi4XWohwi2cVIaA14W3CtmXo15r5iE6B/xyYM3F0Dwg9PoJ1LJvyzxICF7IC4OT/h0qD0ZQChoRPEjjrYkUFK5McYd51zo1WwdRUjUSN9L8UCfUq34QoqAmrFt0wwOB45WNgihR2BepNx2N7gqVxSrrYjsycEO5g3qvfpJduH4CJPQ0MQN1VCzxDAZBGpA18wSwkklDh/CFSqSghWUKIB8pQdubqFYk/OB+BcT+zkGR9QAXprhAU2FFdzCsZGE4Q2b6fr51++nLvpWrUYbalMpvf75cbhfdrD+dEXJrtSp9ulqHrZFOk8Tdjh0CNw/ooewWTPnBrlaI51z3GhG4X58AHzzMUeWi/K4jduNwIDAQABMA0GCSqGSIb3DQEBCwUAA4ICAQBBCbc9aVDqiy0n2UyOv+WDNhQEat1rGEeeg9atXHwiVqCVr1Q3oVz5TE6eyvz0rhs2Uv6efTNz2wrEYjNdHpSQrIO/HmALpOU8RfjAF9mDMqBW97Cv8OzFVznoUIhzeKz3d65uQVe6nWdvR8KZUequ5ZwxCEBNEgURwqOBHItRkokS7GEgMprWsu6rF1ktAoKBu2PnCCBWLnMggmvLJGOK0St3GkbkJVTkG+3eQpqN4kunLOLCOmaOrHcV0jQBY8Zs/fZyFIUde4YAgnQs5Fwp6rWtJam8si90I78Rw6EhxqFRIHBuJ6wAFH+0FPL19FCaf4ZyoEGeSTSUkgVwjFnjThR5wRxZy6RZarlm5l6G9OwE52FyKo+ujnQgxgN0a/1WTFDzOGslS+1xg3KIGa1gdxqGgnDfbw/sKsdHIV71LWu93ADKSNt2AHL/En9MxkqrbKOL2KXsRZqRyLz+tRQ4YCJUF2L6XD8oE28N/cPbG3vU2ptD+rRtObWiZ6o9bS6mvEDvydV4J9EoQ94mPnTCqK5r00ppAdW/Q2JVr7KVthXlIBb9+hiM2HjEfloXvvs/KIXg9isPoFL5G/Q4aEayqtFZNRTEcT9WJLRcYM4/BjxM/XgaAQl/5bHI7q6iTo+ztZXTgFN3w8Sw3wlCh5kM97nS86Ph4DXVhUMM0BzVQg=="
                ],
                "x5t#S256": "oIro7NrLWqHqugPhDXKbsj7tGo-R8MpHzgNI0g7fS5c",
                "n": "mZPO7EdOBjph4zpqk15YXoSeLipsEf6hw9DoP85ZyS8wScQ93JjWmbxAHfXdVqaGfMcIDy2iUsJDc7WYt86HfTKsoBcyaEqbCxfeavMGrvN6sB2LpEkqOJkjVlun4HGHYBv1ZypX3LoCgHt6dwZFdR1xNed9t9GSE7obb0Fds8b22I7jTt6yUAX7b_STdWsEesOwq1vCSAN777uE7cRYmsTKd_NWzkeGEOlH8sJ2MB1ZV-8BqNvSurwng6VDi_69VdAv7xNpjteJ4WG5aoFfC0aLJUsNrpSOMXQKT_TTjGNj-cycEUVlMXuz_j23yu6XkJT4oYuF1qIcItnFSGgNeFtwrZl6Nea-YhOgf8cmDNxdA8IPT6CdSyb8s8SAheyAuDk_4dKg9GUAoaETxI462JFBSuTHGHedc6NVsHUVI1EjfS_FAn1Kt-EKKgJqxbdMMDgeOVjYIoUdgXqTcdje4KlcUq62I7MnBDuYN6r36SXbh-AiT0NDEDdVQs8QwGQRqQNfMEsJJJQ4fwhUqkoIVlCiAfKUHbm6hWJPzgfgXE_s5BkfUAF6a4QFNhRXcwrGRhOENm-n6-dfvpy76Vq1GG2pTKb3--XG4X3aw_nRFya7Uqfbpah62RTpPE3Y4dAjcP6KHsFkz5wa5WiOdc9xoRuF-fAB88zFHlovyuI3bjc",
                "e": "AQAB"
            }
        ]
    },
    "owner_id": "A122F025-297A-48F4-B1A9-DC6EAE46CEAB",
    "policy_uri": "https://ais.test/policy_v1_2",
    "tos_uri": "https://ais.test/tos_v1_1",
    "tos_uri_label": "Allgemeine Geschäftsbedingungen AIS",
    "status": "active",
    "endpoints": {
        "signDoc": "https://signing.example.com/csc/v1/signatures/signDoc"
    }
}
Definition of the user claims provided in the verified_claims element follows the definition given in Identity Service.

6.2. Setup Process

We create a Service Provider Record for every QTSP in the scheme. The SP record (as shown in the previous section) allows the IDPs to set up their respective service configuration and the credentials of the QTSP in its role as client of the Token Introspection Endpoint. The configuration data also parameterize the user consent process, e.g., the TOS URL of the respective QTSP.

Every IDP periodically obtains the list of QTSPs from the SP directory and creates the necessary local configuration to allow those QTSPs to use the Token Introspection Endpoint.

We ensure that the service configuration of the IDP is extended with a section remote_signature_creation containing the following information from the QTSP (SP) records:

  • signDoc

  • conformance_levels_supported

Every QTSP synchronizes periodically with the SP Directory in order to update the list of active IDPs.

The QTSP needs a separate technical account at the AS of the Platform to be able to query the SP Directory (and other directories) and to send requests to the mediation service.

7. Long-Term Non-Repudiation

IDPs sign introspection responses to the QTSP in order to provide evidence of the originator of the data. In accordance with well-established best practice in the OAuth and OpenID Connect space, the respective digital signatures are verified using raw public keys, i.e., without a corresponding public key certificate.

The public keys for a certain IDP are published as part of its metadata in a JWK Set (JWKS) as defined in RFC 7517 under the so-called JWKS_URI (see RFC 8414).

This mechanism allows the IDP to maintain and rotate its keys autonomously.

As a consequence, it also means that a QTSP can only prove the link between an IDP and a particular public key as long as this key is published by the IDP.

In order to enable the QTSP to prove this link beyond this time span, operates a long-term public key archive that QTSPs can use to prove in court

  • that a certain IDP belonged to the Scheme at a particular time and

  • the link between this IDP and a particular public key.

7.1. Long Term Public Key Archive

The long-term public key archive is a Git server provided by us that maintains digitally signed snapshots of the list of active IDPs at a certain time along with their respective public keys.

For every IDP, the archive contains a file containing its JWK Set, including all information as published by the IDP. This will typically include the kid and the actual key material as shown in the following example:

Example 18. JWK Set
{
   "keys":[
      {
         "kty":"RSA",
         "e":"AQAB",
         "use":"sig",
         "kid":"hN2z",
         "n":"m1FEkyK6cJYHAni1_jEFOhufUE-w25yUYWHF4Guz9CLHQGBPfgxTFyZ6h06UncFFWAmwPudH7D4tRGqDaf3MtpwYE8mU7CJHXzqYP-xAdbh97WXQTJMLDoWuLDx2YaXWuBtqS_Dhbrs_26BBJIx1e-cu994RN8uWgqsbgKKP-vFk2BKEokeh0yUDiXNIqqx49yvpZ_iqrRUjyG36bo7ZPCDIZcLjK2vidf3z1AulhjgDfxt49UoOqPzvWcg7On0OxllItHG-6LPVtXtdJweRmzvP-aexoEGqBdixpFGm1ZbohYkwgbAk37Um7DiEgySt4hrk3m8AT8DPP3vv043Ddw"
      }
   ]
}

The file name is built by URI query encoding the Issuer URL of the IDP.

The HEAD of the repository (the latest commit) contains the JWK Sets for all those, and only those, IDPs that belong the scheme at the time of the commit. If an IDP is removed from the scheme, its respective file is removed from the archive with the next commit.
Example 19. Directory Listing
drwxr-xr-x  2 user  group  64 Aug  8 10:32 https%3A%2F%2Fissuer.idp1.com
drwxr-xr-x  2 user  group  64 Aug  8 10:16 https%3A%2F%2Fissuer.idp2.com
drwxr-xr-x  2 user  group  64 Aug  8 10:16 https%3A%2F%2Fissuer.idp3.com%2Ftenant13424

Every commit of a new snapshot to the repository is digitally signed by the identity provider using a private key whose corresponding public key certificate was shared in advance with all partners.

The integrity and authenticity of the data can be verified using Git mechanisms as shown in the following example.

Example 20. Verifying a Git commit
git log --show-signature

commit f59d845db617d08eb670ef42cff39fd5a895de70 (HEAD -> master)
smimesign: Signature made using certificate ID 0x9d0bff78f54c4940a094c25451386477f9c0f8f2
smimesign: Good signature from "CN=...,O=rodian.com AG,..."
Author: rodian.com <key-archive@rodian.com>
Date:   Tue Aug 6 10:00:00 2019 +0200
    Initial Status

commit 45737b2aeb470e5c56b03e7500522eda65bd54c9
smimesign: Signature made using certificate ID 0x9d0bff78f54c4940a094c25451386477f9c0f8f2
smimesign: Good signature from "CN=...,O=rodian.com AG,..."
Author: rodian.com <key-archive@rodian.com>
Date:   Wed Aug 7 12:00:00 2019 +0200
    Added: https%3A%2F%2Fissuer.idp2.com

...

QTSPs get access to this data via the Git protocol. It is recommended that every QTSPs maintains its own copy of the long term public key archive (git clone) and periodically pulls the latest changes (git pull).

That way, the QTSP ensures availability of all relevant evidence along with the history in case there is a dispute.

Integration with the long-term public key archive is independent of the actual signing process as specified in this document.

7.2. Collection Service

The long-term public key archive is filled by the Collection Service. It periodically (or triggered by a certain event) fetches the key sets of all active IDPs and stores them in the file structure explained above.

The Collection service commits the changes into a local Git repository and pushes all changes to the central repository (the long term public key archive).

8. QTSP to End-User Notifications

The QTSP might be required to send notifications to users pertaining to their previous use of this QTSP for signing, for example to inform them about a security incident. Such a notification is channeled through the IDP that provided the user data for the respective signing process or its successor (in case of merger or acquisition).

As a pre-requisite, the QTSP MUST retain the iss, sub, and txn claims provided in the Token Introspection Response for every signing operation and every IDP MUST be able to determine the respective user account based on both the sub as well as the txn claim.

A notification is performed via email. The QTSP is supposed to send an email to a dedicated email address at the QTSP. This email address is obtained by the QTSP from the platform’s IDP directory in the course of the processing of the signature request and stored with the other transaction data.

8.1. Determination of the IDP

The QTSP obtains the iss claims for the specific signing transaction. The QTSP queries the respective IDP record from the IDP directory by sending a GET request to the following URL https://<basepath>/idps/<version>/?iss=<iss>;.

8.2. Determination of the IDP’s Email Address

The IDP record contains the email address for notification purposes in the element notification_email.

8.3. Email Composition at QTSP

The QTSP composes the email and adds the (original!) iss, sub, and txn of the user, its SP id, and the message the IDP shall channel through to the user.

It is strongly RECOMMENDED to sign and encrypt these emails in order to prevent impersonation of the QTSP, to protect the message’s integrity, and to ensure privacy. The signature must ensure that the email’s sender cannot be spoofed to authenticate the QTSP towards the IDP. The means utilized for email signing and encryption are out of scope of this specification.

8.4. Email Processing at IDP

The IDP determines the legitimate email sender(s) for a certain QTSP from the QTSP’s record in the platform’s SP directory. The element notification_email_senders is a string array containing a list of authorized email addresses.

If the sender of the actual message is not contained in this list, the IDP aborts the processing of this particular email and notifies the respective QTSP of the attempt.

The IDP is supposed to notify the user about the QTSP’s message using a suitable mechanism, e.g., the inbox in the bank’s online banking portal or app.

9. IDP to QTSP notifications

An IDP might be required to inform QTSPs of an incident regarding a certain user or group of users. The platform manages email addresses the IDP can utilize to send emails to the respective QTSP.

9.1. Determination of the QTSP(s)

The IDP MUST keep track of transactions in which context it provided QTSPs with identity data along with the respective user identities and time of the transaction.

This transaction data is used to determine the set of QTSPs to be notified for a given incident, i.e. the IDP selects the transactions for the affected user for the period the incident existed and determines the set of affected QTSPs.

Note: The QTSP is identified by its qtsp_id in the respective authorization request, which matches the client_id element of the QTSP’s record in the SP directory.

9.2. Determination of the QTSP’s Email Address

Every QTSP’s record in the SP directory contains the email address to be used for notification in the notification_email element.

9.3. Email Composition at IDP

The IDP composes the email and adds the description of the incident along with its iss and the sub, and txn values as asserted in the respective Token Introspection Responses(s).

It is strongly RECOMMENDED to sign and encrypt these emails in order to prevent impersonation of the IDP, to protect the message’s integrity, and to ensure the users’s privacy. The signature must ensure that the email’s sender cannot be spoofed to authenticate the IDP towards the QTSP. The means utilized for email signing and encryption are out of scope of this specification.

9.4. Email Processing at QTSP

The QTSP determines the legitimate email sender(s) for a certain IDP from the element notification_email_senders field of the IDP’s record in the IDP directory. The element notification_email_senders is a string array containing a list of authorized email addresses.

If the sender of the actual message is not contained in this list, the QTSP aborts the processing of this particular email and notifies the respective IDP of the attempt.

The way the QTSP processes and acts upon the message is at the discretion of the QTSP.

10. Security Considerations

10.1. Attacker/Threat Models

Abbreviations used:

  • Account Chooser: AC.

  • Service Configuration: SC

  • Mediation Service: MS

H - Honest, M - Malicious/Compromised

AC SC AS 1 AS 2..n RP 1 RP 2..m QTSP MS User 1 User 2..u

AM1a

M

H

M

H

H

H

H

H

M

H

AM1b

M

H

H

H

M

H

H

H

M

H

AM2

H

M

M

H

H

H

H

H

M

H

AM3

H

H

M

H

H

H

H

H

M

H

AM4

H

H

H

H

M

H

H

H

M

H

AM5

H

H

M

H

M

H

H

H

M

H

AM6

H

H

H

H

H

H

H

H

M

H

AM7

H

H

H

H

H

H

M

H

M

H

AM8

H

H

H

H

H

H

H

M

M

H

Reasoning:

  • AM1a-2: We assume that Account Chooser and Service Configuration can be compromised and that there might be a malicious RP or AS that wants to exploit this situation. Note that a malicious AS might have introduced compromised data into the service configuration itself.

  • AM3-5: A single AS, a single RP, or both might be compromised. In all scenarios, they can also play the role of a malicious user. We assume that it is not feasible to compromise multiple ASs and RPs at the same time.

  • AM6: Malicious users can act independently of a compromised RP/AS.

  • AM7-8: QTSP and MS can be malicious (and act as a malicious user at the same time).

10.2. Security Goals

  • G1: When a document is signed, the identity information in the signature matches the identity information of the user that confirmed the transaction at the AS (unless that AS is malicious).

  • G2: A user cannot sign a document without SCA at the AS from which the QTSP took the identity data, unless that AS is malicious.

  • G3: An attacker cannot modify the document an honest user signs using an honest RP and an honest AS.

  • G4: The RP cannot obtain a signature for a document the user did not want to sign.

  • G5: An attacker cannot obtain information about the documents an honest user signed at an honest RP using an honest AS.

  • G6: A malicious RP cannot obtain a QES without paying.

10.3. Security Measures

The following security measures are used to ensure that the security goals are achieved:

Measure Description Purpose (Main Security Goals)

M1: OAuth PKCE

Cryptographic nonce, bound to the user agent and the particular OAuth transaction

Prevention of code injection/replay on an attackers device (G1, G3)

M2: TLS protected connection

All messages go through TLS protected connections only

Leakage prevention for Signature Activation Data (G1-5)

M3: OAuth 2.0 Mutual TLS Client Authentication

TLS Client Authentication for authentication of Relying Parties towards AS

Signature Activation Data is only revealed to authorized party (G1, G3, G4)

M4: Pushed Authorization Request

Description of transaction data the user needs to consent to are pushed to the AS on an mTLS-protected backchannel connection

Authorization cannot be modified when the authorization requests goes through the browser (G1, G3, G4)

M5: Certificate Bound Access Tokens

TLS Client Authentication and certificate fingerprint in OAuth Access Token

Replay Prevention for Signature Activation Data, use of access token requires private key corresponding to public key certificate the access tokens refers to (G1, G3, G4)

M6: Token Introspection

Access Tokens are handles, token data need to be obtained from AS directly

Prevent modification or creation of false access tokens (G1, G2, GG3, G4)

M7: Signed Introspection Response

Token Introspection Responses are signed by the AS

Gives QTSP evidence of identification and signature initiation process with AS (G1)

M8: Access Token bound to hash to be signed

Access Token is associated with hash to be signed, QTSP compares access token data with actual API request data

RP cannot request signature on different hash (G4)

M9: Access Token bound to client_id of RP

Access Token is associated with client_id of authorized RP

Only RP can request signature creation (G1, G3)

M10: Access Token bound to user id

Access Token is associated with user_id of authorizing user

Signature cannot be created for different user (victim) (G2)

M11: Issuer URL in Authorization Response

The AS returns its issuer URL in the authorization response, and the RP checks this URL.

Attacker cannot lead a victim to authorize at a different AS than the RP expects (mix-up attack) (G1, G3)

M12: High-entropy Tokens

Tokens used in the protocol (State, request_uri, Authorization Code, and Access Token) contain/consist of hard-to-guess randomly chosen values.

Attacker cannot guess or enumerate valid values for a state, a request_uri, an authorization code, or an access token.

M13: Rate-limiting at clients

RPs have controls in place such that users cannot start an arbitrary, high number of authorization requests.

Maliciously repeated attempts to create QES could create high costs for RPs.

10.4. Important Attacks and Mitigations

Following the attacker models introduced above, we can rule out the following attacks in particular:

10.4.1. AM1a-2: Misconfigured Endpoints and Mix-Up

It is very important to ensure that RPs only receive legitimate service configurations. Otherwise, an attacker would be able to mount a number of attacks by manipulating the URLs of the OpenID Configuration, Authorization, Token, or Introspection Endpoints.

The attacks include stealing codes (e.g., via a mix-up attack), injection of stolen codes or tokens into otherwise normal flows (e.g., “Cuckoo’s Token Attack”), and other attacks; these attacks violate G1, G3, and G5.

To mitigate such attacks,

  • RPs must only retrieve service configurations from servers, in particular, there must be no way for an attacker to inject a URI into the account chooser response that causes the RP to retrieve the service configuration from an attacker’s server;

  • the integrity of the service configuration servers at must be ensured at all times.

Defense-in-depth against these attacks is provided in particular by M1, M3, M5, M9, M10, and M11 above.

10.4.2. AM3: Malicious AS

  • A malicious AS could forward an honest user to another AS. In this case, the malicious AS would be able to control/change the scope of the authorization request. In order to mount an attack, an AS would need to manipulate the OpenID Configuration such that the authorization endpoint is an URL controlled by the attacker AS, while all other endpoints point to URLs of an honest AS. This case is discussed above.

  • Additionally, a malicious AS can create a QES for any identity. This can be detected in the audit logs of the QTSP.

  • A malicious AS could provide an OpenID Configuration containing a jwks_uri that exploits Server-side Request Forgery. This cannot be avoided if an AS is malicious. It is recommended to implement respective protection mechanisms.[1] Honest ASs must ensure authenticity and integrity of their OpenID Configurations at all times.

10.4.3. AM4: Malicious RP

A malicious RP can let the user sign any document, since the document is only identified by its hash value when the user consents to the signature at the AS. This violates G4 and can only be mitigated by enforcing legal requirements for the RP.

10.4.4. AM5: Malicious AS and RP

The attacks from above apply.

10.4.5. AM6: Malicious User

  • A malicious user could provide a code to the relying party that leaked from a different flow of the same relying party. This is mitigated by PKCE (M1).

  • A malicious user could provide a code that a different relying party (potentially a malicious one) obtained at the same AS. This is mitigated by the use of mTLS (M3).

  • Using CSRF, an attacker might try to inject data into the following requests:

    • At the RP:

      • Redirection from account chooser (redirect_uri_ac)

      • Authorization response

      • User consent to signature

    • At the Account Chooser:

      • Selection of bank

    • At the AS:

      • Authorization request

      • Login, SCA, User consent

The RP, AC, and AS must protect themselves against CSRF using the usual techniques.

  • An attacker could try to guess a pushed authorization request URN and use it to display the labels associated with that request by faking/modifying an authorization request to the AS. Therefore, the pushed authorization request request_uri MUST be unguessable by an attacker (see M12).

  • An attacker could try to eavesdrop on data in transit. This is prevented by M2.

  • An attacker could repeatedly start flows with a client, with or without completing them. The client will incur costs by this, since data is provided from the AS to the QTSP. This is prevented by M13.

  • An attacker could start two authorization processes at the same AS and swap the request_uris that are used in these processes. In this case, the flow would fail (when the sign request arrives at the QTSP). This does not seem to be exploitable. (High costs for the RP are prevented by M13.)

10.4.6. AM7: Malicious QTSP

The integrity and authenticity of the service configuration, discussed above, ensures that an attacker cannot use his own QTSP in a flow of the protocol with otherwise honest parties. Nonetheless, an attacker could compromise an existing QTSP.

  • A compromised QTSP can issue QES for any user identity, thereby violating G1 and G2.

  • A compromised QTSP could refrain from sending a mediation record to the mediation service, thereby impeding correct settlement.

The integrity of the QTSP must therefore be ensured at all times.

The QTSP cannot obtain information about the user’s documents, since it only sees the hashes of the documents.

10.4.7. AM8: Malicious Mediation Service

A malicious/compromised mediation service could make an RP pay for transactions that did not happen, or suppress transactions.

10.5. Cryptographic Algorithms

Component Algorithm

all communication links

TLS according to recommendations in RFC 7525, e.g., use of TLS 1.2 (or higher) and cipher suites offering forward secrecy

Access Token Signatures

RSA with minimal key length of 2048 bits

Client Certificate Fingerprint

SHA256

PKCE Challenge

SHA256

10.6. Additional Considerations for Identity Assurance

In addition to the Security Considerations listed above, the following additional considerations apply for QES with Identity Assurance:

10.6.1. Signing Entity

A validator cannot determine whether a signature was created using a local signing device under the signer’s control or a remote signing device under the control of a QTSP. Therefore, the solution must work securely even if the signer created the signature locally using a signing device under her control. This is given, as can be seen in the Formal Description.

10.6.2. Attestation of Identity Data

The identity data is signed by the QTSP which attests the data. In particular, the identity data is NOT signed by the signer instead.

10.6.3. Binding between Signer Certificate and Identity Assertion

There needs to be a strong link between signer certificate and identity assertion in order to prevent assertion swap. This is given, as can be seen in the Formal Description, Step (1).

10.6.4. Freshness of Certificate/Assertion

The signer creates a fresh, short-lived certificate for each signing process. One or more documents may be signed in the same step.

11. References

12. Document Control

12.1. Changes

  • Version 2.5

    • In provided_claim_names in the IDP mediation records, use verified_claims/claims/ as prefix instead of verified_claims/ (already implemented by all IDPs)

    • Declare SHA-256 as MTI for QTSPs; six ETSI hash algorithms as MTI for IDPs and 'should' for QTSPs.

    • Highlight that traditional authorization requests (non-PAR) for this flow MUST be rejected by the IDP.

    • Use error code invalid_authorization_details instead of invalid_request for wrong document details in QID/QESID case

    • Updated references to latest versions of IETF documents

    • Fix example (identity_assurance_claims instead of claims)

    • Clarify minimal supported set of ID claims

    • Clarification that QTSP must omit unknown claims in the certificate (QID/QESID)

    • Clarification that also for QID, hashes must be base64-encoded.

    • Clarification for the count element in the medation record in case of QID.

    • Various minor fixes.

    • Add access token example.

    • Remove the requirement for clients to check the authz details returned.

  • Version 2.5-beta

    • Large update in QES for Identity Assurance (identifiers, processing rules, permissions, data structures, and more)

  • Version 2.4 (2019-10-04)

    • Moved to PAR/RAR

    • include more examples and incorporate feedback

    • added QID feature

    • added feature to allow the QTSP to notify end-users via IDP

    • fixed typos

    • changed indentation of sub sections of QES4IDA section

    • added IDP to QTSP notifications

    • added signAlgo and signAlgoParams parameters

    • added REQUIRED/OPTIONAL tag to all parameters of the signDoc request

    • explicitly state that the signing consent resource is one-time use

    • RP indicates QTSP it will use in the signing consent resource (qtsp_id))

    • service discovery provides RP with list of QTSPs available for a certain IDP

    • IDPs synchronize all QTSPs to local client database

    • changed tos and policy URI description and examples to advice use of URLs to represent document versions

  • 2019-10-08

    • added End-User Notifications

    • crl element in revocationInfo is optional if QTSP provides signed OCSP responses

    • aligned specification with latest clarifications in draft-ietf-oauth-jwt-introspection-response-08

    • clarification regarding default consent purpose

  • 2019-08-20

    • Added Identity Assurance

  • 2019-08-10

    • Added details regarding signature response

  • 2019-08-08

    • added Long Term Public Key Archive for long-term non-repudiation

  • 2019-07-26

    • migrated to Identity Service 2.x specification

    • made PKCE or nonce mandatory and state conditionally mandatory if client does not utilize PKCE/nonce for CSRF protection

  • 2019-07-25

    • transformed specification

    • removed references to Identity Service 2.x

    • general cleanup

  • 2019-05-24

    • alignment with verified_person_data MVP baseline

    • added revocation data for LT mode in conjunction with PAdES

    • revised definition of signing request and response to refer to ETSi spec definition (including all legit parameters)

  • 2019-05-20

    • modified id document handling

  • 2019-04-05

    • added iat to access token

    • added exp to introspection response

  • 2019-04-04

    • Alignment with ETSI TS 119 432 V1.1.1

    • Added references

    • Aligned lifecycle management with platform API

  • 2019-03-16

    • Included acr in Introspection Response

  • 2019-03-08

    • explicitly list the user claims conAdES-B-LTtained in the verified_person_data claim

  • 2019-02-22

    • Renamed client fields in mediation records to client_id

  • 2019-02-18

    • Adopted document to hybrid access token design

    • Moved signingConsents endpoint discovery to AS metadata (.well-known/openid-configuration or .well-known/oauth-authorization-server)

    • signing scope value is published in server metadata using prefix https://www.openbanking.verimi.cloud/scopes/sign only

    • Adopted enhanced mediation record structure

  • 2019-01-14

    • modified signDoc and Signing Consent creation requests to comply to ETSi Spec (hash array instead of single value)

  • 2019-01-08

    • added details on attacks where an attacker repeatedly starts authorization flows

  • 2018-12-21

    • remove address as mandatory data element

  • 2018-12-18

    • Incorporated Developer Feedback

    • Added requirements on User Consent User Interface Design due to legal and regulatory obligations

  • 2018-11-21

    • Incorporated Developer Feedback

  • 2018-11-01

    • Reworked Setup & Operations

    • Detailed mediation record creation

  • 2018-10-29

    • changed scope sign_consent to signing_consent_create

  • 2018-10-23

    • Cleanup options regarding setup of AIS configurations

  • 2018-10-08

    • Added design options on setup and maintenance of AIS/AS-relationship as well as settlement and clearing

  • 2018-10-03

    • Added Setup and Operations section containing a list of use cases and data needed by all parties to setup the QES infrastructure for a particular IDP

    • corrected use of AS and IDP; generally use AS for the bank’s authorization server, IDP for the complete implementation of a bank only

  • 2018-09-13

    • Added malicious MS and malicious QTSP as attacker models AM7 and AM8, respectively

  • 2018-09-12

    • added iss response parameter conveying the AS issuer URL

    • added requirement to check the credentialID in the sign request against the credentialID in the consent resource

    • added requirement to convey the whole consent JSON document in the Introspection Response to the QTSP

    • Added Security Analysis and extended Security Considerations section

    • removed credentialID value eidas_aes, will be re-introduced by another specification for AES

    • Clarified IDP introspection request checks and error response

    • Added hashAlgorithmOID to the consent object and included the hash+hashAlgorithmOID check in the QTSP before signature creation

  • 2018-08-16

    • Added text on order of signature objects

    • Moved text regarding certificate profiles to new document [Solution Design ID Providing via QES]

  • 2019-08-10

    • Added details regarding signature response

  • 2018-08-09

    • Enhanced signing request & response definitions based on [Draft ETSI TS 119 432 V0.0.2 (2018-06)]

  • 2018-08-08

    • changed consent resource definition: added credentialID and renamed profile to certificate_profile

    • Added credentialID and certificate_profile to Token Introspection Response

    • Added signing request and response

  • 2018-08-07

  • 2018-07-30

    • Adopted description to actual architecture model (QTSP as partner of the bank)

    • Added Consent Resource

    • Added example requests and responses

    • Added Certificate Profiles

12.2. Responsibilities

document owner

Dr. Torsten Lodderstedt
1. See, e.g., “Uses and Abuses of Server-Side Requests”, RAID 2016, https://christian-rossow.de/publications/ssr-raid2016.pdf.