Мета

Цей WS призначений для перевірки підписаного вмісту як частини процесу реєстрації пацієнта довіреною особою, вилучення даних пацієнта, якщо вони дійсні, і створення токену сессії для виконання подальших кроків.

Ключові положення

1. Даний метод має використовуватись тільки фрон-енд частиною Auth

2. Даний метод вимагає довірену особу, яка вже автентифікована

3. Перевірити підписни контент так як і jwt та дані пацієнта в ньому

4. Згенерувати токен сессії (jwt) для підвтердження запиту на реєстрацію

Специфікація

Apiary

Авторизація

• Превірити валідність токену доступу

  • в разі помилки - повернути 401 (“Invalid access token”)

• Перевірити, що токен дійсний

  • в разі помилки - повернути 401 (“Invalid access token”)

• Перевірити скоупи користувача на можливість виконання даної дії (scope = confidant_person:sign_up)

  • повернути 403 (“Your scope does not allow to access this resource. Missing allowances: confidant_person:sign_up”) в разі невалідних скоупів

Перевірити підписаний контент

• Перевірити, що signed_content та signed_content_encoding вказані

  • в разі помилки - повернути 422 ('required property signed_content was not present' or ‘required property signed_content_encoding was not present')

• Перевірити, що підписний контент це валідний base64

  • в разі помилки - повернути 422 ('Invalid signed content')

• Перевірити, що підписаний контекнт закодовано в значенні 'base64'

  • в разі помилки - повернути 422 ('is invalid')

• Перевірити, що цифровий підпис валідний

  • в разі помилки - повернути 400

• Перевірити, що підписант запиту пов'язаний з автентифікованою персоною. Отримати персону з MPI використовуючи x-person-id та впевневшись, що person.tax_id або person.documents відповідають підписанту по drfo (з цифрового підпису)

  • яккщо значення drfo відповідає tax_id з врахуванням regexp (^[0-9]{10}$) - порівняти з person.tax_id

  • якщо значення drfo відповідає номеру national_id з врахуванням regexp (^[0-9]{9}$) - порівняти з документом з типом 'NATIONAL_ID'

  • якщо значення drfo містить хоча б одну літеру, виконати зворотну транслітерацію поля використовуючи існуючий алгоритм (описаний тут), тоді перевірити, що значення рівне номеру паспорту з врахуванням regexp (^((?![ЫЪЭЁ])([А-ЯҐЇІЄ])){2}[0-9]{6}$) - порівняти з документом типу 'PASSPORT'

    • в разі помилки - повернути 401 ('Unable to authenticate signer')

Перевірити запит на реєстрацію персони

• Запит на реєстрацію персони сам по собі має містити дані пацієнта (персони) та деякі обмеження як частину авторизації PIS

• Перевірити дані персони у відповідності Rules to validate patient data | Person with confidant

• Перевірити, що значення поля patient_signed рівне ‘true’

  • в разі помилки - повернути 422 ('value is not allowed in enum')

• Перевірити значення поля process_disclosure_data_consent, що воно рівне ‘true’

  • в разі помилки - повернути 422 ('value is not allowed in enum')

Сервісна логіка

Згенерувати JWT

1. Отримати значення JWT TTL з параметруJWT_LOGIN_TTL (в хвилинах).

2. Декодувати поле signed_content та розрахувати хеш MD5.

3. Згенерувати JWT з наступними параметрами:

   1. alg = HS512

   2. aud = pis-registration

   3. content_hash = хеш MD5 декодований зі значення поля signed_content

   4. exp = iat + JWT_LOGIN_TTL

   5. iat = now()

   6. iss = EHealth

   7. jti = згенерований uuid з JWT

   8. nbf = now() - 1 секунда

   9. sub = content_hash

   10. typ = access

Відобразити дані персони

Відобразити дані персони (пацієнта) у відповідності до специфікації