Once approved, TPPs are registered in a national register. In addition, TTs will be able to be issued eIDAS certificates to authenticate themselves and sign their calls to the APIs.
There are two types of certificates:
- The Qualified Website Authentication Certificates (QWACs), which must be used to encrypt communications over TLS;
- The QSealC (Qualified Electronic Seal Certificates), which are intended to sign queries.
Both types of certificates will be issued by Qualified Trust Services Providers (QTSP), certification authorities approved by Europe to issue eIDAS certificates.
Both have a role to play in the context of the PSD2 APIs. The first will be presented by the TPP when establishing the TLS session, and must therefore be validated by the web server not only as being correctly issued by a QTSP, but also extract the information from the X.509 certificate corresponding to its approval.
The European Telecoms and Standards Institution (ETSI) published in May 2018 the standard for nomenclature to be followed in an X.509 certificate to integrate PSD2-related information. This is done within the O(rganization) field of the certificate, concatenating the following information:
- “PSD”
- ISO 3166 code of the country of the NCA (National Competent Authority)
- “-”
- NCA Identifier
- “-”
- The TPP approval number issued by the NCA
For example, the O field on Budget Insight’s certificate will be “PSDFR-ACPR-16948”.
It is this information that the ASPSP must also validate with the authority’s register, in order to ensure that the TPP has the right to operate. Indeed, the QTSP is qualified to validate that a TPP holds the approval at a given time, but the certificate has a lifespan of several years.
The second certificate is used to sign queries within the HTTP session. The STET API uses the HTTP Signature standard (still in draft status) to sign the content. Version 1.4 of the STET API will include the mechanism to be used to transmit the certificate, based on a URL within the keyid field.
Here is an example of a query to the STET API that includes a signature:
Attention should be paid to the Digest header that contains a condensate of the body (not transcribed), and the Signature header that consists of a keyID with the URL to the certificate, the algorithm used, signed headers and the signature.