TPP identification via non-dedicated PSD2 interfaces

According to the RTS on SCA and CSC (Article 34. Certificates), payment service providers shall rely on eIDAS certificates for third party providers’ (TPPs’) identification.

There are 2 types of PSD2 eIDAS certificates and each of them plays an important role: 

1. QWAC (qualified certificate for website authentication) - is used for website authentication, so that ASPSPs and TPPs can be certain of each other’s identity, securing the transport layer. Using this certificate guarantees confidentiality (nobody else could have read the data) and authenticity (that the data was not changed between the end points) of all data transferred through the channel. The ASPSP can choose between using an ASPSP QWAC server certificate or an existing SSL/TLS certificate to receive the TPP’s identification request. 

2. QSeal (qualified certificate for electronic seals) - is used for signing requests. The entity receiving digitally signed data can be sure who signed the data, that the data have not been changed since being signed. QSeals do not provide confidentiality of the data (i.e. there is no encryption of data). Yet, unlike QWAC, QSeal can trace and log the communication sessions. 

According to the EBA, ASPSP can support the use of either QWAC or QSeal or both of them for TPP identification, the last option being recommended. Using just one of the two certificates will not ensure full security and traceability of communication sessions. For more information please refer to the article.

For non-dedicated interfaces, the use of QWAC can be seen similar to using Mutual TLS, when TPP is the ‘client’ and ASPSP acts as ‘server’. TPP sends a request to ASPSP. ASPSP replies back by indicating either its QWAC server-certificate or TLS server-certificate for the purpose of ASPSP identification by TPP. TPP replies back by providing its QWAC client-certificate in the communication layer with the purpose of TPP identification. Such mutual identification between client and server is called Mutual TLS. This same principle can be used under PSD2, via non-dedicated interface.

Now, the question is whether using QWAC alone is enough. As mentioned earlier, both TPP and ASPSP can identify each other and the communication is encrypted, thus secure, when using QWAC certificates. Yet, there are some challenges related to the usage of QWAC certificates alone via non-dedicated interfaces.

1. First of all, as non-dedicated interface represents a modified customer interface, changes to such interface should be minimal in order not to break the end-user journey or jeopardize its security. But the usage of client-certificates alone requires presenting this certificate every time anyone (even end-customer) tries to access the interface, which in turn adds friction. In the pre-PSD2 world, in most cases, during the authentication process - bank requests end-users to insert a set of credentials when accessing the PSU facing interface (e.g. online banking). Thus, customer does not present any client-certificate for authentication. Yet, introducing the requirement of identification via client-certificate changes the PSU authentication process. Due to this added friction, Mutual TLS client-certificates are mostly used in machine-to-machine communication and are perfectly suitable for APIs, but are not so good for end-customer interface. 

2. The second issue refers to the fact that QWAC certificate is used during communication session only to identify TPP and to make such communication session secure via encryption. Using QWAC certificates does not accumulate evidence that the data submitted originates from the TPP identified in the certificate (Article 29. Traceability of RTS). Besides, data can be altered after communication session is closed.

An example where only QWAC certificate is required for TPP identification is the implementation of SocGen in its fallback channel (which is the same modified customer interface). 

Traceability requirements of all TPP requests are indicated in the RTS on SCA and CSC (Article 29. Traceability):

Using the QSeal certificate allows ASPSP to be in compliance with Article 29 and solve both of indicated issues with QWAC certificate. Yet, using QSeal alone is not enough as ASPSPs will need to secure the communication channel. An example where just QSeal is required is the implementation by Caixabank. 

Solution: How adding QSeal on top of QWAC or Mutual TLS solves the above challenges

1. The first issue that might affect end-customer journey can be solved by using HTTP headers which will be used only by TPPs. TPP, on its first request sent to ASPSP, at the beginning of communication session, should include its QSeal certificate in HTTP header and sign requests using QSeal private key. This will allow the ASPSP to:

   • Recognize that it is a TPP trying to access the interface and not the PSU himself;

   • Validate the QSeal certificate and the signature of request. For more information please refer to this article; 

   • Save the QSeal certificate and validation results for all TPP’s requests during the same communication session. This will help with lowering the size of next requests and decreasing the response time;

   Thus, requiring the usage of QSeal and HTTP headers will not affect the end-customer journey.

2. The second issue related to traceability of TPP requests as evidence in potential future disputes can be handled by ASPSP requiring TPPs to sign all their requests and pass this signature in HTTP header. This will allow ASPSP to:
   
   
   • Identify any and all requests originated from a specific TPP;

   • Validate the presence of QSeal private key on TPPs’ side, QSeal certificate was already validated on first request;

   • Log request and signature in audit log for traceability purpose.

The practice of signing HTTP Messages can be applied at the base of using QSeal certificates, together with either QWAC or Mutual TLS, for TPP identification in PSD2 non-dedicated interfaces. ASPSP should provide documentation describing the used HTTP headers and the signature algorithms for passing QSeal certificate and request signature.

To summarize, the best implementation of a TPP identification mechanism in a non-dedicated interface is by combining both QWAC (or Mutual TLS) and QSeal certificates. While the usage of QWAC/Mutual TLS certificate guarantees confidentiality and authenticity of all transferred data, QSeal guarantees that data was not altered and also allows the traceability of TPP actions. Using QSeal certificates helps to avoid changes that would affect end-customers’ journey and also help ASPSPs be fully in compliance with PSD2.