eIDAS — secrets in security?
One of the less discussed topics in Open Banking is trust when it comes to third party bank connections. Is the data from you as a Payment Service User (PSU) secured reliably when it’s transported between the Third Party Provider (TPP) and Account Servicing Payment Service Provider (ASPSP)? How does the bank know if the TPP trying to access your data is who they claim to be?
Security in bank data communication used to be something where full control was within each bank, likewise any other solution they provided to the market. Banks made it their priority to create solutions that secured access to the Customer’s data as much as possible, following their own stringent security policies. How does that fit to Open Banking where the common PSD2-services should be widely available for any licensed TPP across Europe, without any contractual relationship between the TPP and the bank? It doesn’t. The TPP must be able to access PSD2-services from any ASPSP in Europe when there is a PSU — a Customer of that ASPSP demanding this access.
This is where the PSD2/RTS article 34 kicks in. In summary, it says that for the purpose of identification, payment service providers shall rely on qualified certificates for electronic seals or for website authentication as referred to in regulation 910/2014. The RTS also sets other rules, such as, as mentioned, no agreement is required between the TPP and the ASPSP, plus the ASPSPs must adhere to the principle of non-discrimination.
This narrows the scope of hundreds of different fancy security solutions quite effectively. But by that it also harmonizes these solutions seen from TPPs’ point of view: the technical solution is set, the ASPSP cannot require agreement with the TPP so a proprietary identification process cannot be used and by that the non-discrimination rule is covered. It offers one identification solution for TPPs towards any bank in Europe!
But what is regulation 910/2014? Without going into details, its purpose is to standardize electronic identification and trust services for electronic transactions in the European Single Market. It is often referred to as eIDAS (electronic IDentification, Authentication and trust Services) and it entered into force on 17 September 2014. This eIDAS regulation has been inherited by Open Banking and must be used, as stipulated in RTS article 34.
Let’s investigate a few details of this RTS article by picking a few words like certificates, qualified, electronic seal and website authentication. What do those mean in practice?
Certificates are a part of well-known and long-used PKI technology. The high-level model is that if we both trust a third party, I can ask them to sign my public key which I can give to you. With that you can then verify if the digital signature made with my private key is valid. If so, then I have proven my identity to you. In other words, we outsource the KYC process to the third party which we trust.
Standard technology as said. But wait, what is the information in the certificate and in which format? This could be a story of its own, but the short answer is that the content is defined by the RTS and the technical specs by ETSI, a European standards organization which published their specification in August 2018. The key-thing in this certificate is the unique ID (authorization number of the PSP) which originates from the TPP’s ‘Home National Competent Authority’ (NCA), the local authority that grants the PSD2 licenses to TPPs. By this number it is possible to find the TPP in question from official public registers. Within such registers, it is possible to see what PSD2 ‘roles’ the TPP is licensed to play (AISP, PISP, CBPII), plus what countries they are allowed to operate in (‘passporting permissions’). Note that, whilst role information can be found in the certificate, passporting permissions cannot; in addition, there is no guarantee the role information within the certificate is up to date.
RTS refers to certificates as being ‘qualified’. Aren’t all certificates qualified? Not in this context, because qualified electronic signatures can be made only with qualified certificates and those can be issued only by ‘Qualified Trust Service Providers’ (QTSPs). eIDAS requires that the EU maintains an EU Trust List that lists the providers and services that have received qualified status. These trust providers have a connection to National Competent Authorities to verify the PSD2 license, license number and PSD2 roles before issuing the eIDAS certificate to the TPP acquiring it.
In other words, a TPP must first get authorized by their local NCA and then acquire eIDAS certificate(s) from a QTSP.
Looking at the calendar, I think the industry once again is racing against time. It is only 6 months to the moment where ASPSPs must reject all PSD2 calls from TPPs that don’t present their eIDAS certificate(s). Are all ASPSPs ready? Do TPPs have their production setup with eIDAS certificate(s) in place and tested? And will the QTSPs be ready to issue production certificates? These and a number of other questions are still unanswered.
Finally, the RTS names qualified certificates for electronic seals or for website authentication — QSEALC or QWAC respectively. So, two different types of certificates can be used, and it is enough to use only one of them. It is up to each bank to mandate how TPPs should identify themselves: QSEALC only, QWAC only or both. But it is currently unclear which way the industry is heading. With three options available, it is guaranteed there will be a mixture of implementations that TPPs will have to cope with. This arguably adds to confusion and goes against the aim of further harmonization.
Let’s elaborate on these two types of certificates and their intended use. With analogy to other use cases, when using a smart card with a pin we might digitally sign something, in other words put a seal onto the data confirming the signer was the user holding the private key. And when using the netbank with a browser we can see the padlock in the browser address bar which ensures the website we are connecting to is what it is supposed to be. This is proved by the website authentication certificate held by the server. Both of these types of certificates are used in our everyday life. But why did the regulator give us an option? Which one is better, and which one should be used? Or should we use both?
Both QSEALCs and QWACs have their own pro’s and con’s, so using one of these, you will lose some benefits offered by the other. There are no barriers to use both — EBA even recommends that, but it would lead to quite complex solutions in both ends.
The decision of which type of the certificate will be used to authenticate the TPP requesting PSD2 services has been left to ASPSPs. At time of writing it looks like the majority of ASPSPs will choose the ‘QWAC-only’ option because it looks more promising from an implementation and usage point of view.
When speaking about website authentication, we usually refer to TLS (Transport Layer Security) where the server presents the certificate and the browser decides if that can be trusted, marking it with the padlock sign. In eIDAS cases, the certificate owner is not only the server, but the client as well, i.e. the TPP who owns and must present their website certificate to the server. That model is called Mutual TLS or MTLS and is standard technology, even though not yet as prevalent as 1-way TLS.
As can be seen, quite a number of rules were packed into one sentence of the RTS article 34! The whole industry has been, and still is, working hard to define the details for the practical implementations. The RTS also declares that TPPs must have testing facilities available 6 months before the application date 14th September 2019. I am glad to say that Nordea will be ready by 14th March and welcomes TPPs to test their MTLS connectivity in our Sandbox. We even provide a test certificate for you courtesy of the Germany-based QTSP, D-Trust.
Happy hacking!
About the author:
Petri T. Luoto has long experience in Cash Management Product Development and he is currently working as a Business Analyst at Nordea Open Banking. For the last 20 years he has helped to develop new data communication and security solutions for constantly evolving banking digitisation.
