8. Use Case 1. Надання згоди PSU на отримання AISP інформації по рахунку PSU у ASPSP
Редакція OpenBanking Ukraine
Цей розділ описує Use Case 1 щодо створення та авторизації згоди PSU на отримання AISP інформації по рахунку PSU у ASPSP, включно з варіантами Redirect SCA та Decoupled SCA і детальним описом кроків основного та альтернативних сценаріїв.
8.1. Опис Use Case 1
| Первинна дійова особа | PSU |
|---|---|
| Вторинна дійова особа | Платіжний застосунок AISP, ASPSP |
| Передумова | * PSU має діючий рахунок в ASPSP (України); * PSU завантажив платіжний застосунок AISP; * PSU зареєструвався у платіжному застосунку AISP; * PSU увійшов у платіжний застосунок AISP (SCA). |
| Тригер | PSU ініціював створення згоди у платіжному застосунку AISP |
| Результат | Згода на отримання AISP інформації по рахунку PSU у ASPSP створена, статус = valid |
8.2. Activity diagram
8.2.1. Redirect SCA: явний початок процесу авторизації (RedirectSCAApproach: Explicit Start of the Authorisation Process)
Якщо ASPSP підтримує підхід Redirect SCA, потік повідомлень є таким: після запиту на створення згоди відбувається перенаправлення PSU для надання згоди та проходження SCA в платіжний застосунок ASPSP або web-сторінку. Для визначення статусу або вмісту створеної згоди AISP може здійснити відповідний виклик після перенаправлення сеансу в платіжний застосунок AISP.
Примітка: activity diagram знаходиться у окремому файлі у додатку 1.
8.2.2. Decoupled SCA: явний початок процесу авторизації (Decoupled SCA Approach: Explicit Start of the Authorisation Process)
Потік транзакцій у підході Decoupled SCA аналогічний підходу Redirect SCA. Різниця полягає в тому, що ASPSP просить PSU авторизувати згоду на доступ до рахунку, наприклад, через платіжний застосунок. ASPSP просить AISP повідомити PSU про це, надіславши відповідне повідомлення PSU приблизно такого змісту: «Будь ласка, використовуйте свій застосунок xxx для авторизації доступу до рахунку».
Примітка: activity diagram знаходиться у окремому файлі у додатку 2.
8.3. Опис кроків activity diagram
| Крок | Опис |
|---|---|
| Основний сценарій | |
| 0. PSU пройшов SCA у платіжний застосунок AISP | Цей крок вказаний інформаційно. Перехід до кроку 1 основного сценарію. |
| 1. Ініціювати через AISP створення згоди на отримання інфо по рахунку (нові рахунки, новий тип доступу) | Тригер для запуску цього use case, дію виконує PSU. Перехід до кроку 2 основного сценарію. |
2. Викликати POST /v2/consents/account-access | AISP викликає POST /v2/consents/account-access з параметрами згідно опису у розділі 5. Перехід до кроку 3 основного сценарію. |
| 3. Успішно? | Цей крок не є обов’язковим і AISP може не реалізовувати повторення виклику. Якщо виклик здійснений успішно, то відбувається перехід до кроку 4 основного сценарію. Якщо виклик був неуспішний (HTTP status code = 50Х та інші помилки) і кількість повторень не вичерпана — перехід до кроку 2 основного сценарію. Якщо виклик був неуспішний (HTTP status code = 50Х та інші помилки) і кількість повторень вичерпана — перехід до кроку 4.А альтернативного сценарію. |
| 4. Перевірити — QWAC та відомості в РПІ — request | ASPSP перевіряє: * QWAC та відомості в Реєстрі платіжної інфраструктури (див. розділ 6.3 Протоколу функцій та заходів безпеки); * request syntax; * semantics; * коректність IBAN та наявність, тип цього рахунку у ASPSP; * наявність у згоді типу доступу access = accountDetails та balances та/або transactions; * параметр validTo: дата, передана у цьому параметрі, не має перевищувати 180 днів від поточної дати. Перелік перевірок, які може виконувати ASPSP на цьому кроці, може бути значно ширшим і не наводиться у цьому документі тому, що не є предметом регулювання цього документу. Перехід до кроку 5 основного сценарію. |
| 5. ОК? | Якщо всі перевірки пройдено успішно — відбувається перехід до кроку 6 основного сценарію, якщо ні — 7.А альтернативного сценарію. |
| 6. Створити згоду (status = received) | ASPSP створює згоду (consent) у статусі received, у якій зберігає дані з request на створення згоди. Перелік полів таблиці у базі даних для збереження згоди кожен ASPSP визначає самостійно, тому не наводиться у даній таблиці. Перехід до кроку 7 основного сценарію. |
| 7. Надіслати OK response (HTTP code = 201) | ASPSP надсилає OK response з HTTP code = 201 відповідно до розділу 5. Перехід до кроку 8 основного сценарію. |
| 8. Зберегти згоду (status = received) | AISP створює згоду (consent), у якій зберігає дані з request на створення згоди. Перелік полів таблиці у базі даних для збереження згоди кожен AISP визначає самостійно, тому не наводиться у даній специфікації. Перехід до кроку 9 основного сценарію. |
9. Викликати POST /v2/{resource-path}/{resourceId}/{authorisation-category} | AISP викликає POST /v2/{resource-path}/{resourceId}/{authorisation-category} згідно розділу 9.1 Протоколу функцій та заходів безпеки. Перехід до кроку 10 основного сценарію. |
| 10. Встановити SCA status = started | ASPSP встановлює SCA status = started. Перехід до кроку 11 основного сценарію. |
| 11. Перевірити — QWAC та відомості в РПІ — request | ASPSP перевіряє: * QWAC та відомості в Реєстрі платіжної інфраструктури (див. розділ 6.3 Протоколу функцій та заходів безпеки); * request syntax; * semantics; * resourceId (consentId). Перелік перевірок, які може виконувати ASPSP на цьому кроці може бути значно ширшим і не наводиться у цьому документі тому, що не є предметом регулювання цього документу. |
| 12. ОК? | Якщо перевірки пройдено успішно, відбувається перехід до кроку 13 основного сценарію, у іншому випадку — 13.А альтернативного сценарію. |
| 13. Встановити SCA status = psuIdentified | ASPSP встановлює SCA status = psuIdentified. Структуру таблиці для збереження SCA status кожен ASPSP визначає самостійно, тому не наводиться у даній специфікації. Перехід до кроку 14 основного сценарію. |
| 14. Надіслати OK response (HTTP code = 201) | ASPSP надсилає OK response з HTTP code = 201 відповідно до розділу 9.1 Протоколу функцій та заходів безпеки. Перехід до кроку 15 основного сценарію. |
| 15. Відобразити інформацію про початок SCA | AISP інформує PSU про початок SCA. Повідомлення може бути взяте із параметру psuMessage, отриманому на кроці 9. Перехід до кроку 16 основного сценарію. |
| 16. Вибір PSU (крок виконується тільки для Redirect SCA) | AISP на власний розсуд проєктує UI для підтвердження PSU переходу до SCA. Якщо PSU обрав опцію Перейти/продовжити SCA — відбувається перехід на крок 17 основного сценарію для Redirect SCA. Якщо користувач обрав будь-які інші дії — то основний сценарій завершується. |
| 16. Надіслати PSU повідомлення (push) (крок виконується тільки для Decoupled SCA) | ASPSP надсилає PSU у web/mob версію платіжного застосунку ASPSP повідомлення (push) для проходження SCA. Ідентифікація PSU на стороні ASPSP відбувається на основі значення, яке передається у параметрі PSU-ID/PSU-Corporate-ID при створенні згоди (крок 2 основного сценарію). Логіку пошуку PSU для надсилання повідомлення ASPSP розроблює самостійно. Перехід до кроку 17 основного сценарію для Decoupled SCA. |
| 17. Redirect на веб-сторінку, web/mob app ASPSP (крок виконується тільки для Redirect SCA) | AISP перенаправляє PSU по лінку, отриманому у параметрі _links для проходження SCA на стороні ASPSP. Перехід до кроку 18 основного сценарію. |
| 17. PSU самостійно заходить у платіжний застосунок ASPSP (крок виконується тільки для Decoupled SCA) | PSU самостійно заходить у платіжний застосунок ASPSP для проходження SCA та підтвердження згоди. Перехід до кроку 18 основного сценарію. |
| 18. Авторизуватись на web-page, у web/mobile app ASPSP (1+2 фактор SCA) | Користувач авторизується у web/mobile платіжного застосунку ASPSP вводить: * 1 фактор SCA, наприклад — логін і пароль або біометрія; * 2 фактор SCA, наприклад — електронний підпис, ОТП і т. п. ASPSP самостійно визначає набір факторів SCA, які будуть застосовані. Стосовно електронного підпису слід керуватись вимогами ПП НБУ №172 від 20.12.2023р.: https://zakon.rada.gov.ua/laws/show/v0172500-23#Text. Перехід до кроку 19 основного сценарію. |
| 19. Валідувати 1+2 фактор SCA | ASPSP валідує 1+2 фактор SCA. Перехід до кроку 20 основного сценарію. |
| 20. Успішно? | Якщо валідація успішно пройдена — відбувається перехід на крок 21 основного сценарію. Якщо ні, спробувати ще (не більше 5 разів) — відбувається перехід на крок 18 основного сценарію якщо кількість невдалих спроб менше або = 5. Якщо ні (5 невдалих спроб авторизації або користувач відхилив згоду) — відбувається перехід на крок 20.А альтернативного сценарію якщо кількість невдалих спроб більше 5. |
| 21. Встановити SCA status = psuAuthenticated | ASPSP встановлює SCA status = psuAuthenticated. Перехід до кроку 16 основного сценарію. |
| 22. Підтвердити згоду і накласти 2 фактор SCA (Електронний підпис, ОТП і т. п.) | PSU на web-page, у web/mobile платіжного застосунку ASPSP підтверджує згоду і накладає 2 фактор SCA (1-й фактор наслідується із сторінки логування). Стосовно електронного підпису слід керуватись вимогами ПП НБУ №172 від 20.12.2023р.: https://zakon.rada.gov.ua/laws/show/v0172500-23#Text. Перехід до кроку 23 основного сценарію. |
| 23. Валідувати 2 фактор SCA | ASPSP валідує 2 фактор SCA введений PSU. Перехід до кроку 24 основного сценарію. |
| 24. Успішно? | Якщо валідація 2 фактору SCA пройдена успішно — відбувається перехід на крок 25 основного сценарію. Якщо ні, спробувати ще (не більше 5 разів) — відбувається перехід на крок 22 основного сценарію якщо кількість невдалих спроб менше або = 5. Якщо ні (5 невдалих спроб авторизації або PSU відхилив згоду) — відбувається перехід на крок 20.А альтернативного сценарію якщо кількість невдалих спроб більше 5. |
| 25. Встановити SCA status = finalised | ASPSP встановлює SCA status = finalised. Перехід до кроку 26 основного сценарію. |
| 26. recurringIndicator та попередня згода? | Якщо значення параметра recurringIndicator = false і немає попередньої згоди у статусі = valid — відбувається перехід на крок 27 основного сценарію. Якщо значення параметра recurringIndicator = true або false і є попередня згода у статусі = valid — відбувається перехід на крок 27.А основного сценарію. Примітка: створення разової згоди не обов’язково призводить до відкликання множинної згоди — про свій варіант реалізації ASPSP має зазначити на порталі (див. розділ 5 «Додаткові опції щодо встановлення статусу згоди»). |
| 27. Встановити статус створеної згоди = valid | ASPSP встановлює статус створеної згоди = valid. ASPSP має забезпечити гарантоване встановлення статусу попередньої згоди replasedByTpp. Перехід до кроку 28 основного сценарію. |
| 28. Успішно? | Якщо статус створеної згоди успішно змінений на valid — то відбувається перехід на крок 29 основного сценарію. Якщо ні, спробувати ще (Х разів — ASPSP визначає самостійно) — то відбувається перехід на крок 27 основного сценарію. ASPSP має забезпечити гарантоване встановлення статусу створеної згоди valid. Перехід до кроку 29 основного сценарію. |
| 29. Відобразити користувачу інформацію: успішне підтвердження згоди | ASPSP відображає PSU інформацію про успішну активацію нової створеної згоди. Перехід до кроку 30 основного сценарію. |
| 30. Повернути користувача у платіжний застосунок AISP (крок виконується тільки для Redirect SCA) | ASPSP повертає PSU у платіжний застосунок AISP. URI для повернення PSU ASPSP отримує у запиті на початок авторизації у параметрі Client-Redirect-URI на кроці 9 основного сценарію. Перехід до кроку 31 основного сценарію. |
31. Виклик GET consents/account-access/{consentId} або GET /v2/consents/{consent-category}/{consentId}/status | AISP для отримання статусу новоствореної згоди та попередньої (за наявності) здійснює виклик GET consents/account-access/{consentId} (повертає повну інформацію про згоду) або GET /v2/consents/{consent-category}/{consentId}/status (повертає тільки статус згоди). AISP самостійно вирішує, який із endpoints використовувати. Щоб не створювати ситуацію зайвих численних запитів, яку ASPSP може сприйняти як кіберзагрозу, рекомендовано AISP робити цей виклик при відкритті PSU розділу зі згодами в платіжному застосунку AISP. Дія виконується тільки для Decoupled SCA. Параметри виклику описані у розділі 6. Перехід до кроку 32 основного сценарію. |
| 32. Перевірити — QWAC та відомості в РПІ — request | ASPSP перевіряє: * QWAC та відомості в Реєстрі платіжної інфраструктури (див. розділ 6 Протоколу функцій та заходів безпеки); * request syntax; * semantics; * consentId. Перехід до кроку 33 основного сценарію. |
| 33. ОК? | Якщо перевірки пройдено успішно, відбувається перехід до кроку 34 основного сценарію, у іншому випадку — 34.А альтернативного сценарію. |
| 34. Надіслати OK response (HTTP code = 200) | ASPSP надсилає OK response з HTTP code = 200 відповідно до розділу 6. Перехід до кроку 35 основного сценарію. |
| 35. Оновити статус створеного згоду | AISP по consentId знаходить створену згоду і оновлює її статус, отриманий на кроці 34. Перехід до кроку 36 основного сценарію. |
| Альтернативний сценарій | |
| 4.А. Відобразити інфо про технічну помилку | AISP інформує PSU, що згода не створена. Альтернативний сценарій завершується. |
| 7.А. Надіслати NOK response (HTTP status code не = 201) | ASPSP надсилає NOK response згідно розділу 5 Протоколу функцій та заходів безпеки та Data Dictionary. Перехід на крок 4.А альтернативного сценарію. |
| 13.А. Встановити SCA status = failed | ASPSP встановлює SCA status = failed. Структуру таблиці для збереження SCA status кожен ASPSP визначає самостійно, тому не наводиться у даній специфікації. Перехід на крок 14.А альтернативного сценарію. |
| 14.А. Надіслати NOK response (HTTP status code не = 201) | ASPSP надсилає NOK response згідно розділу 5 Протоколу функцій заходів безпеки та Data Dictionary. Перехід на крок 14.Б альтернативного сценарію. |
| 14.Б. Повторити? | AISP визначає самостійно кількість повторень. Цей крок не є обов’язковим і AISP може не реалізовувати повторення виклику. Якщо кількість повторень виклику POST /v2/{resource-path}/{resourceId}/{authorisation-category} НЕ вичерпана, то здійснюється перехід на крок 9 основного сценарію. Якщо кількість повторень виклику POST /v2/{resource-path}/{resourceId}/{authorisation-category} вичерпана, то альтернативний сценарій завершується. |
| 20.А. Відобразити PSU інформацію про невдале підтвердження згоди | ASPSP відображає PSU інформацію про невдале підтвердження згоди (згода не створена або не пройдений SCA). Для Decoupled SCA відбувається перехід на крок 21.А альтернативного сценарію. Для Redirect SCA відбувається перехід на крок 20.Б альтернативного сценарію. |
| 20.Б. Повернути PSU у платіжний застосунок AISP (крок виконується тільки для Redirect SCA) | ASPSP повертає PSU у платіжний застосунок AISP. За наявності Client-Nok-Redirect-URI повертає PSU у платіжний застосунок AISP. Якщо Client-Nok-Redirect-URI немає, то ASPSP використовує Client-Redirect-URI. Client-Nok-Redirect-URI ASPSP отримує у запиті на початок авторизації на кроці 9 основного сценарію. Перехід на крок 21.А альтернативного сценарію. |
| 20.В. Встановити статус згоди = rejected | ASPSP встановлює статус згоди = rejected. Альтернативний сценарій завершується. |
| 21.А. Встановити SCA status = failed | ASPSP встановлює SCA status = failed. Перехід на крок 20.В альтернативного сценарію. |
| 27.А. Змінити статус попередньої згоди із статусу valid на replasedByTpp | ASPSP встановлює статус для попередньої consent = replasedByTpp. Перехід на крок 27.Б альтернативного сценарію. |
| 27.Б. Успішно? | Якщо статус попередньої згоди успішно змінений — то відбувається перехід на крок 27 основного сценарію. Якщо ні, спробувати ще (кількість разів ASPSP визначає самостійно) — то відбувається перехід на крок 27.А основного сценарію. ASPSP має забезпечити гарантоване встановлення статусу попередньої згоди replasedByTpp. |
| 34.А. Надіслати NOK response (HTTP status code не = 200) | ASPSP надсилає відповідний код помилки відповідно до розділу 5 Протоколу функцій заходів безпеки та Data Dictionary. Перехід на крок 34.Б альтернативного сценарію. |
| 34.Б. Повторити? | AISP визначає самостійно кількість повторень. Цей крок не є обов’язковим і AISP може не реалізовувати повторення виклику. Якщо кількість повторень виклику НЕ вичерпана, то здійснюється перехід на крок 31 основного сценарію. Якщо кількість повторень виклику вичерпана, то альтернативний сценарій завершується. |