¶ Описание бизнес-процессов PayControl ГОСТ
¶ Введение
В данной статье описаны возможные реализации пользовательских сценариев для обоих вариантов интеграции PayControl ГОСТ (далее - РС ГОСТ) в процессы Заказчика: в виде отдельного приложения РС ГОСТ и в виде SDK, встраиваемого в Мобильное приложение Заказчика.
Все приведённые ниже сценарии являются базовыми и могут быть доработаны под сценарии и клиентские пути Заказчика в рамках проекта интеграции.
¶ Глоссарий
PayControl ГОСТ (PC ГОСТ) - программный комплекс, предназначенный для подтверждения пользователем различных операций.
PC Server - серверная часть приложения PayControl ГОСТ, обрабатывающая все операции, связанные с регистрацией пользователей и подписанием операций.
Прикладная система - система, интегрируемая с комплексом PayControl ГОСТ.
¶ SDK PayContol ГОСТ
Функциональность SDK РС ГОСТ возможно использовать из экранных форм Мобильного приложения в соответствии с его дизайном.
¶ Подключение пользователей (персонализация)
¶ Онлайн
В данном сценарии предполагается, что у пользователя уже установлено Мобильное приложение Заказчика (далее - МП).
При создании данных для персонализации на серверной стороне РС ГОСТ (далее - PC Server) происходит их шифрование на "секрете" (случайный одноразовый код, идентификатор устройства и т.д.), который будет использован для расшифровки на стороне МП с SDK.
Передача данных для персонализации осуществляется по имеющемуся каналу между МП и Прикладной системой заказчика (под прикладной системой понимается информационная система Заказчика, с которой произведена интеграция PC Server).
После получения МП данных для персонализации и их расшифровки "секретом", на мобильном устройстве происходит генерация открытого и закрытого ключа, а также Пользователю предлагается выбрать один из способов защиты ключей.
Далее PC Server направляет информацию о завершении персонализации в Прикладную систему.
[Опционально] На основе данных пользователя РС ГОСТ, Прикладная система может сформировать документ в бумажном или электронном виде, на основании которого пользователь и оператор прикладная системы признают, что они сформировали и зарегистрировали ключи для формирования/проверки электронной подписи (Акт признания ключа проверки электронной подписи).
Данный документ может быть подтвержден пользователем физически или с использованием другого вида электронной подписи (пример Акта в приложении).
Иные сценарии, доступные к реализации, описаны в разделе Приложение РС ГОСТ → Подключение пользователей.
Схема 1. Онлайн-подключение.
¶ Клиентский путь
Схема 2. Клиентский путь - Онлайн-подключение.
¶ Подтверждение операций
Возможно использование одного сценария или нескольких сценариев сразу.
¶ Подтверждение операции Интернет- и Мобильного Банка
В Интернет-Банке (далее - ИБ) либо приложении Мобильного Банка (далее - МП) формируется запрос на подписание транзакции и направляется в Прикладную систему, где формируется запрос на создание транзакции, направляемый на PC Server.
Опционально: после создания транзакции PC Server либо Прикладная система может сформировать push-уведомление о наличии новой транзакции.
Пользователь переходит по push-уведомлению / открывает Мобильный банк и заходит на страницу подтверждения транзакции.
МП отправляет в PC Server запрос на получение данных о транзакции. Пользователь ознакомляется с деталями транзакции, принимает решение о подтверждении/отклонении, после чего МП запрашивает пароль/Touch ID/Face ID для формирования электронной подписи.
Значение электронной подписи направляется на PC Server, где осуществляется её проверка. После успешного прохождения проверки PC Server направляет в Прикладную систему информацию об успешном подписании/отказе. Оттуда в ИБ либо МП направляется уведомление о подписании / отказе от подписания транзакции.
Схема 3. Подтверждение операции от ИБ/МП.
¶ Клиентский путь
Подтверждение в Мобильном приложении транзакции, созданной в ИБ:
Схема 4. Клиентский путь - Подтверждение операции от ИБ.
Создание и подтверждение транзакции в Мобильном приложении:
Схема 5. Клиентский путь - Подтверждение операции в Мобильном Банке.
¶ Подтверждение операций ИБ в МП (офлайн)
Возможность использования данного режима определяется системой, в которой используется PayControl ГОСТ.
Для подтверждения транзакции ИБ необходимо отразить на странице QR-код для проведения транзакции.
Пользователь с помощью МП сканирует QR-код с информацией о транзакции.
Данные транзакции отображаются в МП для ознакомления Пользователем. После чего Пользователь принимает решение о согласии или отказе в проведении операции.
Затем Пользователю предлагается ввести пароль/Touch ID/Face ID для доступа к ключам.
При правильном вводе данных генерируется код подтверждения операции, который предлагается Пользователю для ввода на странице подтверждения транзакции в ИБ.
Схема 6. Подтверждение операций офлайн.
¶ Клиентский путь
Схема 7. Клиентский путь - Подтверждение операции в офлайн-режиме.
¶ Приложение PayControl ГОСТ
¶ Подключение пользователей (персонализация)
Возможно использование одного сценария или нескольких сценариев сразу.
¶ По QR-коду
В данном сценарии Пользователю необходимо передать формируемый PC Server QR-код, в котором содержатся данные для персонализации устройства Пользователя. Передачу QR-кода необходимо осуществлять по доверенному каналу (например, в ПИН-конверте или на экране рабочего места операциониста).
Пользователь сканирует QR-код с помощью приложения, таким образом получая данные для персонализации. После этого на мобильном устройстве происходит генерация открытого и закрытого ключа. Также Пользователю предлагается выбрать один из способов защиты ключей (перечень вариантов зависит от настроек системы, которой используется приложение PayControl ГОСТ, и возможностей устройства): без пароля, пароль, Touch ID, Face ID.
Далее PC Server направляет информацию о завершении персонализации в Прикладную систему.
Опционально: Прикладная система может сформировать документ в бумажном или электронном виде, на основании которого пользователь и оператор Прикладной системы признают, что они сформировали и зарегистрировали ключи для формирования/проверки подтверждения (Акт признания ключа проверки электронной подписи).
Данный документ может быть подтвержден пользователем физически или с использованием другого вида электронной подписи (пример Акта в приложении).
Схема 8. Подключение по QR-Коду.
¶ Клиентский путь
Ниже представлен процесс, проходимый пользователем для создания ключей, на примере варианта внедрения с отдельным приложением PayControl ГОСТ.
Схема 9. Клиентский путь - Подключение по QR-Коду.
¶ QR-коду + коду активации
После отправления Прикладной системой запроса на PC Server о создании пользователя, PC Server возвращает данные для персонализации двумя частями: QR-код и код активации.
QR-код и код активации должны быть переданы Пользователю по разным каналам, например: QR-код можно отобразить в интерфейсе Прикладной системы, отправить по электронной почте, передать Пользователю физически в ПИН-конверте, а код активации — по SMS, электронной почте, в ПИН-конверте, IVR.
Пользователь сканирует QR-код с помощью приложения и вводит код активации, таким образом получая данные для персонализации. После этого на мобильном устройстве происходит генерация открытого и закрытого ключа, а также Пользователю предлагается выбрать один из способов защиты ключей (перечень вариантов зависит от настроек системы, которой используется приложение PayControl ГОСТ, и возможностей устройства): без пароля, пароль, Touch ID, Face ID.
Далее PC Server направляет информацию о завершении персонализации в Прикладную систему.
Опционально: Прикладная система может сформировать документ в бумажном или электронном виде, на основании которого пользователь и оператор Прикладной системы признают, что они сформировали и зарегистрировали ключи для формирования/проверки подтверждения (Акт признания ключа проверки электронной подписи).
Данный документ может быть подтвержден пользователем физически или с использованием другого вида электронной подписи (пример Акта в приложении).
Схема 10. Подключение по QR-Коду и коду активации.
¶ Клиентский путь
Схема 11. Клиентский путь - Подключение по QR-Коду и коду активации.
¶ Deep Link
После отправки Прикладной системой запроса на создание пользователя PC Server генерирует Deep Link для персонализации. Пользователь нажимает на ссылку и автоматически переходит в мобильное приложение, получая данные для персонализации.
После чего на мобильном устройстве происходит генерация открытого и закрытого ключа, а также Пользователю предлагается выбрать один из способов защиты ключей (перечень вариантов зависит от настроек системы, которой используется приложение PayControl ГОСТ, и возможностей устройства): без пароля, пароль, Touch ID, Face ID.
PC Server направляет информацию о завершении персонализации в Прикладную систему.
Прикладная система может сформировать документ в бумажном или электронном виде, на основании которого пользователь и оператор Прикладной системы признают, что они сформировали и зарегистрировали ключи для формирования/проверки подтверждения (Акт признания ключа проверки электронной подписи).
Данный документ может быть подтвержден пользователем физически или с использованием другого вида электронной подписи (пример Акта в приложении).
Схема 12. Подключение по Deep Link.
¶ Клиентский путь
Схема 13. Клиентский путь - Подключение по Deep Link.
¶ Deep Link + код активации
После отправки Прикладной системой запроса на создание пользователя PC Server генерирует Deep Link для персонализации. Пользователь нажимает на ссылку и автоматически переходит в мобильное приложение, получая данные для персонализации.
Далее Пользователь вводит код активации в мобильном приложении для получения оставшихся данных для персонализации.
После чего на мобильном устройстве происходит генерация открытого и закрытого ключа, а также Пользователю предлагается выбрать один из способов защиты ключей (перечень вариантов зависит от настроек системы, которой используется приложение PayControl ГОСТ, и возможностей устройства): без пароля, пароль, Touch ID, Face ID.
Далее PC Server направляет информацию о завершении персонализации в Прикладную систему.
Прикладная система может сформировать документ в бумажном или электронном виде, на основании которого пользователь и оператор Прикладной системы признают, что они сформировали и зарегистрировали ключи для формирования/проверки подтверждения (Акт признания ключа проверки электронной подписи).
Данный документ может быть подтвержден пользователем физически или с использованием другого вида электронной подписи (пример Акта в приложении).
Схема 14. Подключение по Deep Link и коду активации.
¶ Клиентский путь
Схема 15. Клиентский путь - Подключение по Deep Link и коду активации.
¶ Подтверждение операций
¶ Подтверждение операции через мобильное приложение PayControl ГОСТ
Процесс подтверждения операций имеет общий вид:
-
На стороне Прикладной системы имеется операция, требующая подтверждения Пользователя. Запрос направляется на PC Server.
-
На смартфон Пользователя приходит push-уведомления (опционально) о наличии операции, требующей подписание.
-
По запросу приложения PC Server направляет информацию о наличии операции на подписание в Мобильное приложение.
-
Пользователь переходит в Мобильное приложение, где знакомится с данными операции и принимает решение о подтверждении/отклонении операции нажатием соответствующей кнопки «Подтвердить» или «Х».
-
Пользователю предлагается ввести пароль/Touch ID/Face ID для доступа к ключам.
-
При правильном введении данных происходит подтверждение транзакции.
-
В Прикладную систему отправляется информация о подтверждении.
Схема 16. Подтверждение операции.
¶ Клиентский путь
Схема 17. Клиентский путь - Подтверждение операции.
¶ Видеодемонстрация сценария
¶ Дополнительные возможности
¶ Аутентификация по QR-коду
Сценарий аутентификации по QR-коду является еще одним способом входа в систему по логину и паролю. Данным сценарием можно либо заменить, либо дополнить процесс. При его использовании необходима доработка веб-интерфейса Интернет-банка (далее - ИБ) с добавлением на экран ввода логина и пароля QR-кода.
При его реализации на экране входа в систему Пользователю необходимо продемонстрировать QR-код для считывания Мобильным приложением PayControl ГОСТ (МП Банка, интегрированного с SDK PayControl ГОСТ). В мобильном приложении Пользователь может ознакомиться с реквизитами входа в систему.
При подтверждении входа запрашивается пароль/Touch ID/Face ID для доступа к ключам, заданным в процессе персонализации.
При условии правильного ввода пароля или биометрических данных в интерфейсе, Пользователь автоматически перейдет в авторизованную зону.
Схема 18. Аутентификация по QR-Коду.
¶ Клиентский путь
Схема 19. Клиентский путь - Аутентификация по QR-Коду.
¶ Видеодемонстрация сценария
¶ Интерактивные push-уведомления
Подтверждение операции в приложении PayControl ГОСТ возможно также из интерфейса push-уведомления.
После создания операции, требующей подтверждения, на мобильное устройство будет направлено push-уведомление.
Пользователь может ознакомиться с содержанием информации о транзакции, представленной в уведомлении.
Принимает решение о подписании и нажимает кнопку «Подтвердить» или «Отклонить».
В случае, если для ключей задан способ защиты «без пароля», операция будет подтверждена, а в интерфейсе push-уведомления отобразится информация об успешном подтверждении операции.
В случае выбора другого способа защиты ключей, подтверждение операции будет продолжено в приложении PayControl ГОСТ.
¶ Клиентский путь
Схема 20. Клиентский путь - Подтверждение операции через интерактивное push-уведомление.
¶ Подтверждение операций в 3DS
Для выполнения сценария «Подтверждение операций в 3D-Secure» необходимо отображение информации о подтверждении операции с помощью приложения PayControl ГОСТ на странице 3D-Secure, а также в случае выполнения сценария в офлайн-режиме - отображение окна ввода кода подтверждения, сгенерированного приложением PayControl ГОСТ.
3D-Secure направляет запрос на PC Server на подтверждение транзакции. После чего PC Server направляет на мобильное устройство push-уведомление о наличии транзакции для подписания.
Пользователь заходит в мобильное приложение и просматривает данные транзакции, после чего принимает решение о подписании документа, подтверждая своё решение нажатием соответствующей кнопки «Подтвердить» или «Х».
При нажатии кнопки «Подтвердить» у Пользователя запрашивается пароль/Touch ID/Face ID для доступа к ключам электронной подписи.
Результат электронной подписи направляется на PC Server, где осуществляется её проверка. После успешного прохождения проверки PC Server направляет в 3D-Secure информацию об успешном подписании.
На экране 3D-Secure отображается информация о совершении или отмене операции.
Схема 21. Подтверждение в 3DS.
¶ Клиентский путь
Схема 22. Клиентский путь - Подтверждение в 3DS.
¶ АТМ
¶ Аутентификация в АТМ по QR-коду
Для входа в личный кабинет Пользователя в системе АТМ на экране АТМ необходимо продемонстрировать QR-код, после сканирования которого будет осуществлён вход в личный кабинет без карты.
Пользователь сканирует QR-код, представленный на экране АТМ, с помощью мобильного приложения PayControl ГОСТ (приложения МБ, интегрированного с SDK). При подтверждении/отказе от входа приложение запрашивает доступ к ключам. Пользователь вводит пароль/Face ID /Touch ID.
В интерфейсе АТМ произойдёт автоматическое перенаправление в авторизованную зону, где Пользователю будет доступно меню с доступными для проведения операциями.
Схема 23. Аутентификация в ATM.
¶ Клиентский путь
Схема 24. Клиентский путь - Аутентификация в ATM.
¶ Видеодемонстрация сценария
¶ Подтверждение операций в ATM
При желании совершить операцию с помощью АТМ после аутентификации, Пользователь вводит все необходимые данные для её проведения. После чего на мобильное устройство Пользователя с приложением PayControl ГОСТ приходит push-уведомление о наличии транзакции.
Пользователь знакомится с данными транзакции и принимает решении о её подтверждении или отмене. После нажатия на соответствующую кнопку, Пользователю необходимо ввести пароль или использовать способ доступа к ключам, заданный в процессе персонализации.
Транзакция успешно подписывается, и PC Server передаёт данную информацию в Прикладную систему оператора АТМ.
Схема 25. Подтверждение операции в ATM.
¶ Клиентский путь
Схема 26. Клиентский путь - Подтверждение операции в ATM.
¶ Видеодемонстрация сценария
¶ Приложение
¶ Акт признания открытого ключа
Рисунок 1. Акт признания открытого ключа ЭП.