Блок-диаграмма обмена сообщениями платежа и аутентификации
Рисунок .17. Блок-диаграмма обмена сообщениями платежа и аутентификации
Допустимые комбинации документального обмена зависят от конкретного типа транзакции IOTP.
Далее рассматриваются методы обработки рабочих ошибок (Business Errors) в процессе документального обмена (смотри раздел 4.2).
9.1.1. Документальный обмен аутентификации
Документальный обмен аутентификации является непосредственной реализацией торгового обмена аутентификации (смотри раздел 2.2.4). Он включает в себя:
o | Аутентификатор организация, которая запрашивает аутентификацию; |
o | Аутентифицируемый - организация, которая должна пройти аутентификацию. |
Аутентификация состоит из:
- Запрос аутентификации, посылаемый аутентификатором аутентифицируемому,
- Отклик аутентификации, посылаемый аутентифицируемым аутентификатору в ответ на запрос. Отклик проверяется аутентификатором, результат этой проверки посылается аутентифицируемому, который из этой статусной информации узнает, прошел он аутентификацию или нет.
Документальный обмен аутентификации предполагает также:
- Предоставление аутентифицируемому компонента Organisation, который описывает аутентификатора и
- Опционно, предоставление аутентификатору компонента Organisation, который описывает аутентифицируемого.
Запрос аутентификации может быть подписан цифровым образом, что позволяет аутентифицируемому, проверить доверительные параметры (credentials) аутентификатора. IOTP-сообщения, которые используются в таком обмене представлены на Рисунок .18.
1. | Первая организация предпринимает некоторое действие (например, нажимает кнопку на HTML-странице), которое требует аутентификации |
1 a 2 |
Необходимость аутентификации (за пределами протокола IOTP) |
2. | Вторая организация генерирует: блок запроса аутентификации, содержащий один или несколько компонентов запроса аутентификации и/или компонент информационного запроса о торговой роли, которые посылаются первой организации |
1 ? 2 |
Запрос TPO & аутентификации. Сообщение IotpMsg: блоки TransRef; Signature (опционно); TPO; запроса аутентификации |
3 | Запускается приложение IOTP. Если присутствует блок Signature, первая организацияможет использовать проверку параметров доверия (credentials) второй организации. Если все в порядке, первая организация выбирает запрос аутентификации (если присутствует или их более одного), и запускает аутентификационный алгоритм для формирования блока отклика аутентификации. Для генерации компонентов Organisation, если требуется, используетсякомпонент запроса данных о торговой роли. Наконец создается, если нужно, компонент Signature и все компоненты посылаются второй организации для проверки. |
1 a 2 | Отклик аутентификации. Сообщение IotpMsg: блоки Trans Ref; Signature (опционно) ; Auth Response |
4. | Вторая организация проверяет отклик Authentication, сопостовляя его с блоком запроса и убеждаясь, что первая организация именно та, за которую она себя выдает. По результатам проверки первой организации посылается статусный блок аутентификации. |
1 ? 2 |
Состояние аутентификации. Сообщение IotpMsg: блоки Trans Ref; Signature (опционно); Auth Response |
5. | Первая организация проверяет статусный блок и, если все в порядке, завершает транзакцию. |