Wprowadzenie

Niniejszy artykuł jest trzecim z cyklu artykułów traktujących o wykorzystaniu rozporządzenia eIDAS i certyfikatów kwalifikowanych w kontekście dyrektywy PSD2. Opiszemy w nim wykorzystanie certyfikatów eIDAS
w implementacji PolishAPI.

Certyfikaty eIDAS i PolishAPI

Większość Banków w Polsce zdecydowało się na realizację „interfejsu specjalnego” w formie API, które implementuje standard PoslishAPI. Sam standard został oparty na stylu architektury REST oraz standardzie OAuth i jego pochodnych. PolishAPI opisuje wymagania bezpieczeństwa związane z certyfikatami w punkcie 6.

W standardzie jawnie oddziela się dwa typy kluczy (certyfikatów). Jeden ma służyć do transmisji, drugi do podpisu wiadomości. Wykorzystując wymagania RTS oraz opinię EBA możemy wykonać proste mapowanie. Certyfikat kwalifikowany QWAC powinien służyć do zabezpieczenia transmisji, zaś certyfikat QSealC powinien zostać wykorzystany do podpisu wiadomości.

Skupmy się teraz na metodzie uzgadniania certyfikatów między TPP i ASPSP. Wiemy, że RTS w art. 32 ust. 3 jawnie zabrania ASPSP wymogu rejestracji TPP w swoich systemach przed skorzystaniem z usług „interfejsu specjalnego” oraz „interfejsu awaryjnego”. Proces nawiązywania połącznia i wykorzystania usług „interfejsu specjalnego/awaryjnego” powinien odbyć się automatycznie. W przypadku zestawienia bezpiecznej transmisji TLS (MTLS) sprawa jest jasna – TPP posługuje się certyfikatem QWAC, a to oznacza, że wykorzystując infrastrukturę eIDAS, ASPSP może potwierdzić tożsamość i role TPP. W przypadku podpisu wiadomości sytuacja nie jest już tak jednoznaczna, szczególnie w przypadku PolishAPI.

eIDAS w kontekście pieczęci elektronicznej QSealC wspiera kilka formatów: XAdES, CAdES, PAdES
i ASiC-S/ASiC-E (XML, PDF, DOC, TXT, ZIP..). Te podpisy zawierają w sobie certyfikat, więc nie ma problemu
z potwierdzeniem tożsamości podpisującego. Niestety eIDAS nie ma natywnie wsparcia podpisów dla dokumentów typu JSON. Takimi dokumentami posługuje się PolishAPI. Z pomocą przychodzi nam sam standard i podpowiada w jaki sposób możemy dostać się do certyfikatu QSealC, który został użyty do złożenia podpisu. Mamy do wyboru dwie ścieżki:

• „użycie parametru nagłówka podpisu JWS-SIGNATURE o nazwie „x5u” (punkt 4.1.5 RFC 7515); pozwala na przekazanie URL do zasobu będącego publicznym kluczem certyfikatu X.509”
• „zastosowanie procedury w oparciu o protokół „OAuth 2.0 Dynamic Client Registration” (RFC 7591), pozwalającej na wcześniejsze (w stosunku do faktycznej komunikacji przy użyciu interfejsu XS2A lub wywołań zwrotnych) uzgodnienie certyfikatu pomiędzy stronami”.

Zastanawiające jest jedynie, dlaczego PolishAPI dopuszcza pierwszą metodę, jeżeli można wykorzystać dynamiczną rejestrację klienta?  Osobiście jestem wielkim zwolennikiem drugiej metody. Jeżeli spojrzymy na standard PSD2 OpenBanking GB to dopuszczalna jest tylko dynamiczna rejestracja klienta.

W kolejnym artykule odpowiemy sobie na pytania o operacyjne aspekty walidacji certyfikatów eIDAS
w kontekście dostępu do usług „interfejsu specjalnego” oraz „interfejsu awaryjnego”.