eIDAS

Overview

When a Payment Service Provider (PSP: ASPSP, PISP, AISP or CBPII) makes a request to an Account Servicing Payment Service Provider (ASPSP) the ASPSP needs to be certain that the PSP is who they say they are. In order to validate a PSP’s identity an ASPSP can use an electronic Identification And Trust Services (eIDAS) certificate. eIDAS is an EU regulation based on a set of standards for electronic identification of a person or organisation within the European single market. As such an eIDAS certificate provides sufficient information for an ASPSP to confirm a PSP’s identity.

To gain an eIDAS certificate a PSP will need to apply to a Qualified Trust Service Provider (QTSP). A QTSP is responsible for providing trusted digital certificates and are legally responsible to conduct a variety of checks on a PSP.

OBIE certificates are QTSP-like certificates issued by the OBIE directory for use in the UK Open Banking ecosystem.

OBHD certificates are QTSP-like certificates issued by the Open Banking Hub Directory for a particular country or scheme.

This page covers the contents of an eIDAS certificate, eIDAS implementation methods and what checks Konsentus performs on eIDAS certificates. For response examples please go to GET /v1/psp/eidas.

Certificate contents

An eIDAS certificate is formatted as an x.509 certificate with a number of extensions representing the PSD2 specific requirements of the certificate. Below are the elements that a PSD2 eIDAS certificate should contain:

Subject Name

This section provides details on the company who is the subject of this certificate. It includes:

• The country code of the country the company is based in
• The company’s name
• The address of the company
• The unique PSD2 authorisation number of the company

Issuer Name

This section contains information about the QTSP who issued the certificate. It includes:

• The country code of the country the QTSP is based in
• The name of the QTSP
• The serial number (unique identifier) of the certificate
• The x.509 version that this certificate is using
• The algorithm used to sign the certificate (e.g. SHA-256)
• The expiry date of the certificate

Public Key Info

The PSP’s public key. This section also includes the certificate’s signature. This signature is used to ensure that the certificate’s contents have not been changed since the QTSP published the certificate.

Fingerprints

A set of hash values computed on the entire certificate using the SHA-256 and SHA-1 algorithms. The fingerprints can be used to identify the certificate but are not used to check if the certificates content has been tampered with (that is what the certificate’s signature is used for).

Roles of the PSP

A certificate may contain (but not required to) the PSD2 roles of the PSP. Below are the roles you can find in a certificate:

• PSP_AS (Account Servicing)
• PSP_PI (Payment Initiation)
• PSP_AI (Account Information)
• PSP_IC (Issuing Card-based payment instruments)

It is worth noting that these roles are specific to PSD2 eIDAS certificates and are not the same as the payment services (which are sometimes mistakenly called roles) that payment institutions are assigned in their NCA register. See payment services for more information.

eIDAS implementation methods

QWAC

A Qualified Web Authentication Certificate (QWAC) is used to authenticate entity identity at the transport layer. When a PSP first opens an interaction with an ASPSP a QWAC can be used to establish a TLS session with the ASPSP. By encrypting communications, the two communicating entities, PSP and ASPSP, can ensure that messages sent between them are not read or stolen by external actors. QWACs are used with specific protocols at the transport layer and as such are not designed to be used at the application layer.

QSealC

A Qualified Electronic Seal Certificate (QSealC) is used at the application layer to protect the content of messages being passed between the PSP and ASPSP. The QSeals allow the PSP and ASPSP to validate the identity of the sender of the message (proof of origin) and ensure that the messages have not been tampered (message integrity) with while they were in transit or later stored.

Konsentus eIDAS checking service

When an ASPSP requests a PSP regulatory check using Konsentus’s GET /v1/psp/eidas endpoint the service will perform the following checks against an eIDAS certificate:

Valid QTSP (certificate issuer) check

Konsentus checks whether the QTSP has the EU Member State’s approval to issue a valid eIDAS certificate. This includes checking that the QTSP is registered to issue a QWAC and/or QSealC. For UK issued certificates similar checks are made to ensure they are issued by a UK approved certificate issuer.

For other non-EEA countries and schemes Konsentus checks that the certificate has been issued by an approved certificate issuer for that jurisdiction or scheme.

If the certificate issuer is no longer approved to issue valid certificates or the certificate issuer does not exist, then the service will return a ‘false’ response.

Konsentus also checks whether the certificate issuer is approved to issue certificates for use in the Jurisdiction provided in the API request. If the certificate issuer is not approved to issue certificates in the Jurisdiction, the service will return a ‘false’ response.

Valid Signature check

Once an eIDAS certificate has been issued its contents cannot be changed. For example, if a PSP was to change roles a new eIDAS certificate would have to be issued by a QTSP.

To ensure that the certificate’s contents have not been changed the certificate is digitally signed by the QTSP. A digital signature is generated by the QTSP using its private key. When Konsentus receives the certificate, it will use the public key to verify the signature. If Konsentus cannot verify the signature, then the contents of the certificate cannot be trusted and the service will return a ‘false’ response.

Not Expired check

Each certificate contains an expiry date. Konsentus will check if the expiry date has been exceeded. If the expiry date has exceeded, then the service will return a ‘false’ response.

Not Revoked check

A QTSP can revoke a certificate at any time. There are two methods that QTSPs provide to check if a certificate has been revoked or not.

The first method a QTSP uses is a Certificate Revocation Lists (CRL) which contains a list of serial numbers (unique identifiers) of certificates that have been revoked

The second method QTSPs use is Online Certificate Status Protocol (OCSP) whereby the QTSP provides an API to verify the status of a certificate. The API will respond with a status stating whether the certificate is active or whether it has been revoked.

If either of these methods show that the eIDAS certificate has been revoked, the service will return a ‘false’ response.

Certificate Auth Number

Each certificate contains the name of the PSP together with a unique PSD2 authorisation number. Each authorisation number contains the following elements:

• PSD – an authorisation number always starts with the letters "PSD"
• Country code - a two letter code (e.g. GB, FR) representing the home EEA (European Economic Area) jurisdiction that the PSP is regulated in. See the list of Transaction Jurisdictions.
• NCA - the acronym representing the NCA that regulates the PSP.
• Reference Number - the unique identifier number that is generated by the specified NCA

An example authorisation number for a UK third party might look like: PSDGB-FCA-010101

Konsentus will display the certificate authorisation number within its response, see GET /v1/psp/eidas for more information.

Roles

Please note that Konsentus does not check the roles of a PSP found in an eIDAS certificate. Instead Konsentus checks and display the payment services for which a PSP has been approved by its NCA. See payment services for more information.