All You Need to Know About eIDAS for Open Banking

Image credits: Markus Spiske on Unsplash

This blog post is focussed on providing all the information that you need to know as a stakeholder of open banking and Electronic Identification, Authentication and Trust Services, or, as it is more commonly known, eIDAS in the EU.

The eIDAS Regulation

The eIDAS system came into effect on July 1, 2016, with Regulation (EU) 910/2014 on electronic identification and trust services for electronic transactions in the internal market. Its goal was to create a mechanism to provide trustworthy electronic identification that could be used across borders with a high level of convenience. This was to solve the identity problems of PSD2 like the nonexistence of a centralized identity structure across the region. Refer to this article for more information on this topic. Several different entities like the EU, QTSPs, and NCAs work hand-in-hand to achieve this goal.

Based on Article 25(2) of the eIDAS regulation, a qualified electronic signature (or e-signature) consists of the same legal effect of a handwritten signature. Furthermore, according to Article 25(3), when an e-signature is signed based on a qualified certificate in any member state of the EU, it will be recognized as a qualified e-signature in all member states. This provided a common system across the EU to conveniently establish trust with electronic certificates.

The Role of European Technology Standards Institute

The European Technology Standards Institute (ETSI) is an independent industry body formed of technology providers within Europe. ETSI is recognized by the European Commission as a market standardization body that defines the standards laid out by the European Commission at a much deeper level. As an example, in section 5.1 of the ETSI technical specification governing the standard of implementing the use of eIDAS to satisfy PSD2/RTS requirements (ETSI TS 119 495), the addition of the QCStatement to the X.509 public-key infrastructure has been made mandatory. ETSI has provided this as the standard using IETF RFC 3739 (x509 certificate standard) to satisfy Regulatory Technical Standard (RTS) published by the European Banking Authority (EBA) in order to define how to implement in practice, the security and authentication requirements brought forward by PSD2) Article 34 which is based on Article 3(30) of the eIDAS regulation.

eIDAS for Third Party Providers

A Third Party Provider (TPP), like a smartphone app, has the ability to purchase a qualified eIDAS certificate. Once a TPP acquires an eIDAS certificate, it can use it to directly identify itself with an Account Servicing Payment Service Provider (ASPSP) like a bank.

In the UK, following the conclusion of the FCA adjustment period on March 14, 2020, TPPs must identify themselves to ASPSPs using an eIDAS certificate. This is enforced by the Open Banking Implementation Agency (the OBIE) where a Software Statement Assertion (SSA) cannot be obtained without a valid eIDAS certificate being uploaded to the directory. Without a valid OBIE certified SSA, a TPP cannot onboard with an ASPSP as an OBIE registered TPP.

When a TPP registers with the OBIE, they may use an alternative identification certificate issued by the OBIE, provided that those TPPs have registered their eIDAS certificate with the OBIE. OBIE continues to perform checks of the status of the eIDAS certificate. These OBIE issued certificates are called OBWAC/OBSEAL certificates. The OBIE has provided necessary guidance with regards to eIDAS certificate management.

eIDAS for ASPSPs

With regard to eIDAS certificates, the main duty of an ASPSP is to look up and validate eIDAS certificates produced by TPPs who are interacting with them. When a TPP forwards an eIDAS certificate, the ASPSP has to validate the following:

1. Certificate validation using LOTL
2. OCSP/CRL revocation validation
3. NCA status and role validation

1. Certificate validation using List of Trust Lists

Article 22(a) of the eIDAS regulation sets out that each member state should establish, maintain and publish trusted lists with information related to its Qualified Trust Service Providers (QTSPs) - the certificate authorities issuing the certificates - and the qualified trust services provided by them.

Based on Article 22(3) of the eIDAS regulation, each member state of the EU must make this information available to the European Commission for communication to the public. This is called the List of Trust Lists (LOTL) and can be accessed in an XML format in the trust list browser on the European Commission website. This document may be used as a guide to traverse the LOTL XML document.

For the UK (OBIE regulated ASPSPs), the OBIE has provided valid QTSP root certificates in the Java KeyStore (JKS) format. It contains certificates sourced from the national Trust Lists and root certificates sourced directly from the QTSPs where these have not been published in the national Trust Lists. Though the key stores are provided here as sandbox and production key stores, the only difference between them is the OBIE root certificates (sandbox/production roots).

2. Online Certificate Status Protocol/ Certificate Revocation List revocation validation

As mentioned in ETSI TS 119 495 (Section 4.6), the certificate should be validated for its status using a certificate status service exposed by the Certificate Authority (CA). In this case, the CA is the QTSP. For this, the Online Certificate Status Protocol (OCSP) RFC 6960 or Certificate Revocation List (CRL) RFC 6818 URIs that are provided as certificate extensions have to be used.

3. NCA status and role validation

Based on the ETSI specification, the certificate status validation (OCSP/CRL) is sufficient to validate both the TPP and its roles (based on the relevant QCStatement). But in practice, after the QTSP (OCSP/CRL) validation, an NCA directory validation has to be done. This is because the NCA and the QTSP of a certificate are two separate entities. The QTSP issues the certificate and the NCA maintains the regulatory status and the roles of a TPP. Ideally, based on ETSI TS 119 495 (Section 4.6) when an NCA revokes a TPP, the QTSP has to be notified, causing the certificate to be revoked.

Image source: ETSI Specification

But in practice, this notification cannot be guaranteed. This means that having a qualified eIDAS certificate does not mean the entity having the certificate is regulated at any given time. Hence the NCA validation is required. Each National Competent Authority (NCA) maintains its own register of TPPs. That’s 115+ registers across 31 EEA countries. These registers are all in different formats and the content constantly changes. Regulated TPPs can be added, removed, or have their status changed at any time. Therefore at each and every validation, the regulatory status and the roles have to be validated by calling NCA registers. The NCAName and the NCAId for a specific TPP can be obtained from the QCStatement extension.

In the UK region, if the ASPSP and the TPP are OBIE- regulated, there is no issue since the OBIE JWKS will be always up to date. But OBIE regulated ASPSPs also should support non-OBIE TPPs as well and hence will face the same issue.

Problems With the Current Process

As mentioned above, the process of validating the certificate against LOTL, OCSP/CRL, and 155+ NCAs across the entire region is a strenuous process for an entity that needs to validate a certificate (ASPSP).

Enter TPP Verification Service Providers

It is based on the problems identified above TPP verification services come into play. ASPSPs can directly make one call to a checking service to get a response with all the information related to certificate and TPP validity and the TPP roles. The TPP checking services takes on the complexities of maintaining and keeping up with all the changes happening with regard to this. Several TPP checking services available are Konsentus, Banfico, and PRETA (NCA register).

Conclusion

In this post, I have covered most of the aspects of eIDAS that have to be considered by open banking stakeholders across the European region. To get a deeper understanding of the eIDAS regulation and its functionality, make sure to refer to the hyperlinks related to the various related regulations included in this blog. To learn more about eIDAS and how it’s applied in real-world open banking deployments, take a look at this on-demand webinar and refer to the WSO2 Open Banking documentation on eIDAS for PSD2 compliance.