Wprowadzenie

Niniejszy artykuł jest pierwszym z cyklu artykułów traktujących o wykorzystaniu rozporządzenia eIDAS
i certyfikatów kwalifikowanych w kontekście dyrektywy PSD2. Przedstawimy w nim wymagania PSD2 dla automatycznej weryfikacji tożsamości TPP wobec ASPSP w czasie korzystania z „interfejsu specjalnego” (zazwyczaj API np.: PolishAPI) oraz „interfejsu awaryjnego” (zazwyczaj bankowość elektroniczna).

Wymogi PSD2 w kontekście uwierzytelniania TPP

Dyrektywa w sprawie usług płatniczych 2 (PSD2) zezwala podmiotom trzecim (TPP) na świadczenie usług płatniczych, które wcześniej były zastrzeżone wyłącznie dla banków (ASPSP). Technicznie realizacja tych usług polega na wykorzystaniu przez TPP dostępu do rachunku prowadzonego przez bank. TPP może uzyskać dostęp do rachunku wykorzystując dwa rodzaje interfejsów:

  • „interfejs specjalny”
  • „interfejs awaryjny”

PSD2 wymusza na bankach udostępnienie obu interfejsów (są od tego wyjątki) do użytku TPP. Dodatkowo standardy regulacyjne (RTS) szeroko opisują wymagania techniczne stawiane interfejsom. Z perspektywy naszych rozważań skupimy się na jednym wymaganiu, czyli uwierzytelnianiu/identyfikacji TPP wobec ASPSP. Wymaganie to dla „interfejsu specjalnego” opisane jest w RTS art. 30 ust. 1 lit. a), a dla „interfejsu awaryjnego” w art. 33 ust 5.

Zazwyczaj w IT realizacja techniczna procesu weryfikacji tożsamości jednego podmiotu wobec drugiego odbywa się przy wykorzystaniu infrastruktury klucza publicznego (PKI).  W PSD2 nie jest inaczej i art. 34 ust. 1 RTS wskazuje na konieczność oparcia się na certyfikacie pieczęci elektronicznej lub na certyfikacie uwierzytelniania witryn internetowych. Mamy tutaj jednak dodatkowe uszczegółowienie. RTS mówi jednoznacznie, że chodzi o certyfikaty kwalifikowane zgodne z rozporządzeniem eIDAS. Wymaganie użycia jednego lub drugiego typu certyfikatu może wprowadzić jednak w błąd.  Do weryfikacji tożsamości w czasie nawiązywania połączenia powinniśmy użyć certyfikatu uwierzytelniania witryn internetowych, a nie certyfikatu pieczęci. Na szczęście EBA w opublikowanej opinii wyjaśnia całą sytuację.  Wskazuje, że najlepszym podejściem jest wykorzystywanie certyfikatu uwierzytelniania witryn internetowych do nawiązywania bezpiecznego połączenia (spełnienie wymogu RTS art. 35 ust. 1).  Certyfikat pieczęci powinien być wykorzystywany do stemplowania/podpisywania wiadomości.

Zostajemy jednak z pytaniem: dlaczego akurat certyfikaty kwalifikowane eIDAS? Odpowiedzi możemy szukać w art. 32 ust. 3 RTS, czyli wymaganiu, które zabrania „stwarzania przeszkód” w świadczeniu usług przez TPP, w tym dodatkowych rejestracji, dodatkowych wymogów licencyjnych poza tymi przewidzianymi w ustawie.

Standardowa realizacja PKI wymaga od wszystkich stron wchodzących w relacje zaufania do strony trzeciej, czyli do wystawcy certyfikatu. Zazwyczaj jest to jedna ze stron świadcząca usługę (np. w naszym przypadku usługę zgodną z PolishAPI). W przypadku eIDAS jednostkami wystawiającymi certyfikaty są dostawcy usług zaufania (QTSP), czyli firmy kompletnie niezależne od TPP i ASPSP i nadzorowane przez odpowiednie organy. W Polsce firm o statusie QTSP jest kilka (Centrum, KIR itd.). Oparcie się na certyfikatach eIDAS gwarantuje obu stronom, czyli TPP oraz ASPSP możliwość wzajemnej identyfikacji w pełni automatycznie. Obie strony nie muszą wchodzić w żadne relacje: rejestrować się, podpisywać umów, czy wystawiać sobie certyfikatów. To nie jest konieczne,
a wręcz zabronione. Art. 32 ust 3 RTS stanowi, że ASPSP nie może wymagać od TPP rejestrowania się na swoich stronach, jeżeli TPP przedstawia się ważnym certyfikatem EIDAS. Odstępstwo od braku wymogu rejestracji można zastosować dla środowisk testowych (“sandbox”), ponieważ środowiska te należy udostępnić firmom starającym się o status TPP (czyli firmom, które nie posiadają jeszcze certyfikatu).

Finalnie w PSD2 mamy następującą sytuacje. TPP oraz ASPSP występują do QTSP o certyfikat pieczęci oraz certyfikat uwierzytelniania witryn internetowych. Posiadając takie certyfikaty TPP nawiązuje połączenie z ASPSP i następuje zestawienie bezpiecznego połączenia. Obie strony sobie ufają, ponieważ certyfikaty, które przedstawiły w czasie nawiązywania połączenia zostały wystawione przez zaufane QTSP. W tym momencie TPP może rozpocząć wykonywanie usług Account Information Service (AIS), Payment Initiation Service (PIS), Confirmation of Funds (Cof), czy skorzystać z „interfejsu awaryjnego”. Proces wydaje się standardowy. Powstają jednak pytania:

  • Skąd pobrać certyfikat wystawcy (czyli QTSP) w celu weryfikacji kwalifikowanych certyfikatów TPP?
  • Jak walidować kwalifikowane certyfikaty TPP?
  • Czy eIDAS i PSD2 narzuca dodatkowe wymagania związane z walidacją certyfikatów?
  • Ilu jest dostawców usług zaufania (QTSP) w całej Europie? Czy oni wszyscy mogą wystawić certyfikaty kwalifikowane TPP?
  • Czy certyfikaty QTSP się zmieniają i jak często?
  • Czy posiadanie przez TPP pieczęci i certyfikatu oznacza, że TPP mogą automatycznie wykonać usługi AIS, PIS? Jest jeszcze przecież wymóg posiadania ważnej licencji i wpisu do rejestru?
  • Jak zarządzać certyfikatami QTSP? Czy mogę do tego wykorzystać standardowe mechanizmy/urządzenia PKI?
  • Co z paszportyzacją TPP?

Na te i inne pytanie odpowiemy sobie w kolejnych artykułach z tego cyklu.

psd2 directive tpp