How to use eIDAS certificates to identify PSD2 TPP clients with Ping Identity and Konsentus
In this blog post, I will describe the need for regulated banks and financial service providers to enable the use of standard eIDAS certificates for identification and authorisation of API clients. I will present a technical solution to the challenge based on PingFederate and PingAccess, together with the TPP-checking API from Konsentus.
PSD2 and Secure APIs
Under the EU’s Second Payment Services Directive (PSD2), all regulated Account Servicing Payment Service Providers (ASPSPs) are required to provide secure APIs allowing regulated, trusted Third Party Providers (TPPs) to access account and payment services on behalf of account holders. The PSD2 Regulatory Technical Standard (RTS) dictates that a TPP should be able to use a qualified certificate issued by any eIDAS Qualified Trust Service Provider (QTSP) in order to identify and authenticate themselves to an ASPSP.
The Electronic Identification, Authentication and Trust Services (eIDAS) regulation provides an EU-wide framework governing secure digital interactions between parties. eIDAS defines a number of standards covering a wide variety of use cases; however, within the context of this discussion, it is the use of eIDAS Qualified Digital Certificates that is of interest.
eIDAS and PSD2
When a regulated TPP entity wishes to use eIDAS Qualified Certificates for the purposes of consuming PSD2 APIs, there are at least two other parties that come into play.
The first will be the National Competent Authority (NCA) serving the jurisdiction of that TPP. The NCA is responsible for vetting and validating the TPP organisation and ultimately issuing a TPP Authorisation Number, which will be maintained in a public registry. In other words, the NCA in the TPP’s jurisdiction acts as the source of truth regarding whether a particular TPP is regulated to perform transactions under PSD2 and which PSD2 services (such as Account Information or Payment Initiation) should be offered to said TPP.
Once the TPP has obtained an Authorisation Number from the NCA, they can then obtain Qualified Certificates from a Qualified Trust Service Provider (QTSP) that will include this number as a means of cryptographically asserting the TPP’s identity to other parties (such as ASPSPs). Two different types of certificates come into play here, and TPPs can obtain and use one or both of the following:
- Qualified Website Authentication Certificate (QWAC)
- Qualified Certificate for Seals (QSealC)
While opinions on which type of certificate should be used in which context tend to vary, the consensus seems to be that a TPP should use a QWAC for the purposes of transport-level authentication and a QSealC for transaction and payload signing.
A more detailed explanation of this topic is beyond the scope of this piece, but is recommended reading all the same.
eIDAS Challenges
While on the surface this model appears to offer a sensible solution to the problem of TPP identification (without requiring or mandating registration with third-party entities such as the Open Banking Directory), there are some rather concerning challenges to overcome.
It would be convenient to assume that, since a QWAC is just a rather specialised X509 certificate, any ASPSP could simply adopt Mutual TLS as the client authentication mechanism for TPP OAuth clients and thus get eIDAS support “for free,” provided that their OAuth Authorisation Server supports this capability (PingFederate does, of course).
There is, however, an inherent disconnect in that the entity responsible for maintaining the regulatory status of the TPP (the NCA) is not the same entity that issues the certificate (the QTSP). Furthermore, there is no onus on either of these parties to stay in sync with one another; a QTSP is not obliged to notify any NCA when a TPP certificate is revoked any more than an NCA would be obliged to notify a QTSP when a TPP’s regulatory status changes. Put another way, it is perfectly possible for a TPP whose regulatory status has been revoked to still be in possession of a perfectly valid QWAC or QSealC.
The onus and risk falls squarely on the shoulder of the ASPSPs here, as they are legally required to validate the regulatory status of each TPP every time a TPP performs a PSD2 transaction. What this means in practice is that each ASPSP needs to perform a real-time check against the appropriate NCA register every time a TPP presents an eIDAS certificate to authenticate a transaction. This is in addition to the standard certificate validity checks that would need to be performed to detect revocation of the certificate itself.
TPP Checking Services to the Rescue
In order to simplify and streamline the TPP-checking process for ASPSPs, a number of organisations now offer dedicated TPP checking services, either via a consolidated directory that can be synchronized to an in-house repository, or via a SaaS API. One such organisation is Konsentus, who offer a TPP Regulatory Status API that an ASPSP can use to perform a real-time check based on a TPP’s public certificate. The API uses a consolidated directory pulled from all the applicable NCA and QTSP registers and returns a JSON payload detailing the current status of the TPP. ASPSPs can then use this information as part of their policy to determine whether to allow the specific transaction to proceed.
Here’s an example response payload returned by the Konsentus Sandbox API when I pass my sample eIDAS certificate (kindly provided by my friends at InfoCert):
As we can see, the payload provides information relating to the eIDAS certificate itself (such as validity of signature, expiration, revocation and QTSP) as well as information from the application NCA register detailing the specific Payment Services for which this TPP is authorized.
Solving the TPP Authentication Challenge
The remainder of this article will focus on describing a technical solution to allowing an ASPSP to authenticate a TPP for the purposes of a PSD2 transaction using a QWAC issued to that TPP by a QTSP.
The target architecture uses PingFederate and PingAccess, together with the Konsentus API, to provide an end-to-end solution. Conceptually, it looks as follows:
In this architecture, we use PingAccess as a secure proxy adding additional policy-based protection ahead of PingFederate’s standard OAuth 2.0 endpoints.
A TPP client makes an OAuth 2.0 Token request to PingAccess via Mutual TLS using its eIDAS QWAC. It additionally provides a client ID (pre-registered with PingFederate and associated with the QWAC Distinguished Name). PingAccess validates the certificate (performing the standard issuer and validity checks) and then uses a custom rule to call out to the Konsentus TPP-checking API, passing the QWAC public certificate to obtain further details about the TPP. If the details received from the Konsentus API indicate that the transaction should continue, PingAccess passes the request on to PingFederate.
PingFederate then uses its configured logic to authenticate the client and issue the appropriate token.
These interactions are described in more detail in the below sequence diagram:
NOTE: Registration of the TPP client, either manually or using Dynamic Client Registration, is outside the scope of this discussion. I will publish a follow-up article in due course describing potential approaches for enabling Client Registration with eIDAS certificates.
Configuration Details
To prove out the above solution, I configured a simple setup to demonstrate the flow. I will use the client credentials flow for the demonstration, but the same approach will be used when the TPP issues a call to the Token endpoint as part of the Auth Code flow.
PingFederate
I created an OAuth Client that uses my test eIDAS certificate for authentication:
I had to be sure to import the root signing cert for the QTSP as well:
I also added an OGNL expression into the Access Token Mapping to include the client certificate hash into the access token once issued:
PingAccess
PingAccess was configured to proxy the PingFederate token endpoint by defining a site that refers to PingFederate and an Application to define the proxy endpoint:
I created a custom Rule using the PingAccess Java SDK. This Rule uses the PingAccess Third Party Service framework to make a call out to the Konsentus TPP API. Sample code for this rule can be found here.
I created a Third-Party Service configuration pointing to the Konsentus API Sandbox:
I then configured my new Rule instance to refer to the third-party service, along with providing my Konsentus Sandbox credentials:
The final step in the configuration was to add the rule into the policy flow protecting the Token API endpoint.
Seeing it in Action
To test the flow, we start by executing a POST request to the proxied OAuth 2.0 Token endpoint exposed by PingAccess. I have my test eIDAS QWAC certificate available and pass both the certificate and private key to the CURL command that I’m using:
We can see in the PingAccess log how the custom Rule interacts with the Konsentus API. First we retrieve the client certificate from the request:
Then we call the Konsentus API (passing the certificate we obtain above in the “eidas” header):
We then receive a response payload:
We parse the response to ensure that all the validity checks pass successfully:
We then check the TPP roles to ensure that the requested scope (“accounts” in this case) is allowed (by the TPP role “8”).
Since all the checks succeed, our request is passed through to PingFederate, which issues the client credentials token:
Note that the issued token includes a hash of the client certificate, thus effectively binding it to the client and certificate.
Additional Use Cases
Using PingFederate and PingAccess together with a TPP Checking Service such as the one provided by Konsentus enables ASPSPs to handle eIDAS QWAC certificates for PSD2 TPP client identification and authentication, while including real-time checks against the regulatory status of each TPP every time a transaction is performed.
In this article, I have described a single use case for this approach but will cover additional possibilities in future posts, including the usage of QSealC certificates for payload signing and also an approach for Dynamic Client Registration using eIDAS certificates.
For more information on how the Ping Intelligent Identity Platform helps you meet PSD2 requirements, please visit www.pingidentity.com/psd2.
