Everything you need to know about eIDAS for Open Banking

For those less familiar, the Electronic Identification, Authentication and Trust Services, or the eIDAS system as it is more commonly known, came into effect on 1st July 2016, with Regulation (EU) 910/2014 on electronic identification and trust services for electronic transactions in the internal market.

The goal was to create a mechanism to provide trustworthy electronic identification that could be used across borders with a high level of convenience. It was hoped this would solve the identity problems of the Revised Payment Services Directive (PSD2) such as the non-existence of a centralised identity structure across the region. Several different entities like the EU, QTSPs, and NCAs work together to achieve this goal – writes Amjadh Ifthikar, Senior Software Engineer, WSO2. 

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

The Role of the European Technology Standards Institute 

The European Technology Standards Institute (ETSI) is an independent industry body made up of over 900 members active in the IT space from 65 countries.  ETSI is recognised by the European Commission as a market standardisation body that defines the standards laid out by the European Commission at a deeper technical level needed for implementation and is playing this role with regard to the eIDAS system.  

 eIDAS for Third Party Providers 

A Third-Party Provider (TPP), for example, a provider of  a smartphone app, can 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 14th March, 2020, TPPs must identify themselves to ASPSPs using an eIDAS certificate. This is enforced by the Open Banking Implementation Entity (the OBIE) where a Software Statement Assertion (SSA) cannot be obtained without a valid eIDAS certificate being uploaded to the TPP application maintained by the OBIE. 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 (provides the TPP the ability to mask the eidas certificate by using this certificate instead and will be easier to be validated from an ASPSP perspective since the certificate root would be the OBIE certificates) issued by the OBIE, provided that those TPPs have registered their eIDAS certificate with the OBIE. These OBIE issued certificates are called OBWAC/OBSEAL certificates. To TPPs entering the open banking ecosystem, 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 must validate the following: 

1. Certificate validation using List of Trust Lists (LOTLs)
2. Online Certificate Status Protocol (OCSP) / Certificate Revocation List (CRL) revocation validation
3. NCA status and role validation
4. Certificate validation using LOTLs

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 to communicate with 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.  

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). 

OCSP/ CRL 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. 

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 must be undertaken. 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. 

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 validation, the regulatory status and the roles must 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, if the ASPSP and the TPP are OBIE-regulated, there is no issue since the OBIE JWKS will always be up to date. But OBIE-regulated ASPSPs should also support non-OBIE TPPs as well. 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 

Based on the problems outlined above, this is where 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 about this.  

The Future 

In the future, we hope that these complexities will be addressed and a mechanism will be created to validate an entity more efficiently without the need of any third party. In order to reshape the future of eIDAS, currently the EU is conducting a public consultation on amending the eIDAS regulation to make the system more fit for purpose based on available new technology. While evaluating feedback on the existing regulation, the EU is looking at strengthening and broadening the scope of eIDAS with this consultation. 

This article has 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 regulations included in this article.