This article is the fourth in a series of articles dealing with the use of the eIDAS Regulation and qualified certificates in the context of the PSD2 directive. We will describe the operational aspects of validating qualified eIDAS certificates.

Validation of certificates in PSD2

Previous articles in our series introduced the conceptual model and described the relationship among eIDAS qualified certificates, the PSD2 directive and the PolishAPI standard. Let’s try to face the practical usage of acquired knowledge. To achieve this, we need some more information on the eIDAS regulation. The regulation introduced two entities on a Pan-European scale: “trust service” and “electronic identification”. The focus on our interest are trust services. More specifically, two of them, namely: qualified website authentication certificate (QWAC) and qualified electronic seal certificate (QSealC). While talking about the eIDAS trust service, we can imagine it as Pan-European PKI. The case  concerns also qualified trust service providers (QTSP) here. They issue certificates recognized throughout the European Union. We also have payment institutions (PSPs) or other entities / persons to whom these certificates are issued. Adopting the PKI abstraction for understanding the operation of the trust service for further considerations simplifies the validation process, that can be described by one-sentence: Validation of PSD2 certificates is conceptually identical as the validation process found in standard PKI. However, there are differences in the implementation that should be handled in the “special interface” / “emergency interface” PSD2. The most important differences there are:

  1. Certification Authorities (QTSPs) exist throughout Europe. The “special / emergency interface” should recognize TPP certificates issued by all QTSPs.
  2. Lists of QTSP certificates can be found on the websites of relevant regulatory bodies (major certification authorities) throughout Europe. In Poland, the list (TSL) is available at:
  3. The TSL lists contain QTSP certificates for all EIDAS services, eg.: issuing certificates and time stamping. So it’s not just QWAC and QSealC services.
  4. The number of QTSP certificates varies over time and the knowledge of TSL and QTSP lists should be updated on an ongoing basis.
  5. Certificates issued by QTSP do not have to contain references to CRL and OCSP.

If someone wants to read the current standards in eIDAS, they can be found at:

All of the above implies one conclusion. “Special interface” and “Emergency interface” must be equipped with specialized IT solutions (such as our TPP Validator) supporting validation of eIDAS certificates. By default, in the case of communication between companies, a hardware gateway (e.g. Netscaler or F5) or API Gateway is used for certificate validation. This solution is not valid for the validation of PSD2 certificates, for two reasons:

  • The list of certification authorities (QTSP) varies over time (TSL lists may change several times
    a day). It is not possible to build a stable repository of trusted certificates.
  • Validation in hardware gateways is achieved using the OSCP and / or CRL protocols. In the case of PSD2 certificates, the certificate issuer is not required to provide information about OSCP and CRL in the certificate. This can be done on TSL lists.

The above two points describe only “the tip of the iceberg” of the validation requirements of the PSD2 certificate. PSD2 certificates have many additional attributes that should be checked. One of them is the role of TPP (the extension of the certificate is described in ETSI TS 119 495), which will be discussed in the next article.