1.1. Коммерция в Интернет

Рост Интернет и прогресс в электронной коммерции привносят огромные изменения в сферу бизнеса, политики, управления и в само общество. Методы, которые используются партнерами в торговле, обогатились и необратимо изменились. Наиболее заметные изменения характера торговли включают в себя:

• Присутствие. Операции, требующие личного контакта, становятся исключением, а не правилом. Этот процесс начался при внедрении торговли по почте и по телефону. Электронная коммерция через Интернет еще шире раздвигает область и объем операций, проводимых без личного контакта участников сделок.
• Аутентификация. Важной частью личного присутствия является возможность партнеров использование знакомых объектов и диалога для подтверждения того, кем они являются. Продавец демонстрирует различными способами свою способность производить кредитные и платежные операции. Покупатель предъявляет физические свидетельства своей платежеспособности, полученные от государства или финансовой организации. При этом учитывается разнообразная объективная информация: местоположение магазина, внешность, знакомство и поведение участников, знакомство с данной фирмой и ее торговым знаком.
• Инструменты платежа. Несмотря на широкое рзвитие безналичных платежей, заметная часть торговых операций обеспечивается наличными деньгами или даже бартером. Существующая инфраструктура платежной системы по экономическим соображениям не может поддерживать операции с низкими суммами платежей, но и не может от них отказаться.
• Стоимость операций. Новое значение низкой стоимости операции в Интернет связано с возможностью того, что продавец может предложить, например, объекты с ценой, составляющей долю денежной единицы, которой не существует в реальности.
• Доставка. Внедряются новые методы доставки, включая доставку по сети, например, информации или программных продуктов. Возможна доставка по частям при играх, просмотре, прослушивании и некоторых других виртуальных услугах, при этом она должна быть подтверждена до осуществления платежа. Логично, что деньги в этом случае не могут быть возвращены.

1.2. Преимущества IOTP

Разработки программ для электронной коммерции будут более привлекательны, если они окажутся совместимыми для разных разработчиков. Однако IOTP призван, прежде всего, решить проблему коммуникаций между различными решениями.

Виды платежей

IOTP предлагает стандартные рамки для инкапсуляции платежных протоколов. Это означает, что средства платежей смогут лучше взаимодействовать, если они встроены в программы, следующие протоколу IOTP. В результате базовые виды электронных платежей смогут найти более широкое распространение на большем разнообразии рабочих платформ.

Продавцы

Существует несколько преимуществ для торговцев:

• Они смогут предложить более широкий перечень видов платежей,
• Они смогут быть более уверены, что покупатель будет иметь программу, необходимую для осуществления покупки
• При получении платежа и расписки от покупателя о получении товара или услуги они смогут обеспечить клиента гарантией, что он имел дело именно с тем человеком или организацией
• новые торговцы смогут вступить в этот Интернет-рынок с новыми продуктами и услугами, используя новые возможности, предоставляемые IOTP.

Банки и финансовые организации

Существует несколько преимуществ для банков и финансовых организаций:

• они смогут предоставить услуги IOTP для торговцев
• они найдут новые возможности для реализации услуг, сопряженных с IOTP:

1. предоставление услуг клиентам продавцов
2. деньги от обработки новых платежей и депозитов

• они имеют возможность построить отношения с новыми продавцами

Покупатели

Для покупателей также имеется несколько преимуществ:

• они получат больший выбор продавцов, с которыми смогут иметь дело
• имеется более удобный интерфейс для осуществления покупки
• существуют возможности уладить их проблемы через продавца (а не через банк)
• существует запись их операций, которая может использоваться, например, налоговыми службами

1.3. Основы IOTP

Протокол описывает содержимое, формат и последовательность сообщений, которые пересылаются между партнерами электронной торговли - покупателями, торговцами и банками или финансовыми организациями.

Протокол спроектирован так, чтобы обеспечить его применимость при любых схемах электронных платежей, так как он реализует весь процесс продажи, где передача денег всего лишь один шаг из многих.

Схемы платежей которые поддерживает IOTP включают MasterCard Credit, Visa Credit, Mondex Cash, Visa Cash, GeldKarte, eCash, CyberCoin, Millicent, Proton и т.д..

Каждая схема содержит некоторый обмен сообщениями, который является характерным именно для нее. Эти схемно-зависимые части протокола помещены в приложения к данному документу.

Документ не предписывает участникам, какое следует использовать программное обеспечение или процесс. Он определяет только необходимые рамки в пределах которых реализуется торговая операция.

2. Введение

Открытый торговый протокол Интернет определяет некоторое число различных операций IOTP:

• Покупка. Осуществляет предложение, оплату и опционно доставку.
• Возврат. Производит возврат платежа для покупки, выполненной ранее.
• Обмен ценностями. Включает в себя два платежа, наприммер в случае обмена валют.
• Аутентификация. Производит проверку для организации или частного лица - являются ли они тем, за кого себя выдают.
• Отзыв платежа. Осуществляет отзыв электронного платежа из финансового учрежденрия.
• Депозит. Реализует депозит средств в финансовом учреждении.
• Запрос. Выполняет запрос состояния операции IOTP, которая находится в процессе реализации, или уже выполнена.
• Пинг. Простой запрос одного приложения IOTP с целью проверки, функционирует ли другое приложение IOTP.

Эти операции считаются базовыми, позднее могут быть определены другие операции IOTP. Каждая из перечисленных выше операций IOTP включает в себя:

• Некоторое число организаций, выполняющих торговую функцию и
• Набор торговых обменов. Каждый торговый обмен включает в себя обмен данными между торговыми ролями в форме набора торговых компонентов.

2.1. Торговые роли

Торговые роли идентифицируют различные обязанности, которые может выполнять организации в процессе торговли. В IOTP используется пять торговых ролей, которые проиллюстрированы на рис. 1.

Рис. 1. Торговые роли в IOTP

Определены следующие роли:

• Покупатель. Человек (или организация), который получает товар или услугу и платит за это.
• Продавец. Человек (или организация), у которого приобретается а, выполненного потребителем. товар или услуга, который оффициально ответственнен за их предоставление и кто извлекает выгоду в результате платеж.
• Оператор платежей. Субъект, который получает платеж от потребителя в пользу торговой фирмы или физического лица.
• Оператор доставки. Субъект, который доставляет товар или предоставляет услугу потребителю от торговой фирмы или лица.
• Лицо или фирма обслуживающая клиента торговой фирмы. Субъект, который вовлечен в обслуживание клиента торговой фирмы.

Роли могут выполняться одной организацией или различными организациями. Например:

• В простейшем случае одна организация (напр., продавец) может оформлять покупку, принимать платеж, доставлять товар и осуществлять обслуживание покупателя.
• В крайнем случае, продавец может оформить покупку, но предложить покупателю осуществить платеж в банке, попросить доставить товар специальную фирму, выполняющую доставк, и обратиться к третей фирме, обеспечивающей круглосуточное обслуживание, с просьбой помочь покупателю в случае возникновения каких-то непредвиденных проблем.

Заметим, что в этой спецификации, если не указано обратного, когда используются слова Покупатель (Consumer), Продавец (Merchant), Кассир (Payment Handler), Агент доставки (Delivery Handler) или обслуживание потребителя (Customer Care Provider), подрузамевается торговая роль (Trading Role), а не конкретная организация.

Любая конкретная организация может выполнять множество ролей. Например компания, которая продает товары или услуги через Интернет, может выполнять роь продавца при продаже товара или услуги и роль потребителя, когда компания покупает товары или услуги сама.

2.2. Торговый обмен

Протокол Интернет для торговли (The Internet Open Trading Protocols) идентифицируют четыре торговых обмена, которые включают обмен данными между торговыми ролями. Среди них:

• Предложение. Обмен предложения (Offer Exchange) предполагает, что продавец предоставляет покупателю причины, почему сделка должна иметь место. Такой обмен называется предложением, если сделка может состояться.
• Оплата. Платежный обмен (Payment Exchange) предполагает осуществление какого-то платежа между потребителем и кассиром. Направление платежа может быть любым.
• Доставка. Процедура доставки (Delivery Exchange) сопряжена с передачей товаров или доставкой информации о товарах агентом доставки Потребителю.
• Аутентификация. Аутентификационный обмен (Authentication Exchange) может использоваться любой из тоговых ролей для аутентификации другой торговой роли и выяснения является ли субъект тем, за кого он себя выдает.

Операции IOTP состоят из различных комбинаций этих торговых обменов. Например, операция покупки IOTP включает в себя обмены Предложения, Оплаты и Доставки. А операция обмена ценностями IOTP состоит из предложения и двух обменов оплаты.

Торговые обмены (Trading Exchanges) состоят из торговых компонентов, которые передаются между различными торговыми ролями. Где возможно, число круговых задержек в операциях IOTP минимизируется путем объединения компонентов нескольких торговых обменов в комбинированные сообщения IOTP. Например, операция покупки IOTP объединяет компонент организации доставки и компонент предложения, для того чтобы избежать лишних запросов и откликов Потребителя.

Ниже каждый торговый обмен IOTP описан более детально. Для простоты описания они рассматриваются как независимые процедуры.

2.2.1. Предложение

Целью обмена Предложения является обеспечение Покупателя информацией о сделке с тем чтобы он мог решить, продолжать ли ему эту сделку. Это продемонстрировано ниже на рис. 2.

Рис. 2. Предложение

Предложение использует следующие торговые компоненты, которые пересылается между покупателем и продавцом.

• Компонет статус используется для сообщения партнеру что сформирован корректный отзыв-предложение.
• Компоненты Организации содержит информацию, которая описывает организации, исполняющие определенные торговые роли в данной сделке.

Точное содержание информации, выданной Продавцом Покупателю, варьируется в зависимости от типа операции IOTP. Например:

• низкая стоимость сделки может не требовать подписи
• сумма оплаты может варьироваться в зависимости от фирмы и используемого протокола оплаты
• некоторые предложения могут не включать в себя доставку товара
• обмен ценностями включает два платежа
• продавец может не предлагать покупателю каких-либо услуг.

Информация, предоставляемая покупателем продавцу, предоставляется различными способами, например, она может быть получена.

• Используя [HTML] страницы, как часть "практики" покупателей.
• Используя стандарт OPS (Open Profiling Standard), который был недавно предложен,
• В форме компонентов Организации, ассоциирующихся с аутентификацией Покупателя Продавцом.
• Как компоненты Заказа в последней версии IOTP.

2.2.2. Платежный обмен

Целью платежного обмена (Payment Exchange) является оплата, производимая покупателем кассиру или наоборот, используя вид и протокол платежа, выбранные покупателем. Второй целью является опционное обеспечение покупателя платежной распиской (Payment Receipt), которая может использоваться для связи платежа с его причиной, как это описано в обмене предложения (Offer Exchange).

Обмены платежа могут реализовываться различными способами. Наиболее общий случай, где сделка зависит от типа и платежного протокола, показан на диаграмме рис. 3. Возможны и более простые платежные обмены.

Рис. 3. Платежный обмен

Платежный обмен использует следующие торговые компоненты, которыми обмениваются покупатель, продавец и кассир:

• Компонент списка типов платежей содержит перечень допустимых видов платежа (например, MasterCard, Visa, Mondex, GeldKarte), платежные протоколы (например, SET Version 1.0, SCCD (Secure Channel Credit Debit - имя, используемое для платежей через кредитные карточки, где неавторизованный доступ блокируется с помощью механизма формирования безопасного транспортного канала, такого как SSL/TLS), а также сумма и вид валюты. Продавец посылает список типов платежей покупателю. Покупатель сравнивает типы платежей, протоколы, тип валюты и сумму со своими возможностями и делает выбор.
• Компонент выбора типа платежа содержит выбор покупателя. Тип платежа, протокол, вид валюты, сумма и возможно протокольно зависимая информация посылается продавцу. Эта информация используется для модификации данных предложения (Offer Exchange). Например, продавец может предложить скидку, с тем, чтобы стимулировать использование карточки накопления (store card).
• Компонент Статус используется, чтобы проинформировать кассира, что обмен предложения успешно завершился, и кассиром для сообщения о благополучном завершении платежного обмена.
• Компоненты Организаций генерируются Продавцом. Они содержат детали ролей Продавца и Кассира:

• Компонент платеж содержит данные о сумме платежа, валюте и направлении оплаты (кто кому).
• Компонент подпись "Offer Response", если присутствует, цифровым образом подтверждает целостность и корректность всех остальных компонентов. Заметим, что компоненты списка типов платежа (Brand List) и выбор типа платежа (Brand Selection) не подписываются до тех пор, пока платежные данные не сформированы (шаг 4 на диаграмме).
• Компонент данные о торговых ролях (Trading Role Data) содержит информацию о других ролях (например, продавца), о которых нужно проинформировать кассира.
• Компонент схема платежа (Payment Scheme) содержит сообщения платежного протокола, используемого при сделке. Например, это могут быть сообщения SET, сообщения Mondex, сообщения GeldKarte или какого-то другого метода платежа, поддерживаемого IOTP. Содержимое компонента схема платежа (Payment Scheme) определено в приложениях, которые описывают то, как работает IOTP с различными платежными протоколами.
• Компонент платежной расписки (Payment Receipt) содержит запись о платеже. Содержимое зависит от используемого платежного протокола.
• Компонент подпись платежной расписки (Payment Receipt) предоставляет подтверждение корректности платежа путем цифровой подписи компонентов платежной расписки и подписи отклика-предложения. Подпись предложения гарантирует целостность и корректность компонентов заказа, организаций, и доставки, содержащихся в предложении. Эта подпись соединяет платеж и предложение.

Пример платежного обмена представленного выше, является наиболее общим случаем. Возможны и более простые варианты. Например, если сумма платежа не зависит от выбранного типа платежа и платежного протокола, тогда информация, генерируемая на этапе 3, может быть послана покупателю одновременно с формированием компонента список типов платежей (Brand List) на этапе 1. Эти и другие вариации описаны в разделе базовые торговые операции IOTP (смотри раздел 9.1.8).

2.2.3. Обмен доставки

Целью обмена доставки является обеспечить физическую или сетевую доставку купленного товара или услуги покупателю. Второй целью служит передача покупателю “декларации о доставке”, предоставляя дополнительную информацию о доставке, такую как номера накладной или номер трайлера, с помощью которого будет доставлен груз. Результат доставки может быть также подтвержден с помощью электронной подписи. Обмен сообщениями показан на диаграмме ниже.

Рис. 4. Обмен доставки

Обмен доставки использует следующие торговые компоненты, которыми обмениваются покупатель, продавец и агент доставки:

• Компонент Статус используется для указания агенту доставки, что предыдущий обмен (например, обмен предложения или платежный обмен) успешно завершился, а агентом доставки для индикации завершения обмена доставки.
• Компоненты организации содержат информацию об адресе доставки и ролях агента доставки и продавца:

• Компонент заказа содержит информацию о товарах или услугах, которые должны быть доставлены.
• Компонент доставки содержит информацию о том, как будет осуществлена доставка, например по почте или с помощью e-mail.
• Компонент подписи предложения-отклика (Offer Response), если присутствует, электронным образом подписывает все перечисленные выше компоненты, обеспечивая их целостность.
• Компонент подпись платежной расписки (Payment Receipt) предоставляет подтверждение платежа, с помощью электронной подписи компонента платежной расписки и предложения. Это используется агентом доставки для проверки того, что доставка авторизована.
• Компонент накладной (Delivery Note) содержит информацию об обслуживании покупателя, относящуюся к доставке. Программа покупателя не интерпретирует информацию о доставке, но должна быть способна отобразить эту информацию, как в момент доставки, так и позднее, если покупатель выбирает из списка операций сделку, к которой относится данная доставка.
• Компонент подпись отклика доставки (Delivery Response), если присутствует, предоставляет подтверждение результатов доставки путем электронной подписи накладной (Delivery Note) и подписей любого отклика-предложения или отклика платежа, которые получил агент доставки.

2.2.4. Аутентификационный обмен

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

В аутентификационный обмен вовлечены:

• Аутентификатор - организация, запрашивающая аутентификацию и
• Аутентифицируемый - организация, которая должна быть аутентифицирована.
>

Это проиллюстрировано на диаграмме ниже.

Рис. 5. Обмен аутентификации

Обмен аутентификации использует следующие торговые компоненты, которыми обмениваются между собой две организации:

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

2.3. Обзор базового уровня IOTP

Здесь описываются операции, которые образуют основу IOTP. Главными факторами, определяющими реализацию IOTP, являются роли, которые поддерживает реализованное решение. Роли в пределах IOTP более детально описаны в разделе 2.1. Базовыми ролями являются: продавец, покупатель, кассир, агент доставки и агент обслуживания покупателя.

Существует три типа Кассиров:

• принимающие платеж как часть сделки или совершающие выплату, как возврат платежа;
• принимающие средства как часть депозитной операции;
• выдающие средства при отмене сделки.

Ниже приведенная таблица определяет для каждой роли операции IOTP и торговые блоки, которые должны поддерживаться для каждой роли.

В выше приведенной таблице:

• "Нужно" означает, что торговая роль должна поддерживать операцию или торговый блок.
• "Можно" означает, что программная реализация может поддерживать операцию или торговый блок по усмотрению разработчика.
• "Зависит" означает, что программная реализация операции или торгового блока зависит от одного из следующих условий:

• "Ограничено" означает, что торговый блок должен быть понят, и c его содержимым можно манипулировать, но не при любых условиях. В частности, в случае блока подписи Покупатель не обязан уметь проверять цифровые подписи.

Решения IOTP должны поддерживать все операции IOTP и торговые блоки, необходимые, по крайней мере, для одной из ролей (колонка), как это описано в приведенной выше таблице для решений, которые считаются поддерживающими IOTP.

3. Структура протокола

В предыдущем разделе дано введение, которое объясняет:

• Торговые роли, которые выполняют различные организации в ходе реализации сделки: Продавец, Покупатель, Кассир, Агент доставки и Агент обслуживания покупателя.
• Торговые обмены, каждый из которых предполагает некоторый информационный обмен между торговыми ролями в форме набора торговых компонентов.

Ниже описано:

• Как торговые компоненты формируются в торговые блоки и сообщения IOTP, которыми осуществляется обмен в форме XML-документов между различными торговыми ролями.
• Как производится обмен IOTP-сообщениями между торговыми ролями для того, чтобы выполнить операцию IOTP.
• XML-определения сообщений IOTP, включая операционный блок ссылки (Transaction Reference Block), - XML-элемент, который идентифицирует IOTP-операцию и IOTP-сообщение Message, сопряженное с ним.
• Определения ID-атрибутов XML, которые используются для идентификации сообщений IOTP, торговых блоков и компонентов, а также то, как они соотносятся с использованием элементов ссылок из других XML-элементов.
• Как дополнительные XML-элементы и новые определенные пользователем значения для существующих IOTP-кодов могут использоваться при расширении IOTP.
• Как IOTP использует элемент Packaged Content для вложения данных, таких как сообщения платежных протоколов или определения заказа, в сообщения IOTP.
• Как IOTP идентифицирует языки, чтобы можно было использовать различные языки в рамках сообщений IOTP.
• Как IOTP работает с безопасными и опасными сетевыми позициями (Net Locations), при посылке сообщений.
• Как могут аннулироваться операции IOTP.

3.1. Обзор
3.1.1. Структура сообщений IOTP

Структура сообщения IOTP и его отношения с торговыми блоками и компонентами проиллюстрировано на диаграмме ниже.

Рис. 6. Структура сообщения IOTP

На диаграмме определена концепция блока ссылок операции (Transaction Reference Block). Такой блок содержит среди прочего уникальный идентификатор операции IOTP. Кроме того, каждому блоку и компоненту присваивается ID-атрибут (смотри раздел 3.4), который является уникальным в пределах IOTP. Следовательно, комбинации ID-атрибута и глобального уникального идентификатора в блоке ссылок операции достаточно, для однозначной идентификации любого торгового блока или компонента.

3.1.2. Операции IOTP

Предопределенный набор сообщений IOTP, которыми обмениваются торговые роли, составляют операцию IOTP. Это проиллюстрировано ниже на диаграмме.

Рис. 7. Функциональная схема операция IOTP

На приведенной выше диаграмме Интернет рассматривается в качестве транспортного механизма. Но это не всегда так. Сообщения IOTP могут транспортироваться с использованием различных механизмов.

В этой версии IOTP специфицированы следующие операции IOTP (смотри раздел 9):

• Покупка. Поддерживает предложение, платеж и, опционно, доставку.
• Возврат. Поддерживает возврат денег для сделанной ранее покупки.
• Обмен ценностями. Включает в себя два платежа, которые реализуют обмен ценностями, например валютный обмен.
• Аутентификация. Поддерживает удаленную аутентификацию одной торговой роли другой ролью с помощью различных аутентификационных алгоритмов, и предоставляет информацию об организации - торгового агента, который должен быть аутентифицирован с целью, например, подготовки предложения.
• Отзыв. Поддерживает отзыв электронного платежа из финансовой организации.
• Депозит. Поддерживает депозит электронного платежа в финансовой организации.
• Запрос. Поддерживает запрос состояния транзакции IOTP, которая в данный момент реализуется или уже завершилась.
• Ping. Эта операция поддерживает простой запрос, который позволяет одному приложению IOTP выяснить, работает ли некоторое другое приложение IOTP.

3.2. Сообщение IOTP

Как было описано выше, сообщения IOTP представляют собой [XML] документы, которыми обмениваются торговые роли, участвующие в сделке.

XML-определение сообщения IOTP выглядит следующим образом.

<!ELEMENT IotpMessage
( TransRefBlk,

) >
<!ATTLIST IotpMessage
xmlns CDATA
'iotp:ietf.org/iotp-v1.0'

Содержимое:

TransRefBlk содержит информацию, которая характеризует сообщение IOTP в пределах операции IOTP (смотри раздел 3.3)

Атрибуты:

3.2.1. XML Document Prolog

Сообщение IOTP является корневым элементом XML-документа. Оно, следовательно, должно предшествоваться соответствующим прологом документа XML. Например:

Блок ссылок транзакции содержит информацию, которая идентифицирует IOTP-транзакцию и сообщение IOTP. Блок ссылок операции включает в себя:

• Компонент ID-операции, который однозначно идентифицирует операцию IOTP. Компоненты ID-операции идентичны для всех сообщений IOTP, относящихся к одной IOTP-операции.
• Компонент ID-сообщения, который предоставляет управляющую информацию о сообщении IOTP, а также однозначно идентифицирует сообщение IOTP в рамках операции IOTP.
• Нуль или более компонентов Related To, которые связывают эту операцию IOTP с другими операциями или другими событиями, используя идентификаторы этих событий.

Определение блока ссылок операции (Transaction Reference Block) выглядит следующим образом:

<!ELEMENT TransRefBlk (TransId, MsgId, RelatedTo*) >
<!ATTLIST TransRefBlk ID ID #REQUIRED >

Атрибуты:

Cодержимое:

3.3.1. Идентификационная компонента транзакции

Идентификационная компонента транзакции содержит информацию, которая однозначно задает транзакцию IOTP. Ее определение представлено ниже:

<!ELEMENT TransId EMPTY >

Атрибуты:

Значение IotpTransType управляется процедурой, описанной в разделе 12 IANA Considerations, которая позволяет пользователю определить величины IotpTransType. В последних версиях IOTP, этот список будет расширен с целью поддержки различных типов транзакций IOTP. Вероятно, будет поддержан динамический тип (Dynamic), который указывает, что последовательность шагов в транзакции не является стандартной.

Главным назначением этого атрибута является обеспечение альтернативного пути идентификации транзакции путем спецификации времени его запуска.

Некоторые системы не могут генерировать временные метки. В этом случае этот атрибут должен содержать значение "NA" (Not Available).

3.3.2. Идентификатор сообщения

Компонент Id-сообщения предоставляет контрольную информацию о сообщении IOTP, а также однозначно идентифицирует сообщение в рамках транзакции IOTP. Его определение выглядит следующим образом.

<!ELEMENT MsgId EMPTY >

Атрибуты:

3.3.3. Компонент Related To

Компонент Related To связывает транзакции IOTP с другими транзакциями или другими событиями с помощью идентификаторов этих событий. Определение этого компонента представлено ниже.

<!ELEMENT RelatedTo (PackagedContent) >

RelnKeyWords NMTOKENS #IMPLIED >

Атрибуты:

• IotpTransaction, в случае которого элемент Packaged Content содержит IotpTransId другой транзакции IOTP.
• Ссылка, в случае которой элемент Packaged Content содержит указатель на некоторый другой, не-IOTP документ.

Значения RelationshipType управляются процедурами, определенными в разделе 12 IANA Considerations, которые позволяют пользователю определить свои значения атрибута.

Целью атрибута является обеспечение торговых ролей, включенных в транзакцию IOTP, объяснением природы отношений между транзакциями. Следует позаботиться о том, чтобы слова, использованные в атрибуте Relation, правильно указывали "направление" отношений. Например: одна транзакция может быть возвратом денег для другой выполненной ранее транзакции. В этом случае транзакция, которая возвращает деньги, должна содержать слова атрибута Relation, такие как "возврат за", а не "возврат кому" или просто "возврат".

Cодержимое:

3.4. ID-атрибуты

IOTP-сообщения, блоки (т.e. блоки ссылок операции и торговые блоки), торговые компоненты (включая ID-компонент транзакции и компонент подписи) и некоторые их дочерние элементы задаются атрибутом "ID" XML, который служит для идентификации этих XML-элементов. Эти элементы используются так, что один элемент может ссылаться на другой. Всем этим атрибутам присваиваются ID.

Значения каждого ID-атрибута является уникальным в пределах транзакции IOTP т.e. набор IOTP-сообщений, который имеет тот же самый компонент ID транзакции. Однажды присвоенное значение ID-атрибута элемента никогда не меняется. Это означает, что когда элемент копируется, значение ID-атрибута остается неизменным.

Как следствие можно использовать эти идентификаторы для ссылки и нахождения содержимого любого сообщения IOTP, блока или компонента (смотри раздел 3.5).

3.4.1. Определение ID-атрибутов сообщений IOTP

ID-атрибут Id-компонента IOTP-сообщения должен быть уникальным в пределах транзакции IOTP. Его определение представлено ниже:

IotpMsgId_value ::= IotpMsgIdPrefix IotpMsgIdSuffix
IotpMsgIdPrefix ::= NameChar (NameChar)*

Для сообщений, которые содержат торговый блок информационного запроса или блок запроса Ping, префикс делается равным "I" (Inquiry).

Для сообщений, которые содержат торговый блок отклика на информационный запрос или блок отклика Ping, префикс равен "Q".

Префикс для других торговых ролей в сделке содержится в компоненте Organisation (организации) и прописывается обычно Продавцом. Ниже представлены рекомендуемые значения:

Префиксы должны содержать один символ. NameChar имеет то же значение, что и определение NameChar в [XML].

Короче, Id-компонент первого сообщения IOTP, посланного Покупателем, будет иметь ID-атрибут "C1", второе - "C2", третье - "C3" и т.д. Цифра имеет то же определение что и в [XML].

3.4.2. Определения ID-атрибута для блока и компонента

ID-атрибут блоков и компонентов в пределах транзакции IOTP также должен быть уникальным. Ниже представлено его определение:

BlkOrCompId_value ::= IotpMsgId_value "." IdSuffix
IdSuffix ::= Digit (Digit)*

В IOTP, торговые компоненты и торговые блоки копируются из одного сообщения IOTP в другое. ID-атрибут не изменяется, когда существующий торговый блок или компонент копируется в другое сообщение IOTP.

Короче, первый новый блок или компонент добавляется ко второму посылаемому сообщению IOTP, например, первый ID-атрибут - "C2.1", второй - "C2.2", третий - "C2.3" и т.д. Цифра имеет то же определение, что и в [XML].

3.4.3. Пример использования ID-атрибутов

На диаграмме проиллюстрировано, как используются значения ID-атрибутов.

Рис. 8. Пример использования ID-атрибутов

3.5. Элемент References

Торговый компонент или один из его дочерних XML элементов может содержать XML-атрибут, который указывает на другой блок (т.e. Блок ссылок транзакции или торговый блок) или торговый компонент (включая идентификатор транзакции и компонент подписи). Эти ссылки элементов используются для многих целей, ниже предлагается несколько примеров:

• Идентификация элементов XML, чей дайджест включен в компонент подписи.
• Указание на компонент организации кассира, который используется при платеже.

Элементы Reference всегда содержат значение ID-атрибута блокаили компонента. Идентификация сообщения IOTP, торговогоблока или торгового компонента, на который указывает ссылка элемента, включает в себя наождение XML-элемента, который:

• Принадлежит той же самой IOTP-транзакции (т.e. Id-компонет транзакции и IOTP-сообщения совпадают).
• Имеет значение ID-атрибута элемента соответствующее значению ссылки элемента.

Термин "соответствует" в данной спецификации имеет то же определение, что и в [XML]. Пример "соответствия" ссылки элемента показан ниже.

Рис. 9. Ссылки элемента (Element References)

Атрибуты ссылки элемента определены как "NMTOKEN", а не "IDREF" (смотри [XML]). Это сделано потому, что IDREF требует, чтобы элемент XML, на который ссылаются, принадлежал тому же XML-документу. В IOTP это не всегда так.

3.6. Расширение IOTP

Базовая версия IOTP определяет минимальный протокол, с которым система, поддерживающая IOTP, должна быть способна работать. По мере разработки новых версий IOTP будут определяться дополнительные типы транзакций IOTP. Кроме того, базовая и будущие версии IOTP будут поддерживать два механизма расширения возможностей IOTP пользователем:

1. дополнительные XML-элементы
2. новые значения существующих IOTP-кодов.

3.6.1. Дополнительные XML-элементы

Имена XML элементов и атрибутов используемых в IOTP составляют пространство имен [XML], как это определено атрибутом xmlns элемента IotpMessage. Это позволяет Th IOTP поддерживать включение дополнительных XML-элементов в IOTP-сообщения посредством использования пространства имен XML. Используя XML Namespaces, дополнительные XML-элементы могут быть включены на любом уровне в сообщение IOTP, включая:

1. новые торговые блоки
2. new торговые компоненты
3. новые XML-элементы торгового компонета.

При этом следуют определенным правилам:

Для того чтобы быть уверенным, что дополнительные элементы XML могут быть обработаны корректно, IOTP резервирует использование специального атрибута, IOTP:Critical, который принимает значение True или False и может появляться в дополнительных элементах, добавляемых к IOTP-сообщению. Целью этого атрибута является допущение IOTP проинформировать приложение, можно ли безопасно продолжить транзакцию. В частности:

• Если дополнительный XML-элемент имеет атрибут "IOTP:Critical" со значением "True" и IOTP уведомлен приложением, что оно не знает как обрабатывать элемент и его дочерние элементы, тогда транзакция IOTP выдает техническую ошибку (смотри раздел 4.1).
• Если дополнительный XML-элемент имеет атрибут "IOTP:Critical" со значением "False", тогда транзакция IOTP может продолжать работу, если IOTP уведомлен о том, что приложение не знает как обработать этот элемент. В этом случае:

• Если дополнительный XML-элемент не имеет атрибута "IOTP:Critical", тогда он должен обрабатываться так, как если бы имел атрибут "IOTP:Critical" со значением "True"
• Если XML-элемент содержит атрибут "IOTP:Critical", тогда значение атрибута следует использовать во всех дочерних элементах этого элемента.

Для того чтобы гарантировать то, что документы, содержащие "IOTP:Critical" корректны, этот атрибут объявляется частью DTD для дополнительных элементов в форме:

3.6.2. Opaque Embedded Data

Если IOTP должен быть расширен с помощью Opaque Embedded Data, тогда к инкапсулированным данным должен быть применен элемент Packaged Content (смотри раздел 3.7).

3.7. Элемент PackagedContent

Элемент PackagedContent поддерживает концепцию потока вложенных данных, преобразованную, чтобы защитититься от неверной интепретации транспортной системой и гарантировать совместимость с XML. Примеры использования этого элемента в IOTP включают:

1. для инкапсуляции сообщений платежной системы, таких как сообщения SET,
2. для инкапсуляции описания заказа, чека (payment note) или накладной (delivery note).

В общем, он используется для инкапсуляции одного или более потоков данных. Этот поток данных имеет три стандартизованных атрибута, которые служат для идентификации, декодирования и интерпретации содержимого. Его определение представлено ниже.

<!ELEMENT PackagedContent (#PCDATA) >
<!ATTLIST PackagedContent Name CDATA #IMPLIED Content NMTOKEN "PCDATA" Transform (NONE|BASE64) "NONE" >

Атрибуты:

<ABCD>
<PackagedContent Name='FirstPiece'>
snroasdfnas934k
<PackagedContent Name='SecondPiece'>
dvdsjnl5poidsdsflkjnw45
</PackagedContent>
</ABCD>

Атрибут имени может быть опущен, например, если имеется только один элемент PackagedContent.

• NONE. Содержимое элемента PackagedContent типа PCDATA является корректным представлением данных. Заметим, что разворачивание объекта должно быть произведено (т.e. замена &amp; и &#9;) до анализа данных. Секции CDATA могут встречаться в элементе PackagedContent, где атрибут Transform равен NONE.
• BASE64. Содержимое элемента PackagedContent типа PCDATA представляет собой BASE64 кодировкуреального содержимого.

Cодержимое:

3.7.1. Packaging HTML

PackagedContent может содержать HTML. В этом случае должны выполняться следующие условия:

• Ссылки на любой документы, изображения или другие вещи, такие как звук или WEB-страницы, могут влиять на понимание данных получателем, которые должны соотноситься с другими элементами Packaged, содержащимися в том же родительском элементе, например, описание заказа.
• Если, для того чтобы удовлетворить рассмотренным выше требованиям, в исходный элемент включен более чем один элемент PackagedContent, тогда атрибут Name верхнего уровня, который определяет ссылки на все другие элементы Packaged, должен иметь значение Main.
• Относительные ссылки на другие документы, изображения и т.д. одного элемента PackagedContent на другой реализуются путем установления значения относительной ссылки на атрибут Name другого элемента PackagedContent на том же уровне и в пределах того же родительского элемента.
• Никакие внешние ссылки, которые требуют немедленного разрешения, не должны быть использованы. Так как это может осложнить или сделать невозможным отображение HTML.
• [MIME] используется, чтобы инкапсулировать данные в пределах каждого элемента Packaged. Это означает, что информация в заголовке MIME использована для идентификации типа данных, которые инкапсулированы.

Если выше приведенные соглашения не реализуются, например, включением внешних ссылок, которые должны быть разрешены, тогда получатель HTML должен быть об этом проинформирован.

В качестве руководства разработчику следует иметь в виду, что значения атрибутов Name, относящиеся к элементам PackagedContent, должны допускать извлечение каждого PackagedContent в каталог и отображение HTML непосредственно.

3.7.2. Пакетирование XML

Рекомендуется поддержка XML. Когда необходимо отобразить XML, например, чтобы представить содержимое описания заказа Покупателю, разработчики должны следовать новейшим рекомендациям консорциума World Wide Web.

3.8. Идентификация языков

IOTP использует идентификацию языка [XML] для того, чтобы специфицировать, какие языки применены в тексте и атрибутах IOTP-сообщения.

Для того чтобы определить, какие элементы XML содержат атрибуты xml:lang, нужно придерживаться следующих принципов:

• обязательный атрибут xml:lang содержится в каждом торговом компоненте, где присутствуют атрибуты или содержимое, которое требует отображения или печати на определенном языке;
• опционный атрибут xml:lang вводится в дочерние элементы торговых компонентов. В этом случае значение xml:lang, если оно имеется, переписывает значение для торгового компонента.

Атрибуты xml:lang, которые следуют этим принципам, включаются в торговые элементы, а их дочерние XML-элементы определены в разделе 7.

Отправитель сообщения, обычно Покупатель, может указать свои предпочтения для языка и символьного набора путем спецификации соответствующего списка в Id-компоненте сообщения (смотри раздел 3.3.2). Заметим, что получатель такого сообщения не обязан строго следовать этим предпочтениям, так как он может не иметь необходимых средств для этого. Это также означает, что возможность работать с этими списками не является требованием данной спецификации. Однако возможность реагировать, используя один из объявленных языков или символьных наборов является желательной.

3.9. Безопасные и небезопасные позиции в сети

IOTP содержит несколько "сетевых позиций", которые определяют место, куда молгут быть посланы сообщения IOTP-сообщения. Сетевые позиции (Net Locations) бывают двух типов:

• "Безопасные" сетевые позиции, где конфиденциальность данных гарантируется с помощью, например, некоторых методов шифрования, таких как [SSL/TLS].
• "Небезопасные" сетевые позиции, где конфиденциальность данных не гарантируется.

Заметим, что должны присутствовать безопасна33я или не3безопасная сетевая позиция (Net Location) или обе обязательно.

Если присутствует одна из двух сетевых позиций, только она и может использоваться. Там где представлены оба типа сетевых позиций, допускается использование обоих, в зависимости от предпочтения отправителя сообщения.

3.10. Аннулированные транзакции

Любая торговая роль, вовлеченная в транзакцию IOTP может аннулировать эту транзакцию в любой момент.

3.10.1. Аннулирование транзакций

Транзакции IOTP аннулируются путем посылки сообщения IOTP, содержащего блок Cancel с соответствующим компонентом Status, другой торговой роли, вовлеченной в торговый обмен.

Блок Cancel может быть послан асинхронно по отношению к любому другому сообщению IOTP. В частности он может быть послан до посылки или после получения сообщения от другой торговой роли.

Если транзакция IOTP аннулирована во время торгового обмена (т.e. интервал между отправкой блока "запрос" и получением соответствующего ему блока "отклик"), тогда блок Cancel посылается тому же адресату, что и следующее сообщение IOTP в торговом обмене.

Если покупатель аннулирует транзакцию после завершения торгового обмена (т.e. блок "отклик" торгового обмена уже получен), но до завершения тразакции IOTP, покупатель посылает блок Cancel с соттветствующим компонентом Status сетевой позиции, идентифицированной SenderNetLocn или SecureSenderNetLocn, содержащимся в компоненте опции протокола (смотри раздел 7.1), который размещен в блоке TPO (смотри раздел 8.1). Это обычно торговая роль Продавца.

Покупатель не должен посылать блок Cancel после того как завершилась транзакция IOTP. Аннулирование всей транзакции будет рассматриваться как техническая ошибка.

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

Если торговая роль, отличная от Покупателя, аннулирует транзакцию в любое другое время, это должно восприниматься получателем, как ошибка.

3.10.2. Обработка аннулированных транзакций

Если блок Cancel получен Покупателем в момент, когда аннулирование разрешено, тогда покупатель должен прервать транзакцию.

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

4. Обработка ошибок IOTP

IOTP создан как протокол запросов/откликов, где каждое сообщение состоит из нескольких торговых блоков, которые содержат некоторое. Существует несколько взаимосвязанных соображений при обработке ошибок, ретрансмиссий, дубликатов и тому подобное. Эти факторы приводят к тому, что IOTP вынужден обрабатывать поток сообщений не просто как последовательность запросов и откликов. Кроме того может встретится большое разнообразие ошибок в сообщениях, на транспортном уровне или в торговых блоках или компонентах. Датее будет рассмотрено, как IOTP обрабатывает ошибки, повторные попытки и дубликаты сообщений.

Могут произойти различные ошибки:

1. "технические ошибки", которые не зависят от цели сообщения IOTP,
2. "деловые ошибки", которые указывают, что имеется специфическая проблема для процесса (напр., для платежа или доставки), который исполняется.

Глубина ошибки показывает, где произошла ошибка (при транспортировке, при составлении сообщения или на уровне блока/компонента)

4.1. Технические ошибки

К техническим ошибкам относятся ошибки, которые не зависят от значения сообщения. Это означает, что они могут влиять на любую попытку передачи. Обычно они обрабатываются стандартным образом с ограниченным числом опций для пользователя. Такие ошибки могут быть:

o повторная попытка передачи;
o аннулирование транзакции.

Когда связь работает достаточно хорошо, техническая ошибка индицируется компонентом Error (смотри раздел 7.21) в блоке Error (смотри раздел 8.17), посланным партнером, который детектировал ошибку в сообщении IOTP, партнеру, пославшему ошибочное сообщение.

Если связь слишком плохая, сообщение, которое было послано, может не достичь адресата. В этом случае может произойти таймаут.

Коды ошибок, соответствующие техническим ошибкам записываются в компоненте Error, где перечисляются различные технические ошибки, которые могут случиться.

4.2. Рабочие ошибки

Рабочие ошибки могут случиться, когда IOTP-сообщения "технически" вполне корректны. Они связаны с определенным процессом, например, предложение, платеж, доставка или аутентификация, где каждый процесс имеет разный набор возможных рабочих ошибок.

Например, "Недостаточно средств" является сообщением об ошибке при платеже, но не имеет никакого значения для доставки, в то время как "Back ordered" возможное сообщение об ошибке доставки, но не имеет смысла для платежа. Рабочие ошибки индицируются компонентом Status (смотри раздел 7.16) "блока отклика" соответствующего типа, например, блока Payment Response или Delivery Response. Это допускает любой дополнительный отклик, связанный с информацией, которая необходима для пояснения возникшей ошибки.

Рабочие ошибки должны обычно представляться пользователю так, чтобы он мог решить, что делать дальше. Например, если ошибка связана с недостаточностью платежных средств в предложении, независящим от типа платежа (смотри раздел 9.1.2.2), пользователь может пожелать выбрать другой счет того же типа или другой тип платежа или даже другую платежную систему. Иными словами, если реализация, базирующаяся на IOTP, допускает это и пользователь может перевести дополнительные средства на счет и совершить еще одну попытку.

4.3. Глубина ошибки

Три уровня, на которых могут произойти ошибки в IOTP, включают транспортный уровень, уровень сообщения и уровень блока.

4.3.1. Транспортный уровень

Этот уровень ошибки указывает фундаментальную проблему в транспортном механизме, через который осуществляется передача в IOTP.

Все ошибки транспортного уровня являются техническими и индицируются явно на транспортном уровне, как "No route to destination" из TCP/IP или через таймаут, когда не получено отклика на посланный запрос.

Единственно разумным автоматическим действием, когда сталкиваешся с ошибками транспортного уровня, является попытка повторной передачи, а после нескольких попыток информирование пользователя об этом.

Неявная индикация ошибки, которая может быть получена, является зависимой от транспортной среды и для принятия решения относительно конкретных действий следует обращаться к документации транспортного приложения IOTP.

Таймауты здесь являются функцией как транспорта так и платежной системы, если в запрос инкапсулирована платежная информация. Для выяснения параметров таймаутов и повторных передач рекомендуется обращаться к документации по транспортной и платежной системам. Часто нет способа непосредственно проинформировать партнера об ошибках транспортного уровня, при таких обстоятельствах такие события должны регистрироваться и, если автоматическое восстановление системы не сработало, а в процесс вовлечен человек-пользователь, его следует проинформировать об инциденте.

4.3.2. Уровень сообщения

Этот уровень ошибки указывает на фундаментальную техническую проблему с IOTP-сообщением в целом. Например, XML документ некорректно оформлен, сообщение имеет слишком большую длину для получателя, или обнаружена ошибка в блоке ссылок транзакции (смотри раздел 3.3).

Все ошибки уровня сообщений являются техническтими ошибками и индицируются компонентами Error (смотри раздел 7.21), послаными партером. Компонент Error включает в себя атрибут Severity (степень угрозы), который указывает, является ли ошибка предупреждениеим и может быть проигнорирована, TransientError и что повторная попытка может разрешить проблему или HardError, что говорит о срыве транзакции. Технические ошибки (смотри раздел 7.21.2; Коды ошибок), которые являются ошибками уровня сообщения, включают:

• XML not well formed. Документ имеет не верный формат XML (смотри [XML])
• XML not valid. Документ не вполне отвечает требованиям XML (смотри [XML])
• Технические ошибки блочного уровня (смотри раздел 4.3.3) в блоке ссылок транзакции (смотри раздел 3.3) и блоке подписи. Следует проверить только эти блоки, если с XML все в порядке.

Заметим, что проверки блока подписи включают проверку, где это возможно, того, что каждый из компонентов подпися вычислен правильно. Если подпись вычислена неправильно, тогда данные, которые покрываются подписью не будут признаны истинными. Процедура проверки подписи описана в разделе 6.2.

4.3.3. Уровень блоков

Ошибки блочного уровня указывают на проблему с блоком или одним из его компонентов в сообщении IOTP (помимо блоков ссылок транзакции или подписи). Сообщение передано корректно, структура всего сообщения, включая блоки ссылок транзакции и подписи, вполне разумна, но имеется ошибка, связанная с каким-то другим блоком. Ошибки блочного уровня могут быть:

• техническими ошибками
• рабочими ошибками

Технические ошибки далее делятся на:

• Связанные с проверкой атрибутов блочного уровня и элементов.
• Связанные с проверкой согласованности блоков и компонентов.
• Переходные технические ошибки.

Если случислась техническая ошибка, связанная с блоком или компонентом, формируется компонент Error для посылки отправителю некорректного сообщения.

4.3.3.1. Проверки атрибутов блочного уровня и элементов

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

Проверки элемента и атрибута блочного уровня включают в себя:

• проверку того, что значение каждого атрибута в каждом элементе блока согласуется с правилами спецификации IOTP;
• проверку того, что содержимое каждого элемента согласуется с правилами спецификации IOTP;
• если предыдущие проверки прошли успешно, тогда осуществляется контроль согласованности значений атрибутов и содержимого элементов со значениями атрибутов и содержимым элементов любых других компонентов в пределах блока.

4.3.3.2. Проверки согласованности компонентов и блоков

Проверки согласованности компонентов и блоков состоит из:

• проверки того, что комбинации блоков и/или компонентов, присутствующих в сообщении IOTP, согласуются с правилами спецификации;
• проверки взаимосогласованности атрибутов и содержимого элементов в блоках сообщения IOTP;
• проверки взаимосогласованности атрибутов и элементов в блоках данного сообщения IOTP и блоков, полученных ранее IOTP-сообщений в рамках одной и той же транзакции.

Если блок проходит проверку атрибутов и элементов блочного уровня и контроль согласованности блоков и компонентов, тогда он обрабатывается IOTP-приложением или какой-то оконечной системой, такой как платежный сервер.

4.3.3.3. Переходные технические ошибки

Во время обработки блока могут произойти временные отказы, которые в принципе могут быть преодолены позднее повторной передачей исходного сообщения. В этом случае партнер информируется о переходной ошибке путем посылки компонента Error (смотри раздел 7.21) с атрибутом Severity равным TransientError и атрибутом MinRetrySecs равным некоторому значению, удобному для используемого транспортного механизма и/или платежного протокола (смотри соответствующие приложения транспортного и платежного протокола). Заметим, что переходные технические ошибки могут генерироваться любыми торговыми агентами, вовлеченными в транзакцию.

4.3.3.4. Рабочие ошибки блочного уровня

Если в процессе платежа или доставки происходит рабочая ошибка, тогда присылается соответствующий тип блока отклика, содержащий компонент Status (смотри раздел 7.16) с атрибутом ProcessState равным Failed и CompletionCode, указывающим на природу проблемы.

Некоторые рабочие ошибки могут быть переходными, при таких обстоятельствах Покупатель может справиться с ситуацией самостоятельно и успешно завершить транзакцию каким-то способом. Например, если на кредитной карточке покупателя недостаточно денег, он может воспользоваться для покупки другой кредитной карточкой.

Преодоление переходных рабочих ошибок зависит от CompletionCode. Для понимания имеющихся возможностей смотри определение компонента Status. Заметим, что для рабочих ошибок не формируется компонент или блок Error.

4.4. Idempotency, последовательность обработки и поток сообщений

IOTP-сообщения представляют в действительности комбинацию блоков и компонентов, как это описано в 3.1.1 (Структура сообщений IOTP). В будущем при расширении IOTP разнообразие таких комбинаций еще более расширится. Важно, что многократные приемы/передачи одного и того же запроса изменения состояния имеют тот же результат, как и однократная передача/прием этого запроса. Это называется идемпотентностью. Например, покупатель, оплачивая заказ, желает оплатить его только раз. Большинство сетевых транспортных механизмов имеют определенную вероятность доставки одного сообщения несколько раз или не доставить ни разу, что потребует позднее повторной передачи. С другой стороны, запрос состояния можно повторять и при этом каждый раз должно обрабатываться вновь полученное значение. Правильная реализация IOTP может моделироваться по разному различными процессами.

4.5. Последовательность обработки для роли сервера

"Роли сервера" - это любые торговые роли, несовпадающие с ролью Покупателя. Они являются "ролями сервера", так как они обычно получают запросы, которые они должны обработать и посылать на них отклики. Однако Роли сервера могут также инициировать транзакции. Более конкретно роли сервера должны быть способны:

1. Инициировать транзакцию (смотри раздел 4.5.1). Это могут быть:
1. платеж, связанный с транзакцией;
2. инфраструктурные транзакции.
2. Принять и обработать сообщение полученное от другой торговой роли (смотри раздел 4.5.2). Сюда относится:
1. идентификация, если сообщение принадлежит транзакции, которая была запущена ранее;
2. обработка сообщений-дубликатов;
3. генерация переходных ошибок, если сервер, который обрабатывает входные сообщения перегружен;
4. обработка сообщения, если оно лишено ошибок и авторизовано, и при благоприятном исходе, послать отклик отправителю сообщения.
3. Аннулировать текущую транзакцию, если поступил такой запрос (смотри раздел 4.5.3)
4. Повторно передать сообщение, если ожидается отклик, который не поступил за определенный период времени (смотри раздел 4.5.4).

4.5.1. Инициализация транзакций

Роли сервера могут инициировать большое число различных транзакций. В чатности:

1. Транзакцию информационного запроса (смотри раздел 9.2.1);
2. Транзакцию Ping (смотри раздел 9.2.2);
3. Транзакцию аутентификации (смотри раздел 9.1.6);
4. Транзакцию, сопряженную с платежем, такую как:

4.5.2. Обработка входных сообщений

Обработка входных сообщений включает в себя:

1. проверку структуры и идентификацию сообщения;
2. выявление и обработку сообщений-дубликатов;
3. обработку недублированных, оригинальных сообщений, которая включает в себя:

4.5.2.1. Проверка структуры и идентификация сообщений

Крайне важно проверить, что сообщение имее корректную XML-форму и идентификатор транзакции (IotpTransID-атрибут компонента TransId) в сообщении IOTP может быть распознан, так как IotpTransId будет нужен при формировании отклика.

Если входное сообщение сформировано некорректно, тогда генерируется компонент Error с атрибутом Severity равным HardError и код ошибки XmlNotWellFrmd.

Если входное сообщение сформировано правильно, но IotpTransId не может быть идентифицировано, генерируется компонент Error с :

Далее получатель вводит компонент Error в блок ошибки с новым компонентом TransactionId с новым IotpTransId и отправляет его отправителю исходного сообщения.

4.5.2.2. Выявление и обработка дублированных сообщений

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

Рекомендуемым способом проверки идентичности сообщений является проверка равентства их [DOM-HASH].

Если получено сообщение, прежде чем его исследовать, нужно проверить, завершилась ли обработка предыдущего.

Если обработка не завершилась, генерируется компонент Error с атрибутом Severity = TransientError и кодом ошибки = MsgBeingProc, чтобы указать, что сообщение обрабатывается и послать его обратно отправителю, с предложением повторной присылки поздее.

4.5.2.3. Обработка недублированных сообщений

Если установлено, что сообщение не является дубликатом ранее полученного, тогда оно обрабатывается. Процедура обработки включает в себя:

1. проверку того, что сервер готов для обработки, если это не так, генерируется переходная ошибка;
2. проверку, не находится ли транзакция в режиме ошибки или неаннулирована;
3. контроль корректности входного сообщения, который предусматривает:
1. проверку глубины ошибки сообщения;
2. проверку ошибок блочного уровня;
3. проверку любых инкапсулированных данных
4. проверку ошибок в последовательности полученных блоков;
5. генерацию компонентов ошибки для любых обнаруженных ошибок;
6. если никаких серьезных или переходных ошибок не выявлено, производится обработка сообщения и, если требуется, генерация отклика отправителю входного сообщения.

Этот подход к обработке дублированных входных сообщений означает, что если получены два совершенно идентичных сообщения, будут посланы два идентичнх отклика. Это применимо также к информационным запросам и транзакциям Ping, когда в действительности состояние транзакции или возможность обработки сервером может измениться. Если требуется текущее состояние транзакции или сервера, тогда используется транзакция с новым значением ID-атрибута компонента MsgId.

Процесс обработки входного сообщения должен проверить, свободна ли остальная система. Если сервер слишком занят, он должен выдать компонент Error с атрибутом Severity равным Transient Error и кодом ошибки равным SystemBusy, после чего вернуть отправителю входное сообщение, запрашивая тем самым повторную присылку этого сообщения спустя некоторое время.

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

Проверка того, что транзакция не зафиксировала ошибку и не оказалась аннулированной. Предполагается следующий контроль:

Если это имеет место, сообщение игнорируется. Транзакция с серьезной ошибкой или аннулированная транзакция не может быть перезапущена.

Если с транзакцией все в порядке, производится поиск ошибок на уровне сообщения. Это включает в себя:

• проверку формат XML;
• проверку того, что все элементы, атрибуты и содержимое блока ссылок транзакции не содержат ошибок и соответствуют спецификации IOTP;
• проверку цифровой подписи, которая в свою очередь предполагает:

Проверка ошибок уровня блоков включает:

1. проверку в пределах каждого блока (помимо блока ссылок транзакции) того что:



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


2. проверку того, что комбинации блоков корректны
3. проверку того, что значения атрибутов, элементы и содержимое элементов взаимосогласованы на межблочном уровне в пределах входного сообщения с блоками, полученными или отправленными ранее. Это включает проверку уместности данного блока для этого типа транзакции.

Если сообщение содержит какие-то инкапсулированные данные, то, если возможно, они проверяются на наличие ошибок.

4.5.2.4. Проверка ошибок в последовательности блоков

Далее при объяснении поиска ошибок в последовательностях блоков выражение типа "относится к транзакции IOTP" следует интерпретировать как "содержится в сообщении IOTP, где TransRef Block включает в себя IotpTransId, который указывает на данную танзакцию". Так, например, "Если ошибка или аннулированный блок относится к транзакции IOTP, которая не распознана, тогда..." следует интерпретировать как "Если ошибка или аннулированный блок содержатся в сообщении IOTP, TransRefBlock включает в себя IotpTransId, который относится к транзакции IOTP, которая не распознана, тогда...”.

Ошибки в последовательности прихода блоков зависят от блока. Блоки, где требуется проверка последовательности:

• Error и Cancel блоки. Если Error или Cancel блок относится к транзакции IOTP, которая не распознана, тогда это серьезная (Hard) ошибка. Чтобы избежать зацикливания, не следует посылать оповещения об ошибке, если получен Error или Cancel блок транзакции IOTP.
• Блоки отклика и информационного запроса. Если блоки отклика и информационного запроса относятся к транзакции IOTP, которая не распознана, это серьезная (Hard) ошибка.
• Блок запроса аутентификации. Если блок запроса аутентификации относятся к транзакции IOTP, которая распознана, это серьезная (Hard) ошибка.
• Блок отклика аутентификации проверяется следующим образом:



• Если блок отклика аутентификации не относится к транзакции IOTP, которая распознана, то это серьезная (Hard) ошибка, в противном случае.
• Если блок отклика аутентификации не относится к аутентификационному запросу, который был ранее послан, то это серьезная (Hard) ошибка, в противном случае.
• Если блок отклика аутентификации получен в рамках IOTP-транзакции, до того как аутентификация успешно завершилась, то это серьезная (Hard) ошибка.
• Блок состояния аутентификации проверяется следующим образом:



• если блок состояния аутентификации не относится к транзакции IOTP, которая распознана, то это серьезная (Hard) ошибка, в противном случае,
• если блок состояния аутентификации не относится к аутентификационному отклику, который был перед эти послан, тогда это серьезная (Hard) ошибка, в противном случае,
• если блок состояния аутентификации получен для той же самой транзакции раньне, то это предупреждение (а не ошибка).


• Блок выбора TPO (только для продавца) проверяется следующим образом:



• если блок выбора TPO не относится к транзакции IOTP, которая распознана, то это серьезная (Hard) ошибка, в противном случае,
• если блок выбора TPO не относится к транзакции IOTP, где блок TPO и отклик предложения (в одном сообщении) были посланы ранее, то это серьезная (Hard) ошибка, в противном случае,
• если блок выбора TPO относится к транзакции IOTP, где только блок TPO (т.e. без отклика на предложение) был послан ранее, то это серьезная (Hard) ошибка, в противном случае,
• если блок выбора TPO для того же блока TPO получен ранее, то это серьезная (Hard) ошибка.
• Блок запроса платежа (только для кассира) проверяется следующим способом:



• если блок запроса платежа относится к транзакции IOTP, которая не распознана, тогда все в порядке, в противном случае
• если блок запроса платежа относится к транзакции IOTP, которая не связана с платежом, то это серьезная (Hard) ошибка, в противном случае
• если был предшествующий платеж, который не прошел с кодом завершения недопускющим восстановление, то это серьезная (Hard) ошибка, в противном случае
• если предыдущий платеж еще в работе, то это серьезная (Hard) ошибка.


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



• если блок платежного обмена не относится к транзакции IOTP, которая распознана, то это серьезная (Hard) ошибка, в противном случае
• если платежный обмен не относится к транзакции IOTP, где такой обмен уже был, то это серьезная ошибка (Hard).
• Запрос доставки (только для агентов доставки). Если блок запроса доставки относится к транзакции IOTP, которая распознана сервероим, то это серьезная ошибка.

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

Описанная выше проверка последовательности аутентификационных откликов и платежных запросов поддерживает повторение запросов Покупателя, если предыдущая операция не прошла, например:

• потому что не получен корректный отклик (напр., пароль) на аутентификацию или
• не удалось произвести оплату, так как нехватает денег на кредитной карточке.

Обработка входного сообщения, лишенного ошибок

Если входное сообщение прошло предыдущие проверки, то оно должно быть обработано и послан, если требуется, отклик. Заметим, что:

• Информационные запросы на транзакции Ping следует игнорировать;
• Если входное сообщение содержит блок Error с переходной ошибкой, следует подождать необходимое время и затем повторно послать предыдущее сообщение, если не было получено отклика на сообщение, посланное ранее;
• Если входное сообщение содержит компонент Error с HardError или блок Cancel, тогда последующая обработка транзакции должна быть остановлена. Это включает в себя блокировку отправки любых текущих сообщений или посылку откликов на любые новые приходящие недублированные сообщения;
• Обработка инкапсулированных сообщений (напр., сообщения платежного протокола) может вызвать дополнительные переходные ошибки;
• Цифровая подпись может быть корректно сформирована лишь в случае, если сгенерированы все блоки и компоненты и известно, какие элементы в сообщении должны быть подписаны.

Если выходное сообщение сгенерировано, оно должно быть запомнено, так чтобы иметь возможность, если потребуется, послать его повторно. Заметим, что выходные сообщения, которые содержат переходные ошибки, не запоминаются, так что они формируются заново, при их повторной посылке.

4.5.3. Аннулирование транзакции

Этот процесс используется, чтобы аннулировать транзакцию, Этот процесс служит для аннултрования транзакции работающей на сервере IOTP. Он инициируется некоторым другим процессом, как результат внешнего запроса отдругой системы или сервера, который играет ту же торговую роль. Обработка такого запроса требует:

• если IotpTransId транзакции, которую надо аннулировать, не распознан, или она завершена, то запрос не проходит, в противном случае,
• если IotpTransId относится к транзакции Ping, то запрос не проходит, в противном случае,
• определить, какой локументальный обмен нужно прервать, сформировать блок Cancel и послать его партнеру.

Аннулирование транзакции на сервере IOTP обычно возникает по деловым причинам. Например продавец может попытаться безуспешно аутентифицироваться несколько раз, после чего решает аннулировать транзакцию. Следовательно процесс, который решаетпроизвести такое действие, должен послать сообщение из процесса/сервера с инструкцией о том, какую транзакцию следует аннулировать.

4.5.4. Повторная посылка сообщений

Сервер должен периодически проводить проверки, нет ли транзакций, ожидающих сообщения-отклики и неполчивших их своевременно. Такая задержка может быть связана со следующими факторами:

Если не получено никакого сообщения, оригинальное сообщение должно быть послано повторно. Это должно производиться некоторое число раз в зависимости от надежности используемого транспортного механизма. Если не получено отклика в течении оговоренного времени, транзакция прерывается по таймауту. В этом случае, состояние транзакции устанавливается равным Failed, и выдается код завершения:

4.6. Последовательность обработки для роли клиента

"Роль клиента" в IOTP является торговой ролью Покупателя.

Компания или организация, которая является Продавцом может, например, взять на себя роль покупателя, делая покупки или или выполняя отзыв электронного платежа.

В частности Покупатель должен быть способен:

1. Инициировать транзакции (смотри раздел 4.6.1). Среди них могут быть:



1. платеж, связанный с транзакцией
2. инфраструктурные транзакции.
2. Воспринять и обработать сообщение, полученное от другой торговой роли (смотри раздел 4.6.2). Сюда входит:



1. идентификация того, принадлежит ли сообщение транзакции, запущенной ранее;
2. обработка дублированных сообщений;
3. генерирование переходных ошибок, если сервер, который обрабатывет входное сообщение перегружен;
4. обработка сообщения, если оно не имеет ошибок и, если необходимо, посылка отклика партнеру по результатам обработки.
3. Аннулировать текущую транзакцию, если поступил соответствующий запрос, например от пользователя (смотри раздел 4.6.3).
4. Повторно передать сообщение, если ожидаемый отклик не пришел своевременно (смотри раздел 4.6.4).

4.6.1. Операции инициализации

Роль Покупателя может инициировать большое число различных транзакций. В частности:

4.6.2. Обработка входных сообщений

Обработка входных сообщений для роли покупателя происхотит также как и для IOTP-сервера (смотри раздел 4.5.2) за исключением проверки ошибок в последовательности блоков (для IOTP-сервера смотри раздел 4.5.2.4).

Описание обработки входных сообщений для сервера IOTP включает соображения многопроцессности и многозадачности. Для роли покупателя - в частности при работе на изолированной рабочей системе использование много процессности оставляется на усмотрение разработчика.

4.6.2.1. Поиск ошибки в последовательности блоков

Последовательность обработки блоков для роли покупателя та же, что и для IOTP-сервера (смотри раздел 4.5.2.4) за исключением того, что роль покупателя подставляется вместо роли сервера IOTP:

Для других блоков роль покупателя может получать уведомление об ошибках в порядке прихода блоков иможет зависеть от типа блоков. Блоки, где важна последовательность проверки перечислены ниже:

1. Блок TPO проверяется следующим образом:



1. если входное сообщение содержит блок запроса аутентификации и блок отклика на предложение, то это серьезная (Hard) ошибка, в противном случае,
2. если входное сообщение содержит блок запроса аутентификации и статуса аутентификации, то это серьезная (Hard) ошибка, в противном случае,
3. если входное сообщение содержит блок запроса аутентификации и транзакция IOTP распознана системой покупателя, то это серьезная (Hard) ошибка, в противном случае,
4. если входное сообщение содержит блок состояния аутентификации и транзакция IOTP распознана системой покупателя, то это серьезная (Hard) ошибка, в противном случае,
5. если входное сообщение содержит блок состояния аутентификации, а блок состояния аутентификации послан до сообщения-отклика аутентификации, то это серьезная (Hard) ошибка,
6. если входное сообщение содержит блок отклика на предложение и транзакция IOTP распознана системой покупателя, то это серьезная (Hard) ошибка, в противном случае,


2. Блок отклика предложения проверяется следующим образом:



1. если блок отклика на предложение является частью брэнд-независимого обмена предложения (смотри раздел 9.1.2.2), тогда никакой проверки последовательности не нужно, так как это первое сообщение, в противном случае,
2. если блок отклика на предложение не является частью транзакции IOTP, которая распознана покупателем, то это серьезная (Hard) ошибка, в противном случае,
3. если блок отклика на предложение не относится к транзакции, где в последнем сообщении послан блок выбора TPO, то это серьезная (Hard) ошибка.


3. Блок платежного обмена проверяется следующим образом:



1. если блок платежного обмена не относится к транзакции IOTP, которая распознана системой покупателя, то это серьезная (Hard) ошибка, в противном случае,
2. если платежный обмен не относится к транзакции IOTP, где только что послан блок платежного запроса или платежного обмена, то это серьезная (Hard) ошибка.


4. Блок платежного отклика проверяется следующим образом:



1. если блок платежного отклика не относится к транзакции IOTP, которая распознана системой Покупателя, то это серьезная (Hard) ошибка, в противном случае,
2. если блок платежного отклика не относится к транзакции IOTP, где только что послан блок платежного обмена или блок платежного запроса, то это серьезная (Hard) ошибка.


5. Блок отклика доставки проверяется следующим образом:
1. если блок отклика доставки не относится к транзакции IOTP, которая распознана системой Покупателя, то это серьезная (Hard) ошибка, в противном случае,
2. если блок отклика доставки не относится к транзакции IOTP, где только что послан блок запроса платежа или платежного обмена, то это серьезная (Hard) ошибка.

4.6.3. Аннулирование операции

Этот процесс аннулирует текущую транзакцию системы покупателя в результате внешнего запроса пользователя или другой системы или сервера, исполняющего роль покупателя. Обработка запроса делается также как для сервера IOTP (смотри раздел 4.5.3).

4.6.4. Повторная передача сообщений

Ретрансмиссия сообщений осуществляется так же, как и в случае сервера IOTP (смотри раздел 4.5.4).

5. Соображения безопасности

Здесь рассматриваются следующие проблемы:

5.1. Принятие решения о применении электронной подписи

Использование электронной подписи в IOTP является исключительно опционным. IOTP может успешно работать вообще без цифровых подписей.

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

• начать использовать подписи,
• найти метод работы, где не требуются подписи или,

• выбрать более низкий объем и стоимость торговых операций.

Перечень некоторых причин использования цифровых подписей представлен ниже:

• Продавец (или другая торгвая роль) хочет продемонстрировать, что ему можно верить. Если, например, продавец генерирует подпись отклина-предложения (смотри раздел 7.19.2), используя сертификат, полученный от третей стороны, известной покупателю, тогда покупатель может проверить подпись и сертификат, после чего он сможет с приемлемой достоверностью доверять тому, что предложение получено от означенной организации-продавца. В этом случае подписи используют асимметричную криптографию.
• Продавец, или другая торгвая роль, хочет сгенерировать запись транзакции, которая подходит для определенной цели. Например, с приемлемой достоверностью цифровые подписи могут быть использованы Покупателем, чтобы определить:

• будет ли сообщение принято налоговой службой, в качестве корректной записи транзакции;
• если нужна гарантия, например, от "Better Business Bureau" или подобной организации.

• Кассир или агент доставки, должен знать, что запрос не видоизменен и авторизован. Например, в IOTP, детали того, сколько нужно платить, посылаются покупателю в предложенпии-отклике и затем переадресуются кассиру в платежном запросе. Если запрос не подписан, покупатель может изменить сумму, например, удалив одну цифру. Если Кассир не имеет доступа к исходной платежной информации отклика-предложения, тогда в отсутствии подписи, кассир не может быть уверен, что данные не были модифицированы. Аналогичго, если платежная информация не подписана цифровым образом, кассир не может быть уверен, кто является продавцом, запросившим этот платеж.
• Кассир или агент доставки хочет предоставить неопровержимую запись совершения платежной операции или выполнения доставки. Если платежный отклик или отклик доставки подписан, тогда покупатель может позднее использовать запись о платеже или доставке, чтобы доказать, что она состоялась. Это может использоваться, например, для целей обслуживания покупателя.

Ниже приводится список некоторых причин, почему электронная подпись может не использоваться:

• Торговые роли иногда объединяются, следовательно изменения данных, выполненные покупателем могут быть обнаружены. Одной из причин использования подписи, это выявление того, что изменения внесены покупателем или другим партнером. Однако, если торговые роли имеют доступ к необходимым данным, то можно провести сравнение, нпример, информацию из платежного запроса и из отклика предложения. Доступ к данным может быть реализован, например, продавцом и кассиром, работающими в одной организации.
• Стоимость криптографии слишком велика. Например, если платеж составляет всего несколько центов, стоимость выполнения криптографических операций, сопряженных с генерацией и проверкой цифровой подписи делает последнюю экономически не целесообразной.

5.2. Симметричная и асимметричная криптография

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

Однако неудобства симметричной криптографии заключается в том, что покупатель не может надежно идентифицировать Продавца, Кассира и Агента доставки с которыми он имеет дело. Это существенно понижает доверие системе покупателя.

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

Заметим, что в одной транзакции может использоваться симметричная, асимметричная криптография или обе ее разновидности.

5.3. Конфиденциальность данных

Конфиденциальность информации обеспечивается путем пересылки IOTP-сообщений между торговыми ролями, используя секретный канал, такой как [SSL/TLS]. Использование безопасного канала в IOTP является опционным.

5.4. Безопасность платежного протокола

IOTP сконструирован так, чтобы быть нечувствительным к используемому платежному протоколу.

IOTP способствует безопасности, используя цифровые подписи для установления однозначного соответствия запроса и отклика и для аутентификации отправителя сообщений. Например IOTP связывает вместе: предложение, платеж и доставку.

6. Цифровые подписи и IOTP

IOTP может успешно работать без использования цифровых подписей в открытой сетевой среде, но это менее безопасно - смотри 5. Ниже рассматривается использование цифровых подписей для решения различных задач.

6.1. Как IOTP использует цифровые подписи?

В IOTP цифровые подписи используются как:

• Компоненты IOTP (смотри раздел 7).
• Подпись содержит дайджест одного или более компонентов или торговых блоков, которые могут также включать в себя другие компоненты подписи в любом сообщении;
• идентификатор:

• того, какая организация сделала подписи;
• какая организация должна обрабатывать подпись с целью проверки.

Цифровые сертификаты могут быть связаны с цифровой подписью, если используется асимметричная криптография.Однако если используется симметричная криптография, цифровой сертификат заменяется некоторым идентификатором используемого секретного ключа. Способ, с помощью которого формируются компоненты подписи для одного или нескольких элементов, проиллюстрирован ниже на рис. 10.

Рис. 10. Дайджесты подписи

Классическим примером того, как одна цифровая подпись подтверждает другую в IOTP, является случай когда Продавец сначала подписывет предложение, формируя подпись отклика предложения, которое позднее подтверждается кассиром с помощью подписи платежной расписки. Таким путем платеж в транзакции IOTP связывается с предложением продавца.

Заметим, что один Manifest может соответствовать многим элементам подписи "Value", где каждый элемент значения содержит цифровую подпись того же самого Manifest. Это, в частности, позволяет продавцу согласовать применение различных секретных ключей с кассиром и агентом доставки. Детальные описания компонента подписи содержится в разделе 7.19.

6.1.1. Пример подписи IOTP

Пример использования подписи проиллюстрирован ниже на рис. 11, где показано как взаимодействуют различные компоненты и элементы друг с другом.

Для целей иллюстрации была использована базовая торговая транзакция. Применение элементов и атрибутов аналогично для всех типов транзакций IOTP.

Элемент Manifest в компоненте подписи содержит дайджесты TransRefBlock (не покаазан); ID-компонента транзакции (не покаазан); компонентов организаций (Продавца, Кассира, Агента доставки); компонент списка видов платежа; компонент заказа, платежный компонент, компонент доставки и компонент выбора вида платежа (если покупка зависит от вида платежа).

Рис. 11. Пример использование подписи при покупке

6.1.2. Элементы OriginatorInfo и RecipientInfo

Атрибут OriginatorRef элемента OriginatorInfo в компоненте подписи содержит ссылку на элемент (смотри раздел 3.5), которая указывает на комполнент организации, сгенерировавшей подпись. В данном примере это продавец.

Заметим, что значение элемента атрибута с атрибутом типа, устанавленным равным типу подписи IOTP, должно соответствовать торговой роли организации, которая его подписала. Если это не так, возникает ошибка. Корректные значения представлены ниже в таблице.

Атрибут RecipientRefs элемента RecipientInfo в компоненте подписи содержит ссылки элементов на компоненты организации, которая должна использовать подпись, чтобы проверить:

Заметим, что, если используется симметричная криптография, отдельные элементы RecipientInfo и Value для каждого набора общих секретных ключей размещаются в компоненте Signature. В противном случае, если используется асимметричная криптография, атрибут RecpientRefs одного элемента RecipientInfo может относиться к нескольким компонентам Organisation, если они все используют один и тот же сертификат.

6.1.3. Использование подписей для подтверждения корректного завершения операций

Проверка успешного завершения операции осуществляется с помощью подписи данных сообщений-откликов. В частности:

• для отклика предложения, когда продавец делает предложение Покупателю, котоорое может быть затем послано:



• Кассиру, чтобы проверить, что Продовец авторизует платеж;
• Агенту доставки, чтобы проверить, что продавец авторизует доставку.
• Для платежного отклика, когда Кассир генерирует платежную расписку, которая может быть послана:



• Агенту доставки, в блоке запроса доставки для авторизации доставки вместе с подписью отклика предложения, или
• другому кассиру во втором платежном запросе, чтобы авторизовать второй платеж в транзакции обмена ценностями.



• Отклик доставки, когда Агент доставки генерирует накладную (Delivery Note). Это может быть использовано, чтобы проверить по завершении, что все сделано так как надо.
• Отклик доставки. Один метод аутентификации партнера по сделке заключается в посылке запроса аутентификации, где определено, что эта процедура предсматривает использование электронной подписи.
• Запрос состояния транзакции. Блок отклика информационного запроса может быть снабжен цифровой подписью, чтобы удостоверить аутентичность отклика.
• Ping. Отклик Ping может быть подписан, чтобы иметь возможность проверки распознаваемости подписи.

6.2. Проверка корректности вычисления подписи

Проверка корректности вычисления электронной подписи является частью проверки ошибок уровня сообщения (смотри раздел 4.3.2).

Прежде чем торговая роль сможет проверить подпись, она должна идентифицировать, какой из элементов подписи следует проверить. При этом производятся следующие действия:

• проверка того, что блок подписи присутствует и содержит один или более компонентов подписи;
• идентификация компонента Organisation, который содержит OrgID-атрибут организации, осуществляющей проверку. Если не найдено ни одного компонента организации или обнаружено более одного такого компонента, фиксируется ошибка;
• использование ID-атрибута компонента организации, чтобы найти элемент RecipientInfo, который содержит атрибут RecipientRefs, имеющий отношение к компоненту Organisation. Заметим, что может не быть подписи и по этой причине нечего проверять.
• проверка компонента Signature, который содержит идентифицированный элемент RecipientInfo в виде:

6.3. Проверка платежа или доставки

Далее описываются процессы, необходимые для кассира или агента доставки, чтобы проверить возможность выполнения платежа или доставки. Это может включать проверку подписей, если она специфицирована продавцом.

При этом осуществляются следующие шаги:

• проверка того, что платежный запрос или запрос доставки посланы правильной организацией;
• проверка того, что в запросе представлены правильные компоненты IOTP;
• проверка того, что платеж или доставка авторизованы.

В данном разделе используются следующие термины:

• "Блок запроса" используется в связи с блоком запроса платежа (смотри раздел 8.7) или блоком запроса доставки (смотри раздел 8.10), если не специфицировано обратного;
• "Блок отклика" используется в связи с блоком платежного отклика (смотри раздел 8.9) или блоком отклика доставки (смотри раздел 8.11);
• "Операция" используется в связи с операцией, которая реализуется при получении блока запроса. Операцией может быть платеж или доставка;
• "Операционная организация" используется в отношении Кассира или Агента доставки, которые реализуют операцию;
• "Подписант операции" используется в отношении организации, которая подписаладанные об операции с целью ее авторизации;
• "Верификатор операции" используется в отношении организаций, которые верифицируют данные, чтобы определить, авторизованы ли они для выполнения операции;
• атрибут ActionOrgRef содержит ссылки элемента, которые могут быть использованы для идентификации "Операционной организации", которая должна выполнить операцию.

6.3.1. Проверка того, что блок запроса послан правильной организацией

Проверка того, послан ли блок запроса правильной организации, варьируется в зависимости от того платеж это или доставка.

6.3.1.1. Платеж

Кассир проверяет, может ли он принять или выполнить платеж путем идентификации компоненты платежа в полученном им блоке платежного запроса. Затем, используя ID плетежного компонента для идентификации организации, выбранной Покупателем, проверяет, что это та самая организация. Метод доступа к данным для решения поставленных задач проиллюстрирован на рис. 12.

Рис. 12. Проверка того, что Кассир может осуществить платеж

Далее выполняются следующие процедуры:

• Идентификация платежного компонента (смотри раздел 7.9) в блоке полученного платежного запроса.
• Идентификация компонентов списка видов платежа и выбора вида платежа для платежного компонента. Это включает в себя:



• идентификацию компонента списка видов платежей (смотри раздел 7.7), значение его ID-атрибута соответствует атрибуту BrandListRef платежного компонента. Если не обнаружено ни одного или более одного компонента списка видов платежа, возникает состояние ошибки.
• идентификацию компонента списка выбора вида платежа (смотри раздел 7.8), где значение его атрибута BrandListRef соответствует BrandListRef платежного компонента. Если не обнаружено ни одного или более одного компонента выбора вида платежа, возникает состояние ошибки.



• идентификация элементов вида платежа, платежного протокола и суммы в пределах списка видов платежа, который был выбран Покупателем. Это включает:


• Элемент вида платежа (смотри раздел 7.7.1), где значение его Id-атрибута соответствует значениюатрибута BrandRef выбора вида платежа. Если не обнаружено ни одного или более одного элемента вида платежа, возникает состояние ошибки.
• Протокольный элемент суммы (смотри раздел 7.7.3) является элементом, где значение его ID-атрибута соответствует величине атрибута ProtocolAmountRef в компоненте выбора вида платежа. Если не обнаружено ни одного или более одного протокольного элемента суммы, возникает состояние ошибки.
• Элемент платежного протокола (смотри раздел 7.7.5) представляет собой элемент, значение ID-атрибута которого соответствует величине атрибута PayProtocolRef в идентифицированном протокольном элементе суммы. Если не обнаружено ни одного или более одного подходящего элемента платежного протокола суммы, возникает состояние ошибки.
• Элемент валютной суммы (смотри раздел 7.7.4) представляет собой элемент, значение ID-атрибута которого соответствует величине атрибута CurrencyAmountRef в компоненте выбора вида платежа. Если не обнаружено ни одного или более одного подходящего элемента валютной суммы, возникает состояние ошибки.


• Проверяется совместимость ссылок в списке видов платежа и компонентов выбора вида платежа:



• проверяется, что ссылка элемента существует в атрибуте ProtocolAmountRefs идентифицированного элемента вида платежа, который соответствует ID-атрибуту идентифицированного элемента суммы. Если не может быть обнаружено ни одной или более одной подходящей ссылки элемента, возникает состояние ошибки.
• проверяется, что атрибут CurrencyAmountRefs идентифицированного элемента суммы, содержит ссылку элемента, которая соответствует ID-атрибуту идентифицированного элемента вылютной суммы. Если не обнаружено ни одной или более одной подходящей ссылки элемента, возникает состояние ошибки.
• проверяется совместимость элементов в списке видов платежа. В частности, элементы выбранного вида платежа, суммы, платежного протокола и валютной суммы являются дочерними элементами идентифицированного компонента списка видов платежа. Если это не так, то это ошибка.


• Проверяется то, что кассир, который получил блок платежного запроса является кассиром, выбранным покупателем. Это включает в себя:

6.3.1.2. Доставка

Способ доступа к данным Агента доставки при проверке того, может ли он выполнить доставку показан на рис. 13.

Start
|
v
Delivery
Component
|
|ActionOrgRef
|
v
Organisation
Component
|
-Trading Role
Element
(Delivery Handler)

Рис. 13. Проверка того, что агент доставки может выполнить доставку

Процедура включает в себя следующие шаги:

• Идентификацию компонента Delivery в блоке запроса доставки. Если не обнаружено ни одного или более одного подходящего компонента доставки, возникает состояние ошибки.
• Использование атрибута ActionOrgRef компонента доставки для идентификации компонента Organisation агента доставки. Если не обнаружено ни одного или более одного подходящего компонента Organisation, возникает состояние ошибки.
• Если компонент Organisation для Агента доставки не имеет элемента торговой роли с атрибутом Role агента доставки, то это ошибка.
• Наконец, если организация, которая получила блок запроса доставки не идентифицирует компонент Organisation для агента доставки, то это ошибка.

6.3.2. Проверка компонентов Correct, присутствующих в блоке запроса

Далее проверяется то, что в блоке платежного запроса (смотри раздел 8.7) или запроса доставки (смотри раздел 8.10) присутствуют правильные компоненты. Если компоненты отсутствуют, то это ошибка.

6.3.3. Проверка авторизованности операции

Предыдущие шаги идентифицировали операционную организацию и проверяли наличие всех необходимых компонент. На данном этапе проверяется, что операционная организация авторизована для выполнения данной процедуры.

Операционная организация идентифицирует Продавца, проверяет, что с ним имеется соглашение, которое допускает выполнение операции, и что любые ограничения этого соглашения выполнены, тогда, если требуются подписи, проверяется, что они подтверждают корректные данные. Эти шаги включают в себя:

• идентификацию Продавца. Это компонент Organisation с элементом торовой роли, который имеет атрибут Role со значением Продавец. Если не обнаружено ни одного или более одного подходящего элемента торговой роли, возникает состояние ошибки.
• проверку наличия соглашений операционных организаций с Продавцом, позволяющих выполнение операции. Чтобы решить эту задачу операционная организация должна проверить, что:



• Продавец известен и существует соглашение с операционной организацией (кассиром или агентом доставки);
• им разрешено участвовать в IOTP-транзакции данного типа. Например кассир может согласиться принимать платежи в рамках операций продажи, но не не обслуживать денежные возвраты;
• любые ограничения в их соглашении с продавцом выполнены, например, требуется ли подпись отклика предложения.


• Проверка корректности подписей. Если подписи необходимы, они должны быть проверены. Это подразумевает:

6.3.3.1. Проверка корректности дайджестов подписи

Все компоненты Signature, содержащиеся в IOTP-сообщении должны включать элементы Digest, которые относятся к:

• ID компоненту транзакции (смотри раздел 3.3.1) сообщения IOTP, которое содержит компонент подписи. Это связывает глобально уникальный IotpTransId с другими компонентами, которые определяют транзакцию IOTP;
• блоку ссылок транзакции (смотри раздел 3.3) первого сообщения IOTP, которое содержит подпись. Это связывает IotpTransId с информацией о сообщении IOTP, содержащемся в ID-компоненте сообщения (смотри раздел 3.3.2).

Необходима проверка того, что каждый компонент подписи содержит элементы дайджеста, которые относятся к корректным данным.

Элементы Digest, которые должны присутствовать, зависят от торговой роли организации, генерирующей цифровую подпись:

• если подписант является продавцом, тогда:

• если подписантом, формирующим цифровую подпись, является кассир, тогда элементы дайджеста должны присутствовать для:

7. Торговые компоненты

Далее рассматриваются торговые компоненты, используемые в IOTP. Торговые компоненты являются дочерними XML-элементами, что показано на диаграмме рис. 14.

Рис. 14. Торговые компоненты

Перечень торговых компонентов представлен ниже в порядке их вероятности использования:

• Компонент протокольных опций
• Компонент запроса аутентификации
• Компонент отклика аутентификации
• Компонент запроса информации о торговой роли
• Компонент заказа
• Компонент организации
• Компонент списка видов платежа
• Компонент выбора вида платежа
• Компонент платежа
• Компонент схема платежа
• Компонент платежная расписка
• Компонент доставки
• Компонент данных доставки
• Компонент накладной
• Компонент подписи
• Компонент сертификата
• Компонент ошибки

Заметим, что следующие компоненты в других секциях этой спецификации:

• Id-компонент транзакции (смотри раздел 3.3.1)
• Id-компонент сообщения (смотри раздел 3.3.2)

7.1. Компонент протокольных опций

Опции протокола представляют собой опции, которые работают с транзакциями IOTP в целом. Определение компонента протокольных опций представлено ниже.

<!ELEMENT ProtocolOptions EMPTY >
<!ATTLIST ProtocolOptions ID ID #REQUIRED
xml:lang NMTOKEN #REQUIREDShortDesc CDATA #REQUIRED
SenderNetLocn CDATA #IMPLIEDSecureSenderNetLocn CDATA #IMPLIED
SuccessNetLocn CDATA #REQUIRED >

Атрибуты:

Этот компонент используется для облегчения выбора транзакции из списка подобных, например из базы данных транзакций IOTP, которые были запомнены Покупателем, Продавцом и т.д..

Это сетевая позиция, куда получатель блока TPO должен послать блок выбора TPO, если это требуется. Содержимое атрибута зависит от транспортного механизма.

Содержимое этого атрибута зависит от транспортного механизма.

Содержимое этого аптрибута зависит от транспортного механизма. Должен присутствовать либо SenderNetLocn, либо SecureSenderNetLocn или оба эти атрибута.

7.2. Компонент запроса аутентификации

Этот торговый компонент содержит параметр данных, которые используются при аутентификации одной торговой роли у другой. Его определение представлено ниже.

<!ELEMENT AuthReq (Algorithm, PackagedContent*)>
<!ATTLIST AuthReq ID ID #REQUIRED
AuthenticationId CDATA #REQUIREDContentSoftwareId CDATA #IMPLIED>

Если требуется, алгоритм может использовать данные вызова, содержащиеся в элементах Packaged Content из компонента запроса аутентификации. Формат Packaged Content является зависимым от алгоритма.

Атрибуты:

Cодержимое:

Алгоритмы, которые могут использоваться, идентифицированы атрибутом Name элемента Algorithm.

7.3. Компонент отклика аутентификации

Компонент отклика аутентификации содержит результаты аутентификационного запроса. Используется алгоритм, содержащийся в компоненте запроса аутентификации (смотри раздел 7.2) и выборанный из блока запроса аутентификации (смотри раздел 8.4).

В зависимости от выбранного алгоритма, результаты его применения будут содержаться в компоненте подписи, которая подтверждает отклик аутентификации, или в элементах Packaged Content компонента отклика аутентификации. Его определение представлено ниже.

<!ELEMENT AuthResp (PackagedContent*) >
<!ATTLIST AuthResp ID ID #REQUIRED
AuthenticationId CDATA #REQUIREDSelectedAlgorithmRef NMTOKEN #REQUIRED
ContentSoftwareId CDATA #IMPLIED >

Атрибуты:

Cодержимое:

Например, для заданной схемы платежа он может содержать данные, зависящие от этой схемы.

7.4. Компонент запроса информации торговой роли

Этот торговый компонент содержит список торговых ролей (смотри раздел 2.1), информация для которых запрошена. Результатом запроса торговой роли является набор компонентов Organisation (смотри раздел 7.6), которые описывают каждую из запрошенных торговых ролей. Его определение приведено ниже.

<!ELEMENT TradingRoleInfoReq EMPTY>
<!ATTLIST TradingRoleInfoReq ID ID #REQUIRED
TradingRoleList NMTOKENS #REQUIRED >

Атрибуты:

7.5. Компонент заказа

Компонент Order содержит информацию о заказе. Его определение представлено ниже.

<!ELEMENT Order (PackagedContent*) >
<!ATTLIST Order ID ID #REQUIRED

ContentSoftwareId CDATA #IMPLIED >

Атрибуты:

Cодержимое:

7.5.1. Содержимое описания заказа

Элемент Packaged Content будет в норме необходим, однако он может быть опущен там, где достаточная информация о покупке может быть получена из атрибута ShortDesc. Если необходимо полное описание заказа, могут использоваться несколько элементов Packaged Content.

Хотя сумма и валюта вероятно присутствуют в элементах Packaged Content описания заказа, они содержатся в торговых компонентах, связанных с платежом (список видов платежа, выбор вида платежа и платеж). Это означает, что важно, чтобы сумма, которая действительно дожна быть уплачена, была четко отображена для Покупателя.

Для совместимости разные реализации должны поддерживать как минимум Plain Text, HTML и XML, что облегчит отображение.

7.5.2. Временные метки OkFrom и OkTo

Заметим, что:

• Дата OkFrom может быть позже чем дата OkFrom компонента Payment (смотри раздел 7.9), связанного с этим заказом, и
• аналогично, дата OkTo может быть раньше чем дата OkTo компонента Payment (смотри раздел 7.9).

Продавец в контексте Интернет-коммерции в исходный момент с анонимными покупателями выявляет условия предложения на WEB-странице. Для того чтобы получить товар или услуги покупатель должен согласиться с этими условиями.

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

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

Заметим также, что даты OkFrom и OkTo могут также присутствовать в элементах Packaged Content описания заказа, эти даты содержатся в компоненте Order. Важно, чтобы даты OkFrom и OkTo использовались в формате, приемлемом для покупателя.

7.6. Компонент Organisation

Компонент Organisation предоставляет информацию об индивидууме или организации. Он может быть использован для различных целей, например:

• описать продавца, который продает товары,
• идентифицировать того, кто осуществляет покупку,
• идентифицировать того, кто будет доставлять товары,
• обеспечивать облуживание покупателя,
• описать того, кто будет Кассиром.

Заметим, что компоненты Organisation, которые должны присутствовать в сообщении IOTP, зависят от выполняемой транзакции. Смотри раздел 9.

Ниже представлено определение компонента.

<!ELEMENT Org (TradingRole+, ContactInfo?, PersonName?, PostalAddress?)>
<!ATTLIST Org ID ID #REQUIRED

LogoNetLocn CDATA #IMPLIED >

Атрибуты:

Атрибут используется для упрощения выбора отдельной организации из списка, например из базы данных организаций, вовлеченных в транзакции, которая записана Покупателем.

Смотри раздел 10. Содержимое этого атрибута должно соответствовать [RFC1738].

Cодержимое:

7.6.1. ID организаций

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

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

В частности, содержимое ID организации определяется следующим образом:

OrgId ::= NonConsumerOrgId | ConsumerOrgId
NonConsumerOrgId ::= DomainName
ConsumerOrgId ::= ConsumerOrgIdPrefix (namechar)+ "/" NonConsumerOrgId
ConsumerOrgIdPrefix ::= "Consumer:"
ConsumerOrgIdID организации покупателя состоит из:

• стандартного префикса, чтобы идентифицировать то, что это организация покупатель. Далее следует
• один или более символов, которые согласуются с определением "namechar" XML. Смотри спецификации [XML]. За ними следует
• NonConsumerOrgId организации, которая выдала ConsumerOrgId. Обычно это продавец. Применение символов в верхнем или нижнем регистре не играет роли.

Заметим, что NonConsumerOrgId не может начинаться с ConsumerOrgIdPrefix. Допускается использование строчных и прописных символов. Ниже приведены примеры Id организации:

• newjerseybooks.comid организации-продавца;
• westernbank.co.ukid организации-кассира;
• consumer:1000247ABH/newjerseybooks.comid организации-покупателя выданный продавцом.

7.6.2. Элемент торговая роль

Этот элемент идентифицирует торговую роль человека или организации в данной транзакции IOTP. Заметим, что организация может иметь более чем одну торговую роль и несколько ролей может присутствовать в одном элементе Organisation. Определение элемента представлено ниже:

<!ELEMENT TradingRole EMPTY >
<!ATTLIST TradingRole ID ID #REQUIRED

ErrorLogNetLocn CDATA #IMPLIED>

Атрибуты:

Этот атрибут:

• не должен присутствовать, когда TradingRole усановлено равным роли Покупателя или DelivTo,
• должен присутствовать, когда TradingRole = Продавец, Кассир или Агент доставки.

Содержимое этого атрибута зависит от транспортного механизма.

• HardError,
• Предупреждение, но Покупатель решает не продолжать транзакцию.
• TransientError и транзакция прерывается по таймауту.

Этот атрибут:

• не должен присутствовать, когда TradingRole равно Покупатель или DelivTo,
• должен присутствовать, когда TradingRole равно Продавец, Кассир или Агент доставки.

Содержимое атрибута зависит от транспортного механизма.

• HardError,
• Предупреждение, но Покупатель решает не продолжать транзакцию,
• TransientError и транзакция прерывается по таймауту.

Этот атрибут:

• не должен присутствовать, когда TradingRole = Покупатель,
• должен присутствовать, когда TradingRole равно Продавец, Кассир или Агент доставки.

Содержимое этого атрибута зависит от транспортного механизма.

Атрибут ErrorLogNetLocn может использоваться для посылки сообщений об ошибках программной компании или другой оргаанизации, ответственной за решение проблем с программами, которые посылают входные сообщения. Смотри раздел 7.21.1.

7.6.3. Элемент контактной информации

Этот элемент содержит информацию, которая может быть использована для контакта с организацией или частным лицом. Все атрибуты являются опционными, однако по крайней мере один из элементов контактной информации должен присутствовать. Его определения представлено ниже.

<!ELEMENT ContactInfo EMPTY >

Атрибуты:

Содержимое этого атрибута должно согласовываться с документом [RFC1738].

7.6.4. Элемент личного имени

Этот элемент содержит имя частного лица. Все поля являются опционными, однако GivenName (имя) или FamilyName (фамилия) должны присутствоать. Его опредление представлено ниже.

<!ELEMENT PersonName EMPTY >

Атрибуты:

7.6.5. Элемент почтового адреса

Этот элемент содержит адрес, который может быть использован, например, для физической доставки товаров, услуг или писем. Его определение предлагается ниже.

<!ELEMENT PostalAddress EMPTY >

LegalLocation (True | False) 'False' >

Атрибуты:

7.7. Компонент списка видов платежей

Компоненты списка видов платежа содержатся в блоке опций торгового протокола (смотри раздел 8.1) транзакции IOTP. Они содержат список:

• виды платежа (смотри также раздел 11.1),
• суммы, которые должны быть заплачены в валюте, которую выбрал или предложил Продавец,
• платежные протоколы, которые могут использоваться для реализации заданного вида платежа,
• сетевые позиции Кассиров, которые воспринимают платеж в рамках платежного протокола.

Определение компонента списка видов платежа представлено ниже.

<!ELEMENT BrandList (Brand+, ProtocolAmount+, CurrencyAmount+, PayProtocol+)>

<!ATTLIST BrandList ID ID #REQUIRED

xml:lang NMTOKEN #REQUIREDShortDesc CDATA #REQUIRED

PayDirection (Debit | Credit) #REQUIRED>

Атрибуты:

• Дебит. Отправитель блока платежного запроса (напр., покупатель), к которому имеет отношение список видов платежа, произведет платеж кассиру.
• Кредит. Отправитель блока платежного запроса к которому имеет отношение список видов платежа, получит платеж от кассира.

Cодержимое:

• видами валюты и суммами в элементах CurrencyAmount, которые могут использоватьсясовместно с видами платежа, и
• Платежными протоколами и Кассирами, которые могут использоваться с этими видами валюты и суммами для конкретного вида платежа.

Отношения между элементами, которые образуют содержание списка видов платежа проиллюстрированы на рис. 15.

Рис. 15. Отношения элементов списка видов платежа

Примеры списков видов платежа содержатся в главе 11.2.

7.7.1. Элемент Brand

Элемент Brand описывает вид платежа, который может быть использован при оплате покупки. Один или более таких элементов образуют компонент списка видов платежа, который имеет атрибут PayDirection, установленный равным Debit. Только один элемент вида платежа может содержаться в компоненте списка видов платежа (Brand List), который имеет атрибут PayDirection = Credit.

<!ELEMENT Brand (ProtocolBrand*, PackagedContent*) >

СontentSoftwareId CDATA #IMPLIED>

Атрибуты:

Так как значения BrandId управляются процедурами IANA, допускается определение значений самим пользователем.

Содержимое этого атрибута должно соответствовать документу [RFC1738].

Cодержимое:

Пример элементов вида платежа имеется в разделе 11.2.

7.7.2. Элемент протокола вида платежа

Элемент протокола вида платежа содержит информацию, которая является специфической для применения определенного протокола к некоторому виду платежей. Его определение предложено ниже.

<!ELEMENT ProtocolBrand (PackagedContent*) >

<!ATTLIST ProtocolBrand ProtocolId CDATA #REQUIRED

ProtocolBrandId CDATA #REQUIRED >

Атрибуты:

Значения ProtocolId должно быть уникальным в пределах элемента Brand, в противном случае происходит ошибка.

Корректные значения этого атрибута описаны в приложении для платежных протоколов, идентифицированных ProtocolId, которые определяют, как платежный протокол работает с IOTP.

Cодержимое:

7.7.3. Элемент Protocol Amount

Элемент Protocol Amount связывает вид платежа с:

• видом валюты и суммами в элементах Currency Amount (смотри раздел 7.7.4), которые могут использоваться с данным видом платежа, и
• платежными протоколами и Кассирами, определенными в элементе платежного протокола (смотри раздел 7.7.5), котоый может быть использован для этого видв валюты и сумм платежа.

Его определение представлено ниже:

<!ELEMENT ProtocolAmount (PackagedContent*) >
<!ATTLIST ProtocolAmount ID ID #REQUIRED
PayProtocolRef IDREF #REQUIREDCurrencyAmountRefs IDREFS #REQUIRED
ContentSoftwareId CDATA #IMPLIED >

Атрибуты:

Cодержимое:

Примеры элементов Protocol Amount приведены в секции 11.2.

7.7.4. Элемент валютной суммы

Элемент валютной суммы содержит в себе:

• код валюты (и ее тип),
• сумму.

Один или более таких элементов заключены в каждом компоненте списка видов платежа. Его определение приведено ниже:

<!ELEMENT CurrencyAmount EMPTY >
<!ATTLIST CurrencyAmount ID ID #REQUIRED
CurrCode CDATA #REQUIRED >

Атрибуты:

• ISO4217-A (по умолчанию) указывает код валюты с помощью трех буквенных символов, которые должны согласовываться с [ISO 4217]
• IOTP указывает, что значения CurrCode управляются процедурой, описанной в разделе 12.

Так как значения CurrCodeType управляются процедурой, описанной в секции 12, допускается определение пользователем собственных значений CurrCodeType. Примеры элементов Currency Amount представлены в разделе 11.2.

7.7.5. Элемент платежного протокола

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

<!ELEMENT PayProtocol (PackagedContent*) >
<!ATTLIST PayProtocol ID ID #REQUIRED

ContentSoftwareId CDATA #IMPLIED>

Атрибуты:

Значения ProtocolId определены схемой/методом платежа владельцев в документе, который описывает, как инкапсулировать платежный протокол в IOTP.

Содержимое этого атрибута зависит от транспортного механизма (и должно быть согласованос документом [RFC1738].

Содержимое этого атрибута должно согласовываться с регламентациями документа [RFC1738]. Смотри раздел 3.9.

ContentSoftwareIdСмотри раздел 14. Словарь.

Cодержимое:

Примеры элементов платежного протокола содержатся в разделе 11.2.

7.8. Компонент выбора вида платежа

Компонент выбора вида платежа идентифицирует выбор вида платежа, платежный протокол и кассира. Этот элемент используется:

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

В базовой версии IOTP, целостность компонентов выбора вида платежа не гарантируется. Однако модификация компонентов выбора вида платежа может привести лишь к отказу обслуживания, если сам платежный протокол безопасен и контролирует модификацию или дублирование сообщений и может противостоять любым другим атакам.

Определение компонента выбора вида платежа представлено ниже.

<!ELEMENT BrandSelection (BrandSelBrandInfo?, BrandSelProtocolAmountInfo?,

BrandSelCurrencyAmountInfo?) >

<!ATTLIST BrandSelection ID ID #REQUIRED

ProtocolAmountRef NMTOKEN #REQUIRED
CurrencyAmountRef NMTOKEN #REQUIRED >

Атрибуты:

Cодержимое:

Используются следующие правила:

• атрибут BrandListRef должен содержать идентификатор компонента списка видов платежа транзакции IOTP;
• на каждый компонент списка видов платежа в блоке опций торгового протокола (смотри раздел 8.1) должен ссылаться один и только один компонент выбора вида платежа.
• BrandRef должен относиться к ID Brand, содержащегося в компоненте списка видов платежа, на который ссылается BrandListRef
• ProtocolAmountRef должен относиться к одному ID элемента, содержащемуся в атрибуте ProtocolAmountRefs элемента Brand, идентифицированного BrandRef
• CurrencyAmountRef должен относиться к одному ID элемента содержащемуся в атрибуте ProtocolAmountRefs элемента Protocol Amount, идентифицированного ProtocolAmountRef.

Пример компонента выбора вида платежа включен в раздел 11.2.

7.8.1. Информационный элемент выбора вида платежа

Информационный элемент выбора вида платежа cсодержит любую дополнительную информацию, которая может быть необходима для какого-то конкретного вида платежа. Смотри приложение IOTP для платежных методов, где описано применние этого элемента.

<!ELEMENT BrandSelBrandInfo (PackagedContent+) >
<!ATTLIST BrandSelBrandInfo ID ID #REQUIRED ContentSoftwareId CDATA #IMPLIED >

Атрибуты:

Cодержимое:

7.8.2. Элемент Amount Info протокола выбора вида платежа

Элемент Amount Info протокола выбора вида платежа содержит любую дополнительную информацию, зависящую от платежного протокола, которая может быть необходима для конкретного вида платежа или плптежного протокола. Смотри приложение IOTP по платежным методам, где описаны методы использования данного элемента.

<!ELEMENT BrandSelProtocolAmountInfo (PackagedContent+)>
<!ATTLIST BrandSelProtocolAmountInfo ID ID #REQUIRED
ContentSoftwareId CDATA #IMPLIED>

Атрибуты:

Cодержимое:

7.8.3. Информационный элемент валютной суммы выбора вида платежа (Brand Selection Currency Amount Info)

Информационный элемент валютной суммы выбора вида платежа содержит любую дополнительную информацию, зависящую от вида платежа и валюты, которая может быть необходима при конкретном виде платежа. Смотри приложение IOTP по платежным методам, где описаны методы использования данного элемента.

<!ELEMENT BrandSelCurrencyAmountInfo (PackagedContent+)>
<!ATTLIST BrandSelCurrencyAmountInfo ID ID #REQUIRED
ContentSoftwareId CDATA #IMPLIED>

Атрибуты:

Cодержимое:

7.9. Компонент платежа (Payment)

Компонент платежа содержит информацию, используемую для управления процедурой выполнения платежа. Он предоставляет информацию о:

• Временном интервале в пределах которого Кассир может начать платежную операцию;
• Ссылку на список видов платежа (смотри раздел 7.7), который идентифицирует виды платежа, протоколы, виды валюты и суммы, которые могут использоваться при осуществлении платежа.
• следует ли предоставлять платежную расписку;
• должен ли данному платежу предшествовать другой платеж.

Его определение выглядит следующим образом.

<!ELEMENT Payment EMPTY > <!ATTLIST Payment ID ID #REQUIRED

StartAfterRefs NMTOKENS #IMPLIED>

Атрибуты:

7.10. Компонент платежной схемы

Компонент платежной схемы содержит информацию платежного протокола для специфической платежной схемы, реализуемой между партнерами, вовлеченными в платеж, например [SET]-сообщение. Определение компонента представлено ниже.

<!ELEMENT PaySchemeData (PackagedContent+) >
<!ATTLIST PaySchemeData ID ID #REQUIRED

Атрибуты:

Cодержимое:

Заметим, что:

• значения атрибута Name каждого элемента pakaged content определены в приложении для платежных протоколов;
• значение каждого Name должно быть уникальным для платежа, где платеж определяется как совокупность всех платежных схем или компонентов платежных расписок с идентияным значением атрибута PaymentRef.

7.11. Компонент платежной расписки

Платежная расписка представляет собой запись о платеже, которая показывает, какая сумма заплачена или получена. Она отдичается от расписки о покупке, тем что здесь нет записи о том, что куплено. Обычно в компоенте платежной расписки содержатся данные, которые описывают:

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

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

Точное определение содержимого платежной расписки зависит от метода платежа. Информация, содержащаяся в компоненте платежной расписки, должна отображаться или каким-либо другим способом доводиться до сведения Покупателя.

Если компонент платежной расписки содержит сообщения платежного протокола, тогда они должны быть обработаны программой метода платежа,чтобы преобразовать их в формат понятный Покупателю.

Определение компонента платежной расписки.

<!ELEMENT PayReceipt (PackagedContent*)>

ContentSoftwareId CDATA #IMPLIED>

Атрибуты:

Программа клиента должна спасать все компоненты, на которые имеются ссылки, с тем чтобы платежная расписка могла быть воспроизведена, если это потребуется.

Cодержимое:

Заметим, что:

Заметим, что должны присутствоать либо атрибут PayReceiptNameRefs, либо элемент PackagedContent или оба.

7.12. Компоент Payment Note

Компонент Payment Note (платежное заывление) содержит дополнительную, несвязанную с платежом информацию, которую Кассир хочет предоставит покупателю. Например, если был произведен отзыв сделки или осуществлен депозит, тогда он может содержать информацию о балансе по завершении перевода. Данные должны дублировать информацию, содержащуюся в компоненте платежной расписки.

Информация, содержащаяся в компоненте Payment Note должна быть отображена или представлена каким-то иным способом покупателю. Для совместимости компонент Payment Note должен поддерживать как минимум содержимое типа "Plain Text", HTML и XML. Его определение представлено ниже.

<!ELEMENT PaymentNote (PackagedContent+) >
<!ATTLIST PaymentNote ID ID #REQUIREDContentSoftwareId CDATA #IMPLIED>

Атрибуты:

Cодержимое:

7.13. Компонент доставки

Компонент доставки содержит информацию, необходимую для доставки товаров или услуг. Его определение приведено ниже.

<!ELEMENT Delivery (DeliveryData?, PackagedContent*) >
<!ATTLIST Delivery ID ID #REQUIRED

Атрибуты:

Если DelivExch = true, должен присутствовать элемент DeliveryData. Если DelivExch = false, он может отстутствовать.

Атрибут DelivAndPayResp не должен иметь значение “истинно”, если DelivExch = “ложно”.

На практике комбинирование блока отклика доставкии блока отклика платежа имеет смысл только в случае, когда Продавец, Кассир и Агент доставки принадлежат одной организации, так как:

Cодержимое:

7.13.1. Элемент Delivery Data

Элемент DeliveryData содержит информацию о том, куда и как должны доставляться товары или услуги. Его определение представлено ниже.

<!ELEMENT DeliveryData (PackagedContent*) >

ContentSoftwareId CDATA #IMPLIED>

Атрибуты:

Значения DelivMethod управляются процедурой, описанной в разделе 12, что допускает определение новых кодов пользователем.

Безопасный запрос доставки предполагает использование безопасного канала, такого как [SSL/TLS] для того чтобы взаимодействовать с кассиром.

Содержимое этого атрибута зависит от транспортного механизма и должно соответствовать регламентациям документа [RFC1738]. Смотри также раздел 3.9.

Cодержимое:

7.14. Информационный компонент доставки Покупателя

Информационный компонент доставки покупателя используется покупателем для спецификации идентификатора, который может быть использован им для идентификации доставки. Его определение приведено ниже:

<!ELEMENT ConsumerDeliveryData EMPTY>
<!ATTLIST ConsumerDeliveryData ID ID #REQUIRED
ConsumerDeliveryId CDATA #REQUIRED>

Атрибуты:

7.15. Компонент Delivery Note

Компонент Delivery Note (накладная)содержит инструкции о доставке товаров или услу, или саму информацию о доставке. Это информация, которую частное лицо или организация, получающие накладную, могут использовать, когда осуществляется доставка.

Для совместимости компонент Delivery Note должен поддерживать Plain Text, HTML и XML. Его определение представлено ниже.

<!ELEMENT DeliveryNote (PackagedContent+) >

Атрибуты:

Cодержимое:

Если содержимым сообщения доставки является сообщение Mime, тогда Delivery Note может запустить приложение, которое вызываеть реальный процесс доставки.

7.16. Компонент Status

Компонент Status содержит информацию состояния бизнес-процесса (успех или неудача) (смотри раздел 4.2). Его определение приведено ниже.

<!ELEMENT Status EMPTY >

ProcessState (NotYetStarted | InProgress | CompletedOk | Failed | ProcessError) #REQUIRED
CompletionCode NMTOKEN #IMPLIED
ProcessReference CDATA #IMPLIEDStatusDesc CDATA #IMPLIED >

Атрибуты:

“Непределено” означает, что тип документального обмена не может быть идентифицирован. Это может быть вызвано ошибкой исходного входного обмена сообщениями. Значения StatusType управляется процедурой, описанной в секции 12 (IANA), и допускающей определение новых значений пользователем.

Заметим, что этот код сообщает об обработке блока запроса. Далее, после посылки блока отклика, сопряженного с процессом, может осуществляться асинхронная обработка.

CompletionCode может иметь до 14 символов.

Этот атрибут должен отсутствовать в сообщении информационного запроса, когда Покупателю сервис-провайдером IOTP не был дан код ссылки.

Этот атрибут может быть использован внутри блока информационного отклика (смотри раздел 8.13), для того чтобы предоставить код ссылки для транзакции, которя ранее была недоступна.

Например, код упаковки может быть не присвоен в момент получения отклика доставки. Однако, если покупатель поздее выдаст запрос состояния транзакции, Агент доставки может проставить код упаковки в атрибут сообщения информационного отклика и послать его Покупателю.

7.16.1. Коды завершения предложения

Код завершения является единственно необходимым, если атрибут ProcessState = Failed (неудача). Ниже следующая таблица содержит допустимые значения CompletionCode, которые могут использоваться и индицировать, возможно ли восстановление процесса. Рекомендуется, чтобы там, где это необходимо для дальнейшего разъяснения, использовался атрибут StatusDesc.

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

Восстановление возможно, если последнее сообщение от другой торговой роли получено снова.

7.16.2. Коды завершения платежа

CompletionCode необходим, если атрибут ProcessState = Failed. Ниже следующая таблица содержит допустимые значения CompletionCode, которые могут использоваться и индицировать, когда возможно восстановление. Рекомендуется, чтобы атрибут StatusDesc использовался индивидуальными платежными схемами для предоставления дальнейших пояснений, там где это уместно.

Ниже приведены опции восстановления.

Если оплата не зависит от вида платежа, тогда покупатель решить проблему путем выбора другой валюты, если она имеется, или заменой вида платежа. Заметим, что это может потребовать замены кассира.

Если оплата не зависит от вида платежа, тогда восстановление для некоторых видов кода завершения возможно для покупателя, который может выбрать другой вид платежа или новый платежный инструмент для того же вида платежа. Заметим, что это может потребовать замены кассира. Здесь применимы следующие коды: BrandNotSupp, PaymtCancelled, InsuffFunds, InstBrandInvalid, InstNotValid, BadInstrument и Unspecified.

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

7.16.3. Коды завершения доставки

Таблица, представленная ниже, содержит допустимые значения атрибута CompletionCode для доставки. Рекомендуется, чтобы для разъяснения ситуации использовался атрибут StatusDesc.

Восстановление при неудаче или в случае частично завершенной доствки невозможно. Покупатель для получения текущего состояния транзакции должен использовать информационный запрос (смотри раздел 9.2.1).

7.16.4. Коды завершения аутентификации

Код завершения необходим только в случае, если атрибут ProcessState = Failed. Ниже следующая таблица содержит допустимые значения атрибута CompletionCode, которые можно использовать. Рекомендуется, чтобы для разъяснения ситуации использовался атрибут StatusDesc.

7.16.5. Неопределенные коды завершения

Код завершения требуется только тогда, когда атрибут ProcessState = Failed. Таблица, представленная ниже, содержит допустимые значения атрибута CompletionCode, которые могут быть использованы. Рекомендуется, чтобы для разъяснения ситуации использовался атрибут StatusDesc.

7.16.6. Коды завершения информационного запроса транзакции

Код завершения требуется только тогда, когда атрибут ProcessState = Failed. Таблица, представленная ниже, содержит допустимые значения атрибута CompletionCode, которые могут быть использованы. Рекомендуется, чтобы для разъяснения ситуации использовался атрибут StatusDesc.

7.17. Компонент данных торговой роли

Компонент данных торговой роли содержит данные, которые должны быть пересланы между торговыми ролями вовлеченными в транзакцию.

Компоненты торговой роли определяют:

o   организацию, которая сформировала компонент и
o   организацию, которая его получила.

Они являются первыми сформированными и включенными в блок “отклик” и затем скопированных в соответствующий блок “запрос”. Например, кассиру может оказаться нужно проинформировать агента доставки о том, что платеж через кредитную карточку авторизован (but not captured). В другом примере продавцу может понадобиться предоставить кассиру некоторую специфическую информацию о Покупателе.

Его определение представлено ниже.

<!ELEMENT TradingRoleData (PackagedContent+) >
<!ATTLIST TradingRoleData ID ID #REQUIRED
OriginatorElRef NMTOKEN #REQUIREDDestinationElRefs NMTOKENS #REQUIRED>

Атрибуты:

Cодержимое:

7.17.1. Кто получает компонент данных о торговой роли

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

• Когда бы ни был получен компонент данных торговой роли в блоке "Отклик", идентифицировать компоненты Organisation, которые должны получить его, как идентифицированные атрибутом DestinationElRefs.
• Когда бы ни был послан блок "Запрос", проверить, был ли он послан одной из организаций (адресат), идентифицированной атрибутом. Если это так, включить в блок "Запрос" следующее:

7.18. Компонент типа информационного запроса

Компонент типа информационного запроса содержит информацию, которая указывает тип процесса, о котором получен запрос. Его определение представлено ниже.

<!ELEMENT InquiryType EMPTY >
<!ATTLIST InquiryType ID ID #REQUIREDType NMTOKEN #REQUIRED
ElRef NMTOKEN #IMPLIEDProcessReference CDATA #IMPLIED>

Атрибуты:

7.19. Компонент Signature (подпись)

Определения структур XML для подписей и сертификатов описаны в документе "Digital Signatures for the Internet Open Trading Protocol" Kent Davidson и Yoshiaki Kawatsura, опубликованном одновременно с этим документом - смотри [IOTPDSIG].

В будущем ожидается, что новые версии IOTP зафиксируют какой-то метод цифровой подписи XML в к ачестве стандарта.

Каждый компонент подписи цифровым образом подтвержжает один или более блоков или компонентов, включая компоненты подписи.

Компонент подпись:

• содержит дайджесты одного или более блоков или компонентов в одном или нескольких IOTP-сообщениях в пределах одной транзакции IOTP и помещает результат в элемент Digest;
• объединяет элементы дайджестов с другой информацией о типе подписи, об отправителе и потенциальных получателях, а также об используемом алгоритме подписи, и помещает их в элемент Manifest,
• подписывает элемент Manifest, используя опционный сертификат, идентифицированный в компоненте Certificate блока Signature, помещая результат в элемент Value комполнента Signature.

Заметим, что может быть много элементов Value, которые содержат подписи элемента Manifest. Компонент Signature может иметь один из четырех типов:

• Подпись отклика предложения,
• Подпись отклика платежа,
• Подпись отклика доставки, или
• Подпись отклика аутентификации.

Для общего объяснения подписей смотри раздел 6.

7.19.1. Использование элементов подписи и атрибутов IOTP

Определения элементов и атрибутов содержится в [IOTPDSIG]. Ниже представлена дополнительная информация, которая описывает, как эти элементы и атрибуты используются в IOTP.

Элемент SIGNATURE
ID-атрибут является обязательным.

Элемент MANIFEST

Опционный атрибут LocatorHrefBase содержит текст, который должен быть включен до текста, содержащегося в атрибуте LocatorHREF всех элементов Digest в пределах элемента Manifest.

Целью элемента Manifest является сокращение значения атрибута LocatorHREF, так как первая часть атрибутов LocatorHREF в подписи идентична.

Обычно в IOTP он будет содержать все символы атрибута LocatorHref вплоть до ("#") (смотри текст ниже).

Элементы ALGORITHM и PARAMETER
Элемент algorithm идентифицирует алгоритмы, использованные при формировании подписи. Тип алгоритма определяется значением алгоритма Type, который указывает, следует ли его использовать в качестве Digest-алгоритма, алгоритма подписи или алгоритма Key Agreement. Следует использовать следующие алгоритмы дайджестов:

• алгоритм [DOM-HASH]. Идентифицируется путем установки атрибута Name элемента Algorithm равным "urn:ibm:dom-hash";
• алгоритм [SHA1]. Идентифицируется путем установки атрибута Name элемента Algorithm равным "urn:fips:sha1" и
• алгоритм [MD5]. Идентифицируется путем установки атрибута Name элемента Algorithm равным "urn:rsa:md5".
• Следует применять следующие алгоритмы подписи:
• алгоритм [DSA]. Идентифицируется путем установки атрибута Name элемента Algorithm равным "urn:us.gov:dsa"
• алгоритм [HMAC]. Идентифицируется путем установки атрибута Name элемента Algorithm равным "urn:ibm:hmac"

Рекомендуется, чтобы использовался также следующий алгоритм подписи:

• алгоритм [RSA]. Идентифицируется путем установки атрибута Name элемента Algorithm равным "urn:rsa:rsa"

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

Один алгоритм может использовать другие алгоритмы через посредство элемента Parameter, например:

<Algorithm ID=A1 type="digest" name="urn:ibm:dom-hash">
<Parameter type='AlgorithmRef'>A2</Parameter> </Algorithm>
<Algorithm ID=A2 type="digest" name="urn:fips:sha1"> </Algorithm>
<Algorithm ID=A3 type="signature" name="urn:ibm:hmac">

Элемент DIGEST

Атрибут LocatorHREF идентифицирует элемент IOTP, который подписан цифровым образом. Он состоит из:

• значения ID-атрибута IotpTrans ID-компонента транзакции, за которым следует:
• символ "#", за которым следует
• ссылка элемента (смотри раздел 3.5) на элемент транзакции IOTP, который является субъектом дайджеста.

Прежде чем анализировать структуру атрибута LocatorHREF, он должен быть объединен со значением атрибута LocatorHrefBase элемента Manifest (смотри непосредственно выше).

Элемент атрибут

Должен существовать один и только один элемент атрибута, который содержит атрибут Type со значением типа подписи и содержимым равным одному из: OfferResponse, PaymentResponse, DeliveryResponse, AuthenticationRequest, AuthenticationResponse, PingRequest или PingResponse; в зависимости от типа подписи.

Значения содержимого элемента атрибута управляются процедурой, определенной в разделе 12 (IANA), и допускающей определение значений пользователем.

Атрибут Critical должен быть установлен равным true.

Элемент ORIGINATORINFO

Атрибут OriginatorRef элемента OriginatorInfo должен всегда присутствовать и содержать ссылку элемента (смотри раздел 3.5) на компонент Organisation организации, которая сформировала компонент Signature.

Элемент RECIPIENTINFO

Атрибут RecipientRefs содержит список ссылок (смотри раздел 3.5), указывающих на организации, которые должны будут проверить подлинность подписи.

7.19.2. Компонент подписи отклика предложения

Элемент Manifest подписи, который имеет тип OfferResponse должен содержать элементы дайджеста для следующих компонентов:

• Id-компонент транзакции (смотри раздел 3.3.1) сообщения IOTP, которое содержит подпись отклика предложения;
• Блок ссылки транзакции (смотри раздел 3.3) сообщения IOTP, которое содержит подпись отклика предложения
• из блока TPO:

• опционно, все компоненты выбора вида платежа, если они посланы Продавцу в блоке выбора TPO;
• из блока отклика предложения:

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

• если продавец получил блок выбора TPO, содержащий компоненты выбора вида платежа, тогда генерируется элемент дайджеста для кассира, идентифицированного компонентом выбора вида платежа, и для агента доставки, идентифицированного компонентом Delivery. Смотри раздел 6.3.1.
• если Продавец не ожидает получить блок выбора TPO, тогда ренерируется элемент дайджеста для Агента доставки и всех Кассиров, вовлеченных в сделку.

7.19.3. Компонент подписи платежной расписки

Элемент Manifest компонента подписи платежной расписки должен содержать элеиенты Digest для следующих компонентов:

• Id-компонент транзакции (смотри раздел 3.3.1) сообщения IOTP, который содержит подпись платежной расписки;
• Блок ссылки транзакции (смотри раздел 3.3) сообщения IOTP, который содержит подпись платежной расписки;
• компонент подписи отклика предложения;
• компонент платежной расписки;
• компонент Payment Note;
• компонент Status;
• компонент выбора вида платежа;
• любой компонент данных о торговой роли.

7.19.4. Компонент подписи отклика доставки

Элемент Manifest компонента отклика доставки должен содержать элементы Digest для следующих компоентов:

• Id-компонент транзакции (смотри раздел 3.3.1) сообщения IOTP, который содержит подпись отклика доставки;
• блок ссылки транзакции (смотри раздел 3.3) сообщения IOTP, который содержит подпись отклика доставки;
• компонент данных доставки покупателя, содержащихся в предыдущем запросе доставки (если имется);
• компоненты Signature, содержащиеся в предыдущем запросе доставки (если имется);
• компонент Status;
• компонент Delivery Note.

7.19.5. Компонент подписи запроса аутентификации

Элемент Manifest компонента подписи запроса аутентификации должен содержать элементы Digest для следующих компонентов:

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

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

7.19.6. Компонент подписи отклика аутентификации

Элемент Manifest компонента подписи отклика аутентификации должен содержать элементы Digest для следующих компонентов:

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

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

7.19.7. Компонент подписи информационного запроса

Если информационный запрос подписан (смотри раздел 9.2.1) элемент Manifest компонента подписи информационного запроса должен содержать элементы Digest компонента типа информационного запроса и, если присутствует, компонент схемы платежа.

7.19.8. Компонент подписи

Если информационный отклик подписан (смотри раздел 9.2.1) элемент Manifest компонента подписи информационного запроса должен содержать элементы Digest блока торгового отклика и компонент Status.

7.19.9. Компонент подписи запроса Ping

Если запрос Ping подписан (смотри раздел 9.2.2), элемент Manifest компонента подписи запроса Ping должен содержать элементы Digest для всех компонентов Organisation.

7.19.10. Компонент подписи отклика Ping

Если отклик Ping подписан (смотри раздел 9.2.2), элемент Manifest компонента подписи запроса Ping должен содержать элементы Digest для всех компонентов Organisation.

7.20. Компонент Certificate

Определения структур XML для подписей и сертификатов описаны в работе "Digital Signatures for the Internet Open Trading Protocol", смотри [IOTPDSIG]. Смотри также начало раздела 7.19.

Компонент Certificate содержит цифровой сертификат. Они используются только, когда, например, использована асиметричная криптография и верифицирующий получатель подписи не получил еще общедоступного ключа (Public Key). Структура сертификата определена в [IOTPDSIG].

7.20.1. Использование в IOTP атрибутов и элементов подписи

Подробные определения упомянутых выше элементов и атрибутов содержатся в [IOTPDSIG]. Далее представлена дополнительная информация, которая описывает, как эти элементы и атрибуты используются в IOTP.

Компонент CERTIFICATE
ID-атрибут является обязательным.

Элемент VALUE
ID-атрибут является обязательным.

7.21. Компонент Error

Компонент Error содержит информацию о технических ошибках (смотри раздел 4.1) в сообщении IOTP, которое было получено одной из торговых ролей, вовлеченных в сделку. Для ясности ниже приведены две фразы, которые определяют использование компонента Error:

• сообщение сопряжено с ошибкой. Сообщение IOTP, которое содержит или вызывает ошибку какого-то вида;
• сообщение, уведомляющее об ошибке. Сообщение IOTP, которое содержит компонент Error, который описывает ошибку, обнаруженную в сообщении.

Определение компонента Error представлено ниже.

<!ELEMENT ErrorComp (ErrorLocation+, PackagedContent*) >
<!ATTLIST ErrorComp ID NMTOKEN #REQUIRED
xml:lang NMTOKEN #REQUIREDErrorCode NMTOKEN #REQUIRED
ErrorDesc CDATA #REQUIRED Severity (Warning|TransientError|HardError) #REQUIRED

Атрибуты:

Если атрибут Severity не равен TransientError, тогда значение этого атрибута игнорируется.

Cодержимое:

Если Severity ошибки не равно TransientError, может быть, если требуется, специфицировано более одного ErrorLocation, в зависимости от природы ошибки (смотри раздел 7.21.2) и от конкретной реализации программы.

7.21.1. Общие принципы обработки ошибок

Если об ошибке уведомляют более чем один компонент Error в сообщении, следует выполнять обработку компонента Error с наивысшим значением атрибута severity. В этом контексте, HardError имеет выше уровень “серьезности” (severity), чем TransientError, который имеет серьезность выше, чем Warning.

7.21.1.1. Severity = предупреждение

Если приложение генерирует сообщение об ошибке с компонентом Error, где атрибут Severity = Warning, тогда, если сообщение об ошибке не содержит другого компонента ошибки с атрибутом Severity выше, чем Warning, сообщение должно включать торговые блоки и компоненты, которые следовало бы включить, если бы сообщения об ошибке отсутствовало. Если сообщение получено с компонентом Error, где Severity = Warning, тогда:

• рекомендуется, чтобы информация об ошибке была доведена до сведения пользователя,
• разработчик приложения IOTP должен:

Если предполагается продолжить транзакцию, тогда, если нет других компонентов Error с более высоким уровнем серьезности, следует проверить, что наличиствуют торговые блоки и компоненты, необходимые для продолжения транзакции. Если они не сформированы, то вырабатывается сообщение с компонентом Error и Severity = HardError.

7.21.1.2. Severity = переходная ошибка

Если приложение генерирует сообщение с компонентом Error, где атрибут Severity = TransientError, тогда в сообщение должен быть только один компонент Error. Кроме того, должен присутствовать атрибут MinRetrySecs. Если сообщение, уведомляющее об ошибке получено с компонентом Error, где Severity = TransientError тогда:

• если атрибут MinRetrySecs присутствует и имеет правильное значение, тогда следует использовать данную величину MinRetrySecs. В противном случае, если MinRetrySecs отсутствует или имеет неверное значение, тогда:

• Проверить, что только один элемент ErrorLocation содержится в компоненте Error и что он относится к сообщению, которое было послано получателем компонента Error с Severity = TransientError. Если имеется более одного элемента ErrorLocation, тогда генерируется сообщение со степенью серьезности равным HardError.

7.21.1.3. Severity = Hard Error

Если приложение генерирует сообщение об ошибке с компонентом Error, где атрибут Severity = HardError, тогда в сообщении должен быть только один компонент Error.

Если получено сообщение с компонентом Error, где атрибут Severity = HardError, транзакция прерывается.

7.21.2. Коды ошибок

Ниже следующая таблица содержит допустимые значения атрибута ErrorCode компонента Error. Первое предложение описания содержит текст, который должен использоваться для описания ошибки при отображении. Индивидуальные реализации могут транслировать его на альтернативные языки по своему усмотрению. ErrorCode не должен быть длиннее 14 символов.

Для плохо сформатированного XML, следует попытаться извлечь блок ссылок транзакции, с тем чтобы корректно сформировать отклик Error.

В этом случае следует установить PackagedContent компонента Error соответствующим типу пропущенного элемента.

В этом случае следует установить PackagedContent компонента Error соответствующим типу пропущенного атрибута.

В этом случае следует создать элементы ErrorLocation, которые определяют все несогласованные атрибуты или элементы.

Если транспортный механизм сервера/системы (например, HTTP) занят, следует использовать транспортные ошибки. Этот код нужно использовать в связи с серверами/системами IOTP или другими аналогичными системами, с которыми связан IOTP.

7.21.3. Элемент положения ошибки

Элемент Error Location указывает элемент и опционно атрибут в сообщении, с которым ассоциируется ошибка. Он содержит ссылку на сообщение IOTP, торговый блок, торговый компонент, элемент и атрибут, где обнаружена ошибка.

<!ELEMENT ErrorLocation EMPTY >

AttName NMTOKEN #IMPLIED>

Атрибуты:

Заметим, что следует включать как можно больше атрибутов. Например, если атрибут в дочернем элементе торгового компонента содержит неверное значение, тогда должны присутствовать все атрибуты ErrorLocation.

8. Торговые блоки

Торговые блоки являются дочерними элементами IOTP-сообщения верхнего уровня, которое послано в форме [XML]-документа от одного партнера торговой операции к другому.

Каждый трговый блок состоит из одного или более торговых компонентов (смотри раздел 7). Это проиллюстрировано на диаграмме.

Рис. .16. Торговые блоки

Торговые блоки определены как часть определения сообщения IOTP (смотри раздел 3.1.1). Определение элемента сообщения IOTP представлено ниже:

<!ELEMENT IotpMessage

) >

Далее в данном разделе определены торговые блоки данной версии IOTP. Это:

• Блок запроса аутентификации (Authentication Request Block)
• Блок отклика аутентификации (Authentication Response Block)
• Блок состояния доставки
• Блок Cancel
• Блок запроса доставки
• Блок отклика доставки
• Блок Error
• Блок информационного запроса
• Блок информационного отклика
• Блок отклика Offer
• Блок платежного обмена
• Блок платежного запроса
• Блок платежного отклика
• Блок подписи
• Блок опций торгового протокола
• Блок выьора TPO

Блок ссылок транзакции определен в разделе 3.3.

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

Торговый блок TPO содержит опции, которые применяются в транзакции IOTP. Определение торгового блока TPO представлено ниже.

<!ELEMENT TpoBlk ( ProtocolOptions, BrandList*, Org* )>
<!ATTLIST TpoBlk ID ID #REQUIRED >

Атрибуты:

Cодержимое:

Блок TPO должен содержать:

• компонент протокольных опций;
• компонент Organisation с торговой ролью Продавца;
• компонент Organisation с торговой ролью Покупателя;
• опционно, компонент организации торговой ролью DeliverTo, если транзакция предполагает доставку;
• компоненты списка видов платежа для каждого платежа транзакции;
• компоненты Organisation для Кассира, включенного в транзакцию;
• опционно, компоненты Organisation для Агента доставки (если имеется) транзакции;
• дополнительные компоненты Organisation, которые Продавец захочет включить. Например.

8.2. Блок выбора TPO

Блок выбора TPO содержит результаты выбора, сделанного из списка, содержащегося в блоке протокольных опций (смотри раздел 8.1). Определение блока выбора TPO предлагается ниже.

<!ELEMENT TpoSelectionBlk (BrandSelection+) >
<!ATTLIST TpoSelectionBlk ID ID #REQUIRED>

Атрибуты:

Cодержимое:

Блок выбора TPO должен содержать по одному компоненту выбора вида платежа для каждого списка видов платежа блока TPO.

8.3. Блок отклика Offer

Блок отклика Offer содержит подробности о товарах, услугах, сумме, инструкций доставки или финансовых операциях, которые должны быть осуществлоены. Его определение дано ниже.

<!ELEMENT OfferRespBlk (Status, Order?, Payment*, Delivery?, TradingRoleData*)>
<!ATTLIST OfferRespBlk ID ID #REQUIRED>

Атрибуты:

Cодержимое:

Компонент Order должен присутствовать, если только атрибут ProcessState компонента Status не равен Failed.

Блок отклика Offer должен содержать:

• компонент Order транзакции;
• компоненты Payment для каждой проплаты транзакции;
• компонент Delivery транзакции (если предусмотрено).

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

Блок запроса аутентификации содержит данные, которые используются одной из торговых ролей для получения информации и опционно для аутентификации другой торговой роли. Этот блок содержит:

• информацию о том, как аутентифицировать себя и/или
• запрос о дополнительной информации об организации, которую надлежит аутентифицировать.

Его определение предагается ниже.

<!ELEMENT AuthReqBlk (AuthReq*, TradingRoleInfoReq?)>
<!ATTLIST AuthReqBlk ID ID #REQUIRED >

Атрибуты:

Cодержимое:

Если присутствует один компонент запроса аутентификации, тогда именно он и должен использоваться. Если присутствует несколько компонентов запроса аутентификации, тогда получатель должен выбрать один компонент, основываясь на своих предпочтениях и возможностях программного обеспечения.

Если нет ни одного компонента запроса аутентификации, это означает, что блок аутентификационного запроса запрашивает присылку компонентов Organisation, как это специфицировано в компоненте информационного запроса торговой роли.

В аутентификационном блоке должен быть по крайней мере один компонент (аутентификационного запроса или информационного запроса торговой роли), в противном случае имеет место ошибка.

8.5. Блок отклика аутентификации

Блок отклика аутентификации содержит отклик, который является результатом обработки блока запроса аутентификации. Его определение представлено ниже.

<!ELEMENT AuthRespBlk (AuthResp?, Org*) >
<!ATTLIST AuthRespBlk ID ID #REQUIRED >

Атрибуты:

Cодержимое:

Компоненты, присутствующие в блоке отклика аутентификации должны согласовываться с требованиями соответствующего блока аутентификационного запроса, в противном случае имеет место ошибка.

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

Блок состояния аутентификации индицирует успех или неудачу верификации блока отклика аутентификации аутентификатором. Его определение представлено ниже.

<!ELEMENT AuthStatusBlk (Status) >
<!ATTLIST AuthStatusBlk ID ID #REQUIRED >

Атрибуты:

Cодержимое:

8.7. Блок платежного запроса

Блок платежного запроса содержит информацию, которая запускает процедуру платежа. Его описание представлено ниже.

<!ELEMENT PayReqBlk (Status+, BrandList, BrandSelection,
Payment, PaySchemeData?, Org*, TradingRoleData*)>

Атрибуты:

Cодержимое:

Блок платежного запроса должен содержать:

• Компонент Organisation с торговой ролью продавца;
• Компонент Organisation с торговой ролью Покупателя;
• Компонент Payment для платежа;
• Компонент Brand List;
• Компонент выбора вида платежа из списка;
• Компонент Organisation для Кассира, осуществляющего платеж;
• Компонент Organisation (если такоая имеется) для организации, которая выполнила предыдущий шаг, например другой Кассир;
• Компонент Organisation для организации, которая выполняет следующий шаг. Это может быть, например, Агент доставки или Кассир;
• Компонент Organisation для любых дополнительных организаций, которые Продавец включил в блок отклика Offer;
• Опционный компонент данных платежной схемы, если это требуется методом платежа, определенном в приложении IOTP;
• Любой компонент информации о платежной роли, который может потребоваться (смотри раздел 7.17.1).

8.8. Блок платежного обмена

Блок платежного обмена содержит специфические данные о платежной схеме, которыми обмениваются две торговые роли в рамках сделки. Его определение представлено ниже.

<!ELEMENT PayExchBlk (PaySchemeData+)>
<!ATTLIST PayExchBlk ID ID #REQUIRED>

Атрибуты:

Cодержимое:

8.9. Блок платежного отклика

Этот блок платежного отклика содержит информацию о состоянии платежа, опционной платежной расписке и опционные сообщения платежного протокола. Его определение представлено ниже.

<!ELEMENT PayRespBlk (Status, PayReceipt?, PaySchemeData?,
PaymentNote?, TradingRoleData*)>
<!ATTLIST PayRespBlk ID ID #REQUIRED>

Атрибуты:

Cодержимое:

8.10. Блок запроса доставки

Блок запроса доставки содержит подробности о товарах или услугах, которые должны быть предоставлены вместе с подписью, которая позволяет удостовериться, что доставка была авторизована. Его определение приведено ниже.

<!ELEMENT DeliveryReqBlk (Status+, Order, Org*, Delivery,
ConsumerDeliveryData?, TradingRoleData*)>
<!ATTLIST DeliveryReqBlk ID ID #REQUIRED>

Атрибуты:

Cодержимое:

Блок запроса доставки содержит:

• Компонент Organisation с торговой ролью Продавца;
• Компонент Organisation для торговых ролей Покупателя и DeliverTo;
• Компонент Delivery;
• Компонент Organisation для Агента доставки. В частности компонент Organisation, идентифицированный атрибутом ActionOrgRef компонента Delivery;
• Компонент Organisation (если имеется) для организации, которая осуществила предыдущий шаг, например Кассира;
• Компоненты Organisation для любой дополнительной организации, которую Продавец включил в блок отклика Offer;
• Любые компоненты данных о торговой роли, которая может потребоваться (смотри раздел 7.17.1).

8.11. Блок отклика доставки

Блок отклика доставки содержит Delivery Note, содержащую подробности о том как будут доставляться товары. Его определение представлено ниже. Заметим, что в блоке отклика Delivery элемент состояния доставки с DeliveryStatusCode равным NotYetStarted или InProgress является нелегальным.

<!ELEMENT DeliveryRespBlk (Status, DeliveryNote)>
<!ATTLIST DeliveryRespBlk ID ID #REQUIRED>

Атрибуты:

Cодержимое:

8.12. Торговый блок информационного запроса

Торговый блок информационного запроса содержит компоненттип запроса и опционно платежной схемы.

<!ELEMENT InquiryReqBlk ( InquiryType, PaySchemeData? ) >
<!ATTLIST InquiryReqBlk ID ID #REQUIRED >

Атрибуты:

Cодержимое:

8.13. Торговый блок информационного отклика

Торговый блок информационного отклика содержит компонент Status и опционно компонент Payment Scheme. Его целью является осуществление запроса о текущем состоянии транзакции или сервера.

<!ELEMENT InquiryRespBlk (Status, PaySchemeData?)>
<!ATTLIST InquiryRespBlk ID ID #REQUIRED
LastReceivedIotpMsgRef NMTOKEN #IMPLIED
LastSentIotpMsgRef NMTOKEN #IMPLIED >

Атрибуты:

Cодержимое:

8.14. Блок запроса Ping

Блок запроса Ping используется, чтобы определить, работает ли сервер и является ли криптография совместимой.

Определение блока запроса Ping предложено ниже.

<!ELEMENT PingReqBlk (Org*)>
<!ATTLIST PingReqBlk ID ID #REQUIRED>

Атрибуты:

Cодержимое:

Опционные компоненты Organisation (смотри раздел 7.6).

Если нет ни одного компонента Organisation, тогда запрос Ping является анонимным и служит для проверки, работает ли сейчас сервер.

Однако, если присутствуют компоненты Organisation, это указывает, что отправитель запроса Ping хочет проверить, могут ли быть обработаны цифровые подписи.

В этом случае отправитель включает:

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

Эти компоненты используются для формирования подписи блока отклика Ping.

8.15. Блок отклика Ping

Блок отклика Ping предоставляет результат выполнения запроса Ping. Он содержит компонент Organisation, который идентифицирует отправителя отклика Ping.

Если запрос Ping, для которого этот блок является откликом, содержал компоненты Organisation, тогда он также содержит эти компоненты Organisation.

<!ELEMENT PingRespBlk (Org+)>
<!ATTLIST PingRespBlk ID ID #REQUIRED
PingStatusCode (Ok | Busy | Down) #REQUIRED
SigVerifyStatusCode (Ok | NotSupported | Fail) #IMPLIED
xml:lang NMTOKEN #IMPLIEDPingStatusDesc CDATA #IMPLIED>

Атрибуты:

Cодержимое:

Компоненты Organisation отправителя отклика Ping всегда содержат кроме того компоненты Organisation, посланные в запросе Ping.

Значения статусного кода Ping не включают в себя такие значения как Fail, так как, когда программа, получающая сообщение запроса Ping, не работает, не будет послано никакого отклика Ping.

8.16. Блок подписи

Блок Signature содержит один или более компонентов Signature и соответствующих сертификатов (если требуется), которые подтверждают данные в рамках данной транзакции. Определение компонента Signature и сертификатов содержится в статье "Digital Signatures for the Internet Open Trading Protocol", смотри [IOTPDSIG]. Описание их применения в IOTP можно найти в разделах 7.19 и 7.20.

Определение блока Signature представлено ниже:

<!ELEMENT IotpSignatures (Signature+, Certificate*) >
<!ATTLIST IotpSignatures ID ID #IMPLIED >

Атрибуты:

Cодержимое:

Содержимое блока Signature зависит от торгового блока, который содержится в том же сообщении, что и блок Signature.

8.16.1. Блок подписи в отклике предложении

Блок подписи, который содержится в том же сообщении, что и блок отклика Offer, несет в себе только компонент подписи отклика Offer (смотри раздел 7.19.2).

8.16.2. Блок подписи в платежном запросе

Блок Signature, который содержится в том же сообщении, что и блок платежного запроса, содержит в себе:

• Компонент подписи отклика Offer (смотри раздел 7.19.2) и
• Если поатеж зависит от предыдущего шага (как указано атрибутом StartAfter компонента Payment), тогда компонент подписи платежной расписки (смотри раздел 7.19.3) генерируется на предыдущем этапе (шаге).

8.16.3. Блок подписи в платежном отклике

Блок подписи, который содержится в том же сообщении, что и блок платежного отклика, содержит только компонент подписи платежной расписки (смотри раздел 7.19.3), сформированной на этом этапе (шаге).

8.16.4. Блок подписи в запросе доставки

Блок подписи, который содержится в том же сообщении, что и блок запроса доставки, содержит:

• Компонент подписи отклика Offer (смотри раздел 7.19.2) и
• Компонент подписи платежной расписки (смотри раздел 7.19.3), сформированный на предшествующем шаге.

8.16.5. Блок подписи в отклике доставки

Блок Signature, который содержится в том же сообщении, что и блок отклика доставки, содержит только компонент подписи отклика Delivery (смотри раздел 7.19.4), сформированный на этом шаге.

8.17. Блок ошибки

Торговый блок Error содержит один или более компонентов Error (смотри раздел 7.21), которые несет в себе информацию о технических ошибках (смотри раздел 4.1) в сообщении IOTP, полученном одной из торговых ролей, вовлеченных в сделку.

Ниже представлены две фразы, которые используются в описании торгового блока Error:

• ошибочное сообщение. Сообщение IOTP, которое содержит или является причиной ошибки какого-то рода;
• сообщение, опровещающее об ошибке. Сообщение IOTP, которое содержит торговый блок Error, описывающий ошибку, найденную в сообщении.

Торговый блок Error может содержаться в любом сообщении, уведомляющем об ошибке. Реакция на такое сообщение зависит от серьезности (severity) ошибки. Разъяснения различных значений серьезности ошибки (и сопряженных с ними действий) дано в определении компонента Error.

Несмотря на то что торговый блок Error может уведомлять о многих различных ошибках, используя несколько компонентов Error, разработчики приложений могут и не поддерживать такую возможность.

Структура торгового блока Error представлена ниже.

<!ELEMENT ErrorBlk (ErrorComp+, PaySchemeData*) >
<!ATTLIST ErrorBlk ID ID #REQUIRED >

Атрибуты:

Cодержимое:

8.18. Блок Cancel

Блок Cancel используется одной торговой ролью чтобы информировать остальных о том, что транзакция аннулируется. Пример использования включает в себя:

• Роль Покупателя, информирующую других о том, что он не собирается продолжать транзакцию. Это позволяет серверу завершить транзакцию, не дожидаясь таймаута.
• Роль, отличная от покупателя, информирует Покупателя о том, что транзакция останавливается. В этом случае Покупатель вряд ли повторно пошлет предыдущее сообщение в предположении, что оно не было получено.

Его определение имеет вид.

<!ELEMENT CancelBlk (Status) >
<!ATTLIST CancelBlk ID ID #REQUIRED >

Атрибуты:

Cодержимое:

9. Транзакции IOTP

Базовая версия протокола IOTP поддерживает три типа транзакций. Среди них:

• Транзакции аутентификации IOTP, которые поддерживают аутентификацию одного партнера сделки другим партнером и/или получение информации о другой торговой роли.
• Транзакции IOTP, которые включают в себя один или более платежей. В частности:

- Депозит
- Покупка
- Возврат денег
- Отзыв сделки
- Обмен ценностями

• Транзакции IOTP предназначенные для проверки корректности функционирования инфраструктуры. В частности:

- Транзакция запроса состояния и
- Ping

Хотя транзакции аутентификации могут выполняться сами по себе, опционно любая платежная операция может предшествоваться аутентификацией. Остальная часть данного раздела поделена на две части, где описывается:

• Аутентификационные и платежные транзакции (аутентификация, депозит, покупка, возврат денег, аннулирование сделки и обмен ценностями)
• Инфраструктурные транзакции (транзакция запроса состояния и Ping), которые предназначены для поддержки запросов о том, успешно ли прошла транзакция или правильно ли работает сервер торговой роли.

9.1. Транзакция аутентификации и платежа

Транзакции, имеющие отношение к аутентификации и платежу состоят из шести документальных обменов, которые объединяются в последовательности, чтобы реализовать определенную транзакцию.

Вообще имеется теснаое но не точное соответствие между документальным и торговым обменами. Главное отличие заключается в том, что некоторые документальные обмены включают в себя часть или все два торговых обменов одновременно для того чтобы минимизировать число IOTP-сообщений, посылаемых через Интернет.

Эти шесть документальных обменов включают в себя:

• Аутентификация. Это прямая реализация аутентификации торгового обмена;
• Предложение (Offer), зависимое от вида платежа. Это торговый обмен предложения, объединенный с платежным обменом выбора вида платежа. Его целью является обеспечение Продавца информацией о выборе вида платежа;
• Предложение, не зависимое от вида платежа. Это также торговый обмен предложения (Offer). Однако в этом случае содержимое отклика Offer не зависит от выбора вида платежа;
• Платеж. Это непосредственная реализация платежной части торгового обмена;
• Доставка. Это прямая реализация обмена доставки;
• Доставка с платежом. Это реализация совмещеных торговых обменов платежа и доставки.

Эти документальные обмены скомбинированы вместе в различные последовательности, чтобы реализовать каждую из транзакций. Способ, которым они могут комбинироваться проиллюстрирован на рис. 17.

Рис. 17. Блок-диаграмма обмена сообщениями платежа и аутентификации

Допустимые комбинации документального обмена зависят от конкретного типа транзакции IOTP.

Далее рассматриваются методы обработки рабочих ошибок (Business Errors) в процессе документального обмена (смотри раздел 4.2).

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

Документальный обмен аутентификации является непосредственной реализацией торгового обмена аутентификации (смотри раздел 2.2.4). Он включает в себя:

Аутентификация состоит из:

• Запрос аутентификации, посылаемый аутентификатором аутентифицируемому,
• Отклик аутентификации, посылаемый аутентифицируемым аутентификатору в ответ на запрос. Отклик проверяется аутентификатором, результат этой проверки посылается аутентифицируемому, который из этой статусной информации узнает, прошел он аутентификацию или нет.

Документальный обмен аутентификации предполагает также:

• Предоставление аутентифицируемому компонента Organisation, который описывает аутентификатора и
• Опционно, предоставление аутентификатору компонента Organisation, который описывает аутентифицируемого.

Запрос аутентификации может быть подписан цифровым образом, что позволяет аутентифицируемому, проверить доверительные параметры (credentials) аутентификатора. IOTP-сообщения, которые используются в таком обмене, представлены на рис. 18.

Рис. 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 в блоке состояния. Если он указывает на:

Если аутентификатор получает от Покупателя сообщение 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-элементов:

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

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).

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

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

Обработка сообщений

Получив сообщение TPO (смотри ниже), Покупатель может:

• сформировать и послать сообщение выбора TPO Продавцу, или
• индицировать сбой, послав Продавцу блок Cancel, содержащий компонент Status с атрибутом StatusType = Offer, ProcessState = Failed и CompletionCode (смотри раздел 7.16.4) равным: ConsCancelled или Unspecified.

Получив сообщение выбора TPO (смотри ниже), Продавец может:

• сформировать и послать сообщение отклика Offer Покупателю, или
• индицировать сбой, послав Покупателю блок Cancel, содержащий компонент Status с атрибутом StatusType = Offer, ProcessState = Failed и CompletionCode (смотри раздел 7.16.4) равным: MerchCancelled или Unspecified.

Получив сообщение отклика Offer (смотри ниже), Покупатель может:

• сформировать и послать следующее сообщение транзакции IOTP соответствующей торговой роли. Это зависит от типа транзакции, или
• индицировать сбой, послав Продавцу блок Cancel, содержащий компонент Status с StatusType = Offer, ProcessState =of Failed и CompletionCode (смотри раздел 7.16.4) равным: ConsCancelled или Unspecified.

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

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

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

Обмен сообщениями проиллюстрирован на рис. 20 ниже:

… Продолжение ...
Рис. 20. Обмен для предложения, независимого от вида платежа

Заметим, что документальный обмен предложения, независимого от видов платежа происходит, когда продавец предлагает покупателю лишь один вид платежа, протокол и вид валюты. Это может произойти и при нескольких предлагаемых видах платежа, если имеется один Кассир и все виды платежа используют один и тот же набор протоколов.

Заметим, что блоки TPO и отклика Offer могут быть посланы в одном IOTP-сообщении (смотри документальный обмен предложения, зависимого от вида платежа), даже если блок отклика Offer не изменяется. Однако это увеличивает число сообщений в транзакции и следовательно может увеличить время отклика.

Приложения, поддерживающие торговую роль Покупателя, должны проверять наличие блока отклика Offer в первом сообщении IOTP с тем чтобы определить, является ли обмен зависимым от вида платежа.

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

Получив сообщение TPO и отклика Offer (смотри ниже), Покупатель может:

• сформировать и послать следующее сообщение IOTP транзакции соответствующей торговой роли. Это зависит от разновидности транзакции.
• индицировать отказ, послав Продавцу блок Cancel, содержащий компонент Status с StatusType = Offer, ProcessState = Failed и кодом CompletionCode (смотри раздел 7.16.1) равным: ConsCancelled или Unspecified.

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

9.1.2.3. Сообщение TPO

Сообщение используется только в документальном обмене предложения, зависящего от вида платежа. Помимо блока ссылок транзакции (смотри раздел 3.3), в это сообщение входит блок опций торгового протокола (смотри раздел 8.1), который описан ниже.

Блок TPO (TRADING PROTOCOL OPTIONS)

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

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

Если транзакция IOTP включает доставку, тогда блок TPO должен содержать:

• Компоненты Organisation со следующими ролями:

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

Если за документальным обменом Offer следует обмен аутентификации, тогда сообщение TPO может также содержать:

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

Для получения подробностей смотри раздел 9.1.1.4 (сообщение о состоянии аутентификации).

9.1.2.4. Сообщение IOTP выбора TPO

Сообщение выбора TPO используется только в документальном обмене предложения, зависящего от вида платежа. Помимо блока ссылок транзакции (смотри раздел 3.3), это сообщение включает в себя блок выбора TPO (смотри раздел 8.1), который описан ниже.

Блок выбора TPO (смотри раздел 8.2) содержит:

• Один компонент выбора вида платежа (смотри раздел 7.8) для использования в последующем платежном обмене. Он содержит результаты выбора покупателем вида платежа, платежного протокола и вида валюты из списка компонента выбора вида платежа.

9.1.2.5. Сообщение отклик на предложение IOTP

Сообщение отклика Offer используется только в документальном обмене предложения, зависящего от вида платежа. Помимо блока ссылок транзакции (смотри раздел 3.3), это сообщение состоит из:

• блока отклика Offer (смотри раздел 8.1) aиnd
• опционного блока подписи (смотри раздел 8.16).

Блок отклика предложения (блок отклика OFFER)

Блок отклика Offer (смотри раздел 8.3) содержит следующие компоненты:

• один компонент Status (смотри раздел 7.16), который индицирует состояние отклика Offer. Атрибут ProcessState должен быть равен CompletedOk;
• один компонент Order (смотри раздел 7.5), который содержит детали о товарах и услугах, которые покупаются, или о финансовых операциях, которые имеют место;
• один или более компонентов (смотри раздел 7.9) для каждого платежа, которы надлежит произвести;
• нуль или один компонент Delivery (смотри раздел 7.13), содержащий детали доставки, которую надлежит осуществить, если транзакция предполагает доставку;
• нуль или более компонентов данных о торговой роли (смотри раздел 7.17), если это затребовано Продавцом.

Блок подписи (отклик предложения)

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

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

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

• следующие компоненты блока отклика предложения:

9.1.2.6. Сообщение TPO и отклика Offer

Сообщение TPO и отклика Offer используется только в документальном обмене предложения, независящего от вида платежа. Помимо блока ссылок транзакции (смотри раздел 3.3), это сообщение включает в себя:

• блок опций торгового протокола (TPO) (смотри раздел 8.1);
• блок отклика Offer (смотри раздел 8.1) и
• опционный блок Signature (смотри раздел 8.16).

Блок TPO (TRADING PROTOCOL OPTIONS)

Это тот же самый блок опций торгового протокола, что описан в IOTP-сообщении TPO (смотри раздел 9.1.2.3).

Блок отклика OFFER

Это тот же самый блок отклика Offer, что и в сообщении отклика Offer (смотри раздел 9.1.2.5).

Если до документального обмена Offer имел место обмен аутентификации, тогда сообщение TPO и отклика Offer может содержать (смотри раздел 8.6).

Блок подписи тот же самый блок Signature, что и в сообщении отклика Offer (смотри раздел 9.1.2.5), со следующими добавлениями:

• если документальный обмен Offer является зависимым от вида платежа, тогда компонент Signature в блоке подписи дополнительно имеет элемент дайждеста для компонента выбора вида платежа, содержащегося в блоке выбора TPO;
• если перед документальным обменом Offer имела место аутентификация, тогда компонент Signature в блоке подписи дополнительно содержит элемент дайджеста для блока состояния аутентификации.

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

Документальный обмен платежа является непосредственной реализацией последней части платежного обмена (смотри раздел 2.2.2) после того как вид платежа выбран покупателем. Платежный обмен состоит из:

• Покупатель формирует платежный запрос, используя информацию из предыдущего IOTP-сообщения, и посылает его кассиру;
• Затем кассир и покупатель обмениваются платежными IOTP-сообщениями, куда инкапсулируются сообщения платежного протокола. Этот обмен происходит вплоть до завершения процедуры платежа и, наконец,
• Кассир посылает сообщение платежного отклика покупателю, где содержится платежная расписка.

IOTP-сообщения, которые используются при платежном обмене показаны на рис. 21.

Рис. 21. Обмен платежными документами

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

Получив сообщение платежного запроса, кассир должен проверить, авторизован ли данный платеж (смотри раздел 6). Он может затем:

• сформировать и послать сообщение платежного обмена покупателю, если этого требует платежный протокол или
• сформировать и послать сообщение платежного отклика, если протокольный платежный обмен завершен или
• индицировать сбой, послав покупателю блок Cancel, содержащий компонент Status с атрибутом StatusType = Payment, ProcessState = Failed и кодом CompletionCode (смотри раздел 7.16.4) равным: BrandNotSupp, CurrNotSupp, PaymtCancelled, AuthError, InsuffFunds, InstBrandInvalid, InstNotValid, BadInstrument или Unspecified.

Получив платежное ообщение, Покупатель может:

• сформировать и послать платежное сообщение Кассиру или
• индицировать сбой, послав кассиру блок Cancel, содержащий компонент Status с атрибутами StatusType = Payment, ProcessState = Failed и кодом CompletionCode (смотри раздел 7.16.2) равным: ConsCancelled или Unspecified.

Получив платежное ообщение, кассир может:

• сформировать и послать платежное сообщение покупателю, если этого требует платежный протокол или
• сформировать и послать сообщение платежного отклика, если протокольный платежный обмен завершен или
• индицировать сбой, послав Покупателю блок Cancel, содержащий компонент Status с атрибутами StatusType = Payment, ProcessState = Failed и кодами CompletionCode (смотри раздел 7.16.2) равными: PaymtCancelled или Unspecified.

Получив платежное ообщение-отклик, Покупатель может:

• сформировать и послать следующее сообщение транзакции соответствующей торговой роли. Это зависит от разновидности транзакции,
• остановиться, так как транзакция завершена или
• индицировать сбой, послав Продавцу блок Cancel, содержащий компонент Status с атрибутами StatusType = Payment, ProcessState = Failed и кодом CompletionCode (смотри раздел 7.16.1) равным: ConsCancelled или Unspecified.

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

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

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

9.1.3.2. Сообщение платежного запроса

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

• блок платежного запроса и
• опционный блок подписи

Блок платежного запроса (смотри раздел 8.7) состоит из:

• следующих компонентов копируемых из блока отклика Offer, полученного в ходе предыдущего документального обмена предложения:

• следующих компонентов блока TPO:

• одного компонента выбора вида платежа, т.e. компонента выбора вида платежа, где атрибут BrandListRef указывает на список видов платежа. Этот компонент может быть:

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

Заметим, что:

• если в блоке отклика Offer имеется более одного компонента Payment, тогда вторым платежем являет тот, что записан в блоке отклика Offer и который содержит атрибут StartAfter (смотри раздел 7.9), указывающий на компонент Payment предыдущего платежа;
• Кассир, который должен быть сюда включен, идентифицируется компонентом выбора платежа (смотри раздел 7.8). Объясненеи того как идентифицируется Кассир смотри в разделе 6.3.1;
• компонент списка видов платежей определяется атрибутом BrandListRef компонента o Payment;
• компонент выбора вида платежа берется из блока отклика Offer, где имеется атрибут BrandListRef (смотри раздел 3.5), который идентифицирует компонент списка видов платежей.

Блок подписи (запрос платежа)

Если предшествующий документальный обмен предложения содержал цифровую подпись(смотри раздел 9.1.2.5), или подпись была включена в предыдущий платежный отклик (смотри раздел 9.1.3.4), тогда они должны обе быть скопированы в блок подписи сообщения платежного запроса.

9.1.3.3. Сообщение платежного обмена IOTP

Помимо блока ссылок транзакции (смотри раздел 3.3), это сообщение включает в себя блок платежного обмена.

Блок платежного обмена (смотри раздел 8.8) включает в себя:

• один компонент платежной схемы (смотри раздел 7.10), который содержит специфические данные метода платежа. Подробности по платежному методу смотри в приложении.

9.1.3.4. Платежное сообщение отклика

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

• платежный блок отклика
• опционный блок подписи

Платежный блок отклика (смотри раздел 8.9) включает в себя:

• один компонент платежной расписки (смотри раздел 7.11), которая содержит специфические данные для платежной схемы, которые позволяют, если нужно, проконтролировать платеж;
• один компонент платежной схемы (смотри раздел 7.10), который, если требуется, содержит специфические данные метода платежа. Подробности смотри в приложении;
• опционный компонент накладной (Payment Note) (смотри раздел 7.12);
• нуль или более компонентов данных о торговой роли (смотри раздел 7.17).

Блок подписи (платежный отклик)

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

• блок ссылок транзакции (смотри раздел 3.3) для сообщения IOTP, которое содержит первый вариант блока платежного отклика,
• Id-компонент транзакции (смотри раздел 3.3.1) в блоке ссылок транзакции, который однозначно идентифицирует транзакцию,
• компонент платежной расписки из блока платежного отклика,
• компонент накладной (Payment Note) из блока платежного отклика,
• другие компоненты, на которые ссылается атрибут PayReceiptNameRefs (если имеется) компонента платежной расписки,
• компонент Status из блока платежного отклика,
• любой компонент данных о торговой роли в блоке платежного отклика и
• все компоненты Signature, содержащиеся в блоке платежного запроса (если имеются).

9.1.4. Обмен документами при доставке

Документальный обмен доставки является непосредственной реализацией торгового обмена доставки (смотри раздел 2.2.3). Он состоит из следующих шагов:

• Покупатель запрашивает доставку путем формирования сообщения запроса доставки. При этом используется информация предыдущего IOTP-сообщения транзакции и затем посылает его Агенту доставки;
• Агент доставки посылает сообщение отклика доставки покупателю. Это сообщение содержит детали отклика агента на запрос и опционно цифровую подпись.

Схема обмена сообщениями представлена на рис. 22.

Рис. 22. Обмен документами при доставке

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

Получив сообщение-запрос доставки, агент доставки должен проверить авторизацию выполнения такой операции (смотри раздел 6). Далее он может:

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

Получив сообщение-отклик доставки, покупатель может считать, что транзакция завершена.

Если покупатель получает сообщение, содержащее блок Cancel, информация, содержащаяся в сообщении должна быть доведена до сведения покупателя и дальнейшая работа прервана.

9.1.4.2. Сообщение запроса доставки IOTP

Сообщение запроса доставки IOTP состоит из:

• блок запроса доставки и
• опционный блок подписи

Блок запроса доставки (смотри раздел 8.10) содержит:

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

• следующий компонент из блока платежного отклика:

• нуль или более компонентовданных о торговых ролях (смотри раздел 7.17).

Блок подписи (запрос доставки)

Если предыдущиц документальный обмен Offer содержит подпись отклика Offer илт платежный обмен содержит подпись платежного отклика, тогда тогда они должны быть скопированы в блок подписи.

9.1.4.3. Сообщение-отклик доставки

Сообщение-отклик доставки содержит блок отклика доставки и опционно блок подписи.

Блок отклика доставки содержит:

• один компонент накладной (Delivery Note) (смотри раздел 7.15), который содержит инструкции по доставке товаров или услуг.

Блок подписи (отклик доставки)

Блок подписи должен содержать один компонент подписи, который содержит элементы дайджеста, которые относятся к:

• ID-компоненту транзакции (смотри раздел 3.3.1) сообщения, которое содержит подпись отклика Delivery;
• блок ссылок транзакции (смотри раздел 3.3) сообщения, которое содержит подпись отклика доставки;
• компонент данных покупателя, содержащийся в блоке запроса доставки покупателя;
• компоненты подписи, содержащиесчя в блоке запроса доставки (если имеется);
• компонент Status;
• компонент накладной (Delivery Note)

9.1.5. Обмен документами в процессе платежа и доставки

Документальный обмен платежа и доставки представляет собой комбинацию последней части торгового обмена платежа (смотри раздел 2.2.2) и обмена доставки (смотри раздел 2.2.3). Он состоит из:

• Запрос покупателя начинается с формирования сообщения-запроса платежа, где используется информация предыдущего IOTP-сообщения транзакции. Далее этот запрос направляется кассиру;
• Кассир и покупатель обмениваются платежными сообщениями, в которые вкладываются сообщения платежного протокола, до тех пор пока транзакция не будет завершена;
• Кассир посылает покупателю в одном сообщении IOTP:

IOTP-сообщения, которые вовлечены в этот процесс, показаны на рис. 23.

Рис. 23. Документальный обмен платежа и доставки

Блоки отклика доставки и платежного отклика могут быть обхединены в одном сообщении только если кассир имеет необходимую информацию, чтобы послать блок отклика доставки. Это вероятно так, если роли продавца, кассира и агента доставки совмещены.

Атрибут DelivAndPayResp компонента доставки (смотри раздел 7.13), содержащийся в блоке отклика Offer (смотри раздел 8.3), делается равным True, если блоки отклика доставки и платежного отклика объединены в одном сообщении, и равен False, если блоки отклика доставки и платежного отклика посланы в разных IOTP-сообщениях.

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

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

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

По получении сообщения платежного отклика и отклика доставки транзакция завершена.

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

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

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

9.1.5.2. Сообщение платежного запроса IOTP

Содержимое этого сообщения то же, что и для запроса при платежном документальном обмене (смотри раздел 9.1.3.2).

9.1.5.3. Сообщение платежного обмена IOTP

Содержимое этого сообщения то же, что и для платежного документального обмена (смотри раздел 9.1.3.3).

9.1.5.4. Сообщение платежного отклика и отклика доставки

Содержимое этого сообщения включает в себя:

• блок платежного отклика,
• опционный блок подписи (платежный отклик) и
• блок отклика доставки.

Содержимое блока платежного отклика то же, что и в платежном отклике при платежном документальном обмене (смотри раздел 9.1.3.4).

Блок SIGNATURE (отклик PAYMENT)

Содержимое этого блока то же, что и в блоке Signature (платежный отклик) при платежном документальном обменее (смотри раздел 9.1.3.4).

Содержимое блока отклика доставки то же, что и в блоке отклика доставки при платежном документальном обменее (смотри раздел 9.1.4.3).

9.1.6. Базовая транзакция аутентификации

Базовая транзакция аутентификации может иметь место в любое время между торговыми ролями, вовлеченными в сделку IOTP. Это означает, что она может иметь место:

• перед другой транзакцией IOTP;
• одновременно с другой транзакцией;
• независимо от каких-либо других транзакций.

Базовая транзакция IOTP аутентификации предполагает обмен аутентификационными документами (смотри раздел 9.1.1) как это показано на рис. 24.

Рис. 24. Базовая транзакция аутентификации

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

• когда имеет место базовая транзакция аутентификации на ранней фазе сессии, тогда, например финансовая организация может:

• как средство предоставления продавцу компонента Organisation, который содержит информацию о покупателе и торговой роли DelivTo;
• предоставление возможности аутентифицировать кассира до начала процедуры платежа.

9.1.7. Базовая транзакция депозита

Базовая транзакция депозита поддерживает операции по размещению депозита электронных средств в финансовой орнганизации.

Финансовая организация в этой операции выполняет роль продавца (депозита электронных средств), который предлагает эту услугу за определенное вознаграждение, которое может поступить, например, с некоторого счета клиента в другом банке. Базовая транзакция депозита включает в себя следующие документальные обмены:

• опционный документальный обмен аутентификации (смотри раздел 9.1.1);
• документальный обмен предложения (смотри раздел 9.1.2) и
• документальный обмен платежа (смотри раздел 9.1.3).

Способ, с помощью которого эти документальные обмены могут взаимодействовать, показан на рис. 25.

Рис. 25. Базовая транзакция депозита

Смотри раздел 9.1.12, чтобы определить какие комбинации документальных обменов применимы к конкретным транзакциям.

Заметим, что:

• Продавец (финансовая организация) может принять депозит в виде различных видов электронных платежей. Но покупатель, который собирается разместить депозит, обячно знает, каким видом электронного платежа он намерен воспользоваться, по этой причине все многообразие электронных платежей в каждом конкретном случае сводится к одной разновидности. Однако могут быть несколько протоколов, которые могут использоваться с одним и тем же видом электронного платежа. В этом случае предложение, зависимое от вида платежа, може подойти для согласования используемого протокола.
• Продавец (финансовая организация) может использовать результаты аутентификации не только для идентификации покупателя, но и счета, на котором следует разместить депозит. Если не удается идентифицировать один счет, используются другие средства. Например:

• Базовая IOTP-транзакция депозита без аутентификации может быть использована:

9.1.8. Базовая транзакция покупки

Базовая транзакция покупки поддерживает покупку товаров или услуг с применением любых платежных методов. Она включает в себя следующие документальные обмены:

• опционный документальный обмен аутентификации (смотри раздел 9.1.1)
• документальный обмен предложения (смотри раздел 9.1.2)
• или:

• только документальный обмен платежа или
• комбинированный документальный обменплатежа и доставки (смотри раздел 9.1.5).

Способы, какими эти документальные обмена могут комбинироваться показаны на рис. 26.

Рис. 26. Базовая транзакция покупки

Чтобы определить, какие комбинации документальных обменов встречаются в каждой из транзакций смотри раздел 9.1.12.

9.1.9. Базовая транзакция возврата денег

Процесс возврата денег обычно состоит из:

• запроса возврата, направленного покупателем продавцу, и имеющего целью продемонстрировать:

• Продавец соглашается (или нет) вернуть деньги. Это может включать некоторые переговоры между покупателем и продавцом, и если продавец согласен,
• выполняется возврат денег продавцом покупателю.

Базовая транзакция возврата денег поддерживает субнабор возможностей перчисленных выше, в частности поддерживает:

• отдельную аутентификацию покупателя, где используется базовая транзакция аутентификации (смотри раздел 9.1.6)
• возвратный платеж продавца покупателю с помощью следующих двух торговых обменов:

Способы того, как эти документальные обмены взаимодействуют, показаны на рис. 27.

Рис. 27. Базовая транзакция возврата денег

Базовая транзакция возврата денег без документального обмена аутентификации может использоваться:

• когда аутентификация покупателя осуществлена как-то иначе, например, покупатель, чтобы идентифицировать себя ввел представленный ему ранее код. Код может может быть записан на WEB-странице или прислан по электронной почте.
• когда предыдущая транзакция, например базовая аутентификация, идентифицировала покупателя, при этом используется безопасный канал гарантирует корректность предыдущей аутентификации.
• когда аутентификация покупателя осуществлена кассиром в рамках реализации платежного алгоритма.

9.1.10. Базовая транзакция отзыва платежа

Базовая транзакция отзыва поддерживает возврат электронных средств из финансовой организации.

Финансовая организация в рамках технологии IOTP имеет в этой транзакции, роль Продавца - за выполнение этой операции она может получить определенную оплату. Базовая транзакция отмены сделки включает в себя следующие документальные обмены:

• опционный документальный обмен аутентификации (смотри раздел 9.1.1)
• документальный обмен предложения (смотри раздел 9.1.2) и
• документальный обмен платежа (смотри раздел 9.1.3).

Способы, какими эти документальные обмены могут комбинироваться показаны на рис. 28.

Рис. 28. Базовая транзакция отзыва сделки

Заметим, что:

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

• базовая транзакция отзыва может использоваться без аутентификации:

9.1.11. Базовая транзакция обмена ценностями

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

• Перенос электронных средств на кредитную карту. Например, первый платеж может быть "dollar SET Payment", использующий кредитную карту, а второй платеж использует кредитную карту Visa Cash и осуществляет электронный перевод в долларах.
• Платежный обмен с заграничным субъектом посредством идентичных платежных методов. Например, один платеж может заключаться в снятии средств со счета в английских фунтах методом Mondex, а второй - предполагает внесение на счет денег в евро с помощью того же метода Mondex.
• Платежный обмен с заграничным субъектом посредством различных платежных методов. Например, один платеж может осуществляться по протоколу SET в канадских долларах, а второй - методом GeldKarte в немецких марках.

Базовый обмен ценностями использует следующие документальные обмены:

• опционный документальный обмен аутентификации (смотри раздел 9.1.1);
• документальный обмен предложения (смотри раздел 9.1.2), который определяет детали того, какие суммы и валюты подлежат обмену и
• два документальных обмена платежа (смотри раздел 9.1.3), которые осуществляют два реализуемые платежа.

Способы, которыми эти документальные обмены комбинируются друг с другом изображены на рис. 29.

Рис. 29. Базовая транзакция обмена ценностями

Базовая транзакция обмена ценностями осуществляется в двух вариантах:

• Обмен ценностями, зависящий от вида платежа. Где содержимое предложения, например курс по которому одна форма ценности обменивается на вторую, зависит от вида платежа и протокола, выбранного клиентом и
• Обмен ценностями, независящий от вида платежа. Где содержимое предложения, не зависит от вида платежа и протокола, выбранного клиентом.

В выше приведенном примере фигурирует роль продавца, хотя организацией, выполняющей обмен ценностями может быть банк или какая-то другая финансовая организация. Это потому, что банк выполняет здесь роль продавца, направляя покупателю предложение, которое он может принять или отвергнуть.

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

Использование подписей, чтобы гарантировать целостность обмена ценностями проиллюстрирована на диаграмме рис. 30.

Рис. 30. Подписи при обмене ценностями

9.1.12. Допустимые комбинации документальных обменов

Диаграмма на рис. 31. иллюстрирует информационные условия в различных IOTP-сообщениях, которые могут быть использованы покупателем, чтобы определить допустима или нет конкретная комбинация документальных обменов.

Рис. 31. Допустимые комбинации документальных обменов

1) Если первое сообщение IOTP транзакции содержит запрос аутентификации, то:

2) В противном случае (отсутствие запроса аутентификации в первом сообщении IOTP):

3) Если блок отклина предложения присутствует в каком-либо сообщении IOTP, тогда:

Ниже представлена таблица типов транзакций, которые могут удовлетворять условиям перечисленным выше.

9.1.13. Комбинирование аутентификации с другими транзакциями

Имеется возможность запустить независимую транзакцию аутентификации в любой момент времени, даже в параллель с другой транзакцией IOTP. Обычно она используется:

• Покупателем, чтобы аутентифицировать продавца, кассира или агента доставки или
• Кассиром или агентом доставки, чтобы аутентифицировать покупателя.

В общих чертах базовый процесс состоит из:

• торговая роль, которая решает выполнить аутентификацию другой торговой роли, откладывает выполнение текущей транзакции;
• выполняется не связанная ни с чем аутентификация. Это может быть опцией разработчика, подключенной к исходной транзакции с помощью компонента RelatedTo (смотри раздел 3.3.3) в блоке ссылок транзакции;
• если транзакция аутентификации успешна essful, осходная транзакция возобновляется;
• если аутентификация не прошла, тогда исходная аутентификация аннулируется.

Покупатель, например, может:

• аутентифицировать кассира для платежа в период между получением отклика Offer от продавца и до посылки платежного запроса кассиру;
• аутентифицировать агента доставки между получением платежного отклика от кассира и до отправки запроса доставки.

Кассир может аутентифицировать покупателя после получения платежного запроса и до посылки следующего сообщения, относящегося к платежу. агент доставки может аутентифицировать покупателя после получения запроса доставки и до посылки отклика доставки.

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

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

9.2. Инфраструктурные транзакции

Инфраструктурные транзакции разработаны, для поддержки запросов, прошла ли транзакция успешно или работает ли корректно некоторая торговая роль. Существует два типа таких транзакций:

• транзакция запроса состояния транзакции, которая предоставляет информацию о статусе существующей или уже завершившейся транзакции;
• транзакция Ping, которая позволяет одному приложению определить, работает ли соответствующее приложение другой торговой роли и проверить, могут ли обрабатываться подписи.

Базовая транзакция запроса состояния предоставляет информацию о состоянии существующей или завершившейся транзакции IOTP. Базовая транзакция запроса состояния использует следующие торговые блоки:

• торговый блок информационного запроса (смотри раздел 8.12),
• торговый блок информационного отклика (смотри раздел 8.13)
• опционный блок подписи (смотри раздел 8.16).

Запросы состояния транзакции IOTP могут производиться по разным причинам. Например:

• чтобы помочь возобновить прерванную транзакцию и определить текущее состояние одной из других торговых ролей,
• определить продавцу, завершен ли платеж, доставка и т.д.. Например, покупатель может объявить, что платеж произведен, но нет платежной расписки, подтверждающей это утверждение. Если продавец делает запрос кассиру, то он может определить, произведена или нет соответствующая проплата.

Запросы о базовых транзакциях IOTP Ping (смотри раздел 9.2.2) игнорируются.

Одна торговая роль может послать запрос любой другой торговой роли в любое время. Программа, которая поддерживает торговую роль покупателя IOTP может не делать:

• не подписать цифровым образом отклик, если это запрашивается, при условии, что она не способна сделать это, или
• совсем не реагировать на информационный запрос, так как она может быть в нерабочем состоянии или считать запрос неправомочным из-за того, что он, например, не подписан.

Базовыми требованиями являются:

• Покупатель должен послать блок статусного запроса торговой роли только после следующих событий:

• другие торговые роли должны послать блок информационного запроса состояния транзакции покупателю только после получения сообщения от покупателя и до отправки окончательного отклика покупателю ;
• не существует ограничений на посылку информационных запросов для любых других торговых ролей помимо покупателя.

Ошибки в запросах состояния транзакции могут быть отнесены к следующим трем классам:

• Рабочие ошибки (смотри раздел 4.2) в исходных сообщениях-запросах.
• Технические ошибки (смотри раздел 4.1) - как IOTP, так и специфических для определенных платежных схем es - в исходных IOTP-сообщениях.
• Технические ошибки в сообщении, содержащем сам блок информационного запроса.

Рабочие ошибки в исходных сообщениях

Возврат блока информационного запроса, содержащего компонент Status, который был послан покупателю последним.

Технические ошибки в исходных сообщениях

Возврат блока информационного отклика, содержащего компонент Status. Компонент Status должен содержать атрибут ProcessState равный ProcessError. В этом случае в качестве отклика посылается блок Error, указывающий, где в исходном сообщении была найдена ошибка.

Технические ошибки в блоке информационного запроса

Возврат сообщения Error. То есть, возврат блока Error, содержащего код ошибки (смотри раздел 7.21.2), который описывает природу ошибки в сообщении информационного запроса.

Сообщения информационого запроса транзакции

На рис. 32 рассмотрен процесс реализации базовой транзакции информационого запроса.

Рис. 32. Базовая транзакция статусного запроса

Блок ссылок транзакции

Торговая роль, делающая информационный запрос, должна использовать Id-компонент (смотри раздел 3.3.1), где атрибуты IotpTransId и TransTimeStamp имеют те же значения, что и в Id-компоненте исходной транзакции, объекта запроса. Атрибут IotpTransID в этом компоненте выполняет роль ключа при запросе записей, которые ведет торговая роль. Значение ID-атрибута Id-компонента должно быть отличным от любых других в исходной транзакции (смотри раздел 3.4.1).

Если требуются текущие статусные данные, компонент MsgId, и конкретный ID-атрибут для компонента MsgId должен отличаться от любых других в сообщениях, посланных торговой роли. Блок информационного запроса (смотри раздел 8.12) содержит следующие компоненты:

• один компонент типа информационного запроса (смотри раздел 7.18). Он идентифицирует, относится ли запрос к предложению, платежу или доставке.
• нуль или один компонент платежной схемы (смотри раздел 7.10). Это нужно для инкапсуляции специфических платежных сообщений.

Блок подписи (информационный запрос)

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

Если присутствует блок подписи информационного запроса (смотри раздел 8.12), то он содержит следующие компоненты:

• один компонент Signature (смотри раздел 7.19)
• один или более компонентов сертификата, если таковые нужны.

Блоки информационного отклика должны формироваться, только если транзакция авторизована. Цифровые подписи информационного запроса ставятся только в том случае, если получатель ожидает получение подписанных запросов. В данной версии IOTP это требует предварительного согласования. Это означает, что:

• Покупатели вряд ли будут генерировать запросы, снабженные подписью, но если они это сделают, это не будет считаться ошибкой;
• другие торговые роли могут согласовать применение цифровых подписей, если это требуется. Например, Кассир может потребовать, чтобы информационный запрос был подписан Продавцом.

С другой стороны, если исходная транзакция, к которой относится запрос, реализована через безопасный канал (напр., [SSL]), тогда разумно предположить, что, если отправитель информационного запроса знает Id-компонент исходного сообщения (включая, например, временную метку), то запрос является подлинным. Блок отклика INQUIRY (смотри раздел 8.13) содержит следующие компоненты:

• один компонент Status (смотри раздел 7.16). Этот компонент содержит статусную информацию о запрашиваемой транзакции,
• нуль или один компонент платежной схемы. Этот компонент содержит инкапсулированные платежные сообщения, специфические для выбранной схемы оплаты.

Блок SIGNATURE (отклик информационного запроса)

Если в сообщении, содержащем блок информационного запроса, присутствует блок подписи, тогда он может быть проверен получателем на предмет корректности информационного отклика.

Если блок подписи информационного отклика присутствует (смотри раздел 8.13), он содержит следующие компоненты:

• один компонент Signature (смотри раздел 7.19)
• один или более компонентов Certificate, если они нужны.

Цифровые подписи информационного отклика могут использоваться, только если получатель ожидает прихода подписанных откликов. В данной версии IOTP tэто предполагает предварительное согласование применение цифровых подписей. Это означает, что:

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

9.2.2. Базовая транзакция Ping

Целью базовой транзакции IOTP Ping является проверка коннективности между торговыми ролями, принимающими участие в транзакции. Это позволяет приложению IOTP сделать следующее:

• определить, работает ли приложение IOTP другой торговой роли;
• проконтролировать, могут ли торговые роли работать с цифровыми подписями.

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

Торговыми блоками, используемыми транзакцией Ping, являются:

• блок запроса Ping (смотри раздел 8.14),
• блок отклика Ping (смотри раздел 8.15) и
• блок Signature (смотри раздел 8.16).

Сообщения PING

На рис. 33 отображен обмен сообщениями прибазовой транзакции Ping.

Рис. 33. Базовые сообщения транзакции Ping

Верификация того, что подписи могут обрабатываться, осуществляется отправителем блока запроса Ping путем включения:

• компонентов Organisation, которые идентифицируют себя и предполагаемого получателя блока запроса Ping;
• блок подписи, который гарантирует корректность и целостность запроса Ping.

Получатель запроса Ping таким образом:

• знает, кто послал запрос Ping и может следовательно верифицировать подпись запроса;
• знает, кто должен генерировать подпись отклика Ping.

Заметим, что запрос Ping:

• не влияет на выполнение транзакций;
• в отличии от других сообщений IOTP, таких как TPO или статусный запрос, не запускает новых транзакций IOTP.

Все приложения IOTP должны присылать отклики Ping отправителю запросов Ping, сразу по получении.

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

Для каждой транзакции Ping, каждая роль IOTP может устанавливать различные транспортные сессии.

Любая торговая роль IOTP может посылать запрос Ping любой другой торговой роли. Сообщение Ping имеет свой собственный IotpTransId, который отличается от соответствующего параметра других транзакций.

Блок ссылок транзакции

IotpTransId транзакции Ping должен быть уникальным и отличать данную транзакцию от любых других.

Блок запроса PING

Если транзакция Ping является анонимной, тогда в блок запроса Ping включается компонент no Organisation (смотри раздел 8.7).

Если транзакция Ping не анонимна, то блок запроса Ping содержит компоненты Organisation для:

• отправителя блока запроса Ping;
• верификатора компонента подписи.

Если присутствуют компоненты Organisation, это указывает, что отправитель запроса Ping сформировал блок подписи. Блок подписи должен быть верифицирован торговой ролью, которая получила этот запрос Ping.

Блок подписи запроса Ping (смотри раздел 8.16) содержит следующие компоненты:

• один компонент Signature (смотри раздел 7.19)
• один или более компонентов Certificate, если они требуются.

Блок отклика PING

Блок отклика PING (смотри раздел 8.15) содержит следующие компоненты:

• компонент Organisation отправителя сообщения-отклика Ping

Если транзакция Ping не является анонимной, тогда отклик Ping дополнительно содержит:

• копии компонентов Organisation, содержащиеся в блоке запроса Ping.

Блок SIGNATURE (отклик PING)

Блок подписи отклика Ping (смотри раздел 8.16) содержит следующие компоненты:

• один компонент Signature (смотри раздел 7.19);
• один или более компонентов Certificate, если они нужны.

10. Получение логотипов

Ниже описано, как извлекать логотипы для отображения их программой IOTP, используя атрибут Logo Net Locations, содержащийся в элементе вида платежа (смотри раздел 7.7.1) и компоненте Organisation (смотри раздел 7.6). Полный адрес логотипа определяется следующим образом: Logo_address ::= Logo_net_location "/" Logo_size Logo_color_depth ".gif"

Где:

• Logo_net_location получено из атрибута LogoNetLocn элемента вида платежа (смотри раздел 7.7.1) или компонента Organisation. Заметим, что:

• содержимое этого атрибута зависит от используемого транспортного механизма (такого как HTTP).
• разработчики должны проверить, что если самый правый символ в Logo Net Location представляет собой "/", тогда другой такой же символ не должен включаться в запись адреса логотипа

• Logo_size идентифицирует размер логотипа,
• Logo_color_depth идентифицирует насыщенность цвета логотипа;
• "gif" идентифицирует, что логотип имеет формат "gif" .

Logo_size и Logo_color_depth специфицирует разработчик программы IOTP, которая извлекает логотип, в зависимости от размера и цвета, который желательно иметь.

10.1. Размер Logo

Имеется пять стандартных рамеров логотипа. Размеры в пикселях соответствуют в таблице значениям размера логотипа.

10.2. Насыщенность цвета логотипа

Существует три стандартных значения насыщенности цвета. Насыщенность цвета (включая число бит на пиксель) и соответствующее значение для Logo_Color_Depth представленны ниже в таблице.

Заметим, что если насыщенность цвета логотипа пропущена, тогда извлекается логотип с 256 цветами.

10.3. Примеры логотипа для сетевой позиции

Если логотип сетевой позиции равен ftp://logos.xzpay.com, тогда:

• ftp://logos.xzpay.com/medium.gif извлечет логотип среднего размера с 256 цветами
• http://logos.xzpay.com/small4.gif извлечет логотип малого размера с 16 цветами

Организации, которые делают логотип доступными для работы с IOTP должны всегда допускать размеры "small" и "medium" и использовать формат "gif".

11. Виды платежа
11.1. Определения и выбор вида платежа

Одной из ключевых черт IOTP является возможность для продавца предложить список видов платежа, чтобы покупатель мог сделать выбор. Ниже рассматриваются:

• определения платежных инструментов и видов платежа в контексте IOTP. Вводятся опционные категории видов оплаты "Dual Brand" или "поощрительный вид платежа",
• идентификация и выбор поощрительного вид платежа, который предлагает покупателю некоторые дополнительные выгоды, например скидку. Это означает, что и продавец и покупатель должны быть способны корректно идентияицировать, какой из допустимых поощрительных видов платежа использован.

11.1.1. Определение платежного инструмента

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

• кредитная карта, такая как MasterCard или Visa;
• дебитная карта типа MasterCard Maestro;
• смарт карта, базирующаяся на системе электронных платежей, такой как Mondex, GeldKarte или Visa Cash;
• программа, базирующаяся на системе платежей типа CyberCash или DigiCash.

Большинство платежных инструментов имеют номер, обычно это номер счета, по которому можно идентифицировать платежный инструмент.

11.1.2. Определение вида платежа

Вид платежа часто представляет собой марку, которая идентифицирует конкретный тип платежного инструмента. Список видов платежа представляет собой опции, которые предоставляются продавцом покупателю и из которых покупатель делает свой выбор. Каждый вид платежа может иметь разных кассиров. Среди примеров вида платежа:

• платежные ассоциации и платежные системы частных фирм, например MasterCard, Visa, American Express, Diners Club, Mondex, GeldKarte, CyberCash, и т.д..
• поощрительные виды платежа (смотри ниже). Сюда входят:

11.1.3. Определение двойственного вид платежа (Dual Brand)

Двойственный вид платежа (Dual Brand) означает, что отдельный платежный инструмент может использоваться так, как если бы это были два отдельных вида платежа. Например, может существовать одна японская карта "UC" (MasterCard), которую можно использовать как UC-карту или как обычную MasterCard. Виды платежа через UC-карту и MasterCard могут иметь своих собственных, отличных друг от друга Кассиров. Это означает, что:

• продавец рассматривает, например,"UC" и "MasterCard" как два вида платежа, когда предлагает список видов платежа покупателю,
• покупатель выбирает вид платежа, например, "UC" или "MasterCard,
• клиент приложения определяет, какой платежный инструмент подходит для выбранного вида платежа и выбирает, возможно с помощью самого пользователя, оптимальный платежный инструмент.

Двойственные виды платежа не требуют какого-то специального обслуживания продавцом и, следовательно, не нужно как-то выделять эти виды платежа в DTD. Это происходит потому, что в той части, которая касается продавца, каждый вид платежа в двойственном виде платежа рассматривается как независимый. Только покупатель должен находить соответствие между предлагаемым видом оплаты и имеющимся двойственным платежным инструментом.

11.1.4. Определение стимулирующего вида оплаты

Поощрительный вид оплаты предполагает, что если покупатель им воспользуется, то он получит какие-то дополнительные выгоды. Эти выгоды могут быть получены двумя путями:

• во время покупки. Например, если покупатель платит с помощью "Walmart MasterCard" через сервер Walmart, то он может получить скидку в 5%, это означает, что покупатель в действительности платит меньше,
• от эмитента платежного средства (карты), когда платеж появляется в ведомости. Например, процент за каждую операцию может быть понижен при частом использовании, основываясь на суммарой величине платежей с использованием данного платежного инструмента.

Заметим, что:

• первый пример (получение выгоды в момент покупки), требует чтобы:

• второй (получение выгоды от эмитента платежного средства) - не требует, чтобы отклик Offer изменился;
• каждый поощрительный вид оплаты в списке, предлагаемом продавцом, должен быть идентифицирован как отдельный вид платежа. Например: "Walmart", "Sears", "Marks and Spencer" и "American Advantage Visa", будут рассматриваться как отдельные виды оплаты.

11.1.5. Идентификация льготных видов платежа

Имеется две проблемы, которые нужно решить при идентификации поощрительных видов платежа:

• как продавец или кассир идентифицирует поощрительный вид оплаты, используемый в момент покупки;
• как покупатель надежно идентифицирует поощрительный вид оплаты в списке видов платежа, представленном продавцом.

11.1.5.1. Идентификация поощрительных видов платежа Продавцом/Кассиром

Правильная идентификация того, что покупатель воспользовался поощрительным видом платежа, крайне важно, так как покупатель может объявить, что он имеет право на скидку, которая действует для поощрительного вида платежа, в то время как в действительности это не так. Здесь возможны два подхода:

• использовать некоторую возможность платежного инструмента или метода, чтобы идентифицировать вид используемого платежа. Например, для данного вида платежа может использоваться сертификат SET, если он доступен, или
• использовать номер платежного инструмента (карты), чтобы получить информацию о платежном инструменте, например, в базе данных эмитента, чтобы узнать является ли данный вид платежа льготным.

Заметим, что:

• первый вариант предполагает доступность SET.
• второй - возможен, если продавец или кассир имеют доступ к базе данных эмитента карты.

IOTP не предоставляет продавцу информации о платежном инструменте (напр., карте или номере счета). Эти данные посылаются кассиру в качестве части инкапсулированного платежного протокола. Это означает, что:

• Продавец будет вынужден предположить, что выбранный платежный инструмент был льготным видом платежа, или
• Кассир будет вынужден проверить, что платежный инструмент соответствовал льготному виду платежа, платеж аннулируется, если это не так.

Проверка кассиром, является ли платеж льготным, возможна, если кассир совмещает функции и эмитента карты.

11.1.5.2. Выбор Покупателем льготных видов платежа

Существует два способа, как покупатель может выбрать правильно льготный вид платежа:

• Покупатель визуально выбирает логотип для льготного вида платежа из числа предложенных продавцом,
• приложение покупателя выбирает зарегистрированный код льготного платежа из списка видов платежа, предложенного продавцом.

В последнем случае, код покупателя должен совпадать с кодом из списка продавца, в противном случае соответствие не будет зарегистрировано. Способы, которыми программа IOTP покупателя может получить такой код, включают:

• Покупатель непосредственно вводит этот код. Это располагает к ошибкам и неудобно для клиента, кроме того покупателю надо как-то передать этот код. Этот подход не рекомендуется,
• Используется один из идентификаторов вида платежа, определенных в IOTP и предварительно загруженных в приложение покупателя,
• Используется некоторая информация, содержащаяся в программе, или другие данные, связанные с платежным инструментом. Это может быть:

• покупатель устанавливает вручную связь между льготным видом платежа из списка, предложенного продавцом, и определенным платежным инструментом. Делается это при первом использовании льготного вида платежа. Приложение IOTP запоминает код льготного платежа для использования при будущих покупках.

11.1.5.3. Рекомендации для Id видов платежа в программе покупателя

Новые Id видов платежа выдаются в соответствии с процедурой, заданной IANA (смотри раздел 12).

Рекомендуется, чтобы разработчики приложений IOTP покупателя (напр., платежных программ) обеспечивали предварительную загрузку текущего набора идентификаторов вида платежа и предлагали средства пополнения этого списка.

11.2. Примеры видов платежа

Данный пример содержит три образца XML для компонента списка видов платежа:

• вариант с просой кредитной карточкой;
• список видов платежей, базирующихся на кредитной карте, включая льготные виды платежа, и
• список видов платежа, базирующийся на комплексных электронных деньгах.

11.2.1. Простой пример, базирующийся на кредитной карте

Этот простой пример включает в себя:

• только основные виды платежей с помощью кредитной карты;
• одну цену и одну валюту;
• одного Кассира и
• один платежный протокол.

<BrandList ID='M1.2' XML:Lang='us-en' ShortDesc='Purchase book including s&h'
PayDirection='Debit' >
<Brand ID ='M1.30' BrandId='MasterCard' BrandName='MasterCard Credit'
BrandLogoNetLocn='ftp://otplogos.mastercard.com/mastercardcredit'
ProtocolAmountRefs='M1.33'>
</Brand>
<Brand ID ='M.31' BrandId='Visa' BrandName='Visa Credit'
BrandLogoNetLocn='ftp://otplogos.visa.com/visacredit' ProtocolAmountRefs='M1.33'>
</Brand>
<Brand ID ='M1.32' BrandId='AmericanExpress' BrandName='American Express'
BrandLogoNetLocn='ftp://otplogos.amex.com' ProtocolAmountRefs ='M1.33' >
</Brand >
<ProtocolAmount ID ='M1.33' PayProtocolRef='M1.35' CurrencyAmountRefs='M1.34'>
</ProtocolAmount>
<CurrencyAmount ID ='M1.34' Amount='10.95' CurrCode='USD'/>
<PayProtocol ID ='M1.35' ProtocolId='SCCD1.0' ProtocolName='Secure Channel Credit/Debit'
PayReqNetLocn='http://www.example.com/etill/sccd1' >
</PayProtocol>
</BrandList>

11.2.2. Список платежей с помощью кредитной карты, включая льготные платежи

Пример списка видов платежей с помощью кредитной карты представлен ниже. Он включает в себя:

• два обычных вида платежа через кредитную карту и два льготных вида платежа.
• два платежных протокола:

<BrandList ID='M1.2' XML:Lang='us-en' ShortDesc='Purchase ladies coat' PayDirection='Debit'>
<Brand ID ='M1.3' BrandId='MasterCard' BrandName='MasterCard Credit'
BrandLogoNetLocn='ftp://otplogos.mastercard.com' ProtocolAmountRefs='M1.7 M1.8'>
<ProtocolBrand ProtocolId='SET1.0' ProtocolBrandId='MasterCard:'>
</ProtocolBrand>
</Brand>
<Brand ID ='M1.4' BrandId='Visa' BrandName='Visa Credit'
BrandLogoNetLocn='ftp://otplogos.visa.com' ProtocolAmountRefs='M1.7 M1.8'>
<ProtocolBrand ProtocolId='SET1.0' ProtocolBrandId='Visa:'>
</ProtocolBrand>
</Brand>
<Brand ID ='M1.5' BrandId='BritishAirwaysMC' BrandName='British Airways MasterCard'
BrandLogoNetLocn='ftp://otplogos.britishairways.co.uk'
BrandNarrative='Double air miles with British Airways MasterCard'
ProtocolAmountRefs ='M1.7 M1.8' >
<ProtocolBrand ProtocolId='SET1.0' ProtocolBrandId='MasterCard:BA'>
</ProtocolBrand>
</Brand >
<Brand ID ='M1.6' BrandId='Walmart' BrandName='Walmart Store Card'
BrandLogoNetLocn='ftp://otplogos.walmart.com'
BrandNarrative='5% off with your Walmart Card on purchases over $150'
ProtocolAmountRefs='M1.8'>
</Brand>
<ProtocolAmount ID ='M1.7' PayProtocolRef='M1.10' CurrencyAmountRefs='M1.9' >
<PackagedContent Transform="BASE64">
238djqw1298erh18dhoire
</PackagedContent>
</ProtocolAmount>
<ProtocolAmount ID ='M1.8' PayProtocolRef='M1.11' CurrencyAmountRefs='M1.9' >
<PackagedContent Transform="BASE64">
238djqw1298erh18dhoire
</PackagedContent>
</ProtocolAmount>
<CurrencyAmount ID ='M1.9' Amount='157.53' CurrCode='USD'/>
<PayProtocol ID ='M1.10' ProtocolId='SET1.0'
ProtocolName='Secure Electronic Transaction Version 1.0'
PayReqNetLocn='http://www.example.com/etill/set1' >
<PackagedContent Transform="BASE64">
8ueu26e482hd82he82
</PackagedContent>
</PayProtocol>
<PayProtocol ID ='M1.11' ProtocolId='SCCD1.0'
ProtocolName='Secure Channel Credit/Debit'
PayReqNetLocn='http://www.example.com/etill/sccd1' >
<PackagedContent Transform="BASE64">
82hd82he8226e48ueu
</PackagedContent>
</PayProtocol>
</BrandList>

11.2.3. Пример выбора вида платежа

Для оплаты через 'British Airways' MasterCard для выше приведенного варианта и платежного протокола SET список вида платежа будет иметь вид:

<BrandSelection ID='C1.2' BrandListRef='M1.3' BrandRef='M1.5' ProtocolAmountRef='M1.7'
CurrencyAmountRef='M1.9' >
</BrandSelection>

11.2.4. Список видов платежа, базирующихся на комплексных электронных деньгах

Ниже представлен достаточно сложный пример, который включает в себя:

• платежи, использующие Mondex, GeldKarte, CyberCash или DigiCash;
• в валютах, в список которых входят доллары США, британские фунты, итальянские лиры, немецкие марки и канадские доллары;
• скидку на цену, если платеж выпонен через Mondex, используя британские фунты или американские доллары и
• более одного Кассира для случаев использования Mondex или CyberCash;
• поддержка более чем одной версии CyberCash для платежного протокола CyberCoin.

<BrandList ID='M1.2' XML:Lang='us-en' ShortDesc='Company report on XYZ Co'
PayDirection='Debit'>
<Brand ID ='M1.13' BrandId='Mondex' BrandName='Mondex Electronic Cash'
BrandLogoNetLocn='ftp://otplogos.mondex.com' ProtocolAmountRefs='M1.17 M1.18'>
</Brand>
<Brand ID ='M1.14' BrandId='GeldKarte' BrandName='GeldKarte Electronic Cash'
BrandLogoNetLocn='ftp://otplogos.geldkarte.co.de' ProtocolAmountRefs='M1.19'>
</Brand>
<Brand ID ='M1.15' BrandId='CyberCoin' BrandName='CyberCoin Eletronic Cash'
BrandLogoNetLocn='http://otplogos.cybercash.com' ProtocolAmountRefs ='M1.20'>
</Brand >
<Brand ID ='M1.16' BrandId='DigiCash' BrandName='DigiCash Electronic Cash'
BrandLogoNetLocn='http://otplogos.digicash.com'
BrandNarrative='5% off with your Walmart Card on purchases over $150'
ProtocolAmountRefs='M1.22'>
</Brand>
<ProtocolAmount ID ='M1.17' PayProtocolRef='M1.31'
CurrencyAmountRefs='M1.25 M1.29'>
</ProtocolAmount>
<ProtocolAmount ID ='M1.18' PayProtocolRef='M1.32'
CurrencyAmountRefs='M1.26 M1.27 M1.28 M1.30'>
</ProtocolAmount>
<ProtocolAmount ID ='M1.19' PayProtocolRef='M1.35' CurrencyAmountRefs='M1.28'>
</ProtocolAmount>
<ProtocolAmount ID ='M1.20' PayProtocolRef='M1.34 M1.33'
CurrencyAmountRefs='M1.23 M1.24 M1.27 M1.28 M1.29 M1.30'>
</ProtocolAmount>
<ProtocolAmount ID ='M1.21' PayProtocolRef='M1.36'
CurrencyAmountRefs='M1.23 M1.24 M1.27 M1.28 M1.29 M1.30'>
</ProtocolAmount>
<CurrencyAmount ID ='M1.23' Amount='20.00' CurrCode='USD'/>
<CurrencyAmount ID ='M1.24' Amount='12.00' CurrCode='GBP'/>
<CurrencyAmount ID ='M1.25' Amount='19.50' CurrCode='USD'/>
<CurrencyAmount ID ='M1.26' Amount='11.75' CurrCode='GBP'/>
<CurrencyAmount ID ='M1.27' Amount='36.00' CurrCode='DEM'/>
<CurrencyAmount ID ='M1.28' Amount='100.00' CurrCode='FFR'/>
<CurrencyAmount ID ='M1.29' Amount='22.00' CurrCode='CAD'/>
<CurrencyAmount ID ='M1.30' Amount='15000' CurrCode='ITL'/>
<PayProtocol ID ='M1.31' ProtocolId='MXv1.0'
ProtocolName='Mondex IOTP Protocol Version 1.0'
PayReqNetLocn='http://www.mxbankus.com/etill/mx' >
</PayProtocol>
<PayProtocol ID ='M1.32' ProtocolId='MXv1.0'
ProtocolName='Mondex IOTP Protocol Version 1.0'
PayReqNetLocn='http://www.mxbankuk.com/vserver' >
</PayProtocol>
<PayProtocol ID ='M1.33' ProtocolId='Ccashv1.0' ProtocolName='CyberCoin Version 1.0'
PayReqNetLocn='http://www.cybercash.com/ccoin' >
</PayProtocol>
<PayProtocol ID ='M1.34' ProtocolId='CCashv2.0' ProtocolName='CyberCoin Version 2.0'
PayReqNetLocn='http://www.cybercash.com/ccoin' >
</PayProtocol>
<PayProtocol ID ='M1.35' ProtocolId='GKv1.0' ProtocolName='GeldKarte Version 1.0'
PayReqNetLocn='http://www.example.com/pgway'>
</PayProtocol>
<PayProtocol ID ='M1.36' ProtocolId='DCashv1.0'
ProtocolName='DigiCash Protocol Version 1.0'
PayReqNetLocn='http://www.example.com/digicash' >
</PayProtocol>
</BrandList>

12. Соображения IANA
12.1. Коды контролируемые IANA

Для того чтобы гарантировать совместимость, коды, используемые IOTP, нужно поддерживать в контролируемой среде так, что их значения и использование были строго определены, а дублирование кодов должно быть исключено. IANA представляет механизм решения этой проблемы, как это описано в RFC 2434.

Типы элементов и имена атрибутов, к которым эта процедура применяется, приведены ниже в таблице вместе с исходными величинами, разрешенными для этих атрибутов.

Заметим, что: