Juil 25, 2018 
Une fois agréés, les TPP se retrouvent dans un registre national. En outre, les TT vont être en mesure de se voir délivrer des certificats eIDAS pour s’authentifier et signer leurs appels aux API.
Il existe deux types de certificats :
- Les QWAC (Qualified Website Authentication Certificates), qui doivent être utilisés pour le chiffrement des communications au travers de TLS ;
- Les QSealC (Qualified Electronic Seal Certificates), qui ont pour objet de signer des requêtes.
Les deux types de certificats seront délivrés par des QTSP (Qualified Trust Services Providers), des autorités de certification reconnues par l’Europe pour délivrer des certificats eIDAS.
Les deux ont un rôle à jouer dans le cadre des API DSP2. Le premier va être présenté par le TPP lors de l’établissement de la session TLS, et doit donc être validé par le serveur web non seulement comme étant correctement émis par un QTSP, mais également extraire les informations du certificat X.509 correspondant à son agrément.
L’ETSI (European Telecom’s and Standards Institution) a publié en mai 2018 la norme concernant la nomenclature à suivre au sein d’un certificat X.509 pour intégrer les informations liées à la PSD2. Cela se fait au sein du champ O(rganization) du certificat, en concaténant les informations suivantes :
- “PSD”
- Code ISO 3166 du pays de la NCA (l’autorité nationale compétente)
- “-”
- Identifiant de la NCA
- “-”
- Le numéro d’agrément du TPP délivré par la NCA
Par exemple, le champ O du certificat de Budget Insight sera “PSDFR-ACPR-16948”.
Ce sont ces informations que l’ASPSP doit également valider auprès du registre de l’autorité, afin de s’assurer du droit d’exercer du TPP. En effet, le QTSP est qualifié pour valider qu’un TPP détient l’agrément à un instant donné, mais le certificat a une durée de vie de plusieurs années.
Le second certificat sert à signer les requêtes au sein de la session HTTP. L’API STET se base sur la norme HTTP Signature (encore à l’état de draft) pour signer le contenu. La version 1.4 de l’API STET inclura la mécanique à utiliser pour transmettre le certificat, se reposant sur une URL au sein du champ keyid.
Voici un exemple de requête à l’API STET intégrant une signature :
POST /v1/payment-requests HTTP/1.1
Date: 2018-07-08T09:33:55.375+02:00
PSU-Date: 2018-07-08T09:33:55.954+02:00
Accept: application/hal+json; charset=utf-8
PSU-GEO-Location: GEO:52.506931,13.144558
X-Request-ID: GGF3YUD3BDJK
PSU-Referer: https://demo.biapi.pro/2.0/auth/share/
PSU-IP-Port: 12345
PSU-Accept: text/plain
Authorization: Bearer X1xTLdRL3KpNya/QUTN_9Ggtdr9QFHaj
PSU-Accept-Charset: utf-8
PSU-Accept-Encoding: gzip, deflate
PSU-IP-Address: 10.10.10.10
PSU-User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36(KHTML, like Gecko) Chrome/50.0.2661.75 Safari/537.36
PSU-HTTP-Method: POST
PSU-Accept-Language: en-US
Content-Type: application/json
User-Agent: Budgea/2.0
Digest: SHA-256=T7FMsJqT/o8xiHbq/GoeI879JoC0Je77w5fTUlpCyrM=
Content-Length: 1589
Signature: keyId="https://biapi.pro/qsealc.crt",algorithm="rsa-sha256",headers="date psu-date accept psu-geo-location x-requestid psu-referer psu-ip-port psu-accept authorization psu-accept-charset psu-accept-encoding psu-ip-address psu-user-agent psu-http-method psu-accept-language content-type user-agent digest content-length (requesttarget)",signature="tCYCZAGxVZLMlo87gHeXyPs2RkoNvOhCdsPvjkGhwkHlU1kT8xRBT3lybCT2UcjFrd2WroWaXexC3pYNYHJTwPN9HRV6dVXNRn3Ba2/BOA2n2g/+RELeAX318buwuEzQqAUOfci9d6d52X00+a5Dpb7h91T0zZuMBsPcxK6n2Sw="
L’attention doit s’accorder sur l’en-tête Digest qui contient un condensat du body (non retranscrit), et l’en-tête Signature qui est composé d’un keyID ayant l’URL vers le certificat, de l’algorithme utilisé, des en-têtes qui sont signés, et de la signature.
