The eIDAS Challenge for TPPs under PSD2

PSD2 requires that Account Servicing Payment Service Providers (ASPSPs) shall design their channels in such a way so that Third Party Providers (TPPs) are able to identify themselves when accessing these channels. The ASPSP shall be able to recognize that it is a particular regulated TPP accessing the account and not the end-user himself. Article 30(1)(a) of the RTS provides that ASPSPs are obligated to have in place at least one interface which meets, inter alia, the requirement that AISPs, PISPs and CBPIIs are able to identify themselves towards the ASPSP.

For the purpose of identification, ASPSPs and TPPs shall rely on using eIDAS (electronic IDentification, Authentication and trust Services) Certificates for electronic seal and/or for website authenti­cation. Identifying themselves is mandatory for all TPPs that wish to get access to ASPSP’s sandbox, live API, and/or non-dedicated channel.

The eIDAS Regulation (EU) 910/2014 on electronic identification and trust services for electronic transactions in the internal market was introduced before PSD2. It came into effect on 1 July 2016 and is currently widely used on the European market. eIDAS covers the broad category of all electronic signatures including “any data in electronic form which is attached to or logically associated with other data in electronic form and which is used by the signatory to sign.” In other words, it is an electronic form of signature that a signatory can apply to a document as evidence of their acceptance or approval. This could include a scanned signature image or a click of an “I accept” button on a website or a DocuSign electronic signature.

eIDAS certificates are provided by Qualified Trust Service Providers (QTSPs) who are responsible for assuring the electronic identification of signatories and services by using strong mechanisms for authentication, digital certificates, and electronic signatures. There are hundreds of such providers across EU,but only dozens of QTSPs are providing PSD2 eIDAS certificates.

There are two types of eIDAS certificates:

1. Qualified Website Authentication Certificates (QWAC) - identification at the transport layer. QWAC is similar to SSL/TLS with Extended Validation used in the Internet for the same purpose. It is used for website authentication, so that ASPSPs and TPPs can be certain of each other’s identity, securing the transport layer. TPP should present its QWAC client certificate towards an ASPSP. The ASPSP can choose between using the ASPSP QWAC server certificate or just an existing SSL/TLS certificate to receive the TPP’s identification request.

2. Qualified Certificate for Electronic Seals (QSEAL) - identification at the application layer. It is used for identity verification, so that transaction information is protected from potential attacks after communication. This means that the person receiving digitally signed data can be sure who signed the data and that it hasn’t been changed.

eIDAS QSEAL can be seen as the digital version of a traditional company stamp, and is currently applied to electronic documents sealing to guarantee the origin and integrity of the document.

Note: PSD2 eIDAS QSEAL certificates are used for different purposes - signing of API/HTTP requests and not for sealing of documents.

According to EBA opinion on usage of eIDAS certificates, Clause 14, ASPSPs have three possible scenarios:

1. “Parallel use of QWACs and QSealCs – this will allow AISPs, PISPs and CBPIIs to identify themselves towards the ASPSPs and, at the same time, ensure that the communication is secure and that the data submitted originates from the PSP identified in the certificate.”

This is the most preferred solution, however the QTSP market is not ready to provide PSD2 QSEAL certificates just yet. We expect that the vast majority of the ASPSPs will require both QWAC and QSEAL eIDAS certificates for production access closer to the end of 2019.

2. “Use of QWACs only – this will allow AISPs, PISPs and CBPIIs to communicate securely with and identify themselves towards the ASPSP, but cannot provide evidence that the data submitted originates from the PSP identified in the certificate.”

Currently all ASPSPs require only QWAC eIDAS certificates to access the Sandbox and some live APIs. This option creates a challenge for ASPSP to store the request as evidence in case of potential disputes.

3. “Use of QSealCs with an additional element that ensures secure communication – QSealCs will allow AISPs, PISPs and CBPIIs to identify themselves towards the ASPSPs, but cannot ensure confidentiality during the communication session. Therefore, an additional element that ensures secure communication should be used in order to comply with the requirements of Article 35(1) of the RTS.”

This option might be viable only if the QSEAL certificate is used for signing of the requests, while existing SSL/TLS certificates are used for communication.

What’s the issue with the usual eIDAS vs PSD2 eIDAS certificates?

Even though the usage of eIDAS certificates is available on the market for several years, the specifications were added to the RTS from the very beginning, there are just a few QTSPs that are capable to meet the PSD2 regulatory requirements. So what’s the issue around usual eIDAS certificates and PSD2 specifications?

Usual eIDAS certificates are granted to any company (no matter its license or activity type) or physical person. For instance, Company A that bakes cakes wishes to send an agreement online to its Supplier, Company B, for signing. Both companies have a usual eIDAS certificate, which makes it possible to securely communicate between both companies (QWAC) and ensures that digital signature is actually authorised by Company A and Company B (QSEAL).

In such a case to sign a request, a QTSP will normally give you some card/token with certificate private key or some other device that makes QSEAL signature possible. Another option instead of using such a device is storing the certificate private key on the HSM (Hardware Security Module) of the QTSP. The current costs per signing start from EUR 0.02 (price from the Salt Edge’s research). There are dozens of QTSPs that provide such services within EU right now.

So what about eIDAS PSD2 Certificates? Can all these QTSPs provide them? Unfortunately not. Salt Edge has identified only several QTSPs that have such services, the QTSP market is not ready at all in terms of what they have to do. In case of PSD2, there is no document signing, just secure communication between ASPSP-TPP (QWAC) and signing of requests (QSEAL).

PSD2 eIDAS certificates include additional information that is not present in usual eIDAS certificates, namely:

• National Authority code,

• TPP license number,

• Type of PSD2 role (PSP_AI - account information, PSP_PI - payment initiation, PSP_CI - confirmation of funds, PSP_AS - account servicing).

The problem is on the QSEAL side. There is no possibility to apply the existing infrastructure used for “usual eIDAS certificate” for “PSD2 eIDAS certificate”, as there might be hundreds of thousands or even millions of requests from a TPP per month that should be signed by TPP.  

For example, TPP can do 4 automatic refreshes for the Account Information Service per day = 4 requests per day/per connection, and each API call should be signed. Having around 10,000 end-users, it means as a TPP you’ll have at least 4 requests * 10,000 users * 30 days * avg 10 API calls = 12,000,000 monthly requests. Having the same technological structure:

• physical devices for QSEAL which you have to authorize each request manually with a hardware token

• price of EUR 0.02 per signature of API call using hardware token

We’re getting to EUR 240,000/month for an AIS TPP with 10,000 daily active end-users. This makes it impossible to use current eIDAS structure in the post-PSD2 world. Using soft tokens on the other hand, does not impose any additional expenses per API calls signature.

The RTS indicates that qualified certificates for electronic seals have to be used, however it does not specify that such tokens have to be generated or stored on the QSCD (Qualified Electronic Signature Creation Device), as it was and still is for Document Sealing in the usual eIDAS certificates. This means that a QTSP can issue QSEAL as soft tokens in the same way as QWAC for PSD2 signing requests, not based on token or HSM.

From the Salt Edge’s market study, such an approach has been confirmed by at least 2 QTSPs so far, which are planning to release public QSEALs via soft token in June 2019.

Summary for TPPs:

1. TPPs have to get both QWAC and QSEAL certificates, as the ASPSPs can choose any of the three potential scenarios (just QWAC, just QSEAL, both QWAC and QSEAL)

2. Authorized TPPs can currently get only testing eIDAS certificates from QTSPs. There are several markets within Europe (e.g. the UK) which have proactive local working groups that do provide testing certificates for TPPs and these are valid in such countries until September 2019. However, starting from September 14, even for the UK market, all TPPs should get their live eIDAS certificates from a QTSP.

3. Authorized TPPs have no way of getting live eIDAS certificates until June 2019, just because QTSPs are not ready yet. For TPPs that do wish to start using live PSD2 channels from June, they will need to start researching/contacting QTSPs as soon as possible.

4. TPPs should be very careful when choosing a QTSP and ensure that such provider does offer QSEAL as a soft token rather than a hardware token in order to make it possible to operate on a large scale/volume.

5. TPPs that have agents, branches, several different projects (e.g. retail, business banking, money management apps) or are using a Technical Service Provider  (e.g. Salt Edge) are advised by the EBA to use multiple certificates simultaneously: one per agent, branch or Technical Service Provider. This should ensure business continuity and better risk management, because the legitimacy of one certificate would not be affected by the expiration/revocation of any other.

6. TPPs remain fully responsible and liable for the acts of their agents and Technical Service Providers as well as for the revocation and renewal of the eIDAS certificates issued to them.