Introduction

This article is the third in a series dealing with the use of the eIDAS Regulation and qualified certificates in the context of the PSD2 Directive. We will describe the usage of eIDAS certificates in the implementation of PolishAPI.

eIDAS certificates and PolishAPI

Most banks in Poland decided to implement a “special interface” in the form of an API that implements the PoslishAPI standard. The standard itself was based on the REST architecture style and the OAuth standard with its followings. PolishAPI describes the security requirements related to certificates in section 6.

The standard clearly separates two types of keys (certificates). One should be used for transmission as the other for signing the message. Using the RTS requirements and EBA opinion, we can perform
a simple mapping. The QWAC qualified certificate should be used to secure the transmission, while the QSealC certificate should be used to sign the message.

Let’s focus now on the method of certificates chceking between TPP and ASPSP. We know that RTS in art. 32 section 3 explicitly prohibits the ASPSP to require from the TPP to be registered in its systems before using the “special interface” and “emergency interface” services. The process of establishing connection and use of the “special / emergency interface” services should take place automatically. In the case of establishing TLS secure transmission (MTLS), the matter is clear – TPP uses the QWAC certificate, which means that using the eIDAS infrastructure, the ASPSP can confirm the identity and roles of TPP. In the case of a message signature, the situation is not so clear, especially in the case of PolishAPI.

In accordance with eIDAS regulation, the electronic seal QSealC is supported by several formats: XAdES, CAdES, PAdES and ASiC-S / ASiC-E (XML, PDF, DOC, TXT, ZIP ..). These signatures contain a certificate, so that there is no problem with identity confirmation of the signer. Unfortunately, eIDAS does not support signatures for JSON documents. PolishAPI uses such documents. Thankfully the standard suggests how we can get to the QSealC certificate that was used to sign. We have two paths to choose from:

• “Use of the “x5u” – “JWS-SIGNATURE”- signature header parameter (section 4.1.5 RFC 7515); allows the URL to be forwarded to a resource that is the public X.509 certificate key. “
• “Use of the procedure based on the “OAuth 2.0 Dynamic Client Registration” protocol (RFC 7591), allowing for prior (in relation to actual communication using the XS2A interface or callbacks) certificate checking between the parties.”

I wonder that PolishAPI allows the first method, if dynamic customer registration can be used instead? Personally, I am a big supporter of the second method. If we look at the PSD2 OpenBanking GB standard, only dynamic customer registration is allowed.

In the next article, we’ll answer questions about the operational aspects of validating eIDAS certificates in the context of access to the “special interface” and “emergency interface” services.