Документальный обмен аутентификации

Рисунок .18. Документальный обмен аутентификации

9.1.1.1. Принципы обработки сообщений

При получении ссобщения-запроса TPO & Authentication (смотри ниже), аутентифицируемый может:

сформировать и послать аутентификатору сообщение-отклик аутентификации или
обнаружив ошибку в запросе аутентификации, послать аутентификатору блок Cancel, содержащий компонент Status аутентификации с атрибутом StatusType и/или ProcessState = Failed и кодом CompletionCode (смотри раздел 7.16.4) равным: AutEeCancel, NoAuthReq, TradRolesIncon или Unspecified.

Получив сообщение-отклик Authentication (смотри ниже), аутентификатор должен в ответ послать сообщение состояния аутентификации, содержащее блок Status с компонентом Status, где StatusType = Authentication и:

атрибут ProcessState компонента Status = CompletedOk, в случае успешного завершения проверки, или
атрибут ProcessState = Failed, а атрибут CompletionCode =: AutOrCancel, AuthFailed или Unspecified, в случае неудачи аутентификации,

Получив сообщение состояния аутентификации (смотри ниже), аутентифицируемый должен проверить компонент Status в блоке состояния. Если он указывает на:

o	успех аутентификации, тогда аутентифицируемый должен сделать следующее:
-	продолжить следующий шаг транзакции, частью которой является документальный обмен аутентификации, или
-	индицировать отказ продолжения транзакции путем посылки аутентификатору блока Cancel, содержащего компонент Status с атрибутом аутентификации StatusType, ProcessState = Failed и кодом CompletionCode (смотри раздел 7.16.4) = AutEeCancel.
o	аутентификация не прошла, тогда аутентифицируемый должен быть оповещен о неудаче, а процесс остановлен.

Если аутентификатор получает от Покупателя сообщение IOTP, содержащее блок Cancel, тогда аутентифицируемый может обратиться к сетевому узлу CancelNetLocn, специифицированному элементом торговой роли в компоненте Organisation для аутентификатора, указанного в блоке опций торгового протокола.

9.1.1.2. Сообщение запроса аутентификации и TPO

Помимо блока ссылок транзакции (смотри раздел 3.3), это сообщение содержит в себе:

блок опций торгового протокола (смотри раздел 8.1),
блок запроса Authentication (смотри раздел 8.4) и
опционный блок Signature (смотри раздел 8.16).

Каждый из них описан ниже.

Блок опций торгового протокола

Блок опций торгового протокола (смотри раздел 8.1) должен содержать следующие торговые компоненты:

один компонент протокольных опций (смотри раздел 7.1), который определяет опции, работающие для всего документального обмена аутентификации.
один компонент Organisation (смотри раздел 7.6), который описываетаутентификатор. Компонент торговой роли организации должен указывать на роль, какую играет аутентификатор в данной сделке, например Пордавец или Покупатель.

Блок запроса аутентификации

Блок запроса аутентификации (смотри раздел 8.4) должен содержать следующие торговые компоненты:

один компонент запроса аутентификации (смотри раздел 7.2), и

Блок подписи (Запрос аутентификации)

Если запрос аутентификации был снабжен цифровой подписью, то должен быть включен блок Signature. Он содержит дайджесты следующих XML-элементов:

o	блок ссылок транзакции (смотри раздел 3.3) для сообщения IOTP, которое содержит информацию, описывающую сообщение и транзакцию;
o	Id-компонент транзакции (смотри раздел 3.3.1), который однозначно идентифицирует транзакцию IOTP;
o	следующие компоненты блока TPO:
	- компонент протокольных опций;
	- компонент Organisation.

следующие компоненты блока запроса аутентификации:

	- компонент запроса аутентификации
	- компонент информационного запроса о торговой роли

9.1.1.3. Сообщение-отклик аутентификации IOTP

Помимо блока ссылок транзакции (смотри раздел 3.3), это сообщение содержит в себе:

блок отклика Authentication (смотри раздел 8.5) и
опционный блок Signature (смотри раздел 8.16).

Блок отклика AUTHENTICATION
Блок отклика аутентификации должен содержать следующие торговые компоненты:

один компонент отклика аутентификации (смотри раздел 7.3)
один компонент Organisation для каждой торговой роли, идентифицированной в атрибуте TradingRoleList компонента информационного запроса о торговой роли, содержащегося в блоке запроса аутентификации.

Блок SIGNATURE (Отклик аутентификации)

Если элемент Algorithm ( смотри раздел 12) компонента запроса аутентификации содержащийся в блоке запроса аутентификации, указывает, что отклик аутентификации должен содержать цифровую подпись, тогда блок Signature должен быть включен в то же сообщение, где размещается блок отклика аутентификации. Компонент Signature содержит элементы дайджестов для следующиз XML-элементов:

блок ссылок транзакции (смотри раздел 3.3) для сообщения IOTP, которое содержит информацию, описывающую сообщение и транзакцию IOTP;
Id-компонент транзакции (смотри раздел 3.3.1), который однозначно идентифицирует транзакцию IOTP;
следующие компоненты блока запроса аутентификации:

	- компонент запроса аутентификации;
	- компонент информационного запроса о торговой роли;

компоненты Organisation, содержащиеся в блоке отклика аутентификации.

Не следует предполагать, что все торговые роли могут поддерживать цифровую подпись данных. В частности не нужно думать, что эта опция поддерживается Покупателем.

9.1.1.4. Сообщение состояния аутентификации

Помимо блока ссылок транзакции (смотри раздел 3.3), это сообщение содержит в себе:

блок состояния аутентификации (смотри раздел 8.5) и
опционный блок Signature (смотри раздел 8.16).

Блок состоояния аутентификации

Блок состоояния аутентификации (смотри раздел 8.6) должен содержать следующие торговые компоненты:

один компонент Status (смотри раздел 7.16) с атрибутом ProcessState = CompletedOk.

Блок SIGNATURE (состояние аутентификации)

Если блок состояния аутентификации подписан цифровым образом, тогда блок Signature должен включать то что содержать дайджесты следующих XML-элементов:

блок ссылок транзакции (смотри раздел 3.3) для сообщения, которое содержит информацию, описывающую сообщение IOTP и транзакцию;
Id-компонент транзакции (смотри раздел 3.3.1), который однозначно идентифицирует транзакцию IOTP;
Следующие компоненты блока состояния аутентификации:

- компонент Status (смотри раздел 7.16).

Если за документальным обменом аутентификации следует документальный обмен предложения (Offer) (смотри раздел 9.1.2), тогда блок состояния аутентификации и блок подписи (состояние аутентификации) могут объединяться с:

сообщение TPO (смотри раздел 9.1.2.3), или
сообщение TPO и отклик Offer (смотри раздел 9.1.2.6)

9.1.2. Обмен документами предложения

Обмен документами предложения oвстречается в двух формах:

обмен предложения, зависящего от вида платежа. Где содержимое предложения, напр., детали заказа, сумма, детали доставки, и т.д., зависят от вида платежа и протокола, выбранных покупателем;

обмен предложения, не зависящего от вида платежа. Где содержимое предложения не зависит от выбранного вида платежа или протокола.

Каждый из этих типов документального обмена предложения может следовать за бокументальным обменом аутентификации (смотри раздел 9.1.1).

9.1.2.1. Документальный обмен предложения, зависящего от вида платежа

В документальном обмене предложения, зависящего от вида платежа блоки TPO отклика Offer посылаются отдельно продавцом покупателю, т.e.:

комонент списка вида платежа посылается покупателю в блоке TPO;
Покупатель выбирает вид платежа, платежный протокол и опционно вид валюты из компонента видов платежа;
Покупатель посылает выбранные вид платежа, протокол и валюту продавцу в блоке выбора TPO;
Продавец использует полученную информацию, чтобы определить содержимое и затем послать блок отклика Offer покупателю.

Это проиллюстрировано на диаграмме ниже (Рисунок .19).

1.	Покупатель решает совершить покупку и посылает продавцу информацию (напр., используя HTML), которая позволяет продавцу сформировать предложение,
C a M	Информация предложения – вне области действия IOTP
2.	Продавец решает, какой платежный протокол, валюту и пр. использовать, помещает эти данные в компонент видов платежа в блоке TPO и посылает покупателю
C ? M	TPO (опции торгового протокола). IotpMsg: блоки Trans Ref Block; TPO
3.	Приложение IOTP запущено. покупатель выбирает вид платежа, платежный протоколи вид валюты. Компонент выбора вида платежа посылается Продавцу.
C a M	Выбор TPO. IotpMsg: блоки Trans Ref Block и выбора TPO
4.	Продавец использует выбранный вид платежа, плптежный протокол, валюту и информацию предложения для формирования блока отклика Offer, содержащего детали транзакции IOTP, включая цену, и т.д., опционно подписывает его и посылает покупателю
C ? M	Отклик OFFER. IotpMsg: блоки Trans Ref, Signature (опционный) и отклика Offer
5.	Покупатель проверяет все ли в порядке в Offer, затем комбинирует компоненты из блоков TPO, выбора TPO и отклика Offer, чтобы сформировать следующее сообщение транзакции, и посылает его вместе с блоком подписи (если таковая нужна) соответствующей торговой роли

… продолжение ...

Содержание раздела