Zgoda – Jest to dokument który klient akceptuje i na podstawie którego Bank uzyskuje prawo do pewnych czynności. Definiujemy w tym momencie 3 rodzaje zgód:

ISM-CA – Centrum Autoryzacji w strukturze PKO gdzie są przechowywane informacje na temat wszystkich zgód udzielonych przez klienta. W szczególności jest przechowywane:

Identyfikator ISM-CA jest przekazywany w metodzie /api/bank/{bankId}/authorize i zwracany w callback

Privilige – konkretne uprawnienie które definiuje ASPSP w swoim API. Każde ASPSP może definiować privilige dowolnie i z dowolną granularnością.

Zakładamy, że my tego nie słownikujemy po swojej stronie- trzymamy listę privilige w consent_template w JSON

Purpose – Cel. Jest to abstrakcja definiująca po co dana zgoda została udzielona i na co ona pozwala. Przykrywa to w jakim standardzie PSD2 API działa dany ASPSP i jak definiuje Privilige.

Zakładam, że to jedyny słownik jakim komunikujemy się na styku TPP-PSD2Hub. Pytanie jak zarządzamy i definiujemy ten słownik.

SZUP (szablon uprawnień) – reprezentacja w bankup danego Purpose w zależności od standardu PSD

U nas jest CONSENT_TEMPLATE

ZUP (zestaw uprawnień) – Konkretna instancja SZUP która przechowuje m.in. dane identyfikacyjne klienta, konta oraz wszystko predefiniowane w SZUP

U nas jest CONSENT

Access Token – Token który pozwala na dostęp do danych zdefiniowanych w SZUP w danym ASPSP

AISPAuthirization.accesstoken

Data Lake – Miejsce gdzie Bank przechowuje pobrane dane na potrzeby ewidencjonowania i / lub dodatkowego przetwarzania

B-DB – Bankupowa baza znormalizowanych danych pobranych klienta.

LDS

[KANAŁ] Klient akceptuje regulamin, wybiera bank i konta który chce podłączyć

[XS2A] Regulamin jest przetwarzany na Purpose

[XS2A] Purpose, bank oraz konta sa przekazywane do Bankup

W tym celu wywoływana jest metoda /api/bank/{bankId}/authorize
2 scenariusze:

Z następującym parametrami
​{
​"userId": "string",
​"months": x,
​"values": [
​{
​"key": "string",
​"value": "string"
​}
​],
​"saveCredentials": true,
​"externalconsentid": string,
​"externalconsentguid": string,
​"purpose": [
​{
​"key": "string"
​}
​]
​}

[BANKUP] sprawdza który SZUP powinien być użyty dla danego purpose i danego Banku

j.w.

Na tym etapie następuje związanie klienta, z ZUP oraz wybrany „ISM-CA:ID" (stworzony nowy, bądź wybrany już istniejący)

j.w. – tworzony jest rekord w consent

[BANKUP] zwraca URL gdzie ma się odbyć twarda autentykacja.

Odpowiedź z metody /api/bank/{bankId}/authorize

[KANAŁ] pozwala klientowi się twardo autentykowac po czym przekazuje do XS2A rezultat, w szczególności CODE

[XS2A] zapisuje do ISM-CA nową zgodę, bądź aktualizuje poprzednią

[XS2A] przekazuje do Bankup CODE oraz resztę danych

Przekazywany do PSD2Hub jest kod poprzez wywołanie metody /api/bank/{bankId}/authorize
{
userId: "userId",
months: x,
sessionId: "sessionId",
values:[
{
key: "Consent",
value:"—code—"
}
]
}
Tworzony jest lub aktualizowany wpis w tabeli PSD2context i powiązanie consent-psd2context

[BANKUP] wymienia CODE na ACCESS-TOKEN i wiąże go z ZUP

[BANKUP] przekazuje to XS2A potwierdzenie zakończenia autentykacji

Po otrzymaniu access token i refresh token wołany jest callback wystawiany przez XS2A z zawartością:

JSON zwracany przy wywołaniu zarejestrowanego adresu callback

{

„tpptoken": „<token provided by TPP when initialising AIS session e2-e identifier>",

„sessionid": „<sessionId>",

"stage": „accounts",

"status": "inProgress",

"accountsFetchedCount": 2,

"accountsProcessedCount": 0

}

Wywołanie callback możliwe jest przy każdej zmianie pary wartości stage/status.

[XS2A] ustawia stan zgody w ISM-CA na aktywny

[XS2A] zwraca do kanału informacje o zakończeniu autentykacji

[KANAŁ] rozpoczyna korzystanie ze zgody

Każdy rekord z tabeli transaction i bankaccount ma referencję do consent (wiele do wielu).

Dodatkowo dane przechowują informacje o:

Jeden bank nie może wystawić kilku access tokenów dla jednego klienta. To znaczy, wszystkie konta danego klienta z danego ASPSP są udostępniane na podstawie jednego access tokenu.

Wszystkie konta – tzn wszystkie konta na które klient wyraził zgodę

Tego typu operacja wymaga dezaktywacji bieżącego access tokenu i uzyskanie nowego. Nowy token będzie powiązany z innym zakresem uprawnień (inna lista kont) więc wymaga nowego ISM-CA:ID

Jest to flow jeszcze nie przeanalizowany. Na chwilę obecną zakładamy, że:

My dostaniemy grant-invalid i zmieniamy consentStatus na 1. Batch nie odświeża tych rachunków

Opis mechanizmu tutaj: Callback services