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

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

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

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

если IotpTransId транзакции, которую надо аннулировать, не распознан, или она завершена, то запрос не проходит, в противном случае,

если IotpTransId относится к транзакции Ping, то запрос не проходит, в противном случае,

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

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

Транзакции 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. Торговые роли, отличные от Покупателя, могут аннулировать транзакцию в следующих случаях:

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

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

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

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

Аутентификация и идентификация личности

Аутентификация сообщений базируется на применении общедоступного ключа, как это делается в алгоритме RSA. Сервер CyberCash содержит записи общедоступных ключей для "персон" покупателя и продавца. Таким образом, можно аутентифицировать любую информацию подписанную покупателем или продавцом, вне зависимости от пути, которым эта информация попала на сервер. Соответствующий секретный ключ, который необходим для формирования цифровых подписей, хранится покупателем и продавцом и никогда не раскрывается. В программе клиента секретный ключ хранится в зашифрованном виде, защищенный парольной фразой. В то время как истинная идентичность покупателя или продавца определяется парой ключей (общедоступный/секретный), для человека эти ключи запомнить слишком сложно (более 100 шестнадцатеричных цифр). Поэтому, пользовательский интерфейс использует короткие алфавитно-цифровые идентификаторы, выбранные пользователем, для того чтобы специфицировать себя. CyberCash добавляет контрольные цифры к запрошенному ADDS ID, с тем чтобы минимизировать вероятность неверного выбора персоны. IDU персоны является общедоступной информацией. Владение ID персоны без соответствующего секретного ключа в данной системе не предоставляет каких-либо преимуществ. Отдельные лица или организации могут образовать одного или несколько CyberCash клиентов. Таким образом, отдельному лицу может соответствовать несколько несвязанных друг с другом CyberCash-клиентов, а разным лицам может соответствовать общий CyberCash-клиент. Этот подход предоставляет уровень конфиденциальности, согласующийся с Интернет и с требованиями финансовых операций. Однако, персона, желающая воспользоваться кредитной карточкой для покупки в рамках системы CyberCash должна сначала идентифицировать себя, как это требует организация, выпустившая эту карту. Контроль над персоной CyberCash доступен только субъекту, владеющему секретным ключом данной персоны. В то же время, для каждой CyberCash-персоны предусмотрена аварийная парольная фраза блокировки. По получении этой парольной фразы, даже в случае использования небезопасного канала, такого как телефон или обычная электронная почта, CyberCash отложит любые операции для данной CyberCash-персоны. Эта парольная фраза может быть записана отдельно и храниться менее строго по сравнению с секретным ключом, так как она не может быть использована для передачи денег. Это обеспечивает некоторую защиту против потери секретного ключа или пароля, с помощью которого он был зашифрован.

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

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

Аутентификатор - организация, запрашивающая аутентификацию и

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

1.	Первая организация, например покупатель, осуществляет действие (например, нажимает на клавишу на HTML-странице), которое требует, чтобы организация была аутентифицирована.
1 а 2	Запрос аутентификации (за пределами действия IOTP)
2.	Вторая организация генерирует данные вызова и список алгоритмов, которые могут быть использованы для аутентификации и/или запрос данных об организации, после чего посылает все это первой организации.
1 Я 2	Запрос аутентификации. Компоненты: запрос аутентификации, запрос информации о торговых ролях.
3.	Первая организация опционно проверяет любую подпись, связанную с запросом аутентификации, после чего использует специфицированный алгоритм аутентификации, чтобы сформировать отклик аутентификации, который посылается второй организации вместе с запрошенной информацией об организации.
1 а 2	Отклик аутентификации. Компонент: отклик аутентификации, организации
4.	Отклик аутентификации проверяется согласно данным вызова для того чтобы выяснить является ли первая организация той, за которую себя выдает, результат записанный в компонент статус посылается первой организации.
1 Я 2	Статус аутентификации. Компонент: Статус
5.	Первая организация опционно проверяет результаты, записанные в cтатус, и все соответствующие подписи, после чего предпринимает некоторые действия или останавливает процедуру.

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

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

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

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

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

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

Базовая транзакция аутентификации

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

перед другой транзакцией IOTP;

одновременно с другой транзакцией;

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

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

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

	- сформировать безопасный канал связи с покупателем (напр., используя [SSL/TLS]);
	- аутентифицировать покупателя, используя базовую транзакцию аутентификации и затем;
	- предоставить покупателю доступ к информации и другим услугам с конфиденциальностью, с которой они общаются с добросовестными клиентами.

как средство предоставления продавцу компонента Organisation, который содержит информацию о покупателе и торговой роли DelivTo;

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

Базовая транзакция депозита

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

опционный документальный обмен аутентификации (смотри раздел 9.1.1);

документальный обмен предложения (смотри раздел 9.1.2) и

документальный обмен платежа (смотри раздел 9.1.3). Способ, с помощью которого эти документальные обмены могут взаимодействовать, показан на рис. .25.

Рис. .25. Базовая транзакция депозита Смотри раздел 9.1.12, чтобы определить какие комбинации документальных обменов применимы к конкретным транзакциям. Заметим, что:

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

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

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

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

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

Базовая транзакция обмена ценностями

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

Перенос электронных средств на кредитную карту. Например, первый платеж может быть "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. Подписи при обмене ценностями

Базовая транзакция отзыва платежа

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

опционный документальный обмен аутентификации (смотри раздел 9.1.1)

документальный обмен предложения (смотри раздел 9.1.2) и

документальный обмен платежа (смотри раздел 9.1.3). Способы, какими эти документальные обмены могут комбинироваться показаны на рис. .28.

Рис. .28. Базовая транзакция отзыва сделки Заметим, что:

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

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

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

базовая транзакция отзыва может использоваться без аутентификации:

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

Базовая транзакция Ping

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

определить, работает ли приложение IOTP другой торговой роли;

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

блок запроса Ping (смотри раздел 8.14),

блок отклика Ping (смотри раздел 8.15) и

блок Signature (смотри раздел 8.16). Сообщения PING На рис. .33 отображен обмен сообщениями прибазовой транзакции Ping.

1.	Приложение IOTP первой торговой роли решает проверить, находится ли в рабочем состоянии соответствующее приложение партнера. Оно генерирует блок запроса Ping, опционный блок подписи и шлет их другой торговой роли.
1 а 2	Запрос PING. IotpMsg: блоки Trans Ref; подписи (опционный); запроса Ping
2.	Вторая торговая роль, которая получает блок запроса Ping, генерирует блок отклика Ping и посылает его отправителю исходного запроса Ping, с блоком подписи, если это требуется.
1 Я 2	Отклик PING. IotpMsg: блоки Trans Ref; подписи (опционный); отклика Ping
3.	Первая торговая роль проверяет блок отклика 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, если они нужны.

Базовая транзакция покупки

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

опционный документальный обмен аутентификации (смотри раздел 9.1.1)

документальный обмен предложения (смотри раздел 9.1.2)

или:

	- документальный обмен платежа ge (смотри раздел 9.1.3), за которым следует
	- документальный обмен доставки (смотри раздел 9.1.4)

только документальный обмен платежа или

комбинированный документальный обменплатежа и доставки (смотри раздел 9.1.5). Способы, какими эти документальные обмена могут комбинироваться показаны на рис. .26.

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

Базовая транзакция возврата денег

Процесс возврата денег обычно состоит из:

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

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

Продавец соглашается (или нет) вернуть деньги. Это может включать некоторые переговоры между покупателем и продавцом, и если продавец согласен,

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

отдельную аутентификацию покупателя, где используется базовая транзакция аутентификации (смотри раздел 9.1.6)

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

	- опционный документальный обмен аутентификации (смотри раздел 9.1.1)
	- документальный обмен предложения (смотри раздел 9.1.2) и
	- документальный обмен платежа (смотри раздел 9.1.3).

Способы того, как эти документальные обмены взаимодействуют, показаны на рис. .27.

Рис. .27. Базовая транзакция возврата денег Базовая транзакция возврата денег без документального обмена аутентификации может использоваться:

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

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

когда аутентификация покупателя осуществлена кассиром в рамках реализации платежного алгоритма.

Базовая транзакция запроса состояния транзакции IOTP

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

торговый блок информационного запроса (смотри раздел 8.12),

торговый блок информационного отклика (смотри раздел 8.13)

опционный блок подписи (смотри раздел 8.16). Запросы состояния транзакции IOTP могут производиться по разным причинам. Например:

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

определить продавцу, завершен ли платеж, доставка и т.д.. Например, покупатель может объявить, что платеж произведен, но нет платежной расписки, подтверждающей это утверждение. Если продавец делает запрос кассиру, то он может определить, произведена или нет соответствующая проплата. Запросы о базовых транзакциях IOTP Ping (смотри раздел 9.2.2) игнорируются. Одна торговая роль может послать запрос любой другой торговой роли в любое время. Программа, которая поддерживает торговую роль покупателя IOTP может не делать:

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

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

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

	- Продавцу, после отправки блока выбора TPO,
	- Кассиру, после отправки блока платежного запроса,
	- Агенту доставки, после отправки блока запроса доставки,

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

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

Рабочие ошибки (смотри раздел 4.2) в исходных сообщениях-запросах.

Технические ошибки (смотри раздел 4.1) - как IOTP, так и специфических для определенных платежных схем es - в исходных IOTP-сообщениях.

Технические ошибки в сообщении, содержащем сам блок информационного запроса. Рабочие ошибки в исходных сообщениях Возврат блока информационного запроса, содержащего компонент Status, который был послан покупателю последним. Технические ошибки в исходных сообщениях Возврат блока информационного отклика, содержащего компонент Status.
Компонент Status должен содержать атрибут ProcessState равный ProcessError. В этом случае в качестве отклика посылается блок Error, указывающий, где в исходном сообщении была найдена ошибка. Технические ошибки в блоке информационного запроса Возврат сообщения Error. То есть, возврат блока Error, содержащего код ошибки (смотри раздел 7.21.2), который описывает природу ошибки в сообщении информационного запроса. Сообщения информационого запроса транзакции На рис. .32 рассмотрен процесс реализации базовой транзакции информационого запроса.

1.	Первая роль решает сделать запрос о транзакции IOTP, например, нажав кнопку запроса в приложении IOTP. Это вызовет генерацию блока информационого запроса и посылку его соответствующей торговой роли.
1 а2	Информационый запрос. IotpMsg: блоки TransRef; подписи (опционный); информационого запроса
2.	Вторая торговая роль проверяет цифровую подпись (если она присутствует). Если получатель хочет среагировать, тогда торговая роль проверяет состояние транзакции, объекта запроса, используя IotpTransId в ID-компоненте блока ссылок транзакции, посылает сообщение первой торговой роли, после чего процесс останавливается
1 Я 2	Информационный отклик. IotpMsg: блоки TransRef; информационного отклика; подписи (опционный)
3.	Первая торговая роль проверяет блок информационного отклика и опционную подпись, выполняет необходимые действия и останавливается. Это может включать отображение статусной информации конечному пользователю.

Рис. .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это предполагает предварительное согласование применение цифровых подписей. Это означает, что:

Покупатели вряд ли будут формировать отклики с подписями, хотя, если они это сделают, это не будет ошибкой;

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

BC- отклик подключения кредитной карты (bind-credit-card-response)

Отмечает, что процесс подключения кредитной карты завершился. Присылает флаг успеха или неудачи.
#####################################################################
Получатель: CyberApp
##################################################################### Пример сообщения: $$-CyberCash-0.8-$$
id: mycybercashid
transaction: 12312314
date: 19950121100505.nnn
opaque:
EDD+b9wAfje5f7vscnNTJPkn1Wdi7uG3mHi8MrzLyFC0dj7e0JRjZ2PmjDHuR81kbhqb
nX/w4uvsoPgwM5UJEW0Rb9pbB39mUFBDLPVgsNwALySeQGso0KyOjMxNs1mSukHdOmDV
4uZR4HLRRfEhMdX4WmG/2+sbewTYaCMx4tn/+MNDZlJ89Letbz5kupr0ZekQlPix+pJs
rHzP5YqaMnk5iRBHvwKb5MaxKXGOOef5ms8M5W8lI2d0XPecH4xNBn8BMAJ6iSkZmszo
QfDeWgga48g2tqlA6ifZGp7daDR81lumtGMCvg==
$$-CyberCash-End-kchfiZ5WAUlpk1/v1ogwuQ==-$$ #####################################################################
Скрытый ключ. Ключ сессии от BC1 и ID
##################################################################### Содержимое скрытой секции: type: bind-credit-card-response
server-date: 19950121100506.nnn
swseverity: fatal/warning [absent if ok]
swmessage; message about obsoleteness of customer software to be shown to the customer. [only resent if SWSeverity present]
response-code: success/failure/etc.
card-number: 1234567887654321
card-type: visa
card-salt: 47562310
card-expiration-date: 01/99
card*: [other card* lines to also be given in CH.1 message]
message; Простой текст для пользователя может содержать много строк. Все строки card* могут быть спасены в виде единого блока для последующего предоставления в CH.1. card-expiration-date, card-number, card-salt и card-type должны присутствовать всегда. В зависимости от причины неудачи не все поля могут быть представлены в сообщении отклике.

BC- подключение кредитной карты (Bind-Credit-card)

Это начальное сообщение в процессе установления соответствия между кредитной картой и персоной CyberCash. #####################################################################
Отправитель: CyberApp
Получатель: CyberServer
#####################################################################
Пример сообщения: $$-CyberCash-0.8-$$
id: MyCyberCashID
date: 19950121100505.nnn
transaction: 12312314
cyberkey: CC1001
opaque:
EDD+b9wAfje5f7vscnNTJPkn1Wdi7uG3mHi8MrzLyFC0dj7e0JRjZ2PmjDHuR81kbhqb
nX/w4uvsoPgwM5UJEW0Rb9pbB39mUFBDLPVgsNwALySeQGso0KyOjMxNs1mSukHdOmDV
4uZR4HLRRfEhMdX4WmG/2+sbewTYaCMx4tn/+MNDZlJ89Letbz5kupr0ZekQlPix+pJs rHzP5YqaMnk5iRBHvwKb5MaxKXGOOef5ms8M5W8lI2d0XPecH4xNBn8BMAJ6iSkZmszo
QfDeWgga48g2tqlA6ifZGp7daDR81lumtGMCvg==
$$-CyberCash-End-kchfiZ5WAUlpk1/v1ogwuQ==-$$ #####################################################################
Скрытый ключ. Формируется из ключа шифрования CyberCash идентифицированного в CyberKey
##################################################################### Содержимое скрытой секции: type: bind-credit-card
swversion: 0.8win
card-number: 1234567887654321
card-type: mastercard
card-salt: 46735210
card-expiration-date: 05/99
card-name: John Q. Public
card-street:
card-city:
card-state:
card-postal-code:
card-country:
signature:
tX3odBF2xPHqvhN4KVQZZBIXDveNi0eWA7717DNfcyqh2TpXqgCxlDjcKqdJXgsNLkY7
GkyuDyTF/m3SZif64giCLjJRKg0I6mqI1k/Dcm58D9hKCUttz4rFWRqhlFaj
#####################################################################
Подпись покрывает следующие поля: id, date, transaction, cyberkey, type, swversion, card-number, card-salt, card-expiration-date, card-name, card-street, card-city, card-state, card-postal-code, card-country
##################################################################### Объяснение: salt необходимо из-за того, что хэш, запомненный сервером, является менее информативным. Сервер лишь запоминает префикс номера кредитной карты и хэш комбинации номера кредитной карты и salt. Если бы он хэшировал лишь номер кредитной карты, появилась бы возможность выяснить номер кредитной карты путем простого перебора всех возможных номеров. Запись номеров кредитных карт в файлы сервера могут сделать систему весьма уязвимой.

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

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

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

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

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

"Небезопасные" сетевые позиции, где конфиденциальность данных не гарантируется. Заметим, что должны присутствовать безопасна33я или не3безопасная сетевая позиция (Net Location) или обе обязательно. Если присутствует одна из двух сетевых позиций, только она и может использоваться. Там где представлены оба типа сетевых позиций, допускается использование обоих, в зависимости от предпочтения отправителя сообщения.

Безопасный обмен сообщениями

Целью безопасного обмена сообщениями является обеспечение конфиденциальности, целостность данных и аутентификация отправителя. Принято два формата сообщений. Формат 1 следует спецификации ISO/IEC 7816-4, где поле данных кодируется согласно BER-TLV и правилам ASN.1/ISO 8825. Этот формат задается младшим полубайтом класса команды равным 0xC. Формат предполагает также, что заголовок команды включается в вычисление MAC (Message Authentication Code). Формат 2 не использует кодирования BER-TLV. В этом случае информационные объекты, содержащиеся в поле данных и их длины должны быть известны отправителю команды и выбранному приложению. Согласно спецификации ISO/IEC 7816-4 этот формат задается младшим полубайтом байта класса, который должен быть равен 0х4. Поле данных команды в случае формата 1 состоит из следующих TLV (Tag Length Value) информационных объектов, как это показано на рисунке 4.6.4.13.

Рис. 4.6.4.13. Формат 1 поля данных команды для безопасного обмена сообщениями Данные команды, если имеются, должны быть подписаны. Если поле данных закодировано согласно BER-TLV, оно либо не должно принадлежать контекстному классу (тэг лежит вне диапазона 80-BF), либо иметь четный тэг. Вторым информационным объектом является MAC. Его тэг равен 0х8Е, а его длина лежит в диапазоне 4-8 байт. В случае формата 2 МАС не кодируется BER-TLV и всегда является последним элементом информационного поля, а его длина лежит в пределах 4-8 байт. Вычисление s байтов МАС (4?s?8) осуществляется согласно ISO/IEC9797 с использованием 64-битового блочного шифра ALG в режиме CBC. Процедура формирования МАС начинается с получения ключа сессии из мастерного ключа МАС ICC. Ключ сессии KS для безопасного обмена сообщениями получается из уникальных мастерных ключей MK с привлечением непредсказуемых данных R, так что KS := F(KS)[R]. Единственным требованием к функции F является то, что число возможных ее значений достаточно велико и равномерно распределено. При использовании формата 1 сообщение состоит из заголовка команды APDU (Application Protocol Data Unite = CLA INS P1 P2) и командной информации (если таковая имеется). В случае формата 2 сообщение формируется согласно спецификации используемой платежной схемы.
Но оно всегда содержит заголовок команды APDU. Если МАС специфицирован, как имеющий длину менее 8 байтов, он получается из старших (левых) байтов 8-байтного результата его вычисления. Формат зашифрованных командных данных показан на рисунке 4.6.4.14.

Тэг	Длина	Значение
T	L	Криптограмма (зашифрованные данные)

Рис. 4.6.4.14. Формат 1 для зашифрованных командных данных Тэг, согласно спецификации ISO/IEC 7816-6 определяется характером исходных (незашифрованных данных). Четный тэг используется, если объект должен быть включен в вычисление МАС; во всех остальных случаях тэг должен быть нечетным. В случае формата 2 поле данных команды шифруется как целое, исключение составляет MAC, если он присутствует (см. рис. 4.6.4.15)

Значение 1	Значение 2
Криптограмма (зашифрованные данные)	МАС (если имеется)

Рис. 4.6.4.15. Формат 2 поля данных команды Процедура шифрования начинается с получения ключа сессии, который вычисляется на основе мастерного ключа шифрования ICC (см. выше). Шифрование производится с использованием 64-битного блочного шифра ALG в режиме СВС (симметричная схема). Для увеличения безопасности может использоваться PIN (Personal Identification Number). Верификация PIN осуществляется терминалом с использованием асимметричного алгоритма (общедоступный и секретный ключи). Более полное описание технологии EMV вы можете найти по адресу (английская версия): Не исключено, что конкуренцию EMV-картам в торговле через Интернет составят виртуальные кредитные карты, применение которых упомянуто во введении. Назад:
Оглавление:
Вперёд:

Безопасный протокол электронных платежей SET

Для операций с кредитными карточками используется протокол SET (Secure Electronic transactions; см. http://www.visa.com/cgi-bin/vee/sf/standard.html http://www.citynet.net/personal/till/set1.htm), разработанный совместно компаниями Visa, MasterCard, Netscape (http://www.netscape.com) и Microsoft (см. также достаточно полное англоязычное описание протокола по адресу ftp://saturn.itep.ru/../set_bk1.pdf и т.д. “SET - Secure Electronic Transaction Specification”). Полная документация по SET имеет объем около 970 страниц. Данная статья является изложением базовых принципов и понятий. В отличие от SSL протокол SET узко специализирован. Целью SET является обеспечение необходимого уровня безопасности для платежного механизма, в котором участвует три или более субъектов. При этом предполагается, что транзакция реализуется через Интернет. В РФ в настоящее время разработано и разрабатывается большое число различных платежных программ, некоторые из них достаточно совершенны. Здесь следует иметь в виду, что если российские торговые компании и банки не хотят оказаться в изоляции, если они не будут учитывать складывающиеся тенденции и стандарты, шансов конкурировать на международном, а вскоре и на отечественном рынке у них не будет. Для этого нужно снять ряд юридических ограничений, действующих в РФ и блокирующих развитие электронной торговли (это касается прежде всего алгоритмов RSA, электронной подписи и т.д.). На базовом уровне SET осуществляет следующие функции:

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

Конфиденциальность. Все операции производятся в зашифрованном виде.

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

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

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

Совместимость. Должна быть предусмотрена совместимость с любыми программными продуктами и с любыми сервис-провайдерами.

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

Регистрацию держателя карточки

Регистрацию продавца

Запрос покупки

Авторизацию платежа

Перевод денег

Кредитные операции

Возврат денег

Отмену кредита

Дебитные операции Окончательная версия протокола SET была выпущена в мае 1997 года. Протокол работает с четырьмя субъектами: владельцем кредитной карточки, банком, эту карточку выпустившим (issuer - эмитент), продавцом (merchant) и банком, где помещен счет продавца (acquirer). Помимо этих функциональных субъектов в процессе обычно (опционно) участвует центры сертификации, в задачу которых входит подтверждение подлинности предъявляемых параметров аутентификации, причем в случае крупных сделок с этими центрами должны взаимодействовать все участники. Основной целью сертификатов является подтверждение того, что присланный общедоступный ключ прибыл от настоящего отправителя, а не от самозванца. Практика электронной торговли позволяет выделить семь этапов сделки.

Этап	Действие
1	Владелец карты просматривает позиции каталога продавца: В реальном масштабе времени на WEB-сервере На CD-диске на своей рабочей станции Читая бумажную версию каталога Через поисковую систему посредника
2	Владелец карты выбирает понравившийся товар или услугу.
3	Владельцу карты предоставляется форма заказа, содержащая список позиций, их цены, стоимости доставки, уровни платежей по налогам, возможные скидки и т.д. Такая форма может быть доставлена по сети с сервера продавца или сформирована торговой программой владельца карты. Иногда продавцы предоставляют возможность согласования цены продукта (например, предъявляя карту постоянного покупателя или предоставляя цены конкурентов).
4	Владелец карты выбирает средство платежа. SET предполагает применение различных кредитных и платежных карт.
5	Владелец карты посылает продавцу заполненную форму заказа и платежные инструкции. В данной спецификации предполагается, что заказ и инструкции подписываются владельцем карты электронным образом с привлечением имеющихся в его распоряжении сертификатов.
6	Продавец запрашивает платежную авторизацию от эмитента карты.
7	Продавец посылает подтверждение заказа.
8	Продавец доставляет заказанный товар или услугу
9	Продавец посылает запрос на оплату товара или услуги финансовой организации владельца карты.

Порядок следования этапов при определенных условиях может несколько варьироваться. Спецификация SET определяет функции и технику реализации этапов 5, 6, 7 и 9. Таким образом, работа протокола SET инициализируется владельцем карты. Владельцем карты может быть как частное лицо, так и корпоративный клиент, работающие на своих рабочих станциях. Многие современные WEB-броузеры поддерживают протокол SET. Что позволяет осуществлять торговлю товарами и услугами с использованием WWW-технологии. Напрашивается вопрос, почему для финансовых операций не использовать протокол SSL, который весьма широко распространен? SSL позволяет безопасно передавать продавцу номер кредитной карточки покупателя, но не способен реализовать многие другие операции, например, проверить этот номер на правильность, проконтролировать, позволено ли данному клиенту пользоваться данной карточкой и т.д.. Конечно, не трудно создать CGI-скрипты, которые решат некоторые из этих проблем, но это не может заменить контроля в реальном масштабе времени, необходимого для некоторых операций. Нельзя утверждать, что в рамках протокола SSL нельзя решить и эти проблемы, но для этого нужно создать достаточно большое число специализированных программ, которые в существующих пакетах пока отсутствуют. Кроме того, нужно думать и о безопасности на стороне сервера. Продавец, получив номер кредитной карточки, может занести его в базу данных. А где гарантия (для покупателя), что эта база данных достаточно хорошо защищена? Таким образом, даже передача номера кредитной карточки посредством SSL не самая лучшая идея. Тем более такая схема позволяет осуществлять подбор номеров кредитных карт. А заботиться об удобствах воров не самое полезное занятие. Номер кредитной карточки имеет определенную структуру (это не случайное число). Первые четыре цифры - код банка, выпустившего карточку. Последняя цифра представляет собой контрольную сумму номера. Вычисление этой контрольной суммы производится по следующему алгоритму. Каждая цифра номера умножается на его “вес”.

Веса меняются 1,2,1,2. Для карт с четным числом цифр, последовательность весов начинается с 2, в противном случае с 1. Если взвешенное число больше 9, из него вычитается 9. Далее вычисляется сумма по модулю 10. Результат всегда должен получаться равным нулю (с учетом кода контрольной суммы). Схема взаимодействия субъектов в протоколе SET показана на рис. 4.6.2.1 (взаимодействия с центром сертификации не показаны). Протокол SET помогает реализовать следующие процедуры.

Безопасный протокол электронных платежей SET

Рис. 4.6.2.1. Схема взаимодействия субъектов протокола SET

Покупатель инициализирует покупку. При этом покупатель выбирает продавца, просматривает его WEB-сайт, принимает решение о покупке, заполняет бланк заказа. Все это делается до вступления в дело протокола SET. Реально взаимодействие участников сделки регламентируется протоколом IOTP. SET начинает свою работу, когда покупатель нажимает клавишу оплаты. При этом сервер посылает ЭВМ-покупателя сообщение, которое и запускает соответствующую программу. Процедура эта может быть реализована с помощью PHP- или CGI-скрипта, или JAVA-аплета.

Программа клиента посылает заказ и информацию об оплате. Для этого формируется два сообщения, одно содержит данные о полной стоимости покупки и номере заказа, второе - номер кредитной карточки покупателя и банковскую информацию. Сообщение о заказе шифруется с использованием симметричного метода (например, DES) и вкладывается в цифровой конверт, где используется общедоступный ключ продавца. Сообщение об оплате шифруется с привлечением общедоступного ключа банка (эмитента кредитной карты). Таким образом продавец не получает доступа к номеру кредитной карточки покупателя. Программа генерирует хэш-дайджест (SHA1) обоих сообщений с использованием секретного ключа покупателя. Это позволяет продавцу и банкиру проконтролировать целостность сообщения, но препятствует прочтению части, ему не предназначенной (например, номера кредитной карты продавцом).

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

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

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

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

Банк продавца авторизует данную операцию, и посылает подтверждение, подписанное электронным образом, WEB-серверу продавца.

WEB-сервер продавца завершает операцию, выдавая клиенту подтверждение на экран, и заносит результат операции в соответствующую базу данных.

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

Банк, выпустивший карточку, посылает счет покупателю и SET уведомляет покупателя об изменениях на его счету (раз в месяц). Итак, видно, что каждый шаг реализации протокола SET сопровождается аутентификацией. Это препятствует какому-то внешнему субъекту стать посредником и видоизменять сообщения. Для нормальной работы протокола SET все участники должны зарегистрироваться и снабдить партнеров своим общедоступным ключом. Протокол SET может использоваться не только в рамках Интернет, но и при заказах по почте или телефону MOTO (Mail Order/Telephone Order). Для понимания основополагающих принципов вышеизложенного могло бы быть достаточно. Более того, квалифицированный программист мог бы написать программы, которые эти принципы реализовали для некоторой замкнутой системы покупатель-банки-продавец.

Но функция SET шире, этот протокол рассчитан на международную ничем не ограниченную систему платежей. По этой причине ниже будут приведены некоторые, наиболее важные детали работы протокола, регламентирующие его функционирование. В вышеприведенном описании предполагалось, что все субъекты процедуры уже владеют соответствующими ключами. На практике до начала такого обмена все участники должны зарегистрироваться (пройти процедуру аутентификации через соответствующий центр), обменяться общедоступными ключами. Общедоступный ключ сопровождается электронной подписью отправителя (X.509v3). Схема регистрации владельца карты в центре сертификации (СА) показана на рис. 4.6.2.2. Процесс регистрации проходит через 7 состояний, начиная с отправки начального запроса и завершая получением сертификата. Эффективность сертификата при идентификации владельца карты сильно зависит от методов, используемых платежной системой карты и эмитентом карты для аутентификации владельца перед выдачей ему сертификата. Это достаточно критический процесс, учитывая то, что на этом этапе еще не используется цифровая подпись.

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

Запрос сертификата указывает на то, что владелец карты намерен выполнить какую-то коммерческую операцию. Полученный сертификат передается продавцу в рамках запроса покупки вместе с платежными инструкциями. Получив сертификат владельца карты, продавец может быть уверен, что счет владельца карты существует и действует, что подтверждено эмитентом карты или его агентом. В рамках SET сертификаты владельцев карты опционны и оставлены на усмотрение платежной системы. Когда сертификационный центр (СА) получает запрос владельца карты, он дешифрует цифровой конверт, получает симметричный ключ, информацию о счете и секретный код, генерируемый программой владельца карты. Собственно запрос сертификата дешифруется с помощью симметричного ключа. Затем СА использует общедоступный ключ, присланный в запросе, чтобы проверить подпись, сформированную с помощью секретного ключа владельца карты. Если с подписью все в порядке, процесс обработки запроса продолжается. Далее производится верификация самого запроса с привлечением информации о счете. На этом этапе СА взаимодействует с эмитентом карты. Это взаимодействие не регламентируется протоколом SET. В некоторых вариантах на данном этапе для верификации запроса привлекаются возможности платежной системы (brand). Если верификация запроса прошла успешно, сертификат формируется и пересылается владельцу карты. При этом СА сначала генерирует случайное число, которое комбинируется с секретным кодом, присланным в запросе. Полученный код используется в сертификате для защиты информации о счете владельца карты. Номер счета, срок его действия и секретный код преобразуются с помощью однопроходного хэш-алгоритма. Полученный результат помещается в сертификат. Если номер счета, срок его действия и секретный код известны, сертификат можно верифицировать. После данной процедуры СА цифровым образом подписывает сертификат. Время действия сертификата определяется политикой СА, но часто оказывается равным сроку работы платежной карты (но может оказаться и короче).

Сообщение-отклик содержит в себе сертификат, а также секретный код, сформированный СА и логотип платежной системы. Вся эта информация шифруется симметричным ключом, присланным в запросе. Многие из упомянутых процедур и структуры запросов/откликов будут рассмотрены подробно ниже. Сертификаты продавца индицируют поддержку определенной платежной системы. Так как сертификаты продавца снабжены цифровой подписью, они не могут быть модифицированы третьей стороной. Эти сертификаты одобряются банком продавца и предоставляют гарантию того, что продавец имеет официальное соглашение со своим банком. Для работы в среде SET продавец должен иметь как минимум пару сертификатов для каждой разновидности, поддерживаемой им платежной системы. Схема процедуры регистрации продавца показана на рис. 4.6.2.3 и содержит в себе 5 этапов.

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

Для регистрации продавец заполняет регистрационную форму, внося туда свое имя, адрес, идентификатор и т.д. Вместе с заполненной формой в СА посылается общедоступный ключ продавца. Эта информация подписывается программой продавца. Далее программа генерирует случайный симметричный ключ, который используется для шифрования запроса сертификата. Сам симметричный ключ шифруется с использованием общедоступного ключа СА и помещается в цифровой конверт. Сформированное таким методом сообщение посылается продавцом в СА. Когда СА получает запрос продавца, он дешифрует цифровой конверт и извлекает оттуда симметричный ключ, который служит для дешифрации запроса. СА использует ключ, содержащийся в сообщении-запросе, для проверки цифровой подписи (проверка того, что сообщение подписано соответствующим секретным ключом). Если с подписью все в порядке, обработка запроса продолжается, в противном случае прерывается и посылается соответствующее уведомление продавцу. После этого СА проверяет информацию регистрационного запроса, используя известные данные о продавце. Для этого производится обмен между СА и банком продавца (получателем). После успешной верификации этих данных СА формирует и цифровым образом подписывает сертификат продавца. Время действия сертификата определяется политикой СА. Но это время не должно быть больше длительности контракта между продавцом и его банком. Сертификат шифруется сгенерированным новым симметричным ключом, который в свою очередь шифруется общедоступным ключом продавца. Полученный код образует цифровой конверт отклика. Сообщение-отклик посылается продавцу. Когда программа продавца получает отклик от СА, она дешифрует цифровой конверт и получает симметричный ключ для дешифрования регистрационного отклика, содержащего сертификат продавца. SET может работать в режиме, когда участники не имеют сертификатов и не прошли аутентификацию. Такой режим сопоставим с использованием SSL для пересылки номера карточки продавцу, и не может рассматриваться как удовлетворительный.

В рамках протокола используются следующие значения символов-префиксов участников сделки:

Символы-префиксы	Участник сделки
C	Владелец карты (Cardholder)
M	Продавец (Merchant)
P	Расчетный центр (Payment Gateway)
CA	Сертификационный центр (Certificate Authority)

Рассмотрим диаграмму конечных состояний протокола SET (см. рис. 4.6.2.4).

Рис. 4.6.2.4. Диаграмма реализации протокола SET Начальным состоянием покупателя является shopping. Когда решение о покупке принято, программой клиента посылается запрос PReq и система переходит в состояние заказано. Запрос PReq включает в себя инструкцию OI (Order Instruction) и платежную инструкцию PI. Отклик PRes держателю карты может быть прислан немедленно или с некоторой задержкой. Полученная в отклике информация зависит от состояния протокольной машины (принят заказ, транзакция авторизована и т.д.). Продавец посылает запрос авторизации платежному серверу, но флаг CaptureNow не устанавливается равным “истинно”, так как запрос оплаты (capture request) будет обработан позже. В состоянии авторизовано допускается частичный пересмотр условий сделки, при этом система может вернуться в состояние заказано или остаться в состоянии авторизовано. Продавец теперь имеет платежное обязательство от эмитента карты, но он должен обработать запрос покупки, для того чтобы получить соответствующую оплату. Запрос CapReq переводит транзакцию в состояние приобретено (Captured - сделка оплачена) и заказ обрабатывается. Если поступит запрос отмены сделки, система возвращается в состояние авторизовано. Далее владелец карты может запросить кредит. В этом случае обрабатывается запрос кредита, переводя транзакцию из состояния покупка осуществлена (sale processed) в состояние кредит выдан (credit issued). Запрос покупки (Sale Request) используется, когда продавец знает, что заказанный товар на складе и может быть поставлен немедленно при наличии авторизации. Этот запрос используется также в случае заказа товара или услуг, доставляемых через Интернет. Когда расчетный центр (Payment Gateway) обрабатывает запрос, происходит переход транзакции в состояние покупка осуществлена.

С финансовой точки зрения состояния sale processed (обработана) и captured (оплачена) являются эквивалентными. В случае необходимости возврата денег клиенту, запрос кредита (CredReq) переводит систему в состояние кредит получен. Следует учитывать, что реализации некоторых компаний не поддерживают частичный возврат денег (сумма из запроса AuthRevReq копируется в сообщение AuthRevRes). Когда продавец не может выполнить заказ в полном объеме сразу, он поставляет имеющиеся в наличии товары, а нехватающие заказывает дополнительно. Продавец может предложить клиенту различные схемы оплаты, например, осуществить оплату заказа в несколько этапов, или в случае предоставления Интернет услуг оплата может происходить на регулярной основе раз в месяц без участия самого держателя кредитной карты. Протокол SET позволяет расчетному центру (Payment Gateway) определять, будет ли продавец получать номер счета владельца карты. Если эмитент карты решает не выдавать эту информацию, продавцу должен быть предоставлен какой-то другой механизм для возвращения сдачи в рамках текущей транзакции. Для этих целей в рамках транзакции предусмотрено несколько полей:

XID	20-байтовое число, которое однозначно идентифицирует транзакцию (включает в себя все аутентификационные и клиринговые сообщения).
RRPID	20-байтовое число, которое однозначно идентифицирует запрос.
locallD-M	1-20 байтовый локальный идентификатор, присваиваемый транзакции программой продавца
paySysID	1-64 байтовый идентификатор транзакции
MerOrderNum	1-25 байтовый номер заказа продавца

Рассмотрим более подробно функции субъектов протокола SET.

Держатель карты (Cardholder)	Авторизованный владелец платежной карты, предоставленной ему эмитентом и предназначенной для выполнения платежей за покупки и услуги.
Продавец (Merchant)	Субъект или фирма, предлагающие товары, информацию или услуги, получающие от этого прибыль в виде платежей.
Эмитент (Issuer)	Финансовая организация, которая осуществляет выпуск платежных карт для клиентов и поддерживает функционирование их счетов. Эмитент гарантирует осуществление платежа для авторизованной транзакции.
Получатель (Acquirer)	Финансовая организация, которая поддерживает продавцов, осуществляя операции с платежными картами. Получатель осуществляет сбор финансовых данных, имеющих отношение к транзакции, для получения авторизации платежа, который выполняет эмитент.
Расчетный центр (Payment Gateway)	Система, которая предоставляет коммерческие услуги продавцам через посредство получателя, и обеспечивает интерфейс получателю для авторизации и реализации транзакции. Расчетный центр обычно управляется получателем.
Платежная система (Brand)	Система или компания, предоставляющая платежные средства (например, карты VISA, MasterCard и т.д.)
Сертификационный центр (Certificate Authority -CA)	Агент одной или нескольких систем платежных карт, который осуществляет создание и рассылку сертификатов для продавцов, покупателей и расчетных центров. Участники транзакции могут иметь единый сертификационный центр, но могут работать и с разными центрами. Основная задача СА - гарантия того, что данное сообщение, ключ и т.д. посланы определенным субъектом, а не самозванцем.

Протокол SET защищает только финансовую информацию, непосредственно сопряженную с платежной транзакцией. Защита информации, содержащейся в заказе, SET не регламентирует. Хэш описания заказа включается в запрос покупки (PReq). В SET под владельцем платежной карты подразумевается программа, работающая на рабочей станции клиента-покупателя. Эта программа обеспечивает доступ к серверам продавцов, если требуется, поддерживает диалог между покупателем и продавцом, и реализует платежный процесс. При этом посылается заказ, получается отклик на этот заказ, осуществляются, если требуется, дополнительные информационные запросы и получаются данные о ходе реализации транзакции. Эта программа выполняет опосредованную связь с получателем. Зашифрованные платежные данные через систему продавца поступают в расчетный центр, где они дешифруются. Программа продавца предоставляет интерфейс для взаимодействия с программой владельца платежной карты, с программой получателя (Acquirer - банк продавца) и с центром сертификации. Эта программа авторизует транзакцию, инициированную владельцем карты. Выполнение криптографических операций может производиться на аппаратном уровне. Такие криптографические модули могут быть снабжены также аппаратными устройствами генерации и запоминания секретных ключей (например, смарт-карты). Важной функцией расчетных центров помимо реализации платежей является поддержка списков аннулированных сертификатов CRL (Certificate Revocation List). Это крайне важно для вовлеченных финансовых организаций и фирм предоставляющих платежные средства (например, таких как VISA или MasterCard). Сертификаты расчетного центра (РЦ) пересылаются банку продавца (получателю) и служат для обработки сообщений авторизации и платежей. Ключ шифрования расчетного центра, который получает владелец карты из сертификата РЦ, используется для защиты информации о счетах владельца карты. Сам банк продавца (получатель) должен иметь сертификаты для того, чтобы взаимодействовать с сертификационным центром, который может получать и обрабатывать запросы, поступающие непосредственно от продавцов.

Банк продавца получает свои сертификаты из платежной системы (brand). Эмитент карт должен владеть сертификатами, чтобы взаимодействовать с сертификационным центром, который может получать и обрабатывать запросы, поступающие непосредственно от владельцев карт. Эмитент получает сертификаты также из платежной системы. Протокол SET определяет иерархию сертификационных центров, во главе которой находится RCA (Root Certificate Authority). Далее следуют BCA (Brand-specific CA) и GCA (Geo-political CA). Некоторые платежные системы имеют свои сети, например, VisaNet или BankNet. Эти сети осуществляют авторизацию платежей от эмитента к получателю и имеют свою систему защищенной передачи сообщений (ISO 8583). Цифровая подпись устанавливает соответствие между подписанными данными и уникальным секретным ключом подписанта (покупателя, продавца, банкира или центра сертификации). Секретный ключ математически связан с общедоступным ключом, и таким образом, связывает данные и общедоступный ключ. Фундаментальной целью сертификата является установление соответствия между общедоступным ключом и уникальным идентификатором объекта (или субъекта), гарантируя отсутствие подмены. Следует помнить, что общедоступные ключи пересылаются по незащищенным каналам Интернет. В случае держателя карты сертификат подписи устанавливает соответствие между его общедоступным ключом и индивидуальным кодом PAN (Primary Account Number). Цифровая подпись в сочетании с хэшированием сообщения (вычислением его цифрового дайджеста) гарантирует, кроме того, целостность данного сообщения, блокируя возможность его модификации в процессе пересылки. Сообщения SET следуют рекомендациям ISO/IEC и ITU-T ASN.1 (Abstract Syntax Notation) и кодируется с использованием правил DER (Distinguished Encoding Rules). Механизм пересылки сообщений между объектами SET не регламентируется. Предполагается, что приложения SET могут работать в одном из двух режимов.

Интерактивном, когда объекты взаимодействуют в реальном масштабе времени с малыми задержками между запросами и откликами (например, в рамках технологии WWW).

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

Архитектура SET использует концепцию BrandCRLidentifier (BCI). BCI подписывается цифровым образом представителем платежной системы. Протокол SET предполагает использование пар общедоступный/секретный ключ платежными центрами и продавцами обязательным и рекомендательным для владельцев карточек. SET использует стандарты PKCS (Public Key Cryptography Standards). Разработчики программ и систем должны обращать особое внимание на способы хранения секретных ключей. Настоятельно рекомендуется применение аппаратных средств для генерации ключей и шифрования. В настоящее время такие модули предлагаются и для обычных рабочих станций. Особые меры безопасности должны быть приняты для центров сертификации, так как именно они выступают гарантами корректности и безопасности применения общедоступных ключей участников транзакций. Информация о счете владельца карты для продавца шифруется его общедоступным ключом. Доступ продавца к этой информации является опционным, (см. замечания выше). При выборе данной опции должны быть приняты меры для обеспечения конфиденциального хранения этих данных на сервере продавца. Как минимум эта информация должна храниться в зашифрованном виде и к ней должен быть ограниченный доступ. Так как сертификаты, CRL и BCP используются достаточно часто при обработке сообщений SET, должен быть создан безопасный кэш для их хранения. Так как объем транспортируемых протокольных структур весьма велик, для сокращения трафика используется механизм оттисков (thumbprints). Оттиск представляет собой хэш сертификата, CRL или BCI. Точнее это хэш SHA-1 одного из перечисленных объектов, снабженный цифровой подписью. Цифровой конверт сообщения (MessageWrapper). MessageWrapper является информационной структурой верхнего уровня (ASN.1/DER) протокола SET. Эта структура размещается в самом начале сообщения и часто не шифруется. Она определяет тип MessageWrapper, информационные поля цифрового конверта представлены в таблице 4.6.2.1. Таблица 4.6.2.1. Поля MessageWrapper

Название поля	Описание
Message-Wrapper	{MessageHeader, Message, [MWExtension]}}
MessageHeader	{Version, Revision, Date, [MessageID], [RRPID], SWIdent}
Version	Версия SET-сообщения
Revision	Подтип SET-сообщения
Date	Дата генерации сообщения
MessageID	{[LID-C], [LID-M], [XID]}
RRPID	Идентификатор, позволяющий объединять в пары запросы и отклики
SWIdent	Идентификация программы (поставщик и версия), инициировавшей запрос. Эта информация представляется строкой символов
Message	< PInitReq, PInitRes, PReq, PRes, InqReq, InqRes, AuthReq, AuthRes, AuthRevReq, AuthRevRes, CapReq, CapRes, CapRevReq, CapRevRes, CredReq, CredRes, CredRevReq, CredRevRes, PCertReq, PCertRes, BatchAdminReq, BatchAdminRes, CardCInitReq, CardCInitRes, Me-AqCInitReq, Me-AqCInitRes, RegFormReq, RegFormRes, CertReq, CertRes, CertInqReq, CertInqRes, Error>
LID-C	Локальный идентификатор, генерируемый системой владельца карты или для его системы
LID-M	Локальный идентификатор, генерируемый системой продавца или для его системы
XID	Глобальный идентификатор, генерируемый продавцом (или владельцем карты, если нет PInitRes)
MWExtension	Расширение сообщения SET. Расширение используется, когда информация в расширении является общей, описывающей сообщения SET, или когда содержимое сообщения зашифровано, а расширение содержит нефинансовую информацию, не требующую конфиденциальности.

Обработка сообщения начинается с MessageWrapper. Каждое сообщение должно иметь незашифрованный конверт MessageWrapper, который декодируется перед началом обработки самого сообщения. Поля TransID и RRPID используются для ранней диагностики дублированных сообщений. При декодировании MessageWrapper компонента Message не может обрабатываться, но его тип можно определить по полю тип (DER) сообщения. По завершении декодирования MessageWrapper производится дешифрование и верификация подписи Message. После этого проводится декодирование Message. Обработка этого компонента зависит от его типа. При описании протокола используется нотация представленная в таблице 4.6.2.2. Таблица 4.6.2.2. Нотация протокола SET

Понятие	Нотация	Описание
Группа (tuple)	{A,B,C}	Группа из нуля или более информационных элементов. Представляет документы или сообщения, обозначается идентификаторами, содержащими алфавитно-цифровые символы
Компонент	T={A,B,C}	Группе может быть присвоено имя. В этом случае T.A, T.B и T.C обозначают компоненты Т.
Упорядоченное объединение	A\|B\|C	Служит для обозначения упорядоченного объединения элементов A,B и C
Опционное значение	[A]	Значение A является опционным	Допускается любое вложение этих скобок
Выбор		Обозначает, что должно присутствовать одно из значений A,B или C
Опционный выбор	[]	То же, что и предыдущее, но сам выбор опционен
Кратное использование	{A+}	Группа содержит один или более элементов A
	{A*}	Группа содержит нуль или более элементов A
	{[A]+}	Означает, что группа содержит:один или более элементов A в упорядоченном массиве, где каждое вхождение A является опционным (этот элемент может отсутствовать)
Исключающее ИЛИ	Е	Обозначает операцию исключающее ИЛИ

Таблица 4.6.2.3. Операторы, используемые протоколом SET

Нотация	Оператор		Описание
H(t)	хэш		160-битовый хэш группы t
HMAC(t,k)	Ключевой хэш-механизм		160-битовый ключевой хэш группы t, использующий ключ k и алгоритм HMAC-SHA-1 HMAC(t,k) = H(k Е opad) \| H((k Е ipad)\|t)),где ipad - байт 0х36, повторенный 64 раза;opad - байт 0х5С, повторенный 64 раза; аЕ - знак операции исключающее ИЛИ.
L(t1,t2)	Связь		Ссылка, указатель или связь t2 с t1; эквивалентно группе {t1, H(t2)}
Нотация операторов цифровой подписи
S(s,t)	Подписанное сообщение		Подпись объекта s для группы t, включая открытый текст t. Алгоритмом цифровой подписи для SET является RSA с дайджестом SHA-1. Соответствует SignedData PKCS #7.
Нотация операторов двойной цифровой подписи
SO(s,t)	Только подпись		Подпись объекта s для группы t, не включая открытый текст t. SO соответствует внешней подписи PKCS #7. Алгоритмом цифровой подписи для SET является RSA с дайджестом SHA-1.
Нотация операторов шифрования
E(r,t)	Асимметричное шифрование (цифровой конверт)		Сначала шифруется t с новым симметричным ключом k, затем ключ вкладывается в цифровой конверт PKCS #7 для объекта r. Производится шифрование OAEP(k) с использованием общедоступного ключа объекта r, взятого из сертификата группы r. Для симметричного шифрования в SET по умолчанию используется алгоритм DES. Соответствует EnvelopedData.
EH(r,t)	Шифрование целостности		Процедура подобна E за исключением того, что цифровой конверт PKCS#7 содержит OAEP({k,H(t)}) для гарантии целостности, когда подпись не доступна. Программа вычисляет повторно хэш t и проверяет соответствие H(t) в цифровой конверте.
EX(r,t,p)	Дополнительное шифрование		Процедура подобна E за исключением того, что t и p являются частями составного сообщения. t - группа, которая должна быть соединена с p и подвергнута обычному симметричному шифрованию, а p - параметр или часть, которая должна быть подвергнута дополнительной обработке. t связано с p. OAEP({k,p}) вкладывается в цифровой конверт PKCS#7 для объекта r.
EXH(r,t,p)	Дополнительное шифрование с обеспечением целостности		Процедура подобна EX за исключением того, что это делается с OAEP({k,H(t), p}) в цифровом конверте PKCS#7 и с требованием проверки H(t), как и в случае EH
EK(k,t)	Симметричное шифрование посредством ключа k		Симметричное шифрование группы t с помощью секретного ключа k. Соответствует формату EncryptedData
Нотация операторов инкапсуляции
Enc(s,r,t)		Простая инкапсуляция с подписью		Подписанное и затем зашифрованное сообщение. Соответствует SignedData в EnvelopedData
EncK(k,s,t)		Простая инкапсуляция с подписью и предоставленным ключом		Подписанное сообщение, зашифрованное с помощью секретного ключа. Соответствует EncryptedData.
EncX(s,r,t,p)		Дополнительная инкапсуляция с подписью		Составное сообщение, первая часть которого зашифрована симметричным алгоритмом. Вторая часть сообщения преобразуется с привлечением алгоритма OAEP
EncB(s,r,t,b)		Простая инкапсуляция с подписью с загрузкой		Подписанное зашифрованное сообщение с загрузкой (baggage)
EncBX(s,r,t,p,b)		Дополнительная инкапсуляция с подписью и загрузкой		Подписанное, Е-шифрованное составное сообщение с загрузкой

OAEP - Bellare-Rogaway Optimal Asymmetric Encryption Padding
HMAC - ключевой хэш-механизм, базирующийся на алгоритме SHA-1. В операциях с общедоступными ключами и сертификатами в SET используется алгоритм RSA. Обычно длина ключа составляет 1024 бита и только для Root CA (базового центра сертификации) применяются ключи длиной 2048 бит. Для симметричного шифрования обычно применяется алгоритм DES. Помимо него используется также алгоритм CDMF (Commercial Data Masking Facility), он служит для защиты сообщений между получателем и держателем карты. DES работает с блоками данных 64 бита и предполагает использование для операций шифрования и дешифрования одного и того же 56-битного ключа (каждый байт содержит бит четности). Правила заполнения SET для DES-CBC требуют, чтобы строка заполнителя всегда добавлась к открытому тексту, подлежащему шифрованию. Заполнитель делает длину блока данных кратной 8 октетам. Если BL представляет конечную длину блока данных, тогда длина строки заполнителя состоит из 8 -(BLmod 8) октетов. Каждый из байтов заполнителя содержит код 8 -(BLmod 8). Когда длина заполнителя равна одному октету, код октета равен 01. При длине строки в два байта код строки заполнителя будет равна 0202, а при трех байтах - 030303. Алгоритм CDMF осуществляет скремблинг данных, который базируется на DES в несколько облегченной модификации, когда эффективная длина ключа равна 40 бит вместо 56 - для DES. По этой причине алгоритм CDMF называется алгоритмом маскирования, а не шифрования. Транспортировка ключа CDMF осуществляется в рамках SET-сообщений также как и ключей DES. SET использует усовершенствованный Матиасом и Джонсоном метод хэширования, улучшающий технику OAEP. Общая схема процесса шифрования и дешифрования, представляемая с привлечением общепринятых персонажей Алисы (отправитель шифрованного сообщения) и Боба (получатель) представлена в таблице ниже.

Шаг	Действие
1	Алиса запускает программу вычисления дайджеста сообщения, которое она намерена послать Бобу. Этот дайджест будет использован для проверки отсутствия модификации сообщения в процессе его транспортировки от Алисы к Бобу.
2	Алиса шифрует дайджест сообщения с использованием своего секретного ключа, формируя цифровую подпись.
3	Формируется псевдослучайный код (симметричный ключ) и с помощью его шифруется сообщение, цифровая подпись и сертификат Алисы, который содержит в себе ее общедоступный ключ. Чтобы дешифровать данное сообщение Бобу будет нужен указанный выше симметричный ключ.
4	Сертификат Боба, который Алиса должна была получить заранее, содержит копию общедоступного ключа Боба. Чтобы гарантировать безопасность пересылки симметричного ключа, Алиса должна зашифровать его с использованием общедоступного ключа Боба. Зашифрованный таким способом симметричный ключ заносится в одно из полей цифрового конверта (иногда единственное поле), куда в свою очередь будет вложено зашифрованное сообщение.
5	Алиса посылает сообщение Бобу. При этом в его состав входит: Сообщение, зашифрованное с применением симметричного ключа, цифровая подпись, сертификат и асимметрично зашифрованный симметричный ключ (цифровой конверт).
6	Боб получает сообщение от Алисы, дешифрует ключ-конверт с привлечением своего секретного ключа и получает в свое распоряжение симметричный ключ.
7	Боб использует симметричный ключ для дешифрования текста сообщения, подписи Алисы и ее сертификата.
8	Осуществляется дшифрация подписи Алисы с привлечением ее общедоступного ключа, который берется из ее сертификата. В результате получается дайджест посланного сообщения.
9	Боб независимо вычисляет дайджест полученного сообщения с привлечением того же алгоритма, что был использован Алисой.
10	Полученный и вычисленный дайджесты сравниваются. Если они совпадают, значит, сообщение не было модифицировано по дороге и было послано именно Алисой, а не кем-то кто выдается себя за нее (предполагается, что только Алиса знает свой секретный ключ). Несовпадение дайджестов означает, что, либо сообщение было модифицировано после его подписания Алисой, либо отправлено кем-то еще. В обоих вариантах сообщение отбрасывается, опционно Боб может попытаться уведомить об этом Алису.

В протоколе SET часто используются так называемые двойные подписи. Для того чтобы понять их назначение, рассмотрим следующий пример. Пусть Боб хочет послать Алисе предложение купить некоторый товар и авторизационные параметры своего счета в банке, чтобы она могла выполнить оплату товара в случае, если предложение ее устроило. Предположим также, что Боб не хочет, чтобы банк узнал условия предложения, а Алиса получила данные о его счете в банке. Кроме того, Боб хочет, чтобы денежный перевод производился лишь в случае принятия его предложения Алисой. Для решения такой задачи сообщения Алисе и распоряжение банку подвергаются процедуре двойной подписи. Для реализации двойной подписи формируются дайджесты обоих сообщений, после чего они объединяются. Вычисляется дайджест сообщения-результата, после чего этот дайджест шифруется секретным ключом отправителя (Боба). Подписант должен добавить дайджест другого сообщения, для того чтобы получатель мог проверить корректность двойной подписи. Получатель любого из указанных выше сообщений может проверить их аутентичность, путем вычисления дайджеста самого сообщения с последующим добавлением к нему дайджеста другого сообщения (присланного отправителем) и вычислением дайджеста результата. Если вычисленный таким образом дайджест совпадет с дешифрованной двойной подписью, получатель может быть уверен в аутентичности сообщения. При этом ни одна из сторон не может оспаривать корректность действий другой стороны (будет оплачено именно то предложение, которое было послано клиенту). Если Алиса принимает предложение Боба, она может послать сообщение в банк, указав свое согласие на оплату предложения Боба и включив в это сообщение дайджест предложения, вычисляет дайджест всего такого сообщения. Можно было бы включить само предложение, но, во-первых, в этом случае было бы раскрыто его содержимое, а во-вторых, предложение обычно во много раз больше по объему, чем дайджест. Получатель проверяет соответствие этого дайджеста дешифрованной двойной подписи, что позволяет ему судить об аутентичности сообщения.

Банк в этом случае может быть уверен, что согласие получено именно на это, а не на какое-то другое сообщение. В то же время банк не получает доступа к тексту предложения. В протоколе SET двойные подписи используются для установления связи между сообщением-заказом, посланным продавцу, и платежными инструкциями, содержащими информацию о счетах клиента, посланными получателю платежа (обычно это банк продавца). Важным принципом при анализе работы программ SET является идемпотентность - реакция алгоритма на повторное выполнение одних и тех же сообщений. Обычно SET используется поверх протоколов HTTP или SMTP, которые, в свою очередь, работают на основе транспортного протокола TCP. Протокол TCP сам по себе гарантирует доставку сообщения. Но в SET из-за высокой степени финансовой ответственности вводится дополнительный контроль доставки уже на прикладном уровне. Любой механизм гарантированной доставки предполагает повторную посылку сообщения при отсутствии отклика от получателя. Следует иметь в виду, что практически невозможно разделить потерю сообщения и отклика на это сообщение. Именно по этой причине программа получателя должна быть готова к обработке повторных сообщений, так как задержка при транспортировке в Интернет может спровоцировать повторную посылку запроса. Повторные запросы должны иметь тождественные идентификаторы (XID и PRPID). Повторная посылка запросов и их обработка не должны влиять на конечный результат. Но не все виды запросов требуют такой обработки. Информационные запросы в отличие от запросов-заказов не нуждаются в запоминании продавцом (для выяснения того, являются ли они повторными). На такие запросы посылаются отклики каждый раз в соответствии со статусом системы. То есть на один и тот же запрос в разное время может быть получен разный отклик. Если приложение SET детектирует атаку типа “шторма запросов”, оно может не реагировать на эти запросы. XID является статистически уникальным идентификатором платежной транзакции и позволяет идентифицировать все относящиеся к ней сообщения.

Его длина составляет 20 байт. BrandID представляет собой поле, используемое протокольными сообщениями управления платежом и сертификации. Оно содержит имя платежной системы (Brand) и опционное название продукта в рамках данной платежной системы. Запись имеет формат brand:product. Безопасность системы SET зависит от подлинности сертификатов, используемых системой. Система производит иерархическую верификацию всех сертификатов. Цепочка сертификатов завершается корневым сертификатом (Root CA), общим для всей системы. Общедоступный ключ Root CA (корневого сертификационного центра; X.509v3) распространяется в виде сертификата программным обеспечением SET. Для верификации цепи сертификатов необходимо иметь общедоступный корневой ключ. Cert-PE представляет собой сертификат, сформированный узлом сертификации платежного центра (PCA) и связывает расчетный центр с общедоступным ключом шифрования, присылаемым в сообщении запроса сертификата CertReq. Отправитель гарантирует корректность формата сообщения, который должен соответствовать типу сообщения. Если какая-то часть сообщения подписана отправителем, сообщение должно содержать сертификаты CRL и BrandCRLIdentifiers. Для обеспечения совместимости и дальнейшего расширения возможностей протокола используются стандарты PKCS и Cryptographic Message Syntax (стандарт на криптографический синтаксис сообщений), которые определяют и механизмы криптографического вложения. Форматы PKCS используются для вложения данных в сообщения SET. Данный протокол использует следующие методы инкапсуляции PKCS #7.

SignedData для вложения подписанной информации

EnvelopedData для инкапсуляции зашифрованных данных

EncryptedData для инкапсуляции зашифрованных данных c использованием симметричного алгоритма

DigestedData для инкапсуляции хэшированных или связанных данных Тип SignedData из PKCS #7 проиллюстрирован на рис. 4.6.2.5, где отображен процесс цифровой подписи. В пределах SignedData может присутствовать несколько полей Signerinfo, но подписывать SignedData может не более двух субъектов.

Рис. 4.6.2.5.

SignedData Тип подписанного содержимого косвенно защищается включением в текст атрибута contentType (PKCS #9). Дайджест данных, который подписывается, также включает атрибут messageDigest. SignedData всегда содержит два аутентифицированных атрибута contentType и messageDigest. Тип EnvelopedData из PKCS #7 проиллюстрирован на рис. 4.6.2.6.

Рис. 4.6.2.6. EnvelopedData В пределах EnvelopedData допускается наличие нескольких EnvelopedData и только одно RecepientInfo. Тип EncryptedData из PKCS #7 проиллюстрирован на рис. 4.6.2.7.

Рис. 4.6.2.7. EncryptedData Тип DigestedData из PKCS #7 проиллюстрирован на рис. 4.6.2.8.

Рис. 4.6.2.8. DigestedData Обработка сообщений Базовыми процедурами протокола SET является посылка и прием сообщений. Процесс отправки сообщения представлен в таблице 4.6.2.4. Таблица 4.6.2.4. Отправление сообщения

Шаг	Действие
1	Генерация сообщения SET
2	Вложение кода текущей версии в MessageWrapper (цифровой конверт, сейчас 1 или 0)
3	Вложить код даты, включая время.
4	Заполнить MessageID из полей TransID в Message. Если MessageID в Message отсутствует, поле опускается.
5	Вводится RRPID. Если это запрос, генерируется RRPID и запоминается для последующего сравнения с соответствующим кодом отклика. Если посылается отклик, то RRPID копируется из запроса.
6	Вводится SWIdent. Это строка, которая идентифицирует разработчика и версию программного продукта
7	Вкладывается Message
8	Производится DER-кодирование вложенного сообщения
9	Сообщение передается на транспортный уровень

Процедура обработки входящего сообщения рассмотрена в таблице 4.6.2.5. Таблица 4.6.2.5. Прием и обработка входного сообщения

Шаг	Действие
1	Извлекается цифровой конверт сообщения
2	Проверяется формат и содержимое полей цифрового конверта сообщения: версия, субверсия, дата/время, тип сообщения. Если обнаружена ошибка, возвращается отклик Error с ErrorCode.
3	Используя RRPID, производится сравнение и актуализация контрольного журнала на предмет выявления повторных сообщений
4	Произвести DER-декодирование сообщения
5	Если сообщение содержит SignedData, произвести следующее: Актуализовать системный кэш с учетом полученных CRL. Для каждого полученного сертификата, произвести верификацию цепочки сертификатов Проверить подпись сообщения
6	Если сообщение содержит инкапсулированные данные, выполняется извлечение вложенных данных согласно типу вложенного содержимого, включая шаг 5, если вложенные данные содержат SignedData
7	Извлечь идентификаторы BrandCRLIdentifier, включенные в сообщение и актуализовать системный кэш, проверить, что все CRL, идентифицированные BCI, находятся в системном кэше. В противном случае обработка сообщения прерывается.
8	Обработать сообщение
9	Актуализовать системный журнал с учетом состояния транзакции

Верификация цепочки сертификатов требует, чтобы последовательно проверялся каждый сертификат, и контролировалось его соответствие выпустившему его центру. Например, держатель карты должен проверить сертификаты продавца, центра сертификации продавца, центра сертификации платежной системы (Brand CA), и корневого центра Root CA. Процесс верификации включает в себя следующие компоненты:

Контроль сертификатов X.509

Контроль сертификатов SET

Обработку CRL (Certificate Revocation List)

Обработку BrandCRLIdentifier (BCI) На практике предполагается, что процесс верификации будет остановлен на уровне, который был успешно пройден ранее. Все приложения SET помимо самих сертификатов контролируют их дату пригодности. Процедура верификации представлена в таблице 4.6.2.6. Таблица 4.6.2.6. Верификация сертификатов

Шаг	Действие
1	Верифицировать каждый сертификат в цепи согласно правилам X.509
2	Проверить то, что расширения KeyUsage, CertificatePolicies, PriviteKeyUsage и AuthorityKeyIdentifier находятся в согласии c Х.509.
3	Если получено новое значение BCI:а. Проверить его подпись, используя сертификат CRL центра сертификации платежной системыб. Проверить, что BrandName в BCI соответствует тому, что проверено в цепочке сертификациив. Проверить, что дата NotAfter меньше текущей датыг. Проверить SequenceNum. Если оно больше чем SequenceNum из кэша BCI запомнить BCI и проверить, что все CRL, содержащиеся в BCI находятся в кэше CRL. Запомнить любой CRL, который пока нет в кэше
4	Провести верификацию для каждого нового полученного CRL,
5	Проверить каждый сертификат

Блок Cancel

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

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

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

ID	Идентификатор, который однозначно определяет блок Cancel транзакции.

Cодержимое:

Status

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

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

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

ID	Идентификатор, который однозначно определяет блок опций торгового протокола транзакции IOTP (смотри раздел 3.4).

Cодержимое:

ProtocolOptions	Компонент протокольных опций (смотри раздел 7.1) определяет опции, которые распространяются на всю транзакцию IOTP (смотри раздел 9).
BrandList	Этот компонент списка видов платежа содержит один или более видов протоколов и типов платежа, которые можно выбрать (смотри раздел 7.7).
Org	Компоненты Organisation (смотри раздел 7.6) идентифицируют организации и их роли в транзакции IOTP. Роли и организации, которые должны присутствовать, зависят от конкретного типа транзакции. Определения каждой транзакции смотри в разделе 9.

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

компонент протокольных опций;

компонент Organisation с торговой ролью Продавца;

компонент Organisation с торговой ролью Покупателя;

опционно, компонент организации торговой ролью DeliverTo, если транзакция предполагает доставку;

компоненты списка видов платежа для каждого платежа транзакции;

компоненты Organisation для Кассира, включенного в транзакцию;

опционно, компоненты Organisation для Агента доставки (если имеется) транзакции;

дополнительные компоненты Organisation, которые Продавец захочет включить. Например.

	- Агент обслуживания Покупателя;
	- источник сертификатов, который предлагает "коды доверия (Credentials)" Продавца или какую-то другую гарантию на товары или услуги.

Блок ошибки

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

ошибочное сообщение. Сообщение IOTP, которое содержит или является причиной ошибки какого-то рода;

сообщение, опровещающее об ошибке. Сообщение IOTP, которое содержит торговый блок Error, описывающий ошибку, найденную в сообщении. Торговый блок Error может содержаться в любом сообщении, уведомляющем об ошибке. Реакция на такое сообщение зависит от серьезности (severity) ошибки. Разъяснения различных значений серьезности ошибки (и сопряженных с ними действий) дано в определении компонента Error. Несмотря на то что торговый блок Error может уведомлять о многих различных ошибках, используя несколько компонентов Error, разработчики приложений могут и не поддерживать такую возможность. Структура торгового блока Error представлена ниже.
Атрибуты:

ID	Идентификатор, который однозначно определяет блок Error транзакции.

Cодержимое:

ErrorComp	Компонент Error (смотри раздел 7.21), который содержит информацию об индивидуальной технической ошибке.
PaySchemeData	Опционный компонент Payment Scheme (смотри раздел 7.10), который содержит описание платежной схемы.

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

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

ID	Идентификатор, который однозначно определяет блок отклика аутентификации транзакции.

Cодержимое:

AuthResp	Опционный компонент аутентификационного отклика, который содержит результаты обработки компонента запроса аутентификации - смотри раздел 7.3.
Org	Опционные компоненты Organisation, которые содержат информацию, соответствующую торговым ролям, как это запрошено атрибутом TradingRoleList компонента информационного запроса торговой роли.

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

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

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

ID	Идентификатор, который однозначно определяет блок отклика доставки транзакции.

Cодержимое:

Status	Содержит статусную информацию об успехе или неудаче (смотри раздел 4.2) доставки. Заметим, что в блоке отклика Delivery, ProcessState равный NotYetStarted или InProgress считается нелегальным.
DeliveryNote	Компонент Delivery Note содержит подробности о том, как будут доставляться товары или услуги (смотри раздел 7.15).

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

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

ID	Идентификатор, который однозначно определяет блок отклика Offer транзакции.

Cодержимое:

Status	Содержит статусную информацию об успехе или неудаче подготовки предложения (смотри раздел 4.2). Заметим, что в блоке отклика Offer, значения ProcessState NotYetStarted или InProgress являются нелегальными.
Order	Компонент Order содержит подробности о товарах, услугах или финансовой операции, которая имеет место, смотри раздел 7.5.

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

Payment	Компоненты Payment содержат информацию о платежах, которые надлежит произвести, смотри раздел 7.9.
Delivery	Компонент Delivery содержит детали предстоящей доставки (смотри раздел 7.13).
TradingRoleData	Компонент информации о торговой роли содержит данными должны обменяться торговые роли, вовлеченные в транзакцию (смотри раздел 7.17).

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

компонент Order транзакции;

компоненты Payment для каждой проплаты транзакции;

компонент Delivery транзакции (если предусмотрено).

Блок отклика Ping

Блок отклика Ping предоставляет результат выполнения запроса Ping. Он содержит компонент Organisation, который идентифицирует отправителя отклика Ping. Если запрос Ping, для которого этот блок является откликом, содержал компоненты Organisation, тогда он также содержит эти компоненты Organisation.
PingStatusCode (Ok | Busy | Down) #REQUIRED
SigVerifyStatusCode (Ok | NotSupported | Fail) #IMPLIED
xml:lang NMTOKEN #IMPLIEDPingStatusDesc CDATA #IMPLIED> Атрибуты:

ID	Идентификатор, который однозначно определяет торговый блок запроса Ping транзакции.
PingStatusCode	Содержит код, который показывает состояние программы отправителя, которая обрабатывает IOTP-сообщения. Допустимыми значениями являются: o Ok. Сервис работает нормально, включая проверку подписей. o Busy. Все идет хорошо, но возможны некоторые задержки. o Down. Сервер не вполне функционален, но все же может выдать отклик Ping.
SigVerifyStatusCode	Заключает в себе код, который показывает состояние проверки подписи. Он присутствует только когда сообщение, содержащее блок запроса Ping имеет также блок Signature. Допустимы следующие значения: o Ok. Веоификация подписи прощла успешно. o NotSupported. Получатель блока запроса Ping не поддерживает валидацию подписей. o Fail. Верификация подписи не прошла.
Xml:lang	Определяет язык, использованный в PingStatusDesc. Присутствует тогда, когда имеется PingStatusDesc.
PingStatusDesc	Содержит короткое описание состояния сервера, который поылает этот блок отклика Ping. Сервер, если его разработчики хотят, может использовать этот атрибут для посылки более детальной информации, чем содержится в PingStatusCode, он может использоваться, например, для отладрчных целей.

Cодержимое:

Org

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

Компоненты Organisation отправителя отклика Ping всегда содержат кроме того компоненты Organisation, посланные в запросе Ping. Значения статусного кода Ping не включают в себя такие значения как Fail, так как, когда программа, получающая сообщение запроса Ping, не работает, не будет послано никакого отклика Ping.

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

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

ID	Идентификатор, который однозначно определяет блок платежного обмена транзакции.

Cодержимое:

PaySchemeData

Этот торговый компонент содержит специфические данные о платежной схеме, смотри раздел 7.10.

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

Этот блок платежного отклика содержит информацию о состоянии платежа, опционной платежной расписке и опционные сообщения платежного протокола. Его определение представлено ниже. PaymentNote?, TradingRoleData*)>
Атрибуты:

ID	Идентификатор, который однозначно определяет блок платежного отклика транзакции.

Cодержимое:

Status	Содержит статусную информацию об успехе или неудаче (смотри раздел 4.2) платежа. Заметим, что в блоке платежного отклика, значения ProcessState NotYetStarted или InProgress являются нелегальными.
PayReceipt	Содержит специфические данные о платежной схеме, которые могут быть использованы для верификации произведенного платежа. Смотри раздел 7.11. Он должен присутствовать, если атрибут ProcessState компонента Status равен CompletedOk. Атрибут PayReceipt является опционным.
PaySchemeData	Содержит специфические данные о платежной схеме, например, о сообщениях платежного протокола. Смотри также раздел 7.10.
PaymentNote	Содержит дополнительную, несвязанную с платежом информацию, которую кассир желает предоставить покупателю. Например, если выполнен отзыв сделки или осуществлен депозит, он может содержать данные о полученном балансе на счету, после того как данная операция завершена. Смотри раздел 7.12.
TradingRoleData	Компонент информации о торговой роли содержит данные, которые нужны для обмена между ролями, участвующими в транзакции (смотри раздел 7.17).

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

Блок платежного запроса содержит информацию, которая запускает процедуру платежа. Его описание представлено ниже. Payment, PaySchemeData?, Org*, TradingRoleData*)>
Атрибуты:

ID	Идентификатор, который однозначно определяет блок платежного запроса транзакции.

Cодержимое:

Status	Содержит компоненты Status (смотри раздел 7.13) откликов на шаги (напр., отклика Offer и/или Payment), от которых данный шаг зависит. Он используется чтобы индицировать успех или неудачу этих шагов. Платеж может состояться лишь тогда, когда все предыдущие шаги были успешными.
BrandList	Компонент списка видов платежа содержит список из одного или более видов платежа и протоколов, которые могут быть выбраны (смотри раздел 7.7).
BrandSelection	Идентифицирует выбор вида платежа, платежного протокола и Кассира, которые должны быть использованы при оплате в данной транзакции. Имеется один компонент выбора вида платежа (смотри раздел 7.8) для каждой проплаты, которую следует выполнить в процессе транзакции.
Payment	Компоненты Payment содержит информацию о платеже, который выполняется, смотри раздел 7.9.
PaySchemeData	Компонент Payment Scheme содержит специфические данные о платежной схеме, смотри раздел 7.10.
Org	Компонент Organisation содержит подробности об организациях, вовлеченных в платеж (смотри раздел 7.6). Присутствие организаций зависит от транзакции и данных, которые должны быть подписаны. Смотри раздел 6.
TradingRoleData	Компонент данных о торговой роли содержит информацию, которая нужна для пересылки между торговыми ролями, вовлеченными в транзакцию (смотри раздел 7.17).

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

Компонент Organisation с торговой ролью продавца;

Компонент Organisation с торговой ролью Покупателя;

Компонент Payment для платежа;

Компонент Brand List;

Компонент выбора вида платежа из списка;

Компонент Organisation для Кассира, осуществляющего платеж;

Компонент Organisation (если такоая имеется) для организации, которая выполнила предыдущий шаг, например другой Кассир;

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

Компонент Organisation для любых дополнительных организаций, которые Продавец включил в блок отклика Offer;

Опционный компонент данных платежной схемы, если это требуется методом платежа, определенном в приложении IOTP;

Любой компонент информации о платежной роли, который может потребоваться (смотри раздел 7.17.1).

Блок подписи в отклике доставки

Блок Signature, который содержится в том же сообщении, что и блок отклика доставки, содержит только компонент подписи отклика Delivery (смотри раздел 7.19.4), сформированный на этом шаге.

Блок подписи в отклике предложении

Блок подписи, который содержится в том же сообщении, что и блок отклика Offer, несет в себе только компонент подписи отклика Offer (смотри раздел 7.19.2).

Блок подписи в платежном отклике

Блок подписи, который содержится в том же сообщении, что и блок платежного отклика, содержит только компонент подписи платежной расписки (смотри раздел 7.19.3), сформированной на этом этапе (шаге).

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

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

Компонент подписи отклика Offer (смотри раздел 7.19.2) и

Если поатеж зависит от предыдущего шага (как указано атрибутом StartAfter компонента Payment), тогда компонент подписи платежной расписки (смотри раздел 7.19.3) генерируется на предыдущем этапе (шаге).

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

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

Компонент подписи отклика Offer (смотри раздел 7.19.2) и

Компонент подписи платежной расписки (смотри раздел 7.19.3), сформированный на предшествующем шаге.

Блок подписи

Блок Signature содержит один или более компонентов Signature и соответствующих сертификатов (если требуется), которые подтверждают данные в рамках данной транзакции. Определение компонента Signature и сертификатов содержится в статье "Digital Signatures for the Internet Open Trading Protocol", смотри [IOTPDSIG]. Описание их применения в IOTP можно найти в разделах 7.19 и 7.20. Определение блока Signature представлено ниже:
Атрибуты:

ID	Идентификатор, который однозначно определяет блок подписи транзакции.

Cодержимое:

Signature	Компонент Signature. Смотри раздел 7.19.
Certificate	Компонент Certificate. Смотри раздел 7.20.

Содержимое блока Signature зависит от торгового блока, который содержится в том же сообщении, что и блок Signature.

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

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

ID	Идентификатор, который однозначно определяет блок состояния аутентификации транзакции.

Cодержимое:

Status

Содержит статусную информацию об успехе или неудаче аутентификации (смотри раздел 4.2).

Блок ссылок операции (Transaction Reference Block)

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

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

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

Нуль или более компонентов Related To, которые связывают эту операцию IOTP с другими операциями или другими событиями, используя идентификаторы этих событий. Определение блока ссылок операции (Transaction Reference Block) выглядит следующим образом:
Атрибуты:

ID	Идентификатор, который однозначно определяет блок ссылок операции в пределах IOTP-процедуры (смотри раздел 3.4).

Cодержимое:

TransId	Смотри 3.3.1 Id-компонент операции.
MsgId	Смотри 3.3.2 Id-компонент сообщения.
RelatedTo	Смотри 3.3.3 Компонент Related To.

Блок выбора TPO

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

ID	Идентификатор, который однозначно определяет блок выбора TPO транзакции IOTP.

Cодержимое:

BrandSelection

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

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

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

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

информацию о том, как аутентифицировать себя и/или

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

ID	Идентификатор, который однозначно определяет блок запроса аутентификации транзакции.

Cодержимое:

AuthReq

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

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

TradingRoleInfoReq

Компонент информационного запроса торговой роли (смотри раздел 7.4) содержит список торговых ролей, данные о которых запрашиваются.

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

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

Блок запроса доставки содержит подробности о товарах или услугах, которые должны быть предоставлены вместе с подписью, которая позволяет удостовериться, что доставка была авторизована. Его определение приведено ниже. ConsumerDeliveryData?, TradingRoleData*)>
Атрибуты:

ID	Идентификатор, который однозначно определяет блок запроса доставки транзакции.

Cодержимое:

Status	Содержит компоненты Status (смотри раздел 7.13) откликов на шаги (напр., платежный отклик), от которых данный шаг зависит. Он используется чтобы индицировать успех или неудачу этих шагов. Доставку следует осуществлять только если все прдыдущие шаги завершились успешно.
Order	Компонент Order содержит подробности о товарах, услугах или финансовых операциях, которые имеют место, смотри раздел 7.5. Комоненты Organisation (смотри раздел 7.6) идентифицируют организации их роли.
Org	Транзакция IOTP. Роли и организации, которые должны присутствовать зависят от конкретного типа транзакции. Описания транзакций смотри в разделе 9.
Delivery	Компонент Delivery содержит подробности доставки, которую следует осуществить (смотри раздел 7.13).
ConsumerDeliveryData	Опционный. Содержит идентификатор, специфицированный Покупателем, который в случае возвращения Агентом доставки позволяет покупателю определить, о какой доставке идет речь.
TradingRoleData	Компонент данных о торговой роли содержит информацию, которая нужна при обмене между двумя торговыми ролями в процессе транзакции (смотри раздел 7.17).

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

Компонент Organisation с торговой ролью Продавца;

Компонент Organisation для торговых ролей Покупателя и DeliverTo;

Компонент Delivery;

Компонент Organisation для Агента доставки. В частности компонент Organisation, идентифицированный атрибутом ActionOrgRef компонента Delivery;

Компонент Organisation (если имеется) для организации, которая осуществила предыдущий шаг, например Кассира;

Компоненты Organisation для любой дополнительной организации, которую Продавец включил в блок отклика Offer;

Любые компоненты данных о торговой роли, которая может потребоваться (смотри раздел 7.17.1).

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

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

ID	Идентификатор, который однозначно определяет запрос Ping торгового блока транзакции.

Cодержимое: Опционные компоненты Organisation (смотри раздел 7.6). Если нет ни одного компонента Organisation, тогда запрос Ping является анонимным и служит для проверки, работает ли сейчас сервер. Однако, если присутствуют компоненты Organisation, это указывает, что отправитель запроса Ping хочет проверить, могут ли быть обработаны цифровые подписи. В этом случае отправитель включает:

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

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

CD- отклик на данные кредитной карты

Отклик на CD1 с указанием на успешный или нет прием данных о кредитной карте. #####################################################################
Отправитель: CyberServer
Получатель: MerchantApp
#####################################################################
Пример сообщения: $$-CyberCash-0.8-$$
merchant-ccid: ACME-012
merchant-transaction: 123123
merchant-date: 19950121100705.nnn
merchant-opaque: t731/86R72ZLrqHLIf0VG6m3ybvs+dG6K705L8LFKEXgCti0NGjK83CwDsUdiso7U1JP
2Z0BClVHLmhIBY7+QXx5iCEGHy8JKC9IWyNNi2O/OOIDgLeJAkMSZYbNQrSKViY34imS
0s7Q6uDk9wV0fixjvRBuNO2B7urWWsqfkLOYDnHy0RvhyUzYxLrMaTX+/6IkyU5Z0lH3
BXYBUNV8DgitEjgLXmyWuXRDlEBN02yeZgsFRm9GmuBHfCTySm2XqnifizpmKMUa9UiH
onNx9W86fuBdcJF7CJgH5Gct2M/dx/f2VpoRkmeSmWxFrYi8wgtvddSXF9my40NZ8WZz
CEUEvQhcmruopwEeehv+bejc3fDDZ23JKrbhlZ17lSvFR14PKFsi32pXFqTO0ej9GTc5
L6c8nM3tI1qdHNCe0N5f7ASdKS0tYSxAYJLIR6MqPrXjNJEaRx7Vu1odMlkgrzGOV1fo
5w33BQHK3U2h+1e5zYBeHY3ZYG4nmylYYXIye4xpuPN4QU0dGrWZoImYE44QOwjd5ozl
xulPBjj6cpEI/9wTwR3tpkBb4ZfYirxxnoj9JUkPK9Srv9iJ
$$-CyberCash-End-7Tm/djB05pLIw3JAyy5E7A==-$$
#####################################################################
Скрытый ключ: ключ сессии из CD1.
#####################################################################
Содержимое скрытой секции: type: card-data-response
server-date: 19950121100706.nnn
response-code: failure/success/etc.
order-id: 1231-3424-234242
pr-hash: 7Tm/djB05pLIw3JAyy5E7A==
pr-signed-hash: IV8gWHx1f8eCkWsCsMOE3M8mnTbQ7IBBcEmyGDAwjdbaLu5Qm/bh06OX1npe2d3Hijxy
+X8vKcVE6l6To27u7A7UmGm+po9lCUSLxgtyqyn3jWhHZpc5NZpwoTCf2pAK
card-hash: 7Tm/djB05pLIw3JAyy5E7A==
card-number: 4811123456781234
card-type: visa
card-name: John Q. Public
expiration-date: 01/99
merchant-swseverity: fatal/warning
merchant-swmessage; Сообщение для продавца о том, что номер информационного протокола в стартовой строке $$ сообщения продавца устарел.
merchant-message;
Свободный текст, поясняющий ошибку или успех операции. Этот текст предназначен сервером для продавца.
id: myCyberCashID
transaction: 78784567
date: 19950121100505.nnn Сообщение в норме возвращает выбранные поля из дешифрованной закрытой части CH1, в том формате, в каком они были посланы серверу в CD1.

CD- запрос данных о кредитной карте

Используется продавцом для получения номера карты и т.д., если нужна информация для разрешения сомнений. #####################################################################
Отправитель: MerchantApp
Получатель: CyberServer
#####################################################################
Пример сообщения:
$$-CyberCash-0.8-$$
merchant-ccid: ACME-69
merchant-transaction: 123123
merchant-date: 19950121100705.nnn
merchant-cyberkey: CC1001
cyberkey: CC1001
opaque: EDD+b9wAfje5f7vscnNTJPkn1Wdi7uG3mHi8MrzLyFC0dj7e0JRjZ2PmjDHuR81kbhqb
nX/w4uvsoPgwM5UJEW0Rb9pbB39mUFBDLPVgsNwALySeQGso0KyOjMxNs1mSukHdOmDV
4uZR4HLRRfEhMdX4WmG/2+sbewTYaCMx4tn/+MNDZlJ89Letbz5kupr0ZekQlPix+pJs
rHzP5YqaMnk5iRBHvwKb5MaxKXGOOef5ms8M5W8lI2d0XPecH4xNBn8BMAJ6iSkZmszo
QfDeWgga48g2tqlA6ifZGp7daDR81lumtGMCvg==
merchant-opaque:
6BVEfSlgVCoGh1/0R+g1C143MaA6QLvKpEgde86WWGJWx45bMUZvaAu4LVeqWoYCqSGf
aWKUF7awol0h1i1jtgieyAcXB8ikvRJIsupSAwsRMyoNlekR6tucvfv/622JY7+n7nGO
dGbMzP0GJImh2DmdPaceAxyOB/xOftf6ko0nndnvB+/y2mFjdUGLtFQP/+3bTpZttZXj
j7RO1khe1UrAIk2TGQJmNw+ltsu0f42MgsxB8Q31vjPtoiPi5LEmD0Y4jlpJ7Jg2Ub84
F9vJhYpmzNkdiJUe83Hvo/xfJRbhafJpXFEsUZwQK0jU1ksU6CQd2+CPBB+6MxtsHoxJ
mjD6ickhd+SQZhbRCNerlTiQGhuL4wUAxzGh8aHk2oXjoMpVzWw2EImPu5QaPEc36xgr
mNz8vCovDiuy3tZ42IGArxBweasLPLCbm0Y=
$$-CyberCash-End-7Tm/djB05pLIw3JAyy5E7A==-$$
#####################################################################
Содержимое скрытой секции продавца:
type: card-data-request
password: xyzzy
server-date: 19950121100505.nnn [optional]
order-id: 12313424234242
merchant-amount: usd 10.00
pr-hash: 7Tm/djB05pLIw3JAyy5E7A==
pr-signed-hash: IV8gWHx1f8eCkWsCsMOE3M8mnTbQ7IBBcEmyGDAwjdbaLu5Qm/bh06OX1npe2d3Hijxy
+X8vKcVE6l6To27u7A7UmGm+po9lCUSLxgtyqyn3jWhHZpc5NZpwoTCf2pAK
id: myCyberCashID
transaction: 78784567
date: 19950121100505.nnn
Подпись продавца: 8zqw0ipqtLtte0tBz5/5VPNJPPonfTwkfZPbtuk5lqMykKDvThhO0ycrfT7eXrn/hLUC
kXoSctahEVdw1KBJbp0EVr1zVzcN9Aa7m2fJgxNfiisTgIRW+PMaa78rn+Ov
#####################################################################

Скрытый ключ продавца генерируется из общедоступного ключа шифрования CyberCash, идентифицированного в merchant-cyberkey.
Закрытая секция сообщения покупателя (Opaque) - смотри CH1.
#####################################################################
Содержимое закрытой секции и подпись: (в точности как в CH1) swversion: 0.8win
amount: usd 10.00
card*: [от успешного BC4 (включает в себя время действия карты, номер карты и card-salt)]
Подпись: 48SBKUfojyC9FDKCwdCYNvucgiDxYO9erZW4QndIXZRyheTHXH8OeIhwUkyLmgQSD/UK
+IX9035/jUkdNPOxUQq9y/beHS1HU9Fe0wlzfXYRtnjlqvQX+yUfQ4T7eNEs
#####################################################################
Подпись продавца покрывает следующие поля: merchant-ccid, merchant-transaction, merchant-date, merchant-cyberkey, type, password, server-date, order-id, merchant-amount, pr-hash, pr-signed-hash, id, transaction, date, cyberkey
Подпись покупателя: смотри CH1
#####################################################################
[смотри также объяснения для CM1] Продавцу может быть нужно знать, какая карта используется, и некоторую другую информацию, для того чтобы разрешить определенные проблемы, возникающие при транзакции. Вся эта информация содержится в исходном сообщении CH1, вложенном в CM1 для реализации транзакции. Если продавец сохраняет CM1 и другую информацию транзакции, то он может послать это CD1-сообщение серверу. Пароль является дополнительным уровнем безопасности, он предназначен для ручного ввода со стороны продавца, чтобы авторизовать какую-то необычную операцию. Сервер запоминает хэш CCID продавца и пароля.

CH- отклик оплаты с помощью карты (charge-card-response)

Отклик покупателю на CH1-попытку оплатить покупку с помощью кредитной карты. Индицирует успех или неудачу. #####################################################################
Отправитель: MerchantApp
Получатель: CyberApp
#####################################################################
Пример сообщения: $$-CyberCash-0.8-$$
type: charge-card-response
merchant-ccid: ACME-012
id: myCyberCashID
transaction: 78784567
date: 1995121100500.nnn
merchant-date: 19950121100505.nnn
merchant-response-code: failure/success/etc.
pr-hash: 7Tm/djB05pLIw3JAyy5E7A==
pr-signed-hash: a/0meaMHRinNVd8nq/fKsYg5AfTZZUCX0S3gkjAhZTmcrkp6RZvppmDd/P7lboFLFDBh
Ec0oIyxWeHfArb3OtkgXxJ7qe0Gmm/87jG5ClGnpBnw0dY7qcJ6XoGB6WGnD
merchant-message; Это сообщение от продавца следует отобразить пользователю. Может иметь много строчек и не имеет защиты.
opaque: [может отсутствовать, смотри объяснение]
EDD+b9wAfje5f7vscnNTJPkn1Wdi7uG3mHi8MrzLyFC0dj7e0JRjZ2PmjDHuR81kbhqb
nX/w4uvsoPgwM5UJEW0Rb9pbB39mUFBDLPVgsNwALySeQGso0KyOjMxNs1mSukHdOmDV
4uZR4HLRRfEhMdX4WmG/2+sbewTYaCMx4tn/+MNDZlJ89Letbz5kupr0ZekQlPix+pJs
>rHzP5YqaMnk5iRBHvwKb5MaxKXGOOef5ms8M5W8lI2d0XPecH4xNBn8BMAJ6iSkZmszo
QfDeWgga48g2tqlA6ifZGp7daDR81lumtGMCvg==
$$-CyberCash-End-7Tm/djB05pLIw3JAyy5E7A==-$$ #####################################################################
Скрытый ключ. Ключ сессии покупателя, взятый из CH1 и переданный через CM1 для ID и транзакции.
#####################################################################
Закрытая секция содержит (из CM.6): server-date: 19950121100706.nnn
amount: usd 10.00
order-id: 1231-3424-234242
card*: [из успешного BC4]
response-code: failure/success/etc.
swseverity: fatal/warning
swmessage; Ujdjhbn CyberApp, что это закрытая часть. Этот текст отображается для пользователя [присутствует только, когда присутствует SWSeverity].
message; Свободный комментарий причины неудачи или успеха. Этот текст должен быть отображен для покупателя приложением CyberCash. Закрытая секция является опционной, так как сообщение CH1 продавцу может не пройти, из-за неверного идентификатора заказа (order-id), даты, ошибочного идентификатора продавца (merchant-ccid) и т.д.. Таким образом, сервер не может быть вовлечен, так как в данной ситуации не существует безопасного механизма генерации закрытой секции сообщения. Если транзакция осуществляет эту процедуру посредством сервера (через CM*), тогда код отклика на верхнем уровне должен быть зеркальным по отношению к коду-отклику сервера, посланного продавцу. Заметим, что могут быть два сообщения, одно от продавца и одно от сервера.

CH- платеж через кредитную карту (credit-card-payment)

Это сообщение осуществляет представление кредитной карты для выполнения платежа.
####################################################################
Отправитель: CyberApp
Получатель: MerchantApp
#####################################################################
Пример сообщения: $$-CyberCash-0.8-$$
type: card-payment
id: myCyberCashID
order-id: 1231-3424-234242
merchant-ccid: ACME-012
transaction: 78784567
date: 19950121100505.nnn
pr-hash: c77VU/1umPKH2kpMR2QVKg==
pr-signed-hash:
a/0meaMHRinNVd8nq/fKsYg5AfTZZUCX0S3gkjAhZTmcrkp6RZvppmDd/P7lboFLFDBh
Ec0oIyxWeHfArb3OtkgXxJ7qe0Gmm/87jG5ClGnpBnw0dY7qcJ6XoGB6WGnD
cyberkey: CC1001
opaque:
iff/tPf99+Tm5P7s3d61jOWK94nq9/+1jOWK9+vr9+b+94n3tYzmiveJ9/+09/334ubg
3rWM5Ir3ier3/7WM5Ir36+v35v73ife1jOWK94n3/7T3/ffm5uD+7N339/f39/eq3ff3
9/eFiJK5tLizsoeSmpW7uLS8/7iio7Wisfv38biio7uyufv3tfv35uH+7N3d9/exuKX3
5+z3vuu4oqO7srnsvvz8/venoqO0v7al/7iio7WisYy+iv7s3ff3p6KjtL+2pf/wi7nw
3ard3Q==
$$-CyberCash-End-7Tm/djB05pLIw3JAyy5E7A==-$$ #####################################################################
Скрытый ключ. Создан с использованием общедоступного ключа шифрования CyberCash, на который указывает CyberKey.
#####################################################################
Содержимое скрытой секции:
swversion: 0.8win
>amount: usd 10.00
card*: [из успешно прошедшего BC4 (включает в себя время действительности кредитной карты, ее номер, тип и card-salt)]
Подпись: meO38aULnoP09VhTS2E56tnuZBRRlGfbwqaleZ9zNnv7YjExJKBFxuaqYTUDEj427HHh
mm9BVmHRwCq6+8ylZXixGHI1I9A/ufAMrpqMIi6DS3PRlc8WC3CCWoAHyAqr
#####################################################################
type, id, order-id, merchant-ccid, transaction, date, pr-hash, pr-signed-hash, cyberkey, swversion, amount, card*
#####################################################################
Поле pr-signed-hash тождественно полю подписанного продавцом хэша (merchant-signed-hash) в сообщении PR1.

Части тела

Части тела сообщения (как открытые, так и скрытые) состоят из пар атрибут-значение в формате, который напоминает формат стандартного заголовка почтового сообщения (RFC-822). Однако здесь имеются некоторые трудности. Имена атрибутов начинаются с и в основном состоят из букв и лишь иногда содержат в конце дефис, за которым следует число. Такое завершающее число используется, когда имеется индексированный вектор значений. Имена атрибутов часто называют метками (label). Если метка завершается ":", тогда производится обработка согласно требованиям документа RFC-822. Когда важно наличие завершающего пробела (SP, TAB, LF), все лидирующие пробелы на последующих строках удаляются. Такие строки укорачиваются до 64 символов, не считая завершающего символа. Однако если метка завершается ";", это указывает на поле произвольной формы, где символы начала новой строки и любые лидирующие пробелы после начального пробела, который отмечает продолжение строки, являются существенными. Такие строки не должны разрываться за исключением того, что для исключения проблем обработки, они принудительно ограничиваются 200 символами. Пустые строки игнорируются и не означают изменения режима обработки строк. Другим способом решения проблемы может быть следующее: после обнаружения начальной последовательности $$ в стартовой строке, вы можете обрабатывать любые последующие строки в соответствии с первым символом. Если он является алфавитно-цифровым, это новая метка, которая должна завершаться символами ":" или ";", а это указывает на новую пару метка-значение. Если он является пробелом (SP, TAB, LF или CR), это указывает на продолжение предыдущей строки метки. (Как конкретно обрабатывается продолжение, зависит от завершающего символа метки). Если это "$", то строка должна быть оконечной строкой сообщения. Если это #, тогда это строка комментария и должна игнорироваться. Другие начальные символы не определены. На данный момент программные продукты CyberCash не поддерживают комментариев.

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

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

Цифровые подписи

Цифровые подписи являются средством аутентификации. В сообщениях CyberCash, они вычисляются с привлечением хэша данных, подлежащих аутентификации, после чего хэш шифруется посредством секретного ключа RSA. Любой, кто владеет соответствующим общедоступным ключом, может дешифровать хэш и сравнить его с хэшем сообщения. Если они совпадают, вы можете быть уверены, что подпись была сформирована хозяином секретного ключа, соответствующего общедоступному ключу, которым вы воспользовались, и что сообщение не было искажено при транспортировке. В системе CyberCash, клиенты, продавцы и сервер имеют пары ключей (общедоступный/секретный). Сохраняя в тайне свой секретный ключ и регистрируя на сервере свой общедоступный ключ (для продавца или клиента), можно обеспечить высокое качество аутентификации с помощью подписи определенных частей сообщения. Цифровая подпись RSA имеет размер практически равный длине используемого модуля. Например, если модуль содержит 768 бит, то двоичная электронная подпись будет содержать столько же бит, что равно 96 байт. В представлении base64 это займет 128 байт.

CM- auth-capture

Осуществляет авторизацию и вводит сумму оплаты сделки. Сообщение аналогично CM1, хотя и имеет другой код типа. #####################################################################
Отправитель: MerchantApp
Получатель: CyberServer
#####################################################################
Пример сообщения:
[exactly the same as CM1 except
type: auth-capture
]

CM- auth-only (аутентификация)

Это сообщение используется продавцом для выполнения операции авторизации кредитной карты покупателя. #####################################################################
Отправитель: MerchantApp
Получатель: CyberServer
#####################################################################
Пример сообщения: $$-CyberCash-0.8-$$
merchant-ccid: ACME-69
merchant-transaction: 123123
merchant-date: 19950121100705.nnn
merchant-cyberkey: CC1001
cyberkey: CC1001
opaque: EDD+b9wAfje5f7vscnNTJPkn1Wdi7uG3mHi8MrzLyFC0dj7e0JRjZ2PmjDHuR81kbhqb
nX/w4uvsoPgwM5UJEW0Rb9pbB39mUFBDLPVgsNwALySeQGso0KyOjMxNs1mSukHdOmDV
4uZR4HLRRfEhMdX4WmG/2+sbewTYaCMx4tn/+MNDZlJ89Letbz5kupr0ZekQlPix+pJs
rHzP5YqaMnk5iRBHvwKb5MaxKXGOOef5ms8M5W8lI2d0XPecH4xNBn8BMAJ6iSkZmszo
QfDeWgga48g2tqlA6ifZGp7daDR81lumtGMCvg==
merchant-opaque:
6BVEfSlgVCoGh1/0R+g1C143MaA6QLvKpEgde86WWGJWx45bMUZvaAu4LVeqWoYCqSGf
aWKUF7awol0h1i1jtgieyAcXB8ikvRJIsupSAwsRMyoNlekR6tucvfv/622JY7+n7nGO
dGbMzP0GJImh2DmdPaceAxyOB/xOftf6ko0nndnvB+/y2mFjdUGLtFQP/+3bTpZttZXj
j7RO1khe1UrAIk2TGQJmNw+ltsu0f42MgsxB8Q31vjPtoiPi5LEmD0Y4jlpJ7Jg2Ub84
F9vJhYpmzNkdiJUe83Hvo/xfJRbhafJpXFEsUZwQK0jU1ksU6CQd2+CPBB+6MxtsHoxJ
mjD6ickhd+SQZhbRCNerlTiQGhuL4wUAxzGh8aHk2oXjoMpVzWw2EImPu5QaPEc36xgr
mNz8vCovDiuy3tZ42IGArxBweasLPLCbm0Y=
$$-CyberCash-End-7Tm/djB05pLIw3JAyy5E7A==-$$
##################################################################### Содержимое скрытой секции продавца: type: auth-only
order-id: 12313424234242
merchant-amount: usd 10.00
pr-hash: 7Tm/djB05pLIw3JAyy5E7A==
pr-signed-hash: a/0meaMHRinNVd8nq/fKsYg5AfTZZUCX0S3gkjAhZTmcrkp6RZvppmDd/P7lboFLFDBh
Ec0oIyxWeHfArb3OtkgXxJ7qe0Gmm/87jG5ClGnpBnw0dY7qcJ6XoGB6WGnD
id: myCyberCashID
transaction: 78784567
date: 19950121100505.nnn
merchant-signature: v4qZMe2d7mUXztVdC3ZPMmMgYHlBA7bhR96LSehKP15ylqR/1KwwbBAX8CEqns55UIYY
GGMwPMGoF+GDPM7GlC6fReQ5wyvV1PnETSVO9/LAyRz0zzRYuyVueOjWDlr5
#####################################################################
Ключ продавца закрытой части генерируется из общедоступного ключа CyberCash, на который указывает merchant-cyberkey.
Закрытую часть сообщения покупателя (Opaque) - смотри CH1.
#####################################################################
Содержимое закрытой части и подпись: (в точности как в CH1) swversion: 0.8win
amount: usd 10.00
card*: [from successful BC4 (includes card-expiration-date, card-number, and card-salt)]
Подпись: 48SBKUfojyC9FDKCwdCYNvucgiDxYO9erZW4QndIXZRyheTHXH8OeIhwUkyLmgQSD/UK
+IX9035/jUkdNPOxUQq9y/beHS1HU9Fe0wlzfXYRtnjlqvQX+yUfQ4T7eNEs
#####################################################################
Подпись продавца покрывает следующие поля:
merchant-ccid, merchant-transaction, merchant-date, merchant-cyberkey, type, order-id, merchant-amount, pr-hash, pr-signed-hash, id, transaction, date, cyberkey
Подпись покупателя: смотри CH1
#####################################################################
Пояснение: Подпись продавца гарантирует целостность большей части сообщения. Проверка корректности подписи покупателя гарантирует, что закрытая часть сообщения покупателя не была повреждена или заменена.

CM- отклик на операцию оплаты (charge-action-response)

Это квитанция, предоставляемая продавцу в качестве уведомления о выполнении платежной операции. Индицирует успех, неудачу или предоставляет какую-то иную информацию. #####################################################################
Отправитель: CyberServer
Получатель: MerchantApp
#####################################################################
Пример сообщения: $$-CyberCash-0.8-$$
merchant-ccid: ACME-012
merchant-transaction: 123123
merchant-date: 19950121100705.nnn
opaque: EDD+b9wAfje5f7vscnNTJPkn1Wdi7uG3mHi8MrzLyFC0dj7e0JRjZ2PmjDHuR81kbhqb
nX/w4uvsoPgwM5UJEW0Rb9pbB39mUFBDLPVgsNwALySeQGso0KyOjMxNs1mSukHdOmDV
4uZR4HLRRfEhMdX4WmG/2+sbewTYaCMx4tn/+MNDZlJ89Letbz5kupr0ZekQlPix+pJs
rHzP5YqaMnk5iRBHvwKb5MaxKXGOOef5ms8M5W8lI2d0XPecH4xNBn8BMAJ6iSkZmszo
QfDeWgga48g2tqlA6ifZGp7daDR81lumtGMCvg==
merchant-opaque:
6BVEfSlgVCoGh1/0R+g1C143MaA6QLvKpEgde86WWGJWx45bMUZvaAu4LVeqWoYCqSGf
aWKUF7awol0h1i1jtgieyAcXB8ikvRJIsupSAwsRMyoNlekR6tucvfv/622JY7+n7nGO
dGbMzP0GJImh2DmdPaceAxyOB/xOftf6ko0nndnvB+/y2mFjdUGLtFQP/+3bTpZttZXj
j7RO1khe1UrAIk2TGQJmNw+ltsu0f42MgsxB8Q31vjPtoiPi5LEmD0Y4jlpJ7Jg2Ub84
F9vJhYpmzNkdiJUe83Hvo/xfJRbhafJpXFEsUZwQK0jU1ksU6CQd2+CPBB+6MxtsHoxJ
mjD6ickhd+SQZhbRCNerlTiQGhuL4wUAxzGh8aHk2oXjoMpVzWw2EImPu5QaPEc36xgr
mNz8vCovDiuy3tZ42IGArxBweasLPLCbm0Y=
$$-CyberCash-End-7Tm/djB05pLIw3JAyy5E7A==-$$
#####################################################################
Скрытый ключ продавца. Ключ сессии, который совпадает с CM1/2/3/4/5 для той же транзакции и CCID продавца.
Скрытый ключ. Тот же ключ сессии покупателя, что и в сообщении CH1 переданном через CM* для данного ID и транзакции
#####################################################################
Содержимое скрытой секции продавца: type: charge-action-response
server-date: 19950121100706.nnn
action-code: XXX [per ISO 8583]
response-code: failure/success/etc.
order-id: 1231-3424-234242
pr-hash: 7Tm/djB05pLIw3JAyy5E7A==
pr-signed-hash: 8zqw0ipqtLtte0tBz5/5VPNJPPonfTwkfZPbtuk5lqMykKDvThhO0ycrfT7eXrn/hLUC
kXoSctahEVdw1KBJbp0EVr1zVzcN9Aa7m2fJgxNfiisTgIRW+PMaa78rn+Ov

retrieval-reference-number: 432112344321
authorization-code: a12323
card-hash: 7Tm/djB05pLIw3JAyy5E7A==
{
card-prefix: nnxxxx [ Returned if merchant is not full-PAN]
}
или
{
card-number: 1234567890123456 [Returned if merchant is full-PAN]
}
expiration-date: 12/34 [всегда присутствует]
merchant-swseverity: fatal/warning
merchant-swmessage; Сообщение для продавца об устаревшем номере протокола в стартовой $$-строке сообщения продавца.
merchant-message;
Свободный текст, поясняющий причины неудачи или успеха.
Этот текст направляется сервером продавцу...
id: myCyberCashID
transaction: 78784567
date: 19950121100505.nnn Содержимое скрытой секции (покупателя):
server-date: 19950121100706.nnn
amount: usd 10.00
order-id: 1231-3424-234242
card*: [from successful BC4]
response-code: failure/success/etc.
swseverity: fatal/warning
swmessage; Говорит CyberApp, что оно является устаревшим. Этот текст отображается для пользователя. [присутствует только, когда имеется SWSeverity]
message;
Свободный текст, поясняющий причины неудачи или успеха. Этот текст следует отобразить покупателю с помощью приложения CyberCash.

retrieval-reference-number	необходимо для аннулирования.
authorization-code	необходим для post-auth-capture. Оба эти поля присутствуют только в сообщении CM6, если оно было присланы банком. Все зависит от выполняемой операции.
card-prefix	(префикс карты) представляет собой первые две и последние четыре цифры номера кредитной карты. По усмотрению банка продавца присылается номер кредитной или ее префикс.
card-hash	является в действительности хэшем всего номера кредитной карты и salt, представленной покупателем. card-hash необходим для того, чтобы продавец мог, если хочет, сортировать транзакции покупателя по его кредитным картам, не зная их номеров.
card*	представляет собой поля card, полученные вместе с сообщениями CM, присланными в качестве отклика. Они появляются в алфавитном порядке.
server-date	дублируется в целях безопасности в закрытой секции покупателя.
[]	комментарии, появляющиеся после некоторых полей.

CM- возврат

Возврат полученного ранее платежа. В реальности оплата отрицательной суммы. Сообщение совпадает с CM1 за исключением поля тип. #####################################################################
Отправитель: MerchantApp
Получатель: CyberServer
#####################################################################
Пример сообщения:
[в точности как и CM1, только поле type: return]

Дальнейшие разработки

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

Детали формата

Заголовок содержит одну строку, которая выглядит следующим образом $$-CyberCash-0.8-$$
или
$$-CyberCash-1.2.3-Extra-$$ Он содержит в себе несколько полей, разделенных символом минус "-"

1.	"$$" - литерная строка со значением $ в колонке 1.
2.	"CyberCash" - литерная строка (регистр не существенен)
3.	x.y или x.y.z - номер версии формата сообщения. x - первичный номер версии. y - номер субверсии. z, если присутствует, номер субсубверсии.
4.	"Extra" - опционная дополнительная алфавитно-цифровая строка.
5.	"$$" - литерная строка.

Номера версии начинаются с 0.7. ".z" опускается, если z = 0. 0.7 и 0.8 являются тестовыми и начальными версиями поставки системы для кредитных карт. 0.9 и 1.0 представляют собой улучшенные версии этой системы. Строка "Extra" используется в безопасной среде так чтобы один компонент мог что-то сообщить другому без существенных издержек. Например, Firewall-сервер может записать здесь "HTTP" или "SMTP", прежде чем переадресовывать сообщение базовому серверу в пределах периметра Firewall.

Динамическая аутентификация данных

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

Рис. 4.6.4.12. Схема динамической аутентификации данных ICC, которая поддерживает аутентификацию динамических данных, должна содержать следующие информационные элементы.

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

Сертификат общедоступного ключа эмитента. Этот элемент переменной длины записывается в ICC эмитентом карты. Когда терминал проверяет этот элемент, он аутентифицирует общедоступный ключ и сопутствующие данные ICC.

Остаток общедоступного ключа эмитента.

Показатель общедоступного ключа эмитента.

Остаток общедоступного ключа ICC.

Показатель общедоступного ключа ICC.

Секретный ключ ICC. Элемент переменной длины, используемый для формирования подписанных динамических прикладных данных. ICC, которые поддерживают аутентификацию динамических прикладных данных, должны сформировать следующий информационный элемент. Подписанные динамические прикладные данные. Этот информационный элемент переменной длины формируется ICC с помощью секретного ключа, который соответствует общедоступному ключу, аутентифицированному в сертификате общедоступного ключа ICC. Чтобы поддерживать аутентификацию динамических данных, каждый терминал должен запоминать большое число общедоступных ключей сертификационного центра, и ставить им в соответствие информацию, которая должна использоваться с этими ключами.
Терминал способен найти любой такой ключ, заданный RID и индексом общедоступного ключа сертификационного центра, полученных от ICC. ICC, поддерживающая аутентификацию динамических данных должна иметь пару ключей, один из которых является секретным, служащим для цифровой подписи, другой - общедоступный для верификации. Общедоступный ключ ICC запоминается ИС картой в сертификате общедоступного ключа, сформированном эмитентом карты. Общедоступный ключ эмитента сертифицирован центром сертификации. Как следствие для верификации подписи ICC терминал должен сначала верифицировать два сертификата, для того чтобы получить и аутентифицировать общедоступный ключ ICC, который далее служит для проверки корректности динамической подписи ICC. Процедура цифровой подписи использует данные, представленные в таблицах 4.6.4.23 и 4.6.4.24. Модуль общедоступного ключа сертификационного центра содержит NCC байт, где NCC ? 248. Показатель общедоступного ключа сертификационного центра равен 2, 3 или 216+1. Модуль общедоступного ключа эмитента содержит NЭ байт, где NЭ < 248 и NЭ < NCC. Если NЭ > (NCC - 36), модуль общедоступного ключа эмитента делится на две части, одна состоит из NCC - 36 старших байт модуля (левые цифры), а вторая часть содержит остальные NЭ - (NCC - 36) младших байт модуля (остаток общедоступного ключа эмитента). Показатель общедоступного ключа эмитента равен 2, 3 или 216+1. Модуль общедоступного ключа ICC содержит NIC байт, где NIC ? 128 и NIC < NЭ. Если NIC > (NЭ - 42), модуль общедоступного ключа ICC делится на две части, одна - состоит из NЭ - 42 старших байт модуля (левые цифры общедоступного ключа ICC) и остальных NIC - (NЭ - 42) младших байт модуля (остаток общедоступного ключа ICC). Показатель общедоступного ключа ICC равен 2, 3 или 216+1. Для осуществления аутентификации динамических данных терминал сначала извлекает и аутентифицирует общедоступный ключ ICC (аутентификация общедоступного ключа ICC). Вся информация, необходимая для аутентификации общедоступного ключа ICC представлена в таблице 4.6.4.25 и хранится в памяти ICC.

За исключением RID, который может быть получен из AID, эта информация извлекается с помощью команды READ RECORD. Если что-то из этой информации отсутствует, аутентификация терпит неудачу. Таблица 4.6.4.23. Данные общедоступного ключа эмитента, которые должны быть подписаны сертификационным центром.

Имя поля	Длина (байт)	Описание
Формат сертификата	1	Шестнадцатеричное число 0х02
Идентификационный номер эмитента	4	Левые 3-8 цифр от PAN (дополняемые справа кодами 0хF)
Дата истечения времени действия сертификата	2	Дата ММГГ, после которой сертификат становится недействительным
Серийный номер сертификата	3	Двоичное число, уникальное для данного сертификата, присваиваемое центром сертификации
Индикатор хэш-алгоритма	1	Индицирует алгоритм, используемый для вычисления результирующего хэша цифровой подписи
Индикатор алгоритма общедоступного ключа эмитента	1	Индицирует алгоритм вычисления цифровой подписи, который должен использоваться совместно с общедоступным ключом эмитента
Длина общедоступного ключа эмитента	1	Идентифицирует длину модуля общедоступного ключа эмитента в байтах
Длина показателя общедоступного ключа эмитента	1	Идентифицирует длину показателя общедоступного ключа эмитента в байтах
Общедоступный ключ эмитента или левые цифры этого ключа	NCC - 36	Если NЭ ? NCC - 36, это поле состоит из полного общедоступного ключа эмитента дополненного справа NCC -36 - NЭ байт с кодом 0хBB. Если NЭ > NCC - 36, это поле состоит из NCC - 36 старших байтов общедоступного ключа эмитента
Остаток общедоступного ключа эмитента	0 или NЭ -NCC + 36	Это поле присутствует только если NЭ > NCC - 36 и состоит из NЭ - NCC + 36 младших байт общедоступного ключа эмитента
Показатель общедоступного ключа эмитента	1 или 3	Показатель общедоступного ключа эмитента равен 2, 3 или 216+1

Таблица 4.6.4.24. Данные общедоступного ключа ICC, которые должны быть подписаны эмитентом карты

Имя поля	Длина (байт)	Описание
Формат сертификата	1	Шестнадцатеричное число 0х04
PAN (Primary Application Number) приложения	10	PAN дополненный справа кодами 0хF
Дата истечения времени действия сертификата	2	Дата ММГГ, после которой сертификат становится недействительным
Серийный номер сертификата	3	Двоичное число, уникальное для данного сертификата, присваиваемое эмитентом
Индикатор хэш-алгоритма	1	Индицирует алгоритм, используемый для вычисления результирующего хэша цифровой подписи
Индикатор алгоритма общедоступного ключа ICC	1	Индицирует алгоритм вычисления цифровой подписи, который должен использоваться совместно с общедоступным ключом ICC
Длина общедоступного ключа ICC	1	Идентифицирует длину модуля общедоступного ключа ICC в байтах
Длина показателя общедоступного ключа ICC	1	Идентифицирует длину показателя общедоступного ключа ICC в байтах
Общедоступный ключ ICC или левые цифры этого ключа	NЭ - 42	Если NIC ? NЭ - 42, это поле состоит из полного общедоступного ключа ICC дополненного справа NЭ - 42 - NIC байт с кодом 0хBB.Если NIC > NЭ - 42, это поле состоит из NЭ - 42 старших байтов общедоступного ключа ICC
Остаток общедоступного ключа ICC	0 илиNIC - NЭ + 42	Это поле присутствует, только если NIC > NЭ - 42 и состоит из NЭ - NCС + 42 младших байт общедоступного ключа ICC
Показатель общедоступного ключа ICC	1 или 3	Показатель общедоступного ключа ICC равен 2, 3 или 216+1
Данные, подлежащие аутентификации	Переменная	Статические данные, подлежащие аутентификации согласно спецификации ICC для платежных систем

Таблица 4.6.4.25. Информационные объекты, необходимые для аутентификации общедоступного ключа

Метка (Tag)	Длина (байт)	Описание
-	5	Зарегистрированный идентификатор провайдера приложения (RID)
0х8F	1	Индекс общедоступного ключа центра сертификации
0х90	NCC	Сертификат общедоступного ключа эмитента
0х92	NЭ - NCC + 36	Остаток общедоступного ключа эмитента (если имеется)
0х9F32	1 или 3	Показатель общедоступного ключа эмитента
0х9F46	NЭ	Сертификат общедоступного ключа ICC
0х9F48	NIC - NЭ + 42	Остаток общедоступного ключа ICC (если он имеется)
0х9F47	1 или 3	Показатель общедоступного ключа ICC
-	Переменная	Данные, подлежащие аутентификации

Терминал считывает индекс общедоступного ключа центра сертификации. Используя этот индекс и RID, терминал может идентифицировать и извлечь из памяти модуль и показатель общедоступного ключа сертификационного центра и сопряженную с ним информацию. Если терминал не сможет найти нужные данные, сертификация не состоится. Если сертификат общедоступного ключа эмитента имеет длину отличную от длины модуля общедоступного ключа сертификационного центра, аутентификация динамических данных не проходит. Для того чтобы получить восстановленные данные, представленные в таблице 4.6.4.26, используется сертификат общедоступного ключа эмитента и общедоступный ключ центра сертификации. Если хвостовик восстановленных данных не равен 0хBC, аутентификация динамических данных не проходит. Проверяется заголовок восстановленных данных и, если он не равен 0х6А, аутентификация отвергается. Проверяется код формата сертификата и, если он не равен 0х02, аутентификация отвергается. Объединяются слева направо информационные элементы со второго по десятый (см. табл. 4.6.4.26), добавляется остаток общедоступного ключа эмитента (если он имеется) и показатель этого ключа. Для полученной строки применяется соответствующий алгоритм хэширования. Сравнивается вычисленный хэш и восстановленное значение поля результата хэширования. При несовпадении аутентификация не проходит. Таблица 4.6.4.26. Формат восстановленных данных из сертификата общедоступного ключа эмитента.

Имя поля	Длина (байт)	Описание
Заголовок восстановленных данных	1	Шестнадцатеричное число 0х6А
Формат сертификата	1	Шестнадцатеричное число 0х02
Идентификационное число эмитента	4	Левые 3-8 цифр из PAN, дополненные справа кодами 0хF
Дата истечения времени действия сертификата	2	Дата ММГГ, после которой сертификат становится недействительным
Серийный номер сертификата	3	Двоичное число, уникальное для данного сертификата, присваиваемое центром сертификации
Индикатор хэш-алгоритма	1	Индицирует алгоритм, используемый для вычисления результирующего хэша цифровой подписи
Индикатор алгоритма общедоступного ключа эмитента	1	Индицирует алгоритм вычисления цифровой подписи, который должен использоваться совместно с общедоступным ключом эмитента
Длина общедоступного ключа эмитента	1	Идентифицирует длину модуля общедоступного ключа эмитента в байтах
Длина показателя общедоступного ключа эмитента	1	Идентифицирует длину показателя общедоступного ключа эмитента в байтах
Общедоступный ключ эмитента или левые цифры этого ключа	NCC - 36	Если NЭ ? NСС - 36, это поле состоит из полного общедоступного ключа эмитента, дополненного справа NСС - 36 - NЭ байтами с кодом 0хBB. Если NЭ > NСС - 36, это поле состоит из NСС - 36 старших байтов общедоступного ключа эмитента
Результат хэширования	20	Хэш общедоступного ключа эмитента и сопряженных данных
Хвостовик восстановленных данных	1	Шестнадцатеричное число 0хВС

Проверяется то, что идентификационный номер эмитента соответствуют 3-8 цифрам PAN. Если соответствия нет, аутентификация отвергается. Проверяется срок действия сертификата и, если он истек, аутентификация отвергается. Проверяется то, что объединение RID, индекса общедоступного ключа центра сертификации и серийного номера сертификата корректно. Если индикатор алгоритма общедоступного ключа эмитента не распознан, аутентификация не проходит. Если все вышеперечисленные проверки прошли успешно, осуществляется объединение левых цифр общедоступного ключа эмитента и остатка этого ключа (если он имеется). Это делается для получения модуля общедоступного ключа эмитента. После данной процедуры система переходит к извлечению общедоступного ключа ICC. Если сертификат общедоступного ключа ICC имеет длину, отличную от длины модуля общедоступного ключа эмитента, авторизация не проходит. Для того чтобы получить данные, специфицированные в таблице 4.6.4.27, используется сертификат общедоступного ключа ICC и общедоступный ключ эмитента. Если хвостовик восстановленных данных не равен 0хВС, аутентификация не проходит. Если при проверке код заголовка восстановленных данных не равен 0х6А, аутентификация не проходит. Если код формата сертификата не равен 0х04, аутентификация также не проходит. Таблица 4.6.4.27. Формат восстановленных данных из сертификата общедоступного ключа ICC.

Имя поля	Длина(байт)	Описание
Заголовок восстановленных данных	1	Шестнадцатеричное число 0х6А
Формат сертификата	1	Шестнадцатеричное число 0х04
PAN приложения	10	PAN, дополненный справа кодами 0хF
Дата истечения времени действия сертификата	2	Дата ММГГ, после которой сертификат становится недействительным
Серийный номер сертификата	3	Двоичное число, уникальное для данного сертификата, присваиваемое центром сертификации
Индикатор хэш-алгоритма	1	Индицирует алгоритм, используемый для вычисления результирующего хэша цифровой подписи
Индикатор алгоритма общедоступного ключа ICC	1	Индицирует алгоритм вычисления цифровой подписи, который должен использоваться совместно с общедоступным ключом ICC
Длина общедоступного ключа ICC	1	Идентифицирует длину модуля общедоступного ключа ICC в байтах
Длина показателя общедоступного ключа ICC	1	Идентифицирует длину показателя общедоступного ключа ICC в байтах
Общедоступный ключ ICC или левые цифры общедоступного ключа ICC	NЭ - 42	Если NIC ? NЭ - 42, это поле состоит из полного общедоступного ключа ICC, дополненного справа NЭ - 42 - NIC байтами с кодом 0хBB. Если NIC > NЭ - 42, это поле состоит из NЭ - 42 старших байтов общедоступного ключа ICC
Результат хэширования	20	Хэш общедоступного ключа ICC и сопряженных с ним данных
Хвостовик восстановленных данных	1	Шестнадцатеричное число 0хВС

Объединяются слева направо поля из таблицы 4.6.4.27, начиная со второго до десятого, добавляется остаток общедоступного ключа ICC (если имеется), показатель общедоступного ключа ICC и данные, подлежащие аутентификации. Это объединение хэшируется согласно указанному алгоритму. Результат сравнивается со значением поля результат хэширования. При несовпадении аутентификация не проходит. Восстановленный PAN должен быть равен PAN приложения (ICC). После этого проверяется срок пригодности сертификата. Если все выше перечисленные проверки оказались успешными, система переходит к последующим тестам. После получения общедоступного ключа ICC терминал выдает команду INTERNAL AUTHENTICATE для объединения информационных элементов DDOL (Dynamic Data Authentication Data Object List). ICC может нести в себе DDOL, но терминал имеет значение DDOL по умолчанию, специфицированное платежной системой на случай отсутствия этих данных в ICC. DDOL должен содержать непредсказуемое число, формируемое терминалом (тэг 0х9F37, четыре двоичных байта). ICC генерирует цифровую подпись для данных, специфицированных в таблице 4.6.4.28 с использованием секретного ключа (SIC) ICC. Результат называется подписанными динамическими данными приложения. Таблица 4.6.4.28. Динамические данные приложения, которые должны быть подписаны

Имя поля	Длина (байт)	Описание
Формат подписанных данных	1	Шестнадцатеричное число 0х05
Индикатор хэш-алгоритма	1	Индицируется алгоритм хэширования, используемый для получения результата
Длина динамических данных ICC	1	Идентифицирует длину LDD динамических данных ICC в байтах
Динамические данные ICC	LDD	Динамические данные, сформированные и/или записанные в ICC
Символы заполнителя	NIC - LDD - 25	(NIC - LDD - 25) байтов заполнителя, содержащего коды 0хBB
Динамические данные терминала	Переменная	Объединение информационных элементов, специфицированных DDOL

Длина динамических данных ICC LDD удовлетворяет условию 0 ? LDD ? NIC - 25. 3-9 самых левых байтов динамических данных ICC включают в себя 1 байт длины динамического числа ICC, за которым следует 2-8 байт значения этого числа (тэг 9F4C, 2-8 двоичных байтов). Динамическое число ICC формируется ICC. Кроме данных, перечисленных в таблице 4.6.4.28, для аутентификации динамических данных необходимы информационные объекты: Подписанные динамические данные приложения (NIC байтов; тэг 9F4B) и DDOL (тэг 9F49). Если подписанные динамические данные приложения имеют длину отличную от длины модуля общедоступного ключа ICC, аутентификация не проходит. Чтобы получить восстановленные данные, описанные в таблице 4.6.4.29 для подписанных динамических данных приложения используется общедоступный ключ ICC.

Если хвостовик восстановленных данных не равен 0хBC, аутентификация не проходит. Таблица 4.6.4.29. Формат данных, полученных из подписанных динамических данных приложения

Имя поля	Длина (байт)	Описание
Заголовок восстановленных данных	1	Шестнадцатеричное число 0х6А
Формат подписанных данных	1	Шестнадцатеричное число 0х05
Индикатор алгоритма хэширования	1	Индицируется алгоритм хэширования, используемый для получения результата при вычислении цифровой подписи
Длина динамических данных ICC	1	Идентифицирует длину динамических данных ICC в байтах
Динамические данные ICC	LDD	Динамические данные, сформированные и/или записанные в ICC
Символы заполнителя	NIC - LDD - 25	(NIC - LDD - 25) байтов заполнителя, содержащего коды 0хBB
Результат хэширования	20	Хэш динамических данных приложения и сопряженной информации
Хвостовик восстановленных данных	1	Шестнадцатеричное число 0хВС

Далее проверяется заголовок восстановленных данных, если его код не равен 0х6А, аутентификация не проходит. Проверяется код формата подписанных данных и, если он не равен 0х05, аутентификация не проходит. Производится объединение слева направо шести информационных элементов из таблицы 4.6.4.29 (начиная с поля формата подписанных данных). Производится хэширование этого объединения, после чего полученный результат сравнивается со значением поля результата хэширования и, если совпадения нет, аутентификация не проходит. Если все предыдущие шаги оказались успешными, аутентификация динамических данных завершается успехом.

DL- диагностическая запись

Клиентская диагностическая запись о плохом сообщении от продавца или сервера. #####################################################################
Отправитель: CyberApp
Получатель: CyberServer
#####################################################################
Пример сообщения: $$-CyberCash-0.8-$$
id: MyCyberCashID
date: 19950121100505.nnn
transaction: 1234
cyberkey: CC1001 opaque: 2DqiOQfGRZjzddWpEZwGsJnoTsp9Yiri8DE9cPUMPsJ7lTFuE4XHi4QfN2cAipDB2G/G
9hr7Hj4u4xfMky7nPvJurClZejkI8eNp8iXLtrfS4DhR4yCFQjCiKk0dh83p+DDsFVV7
TI3Du2B15sQS+SdaoPwkfVDnJv4Y+b7vu2cN7bG7exCkBapBcJZbReNaWX5sf+U8ypfw
5V6QdMOzNXpef3z+cTTWfGOtmn9T1Pwo1Yi9ObyIf/wiK+IPb+bBZ9UwLZSB+qVMfJmX
GnHXO3AnA/PD+jKYCtsm2Gxv2WB3CuezOyzPtORuqLp5ubgnLBF9aBBjxwLdbn+cp5sm
lw51IHbmo1Jj7H6wyNnRpEjy4tM73jcosBfGeQDHxgyH1uaiFNr2D+WvmuYo7eun2dsy
Wve2O/FwicWHvkg5aDPsgOjzetsn1JCNZzbW
$$-CyberCash-End-kchfiZ5WAUlpk1/v1ogwuQ==-$$
#####################################################################
Скрытый ключ. Генерируется из ключа шифрования CyberCash, идентифицируемого в CyberKey
#####################################################################
Содержимое скрытой секции:
type: diagnostic-log
message: incorrect order-id
swversion: 0.8win
x-type: original-message-type
x-transaction: original-transaction-number
x-opaque: [ели нельзя дешифровать] 9/eFiJK5tLizsoeSmpW7uLS8/7iio7Wisfv38biio7uyufv3tfv35uH+7N3d9/exuKX3
5+z3vuu4oqO7srnsvvz8/venoqO0v7al/7iio7WisYy+iv7s3ff3p6KjtL+2pf/wi7nw
#####################################################################
Приложение клиента не ожидает отклика на это сообщение. Если дешифрация прошла успешно, дешифрованное исходное сообщение будет заключено в закрытую секцию. Если дешифровка не прошла, не дешифрованная закрытая секция берется из исходного сообщения.

DL- диагностические журнальные записи продавца (merchant-diagnostic-log)

Диагностическая запись продавца о плохом сообщении от сервера. #####################################################################
Отправитель: CyberMerchant
Получатель: CyberServer
#####################################################################
Пример сообщения: $$-CyberCash-0.8-$$
merchant-ccid: MyCyberCashID
merchant-transaction: 1234
merchant-date: 19950121100505.nnn
merchant-cyberkey: CC1001
merchant-opaque: 2DqiOQfGRZjzddWpEZwGsJnoTsp9Yiri8DE9cPUMPsJ7lTFuE4XHi4QfN2cAipDB2G/G
9hr7Hj4u4xfMky7nPvJurClZejkI8eNp8iXLtrfS4DhR4yCFQjCiKk0dh83p+DDsFVV7
TI3Du2B15sQS+SdaoPwkfVDnJv4Y+b7vu2cN7bG7exCkBapBcJZbReNaWX5sf+U8ypfw
5V6QdMOzNXpef3z+cTTWfGOtmn9T1Pwo1Yi9ObyIf/wiK+IPb+bBZ9UwLZSB+qVMfJmX
GnHXO3AnA/PD+jKYCtsm2Gxv2WB3CuezOyzPtORuqLp5ubgnLBF9aBBjxwLdbn+cp5sm
lw51IHbmo1Jj7H6wyNnRpEjy4tM73jcosBfGeQDHxgyH1uaiFNr2D+WvmuYo7eun2dsy
Wve2O/FwicWHvkg5aDPsgOjzetsn1JCNZzbW
$$-CyberCash-End-kchfiZ5WAUlpk1/v1ogwuQ==-$$
#####################################################################
Скрытый ключ. Генерируется из ключа шифрования CyberCash, заданного в CyberKey
#####################################################################
Содержимое скрытой секции: type: merchant-diagnostic-log
server-date: 19950121100505.nnn [optional]
message: incorrect order-id
x-type: original-message-type
x-transaction: original-transaction-number
x-opaque: [если невозможно дешифровать] 9/eFiJK5tLizsoeSmpW7uLS8/7iio7Wisfv38biio7uyufv3tfv35uH+7N3d9/exuKX3
5+z3vuu4oqO7srnsvvz8/venoqO0v7al/7iio7WisYy+iv7s3ff3p6KjtL+2pf/wi7nw
##################################################################### Приложение продавца не ждет отклика на это сообщение. Дешифрованное исходное сообщение будет размещено в закрытой части, если только дешифрование произошло успешно. Если шифрование осуществить не удалось, будет послано не дешифрованное сообщение.

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

Документальный обмен аутентификации является непосредственной реализацией торгового обмена аутентификации (смотри раздел 2.2.4). Он включает в себя:

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

Аутентификация состоит из:

Запрос аутентификации, посылаемый аутентификатором аутентифицируемому,

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

Предоставление аутентифицируемому компонента Organisation, который описывает аутентификатора и

Опционно, предоставление аутентификатору компонента Organisation, который описывает аутентифицируемого. Запрос аутентификации может быть подписан цифровым образом, что позволяет аутентифицируемому, проверить доверительные параметры (credentials) аутентификатора. IOTP-сообщения, которые используются в таком обмене, представлены на рис. .18.

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

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

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

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

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

… Продолжение ...
Рис. .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 для Продавца.

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

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

комонент списка вида платежа посылается покупателю в блоке TPO;

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

Покупатель посылает выбранные вид платежа, протокол и валюту продавцу в блоке выбора TPO;

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

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

… продолжение ...
Рис. .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, тогда информация, содержащаяся в сообщении должна быть доведена до сведения покупателя.

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

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

о	Любой новый XML-элемент должен быть декларирован согласно правилам [XML Namespaces]
o	Новые XML-элементы, которые являются торговыми блоками или компонентами должны содержать ID-атрибуты с именем атрибута ID.

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

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

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

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

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

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

IOTP:Critical

(True | False ) 'True'

Допустимые комбинации документальных обменов

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

Рис. .31. Допустимые комбинации документальных обменов 1) Если первое сообщение IOTP транзакции содержит запрос аутентификации, то:

	a) Транзакция IOTP содержит документальный обмен аутентификации (смотри раздел 9.1.1). (Замечание 1)
	b) Если последнее сообщение документального обмена аутентификации содержит блоки TPO и отклика предложения, тогда:
		i) Транзакция IOTP включает документальный обмен предложения, независимый от вида платежа (смотри раздел 9.1.2.2). (Замечание 2)
	c) В противном случае, если последнее сообщение аутентификационного обмена содержит блок TPO, но не содержит блока отклика предложения, тогда:
		i) Сообщение IOTP содержит документальный обмен предложения, зависимый от вида платежа (смотри раздел 9.1.2.1). (Замечание 2)
	d) В противном случае (сообщение состояния аутентификации документального обмена не содержит ни блока TPO ни блока отклика предложения).
		i) Транзакция IOTP содержит только документальный обмен аутентификации. (Замечание 3)

2) В противном случае (отсутствие запроса аутентификации в первом сообщении IOTP):

	e) Транзакция IOTP не включает в себя документальный обмен аутентификации (Замечание 2)
	f) Если первое сообщение содержит блок отклика предложения, тогда:
		i) Транзакция IOTP содержит документальный обмен предложения, независимый от вида платежа (Замечание 2)
	g) В противном случае (отсутствие блока отклика предложения в первом сообщении):
		i) Транзакция IOTP включает документальный обмен предложения, зависимый от вида платежа (Замечание 2)

3) Если блок отклина предложения присутствует в каком-либо сообщении IOTP, тогда:

	h) Если блок отклика предложения содержит компонент доставки, тогда:
		i) Если атрибут DelivAndPayResp компонента доставки равен “Истинно”, то компонент доставки делается равной “Истинно”, тогда:
			(1) Транзакция IOTP состои из документальных обменов платежа и доставки (смотри раздел 9.1.5) (Замечание 4)
		ii) В противном случае (атрибут DelivAndPayResp компонента доставки делается равным “Ложно”)
			(1) Транзакция состоит из документального обмена платежа (смотри раздел 9.1.3), за которым следует обмен доставки (смотри раздел 9.1.4) (Замечание 4)
	i) В противном случае (блок отклика предложения не содержит компонента доставки )
		i) если блок отклика предложения содержит только один компонент платежа, тогда:
			(1) Транзакция IOTP содержит только один документальный обмен платежа (Замечание 5)
		ii) если блок отклика Offer содержит компонент платежа, тогда:
			(1) Транзакция IOTP включает в себя два документальных платежных обмена. Атрибут StartAfter компонента платежа используется для индикации того, какой платеж происходит первым. (Замечание 6)
		iii) если блок отклика Offer не содержит ни одного или имеет более двух платежных компонентов, то имеет место ошибка
4) В противном случае (отсутствие блока отклика Offer) имеет место ошибка.

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

Замечание	Корректность транзакции IOTP
1.	Любая транзакция платежа и аутентификации
2.	Любая транзакция платежа и аутентификации за исключением базовой аутентификации
3.	Транзакция базовой аутентификации или базовой покупки, возврата денег, депозита, отзыва или обмена ценностями с не прошедшей аутентификацией
4.	Толко базовая трканзакция покупки
5.	Базовая транзация покупки, возврата денег, депозита и отзыва
6.	Только базовый обмен ценностями

Доставка

Способ доступа к данным Агента доставки при проверке того, может ли он выполнить доставку показан на рис. .13. Start
|
v
Y">Delivery
Component
|
|ActionOrgRef
|
v
Organisation
Component
|
-Trading Role
Element
(Delivery Handler)
Рис. .13. Проверка того, что агент доставки может выполнить доставку Процедура включает в себя следующие шаги:

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

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

Если компонент Organisation для Агента доставки не имеет элемента торговой роли с атрибутом Role агента доставки, то это ошибка.

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

Формат сообщения

Сообщения CyberCash состоят из следующих компонентов:

Заголовок - определяет начало сообщения CyberCash и включает информацию о версии.

Прозрачная часть - содержит данные, которые не являются конфиденциальными.

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

Завершающая секция - определяет конец сообщения CyberCash и содержит контрольный код, который позволяет судить о том, что сообщение дошло без искажений. Заметим, что этот код призван детектировать случайные искажения сообщения. В CyberCash сообщении запрещены нулевые символы (значение нуль) или символы, характеризуемые восемью битами. "Двоичные" значения, которые могут содержать такие коды, представляются с помощью base64, описанного в документе RFC-1521.

Формат заголовка общего сообщения

Версия 0.8 внешнего формата для кодирования сообщений CyberCash описана ниже. Сообщения CyberCash представляют собой стилизованные документы для передачи финансовой информации по Интернет. В то время как существует множество схем передачи данных по Интернет (HTTP, SMTP и прочие), каждая из них привязывается к определенному механизму передачи. Так как сообщения CyberCash могут передаваться через любую из названных сред (да и через некоторые не названные), должна быть обеспечена независимость от механизма обмена.

Форматы специальных сообщений

Далее описывается формат сообщений CyberCash версии 0.8. Предполагается, что читатель знаком с такими терминами как "получатель" (acquirer), "PAN" (первичный номер счета), и т.д., определенными в документе ISO 8583, и назначение валюты (currency designations), как это определено в ISO 4217. Некоторые несущественные поля для упрощения удалены. В последующих примерах сообщений подписи, хэши и шифрованные секции не имеют никакого реального смысла.

Протокол для работы с кредитными картами CyberCash

Используется CyberApp, чтобы получить обновленную версию. #####################################################################
Отправитель: CyberApp
Получатель: CyberServer
#####################################################################
Пример сообщения:
$$-CyberCash-0.8-$$
transaction: 123123213
date: 19950121100505.nnn
cyberkey: CC1001
opaque:
VHMS611wGkUmR6bKoI+ODoSbl7L5PKtEo6aM88LCidqN+H/8B4xM3LxdwUiLn7rMPkZi
xOGb+5d1lRV7WeTp21QYlqJr8emc6FAnGd5c0csPmcnEpTFh9xZDJaStarxxmSEwm2mw
l2VjEUODH6321vjoMAOFQWn7ER0o
$$-CyberCash-End-0QXqLlNxrn4GNQPPk9AO1Q==-$$
#####################################################################
Скрытый ключ. Генерируется с использованием общедоступного ключа CyberCash, идентифицированного в CyberKey.
#####################################################################
Содержимое скрытой секции:
type: get-application
swversion: 0.8win Объяснение: Может не существовать персоны покупателя и поэтому ID может отсутствовать. Может не быть пары ключей покупателя (общедоступный/секретный) и поэтому не быть подписи. swversion является обязательным, так что сервер мог сказать, что следует возвратить.

Протокол для работы с кредитными картами CyberCash

Возвращает в случае успеха URL копии современного приложения CyberApp или флаг неудачи. #####################################################################
Отправитель: CyberServer
Получатель: CyberApp
#####################################################################
Пример сообщения: $$-CyberCash-0.8-$$
transaction: 12312313
date: 19950110102333.nnn
opaque:
EDD+b9wAfje5f7vscnNTJPkn1Wdi7uG3mHi8MrzLyFC0dj7e0JRjZ2PmjDHuR81kbhqb
nX/w4uvsoPgwM5UJEW0Rb9pbB39mUFBDLPVgsNwALySeQGso0KyOjMxNs1mSukHdOmDV
4uZR4HLRRfEhMdX4WmG/2+sbewTYaCMx4tn/+MNDZlJ89Letbz5kupr0ZekQlPix+pJs
rHzP5YqaMnk5iRBHvwKb5MaxKXGOOef5ms8M5W8lI2d0XPecH4xNBn8BMAJ6iSkZmszo
QfDeWgga48g2tqlA6ifZGp7daDR81lumtGMCvg==
$$-CyberCash-End-0QXqLlNxrn4GNQPPk9AO1Q==-$$ #####################################################################
Скрытый ключ: ключ сессии от GA1
#####################################################################
Содержимое скрытой секции: type: get-application-response
server-date: 19950110102334.nnn
response-code: success/failure/etc.
message; Текст сообщения отображается пользователю, предоставляя дополнительную информацию об успехе или неудаче.
swversion: 0.8win
application-url: http://foo.cybercash.com/server/0.8WIN.EXE
>application-hash: lSLzs/vFQ0BXfU98LZNWhQ== В качестве хэша приложения используется MD5.
application-url и application-hash при ошибке опускаются.
swversion является версией, подлежащей передаче покупателю.

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

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

Хэш-коды

Хэши, используемые в сообщениях CyberCash представляют собой дайджесты сообщений. То есть, некоторое компактное отображение сообщения, которое изменяется неузнаваемо при любых искажениях исходного сообщения. Таким образом, относительно небольшой хэш может использоваться для контроля целостности достаточно большого сообщения. Если вы уверены в аутентичности хэша, и получили сообщение, которое соответствует этому хэшу, вы можете тогда быть уверены, что это оригинальное сообщение. Хэш вычисляется с использованием алгоритма MD5 (смотри RFC-1321) для комбинированного сообщения. Комбинированное сообщение составляется из меток и значений, специфицированных в списке для конкретного хэша. Так как хэш чувствителен к порядку поступающих данных, существенно, чтобы пары метка-значение были сгруппированы в правильной последовательности. До хэширования из текста комбинированного сообщения удаляются все пробелы (SP, TAB, LF и CR) и все коды меньше 32 и больше 127. Таким образом, все формы обозначения начала новой строки, пустые строки, завершающие пробелы и прочее, удаляются. Хэши MD5 имеют по 16 байт. Это означает, что кодировка base64 такого хэша занимает 24 символа (последние два будут всегда заполнителями).

ID-атрибуты

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

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

Если роль не соответствует покупателю, тогда здесь содержится каноническое имя этой организации. Смотри [DNS], за которым опционно следуют дополнительные символы, если требуется сделать NonConsumerOrgId уникальным.

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

newjerseybooks.comid организации-продавца;

westernbank.co.ukid организации-кассира;

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

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

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

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

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

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

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

Идентификация льготных видов платежа

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

как продавец или кассир идентифицирует поощрительный вид оплаты, используемый в момент покупки;

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

Идентификация поощрительных видов платежа Продавцом/Кассиром

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

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

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

первый вариант предполагает доступность SET.

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

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

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

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

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

	ID #REQUIRED
Version	NMTOKEN #FIXED '1.0'
IotpTransId	CDATA #REQUIRED
IotpTransType	CDATA #REQUIRED
TransTimeStamp	CDATA #REQUIRED >

Атрибуты:

ID		Идентификатор, который однозначно определяет Id-компонент транзакции в рамках операции IOTP.
Version		Определяет версию IOTP и, следовательно структуру сообщений IOTP, которые используются транзакцией IOTP.
IotpTransId		Содержит данные, которые однозначно определяют транзакцию IOTP. Это атрибут должен отвечать правилам для идентификаторов сообщений [RFC 822].
IotpTransTyp		Это тип исполняемой транзакции IOTP. Для базовой версии IOTP он идентифицирует "стандартную" транзакцию IOTP и предполагает определенную последовательность и содержимое сообщений IOTP, которыми обмениваются торговые роли. Корректными значениями атрибута являются:
о	BaselineAuthentication (Базовая аутентификация)
o	BaselineDeposit
o	BaselinePurchase
o	BaselineRefund
o	BaselineWithdrawal
o	BaselineValueExchange
o	BaselineInquiry
o	BaselinePing

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

TransTimeStamp

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

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

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

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

	RespIotpMsg NMTOKEN #IMPLIED
xml:lang NMTOKEN #REQUIRED	LangPrefList NMTOKENS #IMPLIED
CharSetPrefList NMTOKENS #IMPLIED	SenderTradingRoleRef NMTOKEN #IMPLIED
SoftwareId CDATA #REQUIRED	TimeStamp CDATA #IMPLIED >

Атрибуты:

ID	Идентификатор, который однозначно идентифицирует сообщение IOTP в рамках транзакции IOTP (смотри раздел 3.4 ID атрибуты). Заметим, что если сообщение IOTP пересылается повторно, тогда значение этого атрибута остается неизменным.
RespIotpMsg	Это ID-атрибут содержит Id-компонент сообщения IOTP, откликом на которое оно является. Таким образом, все сообщения IOTP в пределах транзакции оказываются связаны. Это поле необходимо каждому сообщению IOTP за исключением первого сообщения IOTP в транзакции.
SenderTradingRoleRef	Элемент ссылки (смотри раздел 3.5) торговой роли, которая сформировала сообщение IOTP. Он используется, чтобы идентифицировать сетевую позицию (Net Locations) (смотри раздел 3.9) торговой роли, которой требуется сообщить о технических ошибках (смотри раздел 4.1), связанных с торговыми блоками.
Xml:lang	Определяет язык, используемый атрибутом, или дочерние элементы в пределах этого компонента, если не переписан атрибутом xml:lang в дочернем элементе. Смотри раздел 3.8.
LangPrefList	Опционный список языковых кодов, который согласуется с идентификацией языков [XML]. Он используется отправителем, чтобы указать порядок предпочтения языков, которые получатель сообщения должен использовать при подготовке отклика. Получатель не обязан использовать один из указанных языков.
CharSetPrefList	Опционный список идентификаторов символьных наборов, которые соответствуют символам в [XML]. Он используется отправителем для указания порядока предпочтения символьных наборов, которые получатель может применить при формировании отклика. Получатель не обязан использовать один из указанных символьных наборов.
SoftwareId	Содержит информацию, которая идентифицирует программу, сформировавшую сообщение IOTP. Его целью является помочь разрешить проблему совместной работы различных программ, обменивающихся сообщениями. Это простая текстовая строка на языке, определенном xml:lang. Она должна содержать, по крайней мере:
		имя производителя программного продукта название программного продукта версию программы форму программного обеспечения (build)
TimeStamp	Когда прибор, отправляющий сообщение имеет внутренние часы, атрибут делается равным времени генерации сообщения IOTP в формате [UTC].

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

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

ContentSoftwareId

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

Cодержимое:

PackagedContent

Элементы Packaged Content (смотри раздел 3.7), которые содержат дополнительную информацию, относящуюся к виду платежа и валюты. Смотри приложение IOTP по платежным методам, где описано использование этого элемента.

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

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

ContentSoftwareId

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

Cодержимое:

PackagedContent

Элементы Packaged Content (смотри раздел 3.7), содержащие дополнительные данные, которые могут быть необходимы для конкретного вида платежа. Смотри приложение IOTP по платежным методам, где описаны методы использования данного элемента.

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

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

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

Инфраструктурные транзакции

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

транзакция запроса состояния транзакции, которая предоставляет информацию о статусе существующей или уже завершившейся транзакции;

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

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

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

o	Транзакцию информационного запроса (смотри раздел 9.2.1);
o	Транзакцию Ping (смотри раздел 9.2.2);
o	Транзакцию аутентификации (смотри раздел 9.1.6);
o	Транзакцию, сопряженную с платежем, такую как:
	-	Депозит (смотри раздел 9.1.7);
	-	Покупка (смотри раздел 9.1.8);
	-	Возврат денег (смотри раздел 9.1.9);
	-	Отзыв сделки (смотри раздел 9.1.10);
	-	Обмен ценностями (смотри раздел 9.1.11).

Использование элементов подписи и атрибутов 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, например:

A2

Элемент 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), указывающих на организации, которые должны будут проверить подлинность подписи.

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

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

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

	- Кассиру, чтобы проверить, что продавец авторизует платеж;
	- Агенту доставки, чтобы проверить, что продавец авторизует доставку.

Для платежного отклика, когда Кассир генерирует платежную расписку, которая может быть послана:

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

Отклик доставки, когда Агент доставки генерирует накладную (Delivery Note). Это может быть использовано, чтобы проверить по завершении, что все сделано так как надо.

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

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

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

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

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

Электронная торговля в Интернет

Семёнов Ю.А. (ГНЦ ИТЭФ), book.itep.ru Список таких вопросов можно существенно расширить. Электронные деньги существенно меняют и функции банков, более того некоторые операции банков могут выполняться другими структурами, например, сетевыми сервис-провайдерами или компаниями-разработчиками программного обеспечения. Так, например, MicroSoft через десятки миллионов пользователей Windows может легко захватить заметный сегмент в сфере предоставления кредитов в виде электронных денег. Интернет здесь может использоваться как при покупке через сеть, так и при оплате традиционной (очной) покупки. Схемы взаимодействия участников сделки могут быть весьма замысловатыми, ведь покупатель может быть в одной стране, продавец - в другой, банк покупателя - в третьей, а банк продавца - в четвертой. Учитывая, что в сделке, кроме того, могут участвовать компания, осуществляющая доставку покупки, и фирма, выполняющая обслуживание товара, например мобильного телефона, ситуация еще более осложняется. Понятно, что необходимо определенное юридическое обеспечение подобного рода операций, но уже это выходит за рамки данной книги. Электронная коммерция поменяет современную жизнь также, как Интернет изменил среду общения и доступ к информации. В торговле основную прибыль всегда давала информация (знание конъюнктуры рынка, знание производителей и пр.). Современный этап с его взрывным развитием технологий делает этот фактор решающим. Несколько лет назад я наблюдал, как в книжном магазине в Гамбурге продавали одну книгу. Вещь достаточно ординарная, если бы не одно обстоятельство, - эта книга печаталась и переплеталась в присутствии покупателя. Название я ее забыл, но помню, что автором был американец. Уже здесь видны определенные проблемы. Как проконтролировать тираж, чтобы авторские права не пострадали, как и где начислять налоги на эту деятельность? До недавнего времени программы продавались в коробках, произведенных фирмой разработчиком (практически как книги). Новейшей тенденцией является торговля программами (пока дешевыми) через Интернет.
Для этого имеются все средства и предпосылки. Но эта схема порождает немало юридических и коммерческих проблем. Здесь и упомянутая проблема налогов (пока в США торговля через Интернет не облагается налогами), и нарушения авторских прав. Ведь нужно определить, кто должен платить налоги, дилер, продавший программу, или фирма разработчик, а это не безразлично, если они расположены в разных странах. Да и взаимоотношения между дилером и разработчиком нужно как-то урегулировать, так как нужен надежный контроль за проданным количеством копий программы. Где здесь место таможни (пока продавались коробки с программами, были сопроводительные бумаги, на которых можно было после оплаты сбора поставить штамп "Таможня дала добро")? Сходные проблемы ждут разработчиков и продавцов компьютерных игр, музыкальных CD и DVD-дисков, а в перспективе очень многих других товаров. Развитию электронной торговли способствуют широко распространенные системы склад-магазин (смотри рис. 2.1 и 2.2). Здесь склад и магазин могут иметь общего хозяина, а могу принадлежать и различным фирмам. Прямого отношения к электронной торговле эти структуры не имеют, но при их создании решались некоторые проблемы и создавались программы, которые могут найти применение в электронной коммерции.

Рис. 2.1. Простейшая схема системы склад-магазин

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

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

	Преимущества	Недостатки
Покупатель	Возможность выбора и приобретения товара или услуги, не выходя из дома (экономия времени).	Отсутствие возможности ознакомиться со свойствами товара до его приобретения
	Относительная анонимность покупки	Угроза злоупотреблений в случае раскрытия номера кредитной карты
	Немедленная доставка и сопровождение программ при покупке их через сеть	Как правило, невозможность возврата товара при обнаружении неприемлемого качества
	Получение новых недоступных ранее услуг в сфере развлечений, консультаций, обучения, подписка на газеты, ком-мерческую информацию и пр.
	Получение дополнительной информации о необходимых товарах	Назойливость почтовой рекламы (SPAM)
Продавец	Расширение числа покупателей при неизменных торговых площадях	Дополнительные издержки на внедрение системы
	Возможность автоматического выявления и регистрации IP>-адресов потенциальных клиентов	Потенциальная угроза нанесения ущерба хакерами
	Дополнительная реклама через Интернет	Возможность кражи программ при торговле через сеть (неоплата покупки)
	Облегчение взаимодействия с обслуживающими банками и партнерами, если эта проблема не была решена раньше

По специфике взаимодействия продавца и покупателя выделяются несколько областей бизнеса. К таким областям относятся взаимодействия клиент-клиент P2P (Person-to-Person), продавец-покупатель B2C (Business-to-Consumer) и бизнесмен-бизнесмен B2B (Business-to-Business). Деление это достаточно условно, один и тот же субъект в одних операциях выступает как покупатель в других как продавец. Схема P2P работает при распродаже старых компонентов ЭВМ, книг, кустарных изделий и пр. их владельцами, при обмене и покупке-продаже различных предметов коллекционерами, а также при оказании услуг по ремонту настройке сложного бытового оборудования или, например, в сфере индивидуального обучения. Более перспективной представляется схема B2C>, именно к этому классу относятся практически все Интернет-магазины.

В РФ пару лет назад возник бум создания таких структур. Даже ТВ было привлечено к рекламе некоторых из них. Пожалуй, это было несколько преждевременно. Сохранились лишь несколько книжных магазинов, торговля бытовой техникой, произведениями искусства, лекарствами и т.д.. Пытаются выжить некоторые Интернет-аукционы, которые по своей функции являются, чем-то средним между B2C и P2P. Следует обратить внимание, что почти все они не используют сетевых платежных систем. Во многих случаях отсутствие коммерческого успеха связано с тем, что такие магазины не дают сверхприбылей, но требуют получения лицензий и других начальных инвестиций. Сюда относится и отсутствие достаточного платежеспособного спроса у той части населения, которая знакома с технологиями Интернет и имеет к нему доступ, неразвитая кредитная и банковская системы. В РФ более успешной оказалась область В2В, охватывающая оптовую торговлю медикаментами, металлами, нефтепродуктами, стройматериалами и т.д.. Но даже здесь этот бизнес сильно отличается от аналогичной деятельности, скажем, в США. Как уже отмечалось выше, торговля сопряжена не только с оплатой товара и его получением, но с немалым объемом документов (заказы, счета, чеки, накладные, расписки, платежные поручения и т.д.). В настоящее время специально для торговли через Интернет разработан открытый протокол торговли через Интернет IOTP (Internet Open Trading Protocol). Назад:
Оглавление:
Вперёд:

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

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

	NMTOKEN #IMPLIED
AddressLine1 CDATA #IMPLIED	AddressLine2 CDATA #IMPLIED
CityOrTown CDATA #IMPLIED	StateOrRegion CDATA #IMPLIED
PostalCode CDATA #IMPLIED	Country CDATA #IMPLIED

LegalLocation (True | False) 'False' > Атрибуты:

xml:lang	Определяет язык, используемый атрибутами в этом элементе. Смотри раздел 3.8.
AddressLine1	Первая строка почтового адреса, напр.,"The Meadows"
AddressLine2	Вторая строка почтового адреса. напр.,"Sandy Lane"
CityOrTown	Город в адресе, напр.,"Москва"
StateOrRegion	Штат или область в пределах страны, где находится город, напр., "Зюзино"
PostalCode	Код, известный как, например почтовый код или zip-код, который обычно используется почтовыми организациями для организации эффективной доставки, напр.,"113303"
Country	Страна адреса, напр.,"RU"
LegalLocation	Идентифицирует, является ли адрес зарегистрированным адресом организации. По крайней мере один адрес организации должен соответствовать значению “истина” в противном случае торговой ролью является Покупатель или DeliverTo.

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

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

ContentSoftwareId

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

Cодержимое:

PackagedContent

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

Элемент Brand

Элемент Brand описывает вид платежа, который может быть использован при оплате покупки. Один или более таких элементов образуют компонент списка видов платежа, который имеет атрибут PayDirection, установленный равным Debit. Только один элемент вида платежа может содержаться в компоненте списка видов платежа (Brand List), который имеет атрибут PayDirection = Credit. xml:lang NMTOKEN #IMPLIEDBrandId CDATA #REQUIREDBrandName CDATA #REQUIREDBrandLogoNetLocn CDATA #REQUIREDBrandNarrative CDATA #IMPLIEDProtocolAmountRefs IDREFS #REQUIRED ContentSoftwareId CDATA #IMPLIED> Атрибуты:

ID	Идентификатор элемента, относящийся потенциально к компоненту выбора вида платежа (Brand Selection), содержащегося в последнем сообщении платежного запроса, и однозначно идентифицирующий элемент Brand данной транзакции.
xml:lang	Определяет язык, используемый атрибутами и содержимым данного элемента. Смотри раздел 3.8.
BrandId	Содержит уникальный идентификатор для вида платежа. Он используется для установления соответствия со списком платежных инструментов, которыми располагает Покупатель, чтобы определить, может ли он обеспечить платеж данного вида.

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

BrandName

Содержит название вида платежа, например MasterCard. Это описание вида платежа, которое отображается для Покупателя на понятном для него языке, заданном атрибутом xml:lang. Например, это может быть "American Airlines Advantage Visa". Заметим, что этот атрибут не используется для установления соответствия с инструментами платежа, которыми располагает Покупатель.

BrandLogoNetLocn

Сетевая позиция, которая может быть использована для загрузки логотипа организации. Смотри раздел “Получение логотипа” (раздел 10).

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

BrandNarrative	Этот опционный атрибут предназначен для использования Продавцом для индикации специальных условий или выгод, которрые будут действовать, если Покупатель выберет определенный вид платежа. Например "5% скидка", "бесплатная доставка", "бесплатная гарантия на один год", и т.д..
ProtocolAmountRefs	Идентифицирует протоколы и связанные с ними виды валюты и суммы, которые могут использоваться при данном виде платежа. Специфицируется как список ID протокольных колличественных элементов (смотри раздел 7.7.3), содержащихся в списке видов платежа.
ContentSoftwareId	Смотри раздел 14. Словарь.

Cодержимое:

ProtocolBrand

Протокольные элементы вида платежа, которые содержат информацию о виде платежа, используемого с определенным платежным протоколом (смотри раздел 7.7.2)

PackagedContent

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

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

Элемент Delivery Data

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

DeliveryData xml:lang	NMTOKEN #IMPLIED
OkFrom CDATA #REQUIRED	OkTo CDATA #REQUIRED
DelivMethod NMTOKEN #REQUIRED	DelivToRef NMTOKEN #REQUIRED
DelivReqNetLocn CDATA #REQUIRED	SecDelivReqNetLocn CDATA #REQUIRED

ContentSoftwareId CDATA #IMPLIED> Атрибуты:

xml:lang	Определяет язык, используемый атрибутами компонента. Смотри раздел 3.8.
OkFrom	Дата и время в формате [UTC] после которого Агент доставки может принять на обработку блок запроса доставки (смотри раздел 8.10).
OkTo	Дата и время в формате [UTC], до которого Агент доставки может принять на обработку блок запроса доставки.
DelivMethod	Индицирует метод, с помощью которого могут быть доставлены товары или предоставлены услуги. Корректными считаются значения: о Post. Товары будут доставлены по почте или курьером. o Web. Товары будут доставлены электронным образом в комоненте Delivery Note. o Email. Товары будут доставлены электронным образом через e-mail

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

DelivToRef	Ссылка элемента (смотри раздел 3.4) компонента Organisation транзакции IOTP, которая имеет роль DelivTo. Информация в этом блоке используется, чтобы определить, куда следует доставить покупку. Она должна быть совместимой с DelivMethod. В частности, если DelivMethod является: о Post, тогда здесь должен быть элемент почтового адреса, содержащий достаточно информации для доставки по почте, o Web, тогда не нужны никакие специфические требования. Информация будет послана на web-страницу Покупателя, o Email, тогда здесь должен быть элемент контактной информации с корректным адресом e-mail.
DelivReqNetLocn	Содержит сетевую позицию, куда должен быть послан небезопасный блок запроса доставки (смотри раздел 8.10), который содержит компонент доставки. Содержимое этого атрибута зависит от транспортного механизма и должно согласовываться с требованиями документа [RFC-1738].
SecDelivReqNetLocn	Содержит сетевую позицию, куда должен быть послан безопасный блок запроса доставки (смотри раздел 8.10), который содержит компонент доставки.

Безопасный запрос доставки предполагает использование безопасного канала, такого как [SSL/TLS] для того чтобы взаимодействовать с кассиром. Содержимое этого атрибута зависит от транспортного механизма и должно соответствовать регламентациям документа [RFC1738]. Смотри также раздел 3.9.

ContentSoftwareId

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

Cодержимое:

PackagedContent

Дополнительная информация о доставке в виде одного или несколько элементов Packaged Content (смотри раздел 3.7), предоставляемая агенту доставки продавцу.

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

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

	NMTOKEN #IMPLIED
Tel CDATA #IMPLIED	Fax CDATA #IMPLIED
Email CDATA #IMPLIED	NetLocn CDATA #IMPLIED >

Атрибуты:

xml:lang	Определяет язык данного элемента. Смотри раздел 3.8.
Tel	Телефонный номер, по которому можно контактировать с организацией. Заметим, что это текстовое поле и проверок корректности содержимого не производится.
Fax	Номер факса, по которому можно контактировать с организацией. Заметим, что это текстовое поле и проверок корректности содержимого не производится.
Email	Адрес электронной почты, по которому можно контактировать с организацией. Заметим, что поле должно следовать регламентациям для адресных спецификаций, содержащимся в [RFC822].
NetLocn	Адрес Интернет, по которому можно найти информацию об организации, используя WEB-броузер.

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

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

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

	NMTOKEN #IMPLIED
Title CDATA #IMPLIED	GivenName CDATA #IMPLIED
Initials CDATA #IMPLIED	FamilyName CDATA #IMPLIED >

Атрибуты:

xml:lang	Определяет язык с помощью атрибута внутри элемента. Смотри раздел 3.8.
Title	Отличительное имя; личное прозвище, наследственное или нет, должность (напр., судья, мэр), дворянское звание (напр., герцог, герцогиня, граф), или используемое при обращение к человеку (напр., Mr, Mrs, Miss, товарищ, господин)
GivenName	Имя, под которым человек известен в семье, друзьям или знакомым (имя или фамилия).
Initials	Первая буква второго имени (отчества), под которым человек известен в своей семье, друзьям или знакомым.
FamilyName	Фамилия. Это обычно часть персонального имени, которая передается по наследству от родителей к детям.

Элемент PackagedContent

Элемент PackagedContent поддерживает концепцию потока вложенных данных, преобразованную, чтобы защитититься от неверной интепретации транспортной системой и гарантировать совместимость с XML. Примеры использования этого элемента в IOTP включают: o для инкапсуляции сообщений платежной системы, таких как сообщения SET,
o для инкапсуляции описания заказа, чека (payment note) или накладной (delivery note). В общем, он используется для инкапсуляции одного или более потоков данных. Этот поток данных имеет три стандартизованных атрибута, которые служат для идентификации, декодирования и интерпретации содержимого. Его определение представлено ниже.
Атрибуты:

Name

Опционно. Позволяет разделить случаи множественного применения элементов PackagedContent в одной и той же точке IOTP. Например:

snroasdfnas934k

dvdsjnl5poidsdsflkjnw45

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

Content		Идентифицирует, какой тип данных находится в содержимом элемента PackagedContent. Корректными значениями атрибута Content являются:
о	PCDATA. Содержимое элемента PackagedContent может рассматриваться как PCDATA и более не обрабатываться.
о	MIME. Содержимое элемента PackagedContent является MIME-объектом. Обработка должна включать поиск MIME-заголовков внутри элемента PackagedContent.
о	MIME:mimetype. Содержимое элемента PackagedContent является MIME-объектом с заголовком "Content-Type: mimetype". Хотя допускается иметь MIME:mimetype с атрибутом Transform равным NONE, более желательно иметь атрибут Transform равным BASE64. Заметим, что, если используется Transform = NONE, тогда все содержимое должно соответствовать PCDATA. Некоторые символы будет нужно закодировать как объекты XML, или как символьные объекты.
о	XML. Содержимое элемента PackagedContent может рассматриваться как XML-документ. Следует использвать секции CDATA, или Transform = BASE64, чтобы гарантировать, что содержимое элемента PackagedContent соответствует PCDATA.
Transform		Идентифицирует преобразование, которое было произведено с данными, прежде чем они были помещены элемент. Допустимыми значениями являются:

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

BASE64. Содержимое элемента PackagedContent типа PCDATA представляет собой BASE64 кодировкуреального содержимого. Cодержимое:

PCDATA

Это действительные данные, которые вложены в элемент. Формат данных и правила их кодирования записаны в атрибутах Content и Transform.

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

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

xml:lang NMTOKEN #IMPLIED	ProtocolId NMTOKEN #REQUIRED
ProtocolName CDATA #REQUIRED	ActionOrgRef NMTOKEN #REQUIRED
PayReqNetLocn CDATA #IMPLIED	SecPayReqNetLocn CDATA #IMPLIED

ContentSoftwareId CDATA #IMPLIED> Атрибуты:

ID	Идентификатор элемента, на который может ссылаться элемент Brand; или компонент выбора вида платежа (Brand Selection), содержащиеся в последующих сообщениях платежного запроса. Он однозначно идентифицирует элемент PayProtocol данной транзакции IOTP.
xml:lang	Определяет язык, используемый атрибутами и содержимым данного элемента. Смотри раздел 3.8.
ProtocolId	Состоит из имени протокола и версии, например "SETv1.0".

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

ProtocolName	Описание платежного протокола и его версии на языке, идентифицированном атрибутом xml:lang. Например "Secure Electronic Transaction Version 1.0". Его целью является помочь, если требуется, в предоставлении информации об используемом платежном протоколе.
ActionOrgRef	Ссылка элемента (смотри раздел 3.5) на компонент Organisation для Кассира при данном платежном протоколе.
PayReqNetLocn	Сетевая позиция, указывающая куда следует послать платежный запрос в отсутствии гарантии безопасности при заданном протоколе.

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

SecPayReqNetLocn

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

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

PackagedContent

Опционные элементы Packaged Content (смотри раздел 3.7), содержащие информацию о протоколе, который используется платежным протоколом. Содержание этой информации определяется в приложении для платежных ппротоколов.

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

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

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

	NMTOKEN #REQUIRED
IotpMsgRef NMTOKEN #IMPLIED	BlkRef NMTOKEN #IMPLIED
CompRef NMTOKEN #IMPLIED	ElementRef NMTOKEN #IMPLIED

AttName NMTOKEN #IMPLIED> Атрибуты:

ElementType	Имя типа элемента, где обнаружена ошибка. Например, если элемент декларирован как
IotpMsgRef	Значение ID-атрибута Id-компонента сообщения (смотри раздел 3.3.2), к которому относится компонент Error.
BlkRef	Если ошибка ассоциирована со специфическим торговым блоком, тогда это значение ID-атрибута торгового блока, где обнаружена ошибка.
CompRef	Если ошибка ассоциирована со специфическим торговым компонентом, тогда это значение ID-атрибута торгового компонента, где обнаружена ошибка.
ElementRef	Если ошибка ассоциирована со специфическим элементом торгового компонента, тогда, если элемент имеет атрибут с типом (смотри [XML]) "ID", тогда это значение данного атрибута.
AttName	Если ошибка ассоциирована со значением атрибута, тогда это имя данного атрибута. В этом случае PackagedContent компонента Error должен содержать значение атрибута.

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

Элемент Protocol Amount

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

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

платежными протоколами и Кассирами, определенными в элементе платежного протокола (смотри раздел 7.7.5), котоый может быть использован для этого видв валюты и сумм платежа. Его определение представлено ниже:
PayProtocolRef IDREF #REQUIREDCurrencyAmountRefs IDREFS #REQUIRED
ContentSoftwareId CDATA #IMPLIED > Атрибуты:

ID	идентификатор элемента, на который может ссылаться элемент Brand; или компонент выбора видов платежа, содержащийся в последующих сообщениях платежного запроса. Он однозначно идентифицирует элемент Protocol Amount для данной транзакции IOTP.
PayProtocolRef	Содержит ссылку элемента (смотри раздел 3.5), которая указывает на элемент платежного протокола (смотри раздел 7.7.5), содержащийплатежный протокол и Кассира, которые могут использоваться для данного вида платежа.
CurrencyAmountRefs	Содержит список ссылок элемента (смотри раздел 3.5), который указывает на элемент Currency Amount (смотри раздел 7.7.4), описывающий вид валюты и сумму, которые могут использоваться для данного вида платежа.
ContentSoftwareId	Смотри раздел 14. Словарь.

Cодержимое:

PackagedContent

Опционные элементы Packaged Content (смотри раздел 3.7), содержащие информацию о протокольной сумме, которая может использоваться платежным протоколом. Содержимое этой информации определено в приложении для платежных протоколов.

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

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

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

ProtocolId

Должен согласовываться со значением атрибута ProtocolId в элементе платежного протокола (смотри раздел 7.7.5).

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

ProtocolBrandId

Это идентификатор вида платежа, который должен использоваться с конкретным платежным протоколом. Например, SET и EMV имеют свои определенные, различные значения для Brand Id, для каждого из протоколов.

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

PackagedContent

Опционные элементы Packaged Content (смотри раздел 3.7), содержащие информацию о протоколе и/или виде платежа, которые может использовать платежный протокол. Содержимое этой информации определяется в приложении для платежных протоколов.

Элемент 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 это не всегда так.

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

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

TradingRole NMTOKEN #REQUIRED	IotpMsgIdPrefix NMTOKEN #REQUIRED
CancelNetLocn CDATA #IMPLIED	ErrorNetLocn CDATA #IMPLIED

ErrorLogNetLocn CDATA #IMPLIED> Атрибуты:

ID	Идентификатор, который однозначно определяет элемент торговая роль в пределах текущей транзакции IOTP.
TradingRole	Торговая роль организации. Возможные значения: o Покупатель. Лицо или организация, которая действует в роли покупателя в данной транзакции. o Продавец. Лицо или организация, которая действует в роли продавца в данной транзакции. o Агент доставки. Лицо или организация, которая доставляет товар или предоставляет услуги в рамках данной транзакции; o DelivTo. Лицо или организация, которая получает товары или услуги в рамках данной транзакции. o CustCare. Лицо или организация, которая обеспечивает обслуживание покупателя в данной транзакции.
IotpMsgIdPrefix	Содержит префикс, который должен быть использован для всех IOTP сообщений, посланных торговой ролью в данной транзакции. Значения, которые следует использовать определены в 3.4.1.
CancelNetLocn	Содержит сетевую позицию, куда покупатель должен обратиться, если он аннулирует транзакцию по какой-либо причине. Атрибут может быть использован торговой ролью для отправки отклика, который более соответствует обстоятельствам конкретной транзакции.

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

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

должен присутствовать, когда TradingRole = Продавец, Кассир или Агент доставки. Содержимое этого атрибута зависит от транспортного механизма.

ErrorNetLocn

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

HardError,

Предупреждение, но Покупатель решает не продолжать транзакцию.

TransientError и транзакция прерывается по таймауту. Этот атрибут:

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

должен присутствовать, когда TradingRole равно Продавец, Кассир или Агент доставки. Содержимое атрибута зависит от транспортного механизма.

ErrorLogNetLocn

Опционно. Содержит сетевую позицию, куда Покупателю следует посылать IOTP сообщения, которые содержат блоки Error с компонентами Error сатрибутом Severity равным:

HardError,

Предупреждение, но Покупатель решает не продолжать транзакцию,

TransientError и транзакция прерывается по таймауту. Этот атрибут:

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

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

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

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

код валюты (и ее тип),

сумму. Один или более таких элементов заключены в каждом компоненте списка видов платежа. Его определение приведено ниже:
CurrCode CDATA #REQUIRED > Атрибуты:

ID	Идентификатор элемента, (Brand Selection), содержащиеся в последующих сообщениях платежного запроса. Он однозначно идентифицирует элемент Currency Amount данной транзакции IOTP.
Amount	Указывает сумму, которая должна быть заплачена. Например $245.35 будет выражено как "245.35". Заметим, что значения меньше наименьшей целой величины вполне допустима. Например одна десятая цента будет записана как "0.001".
CurrCodeType	Указывает CurrCode области. Этот атрибут включен с тем, чтобы была возможность поддержания нестандартных "валют" например “торговых марок” и т.д.. Атрибут может принимать значения:

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

IOTP указывает, что значения CurrCode управляются процедурой, описанной в разделе 12.

CurrCode

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

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

Элементы данных и файлы

Приложение в ICC содержит набор информационных элементов. Терминал может получить доступ к этим элементам после успешного выбора приложения. Информационным элементам присваиваются имена, они имеют определенное описание содержимого, формат и кодирование. Информационный объект состоит из метки (tag), кода длины и значения. Метка однозначно идентифицирует объект в рамках данного приложения. Поле длина определяет число байт в поле значение. Объекты могут объединяться, образуя составные объекты. Определенное число простых или составных объектов могут образовывать записи. Присвоение меток регламентируется документами ISO/IEC 8825 и ISO/IEC 7816. Записи, содержащие информационные объекты, хранятся в файлах ICC. Структура файла и метод доступа зависят от назначения файла. Организация файлов определяется приложениями платежной системы PSA (Payment System Application). Проход к набору PSA в ICC разрешается с помощью выбора среды платежной системы PSE (Payment System Environment). Когда PSE присутствует, файлы, относящиеся к PSA, доступны для терминала через древовидную структуру каталога. Каждая ветвь этого дерева является файлом определения приложения ADF (Application Definition File) или файлом определения каталога DDF (Directory Definition File). ADF является входной точкой одного или нескольких прикладных первичных файлов AEF (Application Elementary File). ADF со стороны терминала воспринимается как файл, содержащий информационные объекты, которые инкапсулированы в FCI (File Control Information). Информационные файлы состоят из последовательности пронумерованных записей. Каждому файлу присваивается короткий идентификатор SFI (принимает значения 1-10), с помощью которого можно обращаться к файлу. Чтение каталога осуществляется с помощью команды READ RECORD. Когда PSE присутствует, ICC поддерживает структуру каталога для списка приложений в пределах PSE (определяется эмитентом карты). Каждому приложению присваивается идентификатор AID (Application Identifier; ISO/IEC 7816-5).
К любому ADF или DDF в карте обращение производится посредством имени DF (Dedicated File). DF для ADF соответствует AID и для данной карты должно быть уникальным. Формат записи каталога PSE показан на рисунке 4.6.4.11.

Метка70

Длина
данных
(L)

Метка
61

Длина элемента 1 каталога

Элемент каталога 1 (ADF или DDF)

…
…
…

Метка
61

Длина элемента N каталога

Элемент каталога N (ADF или DDF)

Рис. 4.6.4.11. Формат записи каталога PSE Содержимое полей элемент каталога характеризуется в таблицах 4.6.4.16 и 4.6.4.17. Таблица 4.6.4.16. Формат элемента каталога DDF

Метка (Tag)	Длина	Значение
9D	5-16	Имя DDF
73	переменная	Шаблон каталога

Таблица 4.6.4.17. Формат элемента каталога ADF

Метка (Tag)	Длина	Значение
0х4F	5-16	Имя ADF (AID)
0х50	1-16	Метка приложения
0х9F12	1-16	Предпочитаемое имя приложения
0х87	1	Индикатор приоритетности приложения
0х73	переменная	Шаблон каталога

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

Элементы OriginatorInfo и RecipientInfo

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

Тип подписи IOTP	Корректная торговая роль
OfferResponse	Продавец
PaymentResponse	Кассир
DeliveryResponse	Агент доставки
AuthenticationRequest	Любая роль
AuthenticationResponse	Любая роль
PingRequest	Любая роль
PingResponse	Любая роль

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

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

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

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

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

Компоненты IOTP (смотри раздел 7).

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

идентификатор:

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

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

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

Коды контролируемые IANA

Для того чтобы гарантировать совместимость, коды, используемые IOTP, нужно поддерживать в контролируемой среде так, что их значения и использование были строго определены, а дублирование кодов должно быть исключено. IANA представляет механизм решения этой проблемы, как это описано в RFC 2434. Типы элементов и имена атрибутов, к которым эта процедура применяется, приведены ниже в таблице вместе с исходными величинами, разрешенными для этих атрибутов. Заметим, что:

торговый подписной лист IETF имеет адрес

"Специальные эксперты (Designated Experts)" (смотри [IANA]) назначаются IESG.

Тип элемента/Имя атрибута	Значения атрибутов
Алгоритм/Имя	"sha1" - указывает, что будет использована аутентификация [SHA1]
(Когда алгоритм является производным от компонента AuthReq)	"Подпись" - указывает, что аутентификация включает в себя генерацию цифровой подписи.
	"Pay:ppp", где "ppp" может быть установлено равным любому допустимому значению для "iotpbrand" (смотри ниже)

За исключением алгоритмов, которые начинаются с "pay:", новые значения выделяются после просмотра торгового почтового списка IETF и с привлечением “специального эксперта”. Элемент Algorithm обычно определяется в пределах пространства имен [DSIG]. Со временем эта процедура может измениться.

Тип элемента/Имя атрибута

Значения атрибутов

Вид платежа/BrandId

Следующий список исходных значений BrandId был получен от организаций, которые сипользуют сертификаты протокола SET с 1-го июня 1999:
"Amex" - American Express
"Dankort" - Dankort
"JCB" - JCB
"Maestro" - Maestro
"MasterCard" - MasterCard
"NICOS" - NICOS
"VISA" - Visa
Кроме того определены следующие значения Id видов платежа:
"Mondex"
"GeldKarte"

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

Валютная сумма/CurrCode

Коды валюты зависят от CurrCodeType (смотри ниже).

Если CurrCodeType = "ISO4217-A", тогда код валюты является буквенным, определенным в [ISO4217]. Если CurrCodeType = "IOTP", тогда новые значения должны быть опубликованы через торговый подписной лист IETF и, если в течение трех недель не поступает возражений, они присваиваются в порядке поступления. Код типа валюты IOTP, сконструирован так, чтобы позволять поддержку "новых" псевдовалют, таких как loyalty или frequent flyer points.
На момент написания этого документа ни один из таких кодов не был лпределен.

Тип элемента/Имя атрибута	Значения атрибута
Валютная сумма/CurrCodeType	"ISO4217A" "IOTP"

Новые значения атрибута CurrCodeType выделяются после публикования через подписной лист IETF и рассмотрения экспертами.

DeliveryData/DelivMethod

"Post"
"Web"
"Email"

Новые значения атрибута Delivery Method выделяются после публикования через подписной лист IETF и рассмотрения экспертами. Это может потребовать публикации дополнительной документации, описывающей как используется данный метод доставки.

PackagedContent/Content

"PCDATA"
"MIME"
"MIME:mimetype" (где mimetype должен быть тем же, что и в content-type, как это определено в [MIME])
"XML"

Если атрибут Content имеет форму "MIME:mimetype", тогда управление новыми значениями для "mimetype" определено в [MIME]. В противном случае, новые значения атрибута Content выделяются после публикования через подписной лист IETF и рассмотрения экспертами. Это может потребовать публикации дополнительной документации, описывающей как используется новый атрибут в элементе Packaged Content.

RelatedTo/RelationshipType

"IotpTransaction"
"Reference"

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

Тип элемента/Имя атрибута

Значения атрибута

Значения Status/StatusType

Значения Предложение
Платеж
Доставка
Аутентификация
Не идентифицировано
Новые значения атрибута Status Type выделяются после:oпубликации в Торговой Рабочей Группе IETF, документа RFC, описывающего торговый обмен, торговые роли и соответствующие компоненты, которые относятся к Status и
oрассмотрения документа в торговом почтовом листе IETF и экспертами.

Документ, описывающий новые значения атрибута Status Type, может быть объединен с документами,описывающими новые торговые роли и типы подписей (смотри ниже).

TradingRole/TradingRole

"Consumer"
"Merchant"
"PaymentHandler"
"DeliveryHandler"
"DelivTo"
oпубликации в Торговой Рабочей Группе IETF, документа RFC, описывающего торговый обмен, торговые роли и соответствующие компоненты, которые относятся к Trading Role и
oрассмотрения документа в торговом почтовом листе IETF и экспертами.

Документ, описывающий новые значения атрибута Trading Role может быть объединен с документами, описывающими новые значения Status Types (смотри выше) и типы подписей (смотри ниже).

Тип элемента/Имя атрибута	Значения атрибута
TransId/IotpTransType	"BaselineAuthentication" "BaselineDeposit" "BaselineRefund" "BaselineWithdrawal" "BaselineValueExchange" "BaselineInquiry" "BaselinePing" Новые значения атрибута IotpTransType выделяются после: oпубликации через почтовый список IETF, в виде документа RFC, описывающего новую транзакцию IOTP и oрассмотрения документа в почтовом списке торговой рабочей группы IETF и экспертами.
Attribute/Content (смотри компонент Signature)	"OfferResponse" "PaymentResponse" "DeliveryResponse" "AuthenticationRequest" "AuthenticationResponse" "PingRequest" "PingResponse" Новые значения кода, которые описывают тип подписи выделяются после: oпубликации в Торговой Рабочей Группе IETF документа RFC, описывающего торговый обмен, где используются подписи и oрассмотрения документа в торговом почтовом листе IETF и экспертами.

Документ, описывающий новые значения типа подписи, может быть объединен с документами, описывающими новые типы Status и торговые роли (смотри выше).

Коды, неконтролируемые IANA

Помимо формального выбора и регистрации кодов, как это описано выше, для разработчиков существует необходимость экспериментировать с новыми кодами IOTP. По этой причине могут использоваться "коды определенные пользователем", что не требует регистрациив IANA. Определение кода, задаваемого пользователем, выглядит следующим образом: user_defined_code ::= ( "x-" | "X-" ) NameChar (NameChar)*

NameChar

NameChar имеет то же определение, что и [XML] определение NameChar.

Рекомендуется использование имен доменов (смотри [DNS]), для того чтобы сделать коды, определенные пользователем, уникальными, хотя этот метод и не является совершенно надежным.

Коды ошибок

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

Значение	Описание
Reserved	Reserved. Эта ошибка зарезервирована поставщиком/разработчиком программы. Контактируйте, если требуется, с поставщиком/разработчиком программы. Смотри ID-атрибут Software Id-элемента сообщения в блоке ссылок транзакции (раздел 3.3).
XmlNotWellFrmd	XML плохо сформирован. Документ XML плохо сформатирован. Смотри [XML]Ю, для того чтобы понять, что значит "хорошо сформатирован". Даже если XML сформатирован плохо, он должен быть просмотрен, найден блок ссылок транзакции, с тем чтобы было можно правильно сформировать отклик Error.
XmlNotValid	XML некорректен. Документ XML сформатирован хорошо, но он некорректен. Для того чтобы понять, что значит "корректен" смотри [XML], в частности:o документ XML не следует регламентациям, определенным декларацией типов документов IOTP (DTD)(смотри раздел 13) и o документ XML не следует регламентациям, определенным расширениям декларации типов документов [XML Namespace].

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

ElUnexpected		Нестандартный элемент. Несмотря на то что документ XML сформирован правильно и корректен, присутствует элемент, который не является стандартным для данного контекста согласно правил и ограничениям, содержащимся в данной спецификации.
ElNotSupp		Элемент не поддерживается. Несмотря на то что документ XML сформирован правильно и корректен, присутствует элемент, который: o согласуется с правилами и ограничениями данной спецификации, но o не поддерживается приложением IOTP, которое обрабатывает IOTP-сообщение.
ElMissing	Элемент отстутствует. Несмотря на то что документ XML сформирован правильно и корректен, отсутствует элемент, который должен присутствовать, если следовать правилам и ограничениям данной спецификации.

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

ElContIllegal	Содержимое элемента не верно. Несмотря на то что документ XML сформирован правильно и корректен, элемент Content содержит значения, которые не согласуются с правилами и ограничениями данной спецификации.
EncapProtErr	Ошибка инкапсулированного протокола. Несмотря на то что документ XML сформирован правильно и корректен, PackagedContent элемента содержит данные инкапсулированного протокола, которые неверны.
AttUnexpected	Нестандартный атрибут. Несмотря на то что документ XML сформирован правильно и корректен, присутствие такого атрибута в данном контексте не предусмотрено и не согласуются с правилами и ограничениями данной спецификации.
AttNotSupp	Атрибут не поддерживается. Несмотря на то что документ XML сформирован правильно и корректен, и приутствие атрибута элемента согласуется с правилами и ограничениями данной спецификации, он не поддерживается конкретной программной реализацией, которая обрабатывает сообщение IOTP.
AttMissing	Атрибут отсутствует. Несмотря на то что документ сформирован правильно и корректен, отсутствует атрибут, который согласно правилам и ограничениям данной спецификации должен присутствовать.

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

AttValIllegal	Не верно значение атрибута. Атрибут содержит значение, которое не согласуется с правилами и ограничениями данной спецификации.
AttValNotRecog	Значение атрибута не распознано. Атрибут содержит значение, которое приложение IOTP, обрабатывающее сообщение, не смогло распознать.
MsgTooLarge	Сообщение имеет слишком больую длину. Сообщение слишком велико для приложения, его обрабатывающего.
ElTooLarge	Элемент слишком велик. Элемент слишком велик для приложения, его обрабатывающего.
ValueTooSmall	Значение слишком мало. Значение всего или части элемента Content или атрибута, хотя и верно, но слишком мало.
ValueTooLarge	Значение слишком велико. Значение всего или части элемента Content или атрибута, хотя и верно, но слишком велико.
ElInconsistent	Элемент не согласован. Несмотря на то что документ сформирован правильно и корректен, согласно правилам и ограничениям данной спецификации: о содержимое элемента не согласуется с содержимым других элементовили их атрибутов или о значение атрибута не согласуется со значением одного или нескольких других атрибутов.

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

TransportError	Транспортная ошибка (Transport Error). Этот код ошибки используется для индикации проблем с транспортным механизмом, которые приводят к потере сообщения. Она обычно ассоциируется с переходной ошибкой. Объяснение переходной ошибки содержится с атрибуте ErrorDesc. Значения, которые могут использоваться в ErrorDesc с TransportError специфицированы в приложении IOTP для транспортного механизма.
MsgBeingProc	Сообщение обрабатывается (Message Being Processed). Этот код ошибки используется только с серьезностью (Severity) переходных ошибок. Код указывает, что предыдущее сообщение обрабатывается и, если в орговоренное время, заданное атрибутом MinRetrySecs, не получено отклика, оригинальное сообщение следует послать вновь.
SystemBusy	Система занята (System Busy). Этот код ошибки используется только с серьезностью (Severity) переходных ошибок. Он указывает, что сервер, который получил сообщение, в настоящее время занят и обработать сообщение не может. Если в орговоренное время, заданное атрибутом MinRetrySecs, не получено отклика, оригинальное сообщение следует послать вновь.

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

UnknownError

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

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

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

Значение	Описание
AutEeCancel	Аннулировано аутентифицируемым (Authenticatee Cancel). Организация по какой-то причине отказывается от аутентификации. Это может быть, например, потому что подпись аутентификационного запроса оказалась некорректной или аутентификатор оказался неизвестным или неприемлемым. Восстановление невозможно.
AutOrCancel	Аннулировано аутентификатором (Authenticator Cancel). Организация, запросившая аутентификацию по каким-то причинам отказывается проверять полученный аутентификационный отклик и аннулирует транзакцию. Восстановление невозможно.
NoAuthReq	Запрос аутентификации не возможен (Authentication Request Not Available). Аутентифицирующийся субъект не имеет данных, которые должны быть предоставлены. Например, забыт пароль или субъект не авторизован. Восстановление невозможно.
AuthFailed	Аутентификация не прошла (Authentication Failed). Аутентификатор проверил аутентификационный отклик, но эта проверка по какой-то причине не прошла. Например, оказался неправильным пароль. Восстановление может быть возможно аутентифицируемым путем повторной посылки отклика аутентификации с корректными данными.
TradRolesIncon	Торговые роли несоместимы (Trading Roles Inconsisten). Торговые роли, содержащиеся в атрибуте TradingRoleList компонента информационного запроса торговых ролей (смотри раздел 7.4) не согласуются с торговой ролью, которую аутентифицируемый играет в данной транзакции IOTP. Примеры несогласованности включают в себя: о запрос Кассира информации об Агенте доставки; о запрос Покупателя информации о Продавце.Восстановление может выполнить аутентификатор путем повторной посылки блока аутентификационного запроса с поправленной информацией.
Unspecified	Неспецифицированная ошибка (Unspecified error). Имеет место какая-то неизвестная проблема или ошибка, которая не совпадает ни с одним из кодов CompletionCodes. Восстановление невозможно.
TimedOutRcvr	Восстановимый таймаут (Recoverable Time Out). Сообщения были повторно посланы, но отклика не получено. Документальный обмен прерван по таймауту. Этот код приемлем при транзакции информационного запроса. Восстановление возможно, если последнее сообщение от другой торговой роли получено вновь.
TimedOutNoRcvr	Невосстановимый таймаут (Non Recoverable Time Out). Сообщения были повторно посланы, но отклика не получено. Документальный обмен прерван по таймауту. Этот код приемлем при транзакции информационного запроса. Восстановление невозможно.

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

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

Значение	Описание
BackOrdered	Back Ordered. Товары, подлежащие доставке, ожидают длставки, но еще не доставлены. Доставка будет оформлена, когда товар будет получен. Это справедливо, если ProcessState = CompletedOk. Восстановление невозможно.
PermNotAvail	Постоянно не доступен (Permanently Not Available). Товары не доступны и не могут быть перезаказаны. Это справедливо, если ProcessState = Failed. Восстановление не возможно.
TempNotAvail	Временно не доступен. Товары временно не доступны и могут быть получены при повторном заказе. Это возможно, если ProcessState = CompletedOk. Восстановление невозможно.
ShipPending	Задержка доставки. Товары доступны и запланированы к доставке, но еще не доставлены. Это возможно, если ProcessState = CompletedOk. Восстановление невозможно.
Shipped	Товары доставлены (Goods Shipped). Товар уже доставлен. Ожидается подтверждение доставки. Это возможно, если ProcessState = CompletedOk. Восстановление невозможно.
ShippedNoConf	Доставлен - никакого подтверждения доставки (Shipped - No Delivery Confirmation). Товары были доставлены, но их доставку невозможно подтвердить. Это возможно, если ProcessState = CompletedOk. Восстановление невозможно.
ConsCancelled	Аннулировано Покупателем (Consumer Cancelled). Покупатель по какой-то причине решает аннулировать доставку. Этот код допустим только в компоненте Status, содержащимся в блоках Cancel или информационного отклика. Восстановление невозможно.
DelivCancelled	Доставка аннулирована (Delivery Cancelled). Агент доставки по какой-то причине отказался завершить процедуру доставки и аннулировал транзакцию. Этот код допустим только в компоненте Status, содержащимся в блоках Cancel или информационного отклика. Восстановление невозможно.
Confirmed	Подтверждено (Confirmed). Все товары были доставлены и получено подтверждение их доставки. Это возможно, если ProcessState = CompletedOk. Восстановление невозможно.
Unspecified	Неспецифицированная ошибка (Unspecified error). Имеет место какая-то неизвестная проблема или ошибка, которая не совпадает ни с одним из кодов CompletionCodes. Атрибут StatusDesc должен прояснить причину. Восстановление невозможно.
TimedOutRcvr	Восстановимый таймаут (Recoverable Time Out). Сообщения были повторно посланы, но отклика не получено. Документальный обмен прерван по таймауту. Этот код приемлем при транзакции информационного запроса. Восстановление возможно, если последнее сообщение от другой торговой роли получено вновь.
TimedOutNoRcvr	Невосстановимый таймаут (Non Recoverable Time Out). Сообщения были повторно посланы, но отклика не получено. Документальный обмен прерван по таймауту. Этот код приемлем при транзакции информационного запроса. Восстановление невозможно.

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

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

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

Значение	Описание
UnAuthReq	Неавторизованный запрос (Unauthorised Request). Получатель запроса состояния транзакции отказывается откликаться на запрос.

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

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

Значение	Описание
BrandNotSupp	Вид платежа не поддерживается Кассиром.

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

CurrNotSupp

Валюта не поддерживается. Валюта, в которой выполнен платеж, не поддерживается платежным инструментом или кассиром.

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

ConsCancelled	Отмена Покупателем (Consumer Cancelled). Покупатель по какой-либо причине решил аннулировать платеж. Этот код является единственно верным в компоненте Status, содержащимся в блоках Cancel или информационного отклика. Восстановление невозможно.
PaymtCancelled	Платеж аннулирован (Payment Cancelled). Кассир по каким-то причинам не хочет завершить платежную операцию и аннулирует транзакцию. Этот код является единственно верным в компоненте Status, содержащегося в блоках Cancel или информационного отклика. Опции восстановления смотри ниже.
AuthError	Ошибка аутентификации. Аутентификационная проверка платежной схемы не прошла. Восстановление возможно. Чтобы определить, что допустимо, смотри приложение по платежным схемам.
InsuffFunds	Нехватает средств. Средств для осуществления платежа недостаточно. Опции восстановления смотри ниже.
InstBrandInvalid	Платежный инструмент не приемлем для данного вида платежа. Использован платежный инструмент, который не соответствует выбранному виду платжа. Например, использована кредитная карта Visa, хотя в качестве вида платежа была выбрана MasterCard. Опции восстановления смотри ниже.
InstNotValid	Платежный инструмент не приемлем для сделки. Платежный инструмент по каким-то причинам не может быть использован для предлагаемого вида сделки. Опции восстановления смотри ниже.
BadInstrument	Плохой инструмент. Имеется проблема с использованным платежным инструментом, что означает, что он не может быть применен для платежа. Опции восстановления смотри ниже.
Unspecified	Неспецифицированная ошибка. Имеет место какая-то неизвестная проблема или ошибка, которая не совпадает ни с одним из кодов CompletionCodes. Атрибут StatusDesc должен предоставить объяснение причины. Опции восстановления смотри ниже.
TimedOutRcvr	Восстановимый таймаут (Recoverable Time Out). Сообщения были повторно посланы, но отклика не получено. Документальный обмен прерван по таймауту. Этот код приемлем при транзакции информационного запроса. Восстановление возможно, если последнее сообщение другой торговой роли получено снова.
TimedOutNoRcvr	Невосстановимый таймаут. Сообщения были повторно посланы, но отклика не получено. Документальный обмен прерван по таймауту. Этот код приемлем при транзакции информационного запроса. Восстановление невозможно.

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

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

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

Значение	Описание
AuthError	Ошибка аутентификации. Проверка отклика аутентификации не прошла.

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

ConsCancelled	Прервано покупателем (Consumer Cancelled). Покупатель по каким-то причинам решает прервать транзакцию. Это код является единственно верным в компоненте Status, содержащимся в блоках Cancel или информационного отклика. Восстановление невозможно.
MerchCancelled	Предложение аннулировано (Offer Cancelled). Продавец по каким-то причинам аннулирует свое предложение и прерывает транзакцию. Этот код является единственно верным в компоненте Status, содержащимся в блоках Cancel или информационного отклика. Восстановление невозможно.
Unspecified	Неспецифицированная ошибка. Возникла какая-то неизвестная проблема или ошибка, которая не соответствует ни однму из кодов CompletionCodes. Восстановление невозможно.
TimedOutRcvr	Восстановимый таймаут (Recoverable Time Out). Сообщения были посланы, а откликов не получено. Документальный обмен прерван таймаутом. Этот код допустим в случае информационного запроса транзакции.

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

TimedOutNoRcvr

Невосстановимый таймаут (Non Recoverable Time Out). Сообщения были посланы повторно, а откликов не получено. Документальный обмен прерван таймаутом. Этот код допустим в случае информационного запроса транзакции. Восстановление невозможно.

Команды

Команды всегда инициируются прикладным уровнем терминала TAL (Terminal Application Layer), который посылает инструкции ICC через транспортный уровень TTL (Terminal Transport Layer). Команда содержит последовательность из 5 байт: CLA, INS, P1, P2 и P3.

Имя байта	Назначение
CLA	Класс команды (1 байт).
INS	Код инструкции (1 байт).
P1 и P2	Cодержат дополнительные специфические параметры (по 1 байту).
Р3	Указывает либо длину посылаемых в команде данных, либо максимальную длину данных, которые должны быть присланы в отклике от ICC (зависит от кода INS).

Эти 5 байт вместе с байтами данных образуют командный блок протокольной информации C-TPDU для Т=0. Получив команду, ICC откликается отправкой процедурного или статусных байтов. Процедурный байт указывает TTL, какая операция является следующей. Отклик терминала на процедурный байт представлен в таблице 4.6.4.10. Таблица 4.6.4.10. Отклик терминала на процедурный байт

Значение процедурного байта	Действие терминала
Байт равен INS	Все остальные байты данных будут переданы TTL, или TTL будет готов принять все остальные байты от ICC
Байт равен дополнению INS	Следующий байт данных будет передан TTL или TTL будет готов принять следующий байт от ICC
60	TTL введет дополнительное время выдержки (Work Waiting Time)
61	TTL будет ждать следующий процедурный байт, затем пошлет ICC команду GET RESPONSE с максимальной длиной "xx", где хх равно значению второго процедурного байта
6C	TTL будет ждать следующий процедурный байт, после чего немедленно повторно пошлет ICC предыдущий командный заголовок, используя длину "xx", где хх равно значению второго процедурного байта

Во всех случаях после реализации операции TTL ждет прихода процедурного байта или статусного сообщения. Командное сообщение, посылаемое от прикладного уровня, и сообщение-отклик ICC называются APDU (Application Protocol Data Unit). Формат APDU показан на рисунке 4.6.4.8.

Рис. 4.6.4.8. Структура командного APDU. Все поля заголовка имеют по одному байту.
Поле данных содержит Lc байт.

Lc	Число байт в поле данные (0 или 1 байт)
Le	Максимальное число байт в поле данных отклика (0 или 1 байт)

Если параметры Р1 и Р2 не используются, коды полей должны равняться 00. Формат отклика APDU аналогичен показанному на 4.6.4.8. Поле данных имеет переменную длину и, вообще говоря, может отсутствовать. Однобайтовые поля SW1 и SW2 должны присутствовать обязательно. SW1 характеризует состояние обработки команды, а SW2 - является квалификатором обработки команды. Кодировка команд для полей CLA и INS представлена в таблице 4.6.4.11. Таблица 4.6.4.11. Кодирование командного байта

CLA	INS	Назначение
8х	1Е	APPLICATION BLOCK (Заблокировать приложение)
8х	18	APPLICATION UNBLOCK (Разблокировать приложение)
8х	16	CARD BLOCK (Заблокировать карту)
0х	82	EXTERNAL AUTHENTICATE (Внешняя аутентификация)
8х	АЕ	GENERATE APPLICATION CRYPTOGRAM (Сформировать прикладную криптограмму)
0х	84	GET CHALLENGE (Получить вызов)
8х	СА	GET DATA (Получить данные)
8х	А8	GET PROCESSING OPTIONS (Получить опции обработки)
0х	88	INTERNAL AUTHENTICATE (Внутренняя аутентификация)
8х	24	PERSONAL IDENTIFICATION NUMBER (PIN) CHANGE/UNBLOCK - изменение/разблокировка персонального идентификатора
0х	В2	READ RECORD (Прочесть запись)
0х	А4	SELECT (Выбор)
0х	20	VERIFY (Проверка)
8х	Dx	RFU для платежных систем
8х	Ex	RFU для платежных систем
9х	Xx	RFU производителя для кодирования INS собственника
Ех	xx	RFU эмитента для кодирования INS собственника

Статусные байты SW1 и SW2 указывают TTL, что обработка команды завершена. Значения этих байт интерпретируются в зависимости от обрабатываемой команды. Коды и значения полей SW1 и SW2 представлены в таблице 4.6.4.12. Таблица 4.6.4.12. Кодирование статусных байтов SW1, SW2

SW1	SW2	Значение
90	00	Нормальная обработка Процесс завершился успешно
62 63 63	83 00 Сх	Обработка с предупреждением Состояние постоянной памяти не изменилось; выбранный файл некорректен Состояние постоянной памяти изменилось; аутентификация не прошла Состояние постоянной памяти изменилось; счетчик задан "x" (0-15)
69 69 69 6А 6А 6А	83 84 85 81 82 83	Контроль ошибок Команда не разрешена; метод аутентификации блокирован Команда не разрешена; запрошенные данные некорректны Команда не разрешена; условия использования не выполнены Неверные параметры Р1 Р2; функция не поддерживается Неверные параметры Р1 Р2; файл не найден Неверные параметры Р1 Р2; запись не найдена

Таблица 4.6.4.12А. Сводные данные по командам/откликам

Команда	CLA	INS	P1	P2	Lc	Данные	Le
APPLICATION BLOCK	8C/84	1E	00	00	Число байт данных	Код аутенти-фикации сообщения (MAC)	-
APPLICATION UNBLOCK	8C/84	18	00	00	Число байт данных	Компонент MAC	-
CARD BLOCK	8C/84	16	00	00	Число байт данных	Компонент MAC	-
EXTERNAL AUTHENTICATE	00	82	00	00	8-16	Issue Authentication Data	-
GENERATE APPLICATION CRYPTOGRAM	80	AE	Парам. ссылки	00	Перемен.	Данные транзакции	00
GET DATA	80	CA	9F369F139F17	9F369F139F17	-	-	00
GET PROCESSING OPTIONS	80	A8	00	00	Перемен.	Processing Option Data Object List (PDOL)	00
INTERNAL AUTHENTICATE	00	88	00	00	Длина аутент. данных	Аутентиф. данные	00
PIN CHANGE/UNBLOCK	8C/84	24	00	00, 01 или 02	Число байт данных	PIN данные	-
READ RECORD	00	B2	Номер записи	Парам.ссылки	-	-	00
SELECT	00	A4	Парам. ссылки	Опции выбора	05-10	Имя файла	00
VERIFY	00	20	00	Квали-фикатор	Перемен	PIN данные транзакции	-
GET CHALLENGE	00	84	00	00	-	-	00

Блочный протокол Т=1 предполагает передачу блоков данных между TAL (Terminal Application Layer) и ICC. Эти блоки несут в себе команды, R-APDU (Response Application Protocol Data Unit) и управляющую информацию. Структура блока показана на рисунке 4.6.4.10. Поля заголовка и эпилога (хвостовика) являются обязательными. Биты b1-b3 NAD указывают на адрес отправителя (SAD), а b5-b7 - адрес получателя (DAD). В настоящее время адресация узлов не поддерживается и по этой причине в поле NAD следует записывать код 00. Биты b4 и b8 равны нулю. Код PCB определяет тип блока. Существует три типа блоков: информационные (I-блок), готовности приема (R-блок, подтверждение) и управляющие (S-блок).

Заголовок (Prologue)			Данные	Эпилог
Адрес узла (NAD)	Управляющий протокольный байт (PCB)	Длина (LEN)	APDU или управляющая информация (INF)	EDC (код детектирования ошибки)
1 байт	1 байт	1 байт	0-254 байта	1 байт

Рис. 4.6.4.9. Структура блока Кодирование PCB зависит от его типа, оно представлено в таблицах 4.6.4.13-15. Таблица 4.6.4.13. Кодирование PCB I-блоков

b8	0
b7	Номер по порядку
b6	Цепочка (есть еще данные)
b5-b1	Зарезервировано на будущее

Таблица 4.6.4.14.

Кодирование PCB R-блоков

b8	1
b7	0
b6	0
b5	Номер по порядку
b4-b1	0 - Отсутствие ошибки 1 - EDC и/или ошибка четности 2 - другие ошибки остальные коды зарезервированы

Таблица 4.6.4.15. Кодирование PCB S-блоков

b8	1
b7	1
b6	0 - запрос 1 - отклик
b5-b1	0 - запрос повторной синхронизации 1 - запрос размера поля данных 2 - запрос абортирования 3 - расширение BWT-запроса 4 - VPP-ошибка остальные коды зарезервированы

Поле LEN определяет размер информационного поля и может равняться 0-254. R-блоки не имеют поля данных. Блоки I- и S-типов нумеруются по модулю 2, их число может равняться 0 или 1 (первый блок имеет номер 0). Счетчик нумерации сбрасывается в 0 после ресинхронизации. Поле EDC представляет собой объединение всех байт блока, начиная с NAD и кончая последним байтом поля INF (если это поле присутствует), с помощью операции исключающее ИЛИ. Максимальный размер поля данных ICC (IFSC) блока определяется параметром ТА3, присылаемым ICC в отклике на сброс. IFSI может принимать значения 10-FE, что означает для IFSC диапазон 16-254 байта. Максимальный размер поля данных терминала (IFSD) составляет 254 байта. Время ожидания блока BWT (Block Waiting Time) в общем случае вычисляется согласно следующей формуле. Реально BWT может лежать в диапазоне (971-15371)t.

Когда отправитель намерен передать объем данных больше, чем это определено параметрами IFSC или IFSD, он должен разбить эту последовательность байтов на несколько I-блоков. Передача этих блоков осуществляется с привлечением механизма цепочек. Для объединения I-блоков в цепочку используется бит b6 в PCB (смотри табл. 4.6.4.13). Если b6=0, то это последний блок в цепочке. Если же b6=1, далее следует как минимум еще один блок. Получение любого I-блок с b6=1 должно быть подтверждено R-блоком. Последний блок цепочки, посланный терминалом, подтверждается I-блоком, если получен безошибочно, или R-блоком, при обнаружении ошибки. В случае ICC получение последнего блока цепочки подтверждается R-блоком при обнаружении ошибки.Если ошибки не было, терминал просто посылает очередной I-блок, если должна обрабатываться очередная команда. Передача цепочки возможна в одно и тоже время только в одном направлении. Когда терминал является получателем, он воспринимает цепочки I-блоков, передаваемых ICC, если длина блоков ? IFSD. Если получателем является ICC, карта воспринимает цепочку I-блоков, посланных терминалом и имеющих длину LEN=IFSC, за исключением последнего блока, длина которого может лежать в диапазоне (1-IFSC). Если длина блока > IFSC, ICC такой блок отвергает, послав R-блок с битами b4-b1 в PCB, равными 2.

Комбинирование аутентификации с другими транзакциями

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

Покупателем, чтобы аутентифицировать продавца, кассира или агента доставки или

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

торговая роль, которая решает выполнить аутентификацию другой торговой роли, откладывает выполнение текущей транзакции;

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

если транзакция аутентификации успешна essful, осходная транзакция возобновляется;

если аутентификация не прошла, тогда исходная аутентификация аннулируется. Покупатель, например, может:

аутентифицировать кассира для платежа в период между получением отклика Offer от продавца и до посылки платежного запроса кассиру;

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

Компоент Payment Note

Компонент Payment Note (платежное заывление) содержит дополнительную, несвязанную с платежом информацию, которую Кассир хочет предоставит покупателю. Например, если был произведен отзыв сделки или осуществлен депозит, тогда он может содержать информацию о балансе по завершении перевода. Данные должны дублировать информацию, содержащуюся в компоненте платежной расписки. Информация, содержащаяся в компоненте Payment Note должна быть отображена или представлена каким-то иным способом покупателю. Для совместимости компонент Payment Note должен поддерживать как минимум содержимое типа "Plain Text", HTML и XML. Его определение представлено ниже. PaymentNote (PackagedContent+) >
PaymentNote ID ID #REQUIREDContentSoftwareId CDATA #IMPLIED> Атрибуты:

ID	Идентификатор, который однозначно определяет компонент платежной расписки транзакции IOTP.
ContentSoftwareId	Смотри раздел 14. Словарь.

Cодержимое:

PackagedContent

Содержит дополнительную, не связанную с платежом информацию, которую кассир хочет довести до сведения покупателя в виде одного или более элементов Packaged Content (смотри раздел 3.7).

Компонент Certificate

Определения структур XML для подписей и сертификатов описаны в работе "Digital Signatures for the Internet Open Trading Protocol", смотри [IOTPDSIG]. Смотри также начало раздела 7.19. Компонент Certificate содержит цифровой сертификат. Они используются только, когда, например, использована асиметричная криптография и верифицирующий получатель подписи не получил еще общедоступного ключа (Public Key). Структура сертификата определена в [IOTPDSIG].

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

Компонент данных торговой роли содержит данные, которые должны быть пересланы между торговыми ролями вовлеченными в транзакцию. Компоненты торговой роли определяют: o организацию, которая сформировала компонент и
o организацию, которая его получила. Они являются первыми сформированными и включенными в блок “отклик” и затем скопированных в соответствующий блок “запрос”. Например, кассиру может оказаться нужно проинформировать агента доставки о том, что платеж через кредитную карточку авторизован (but not captured). В другом примере продавцу может понадобиться предоставить кассиру некоторую специфическую информацию о Покупателе. Его определение представлено ниже. TradingRoleData (PackagedContent+) >
TradingRoleData ID ID #REQUIRED
OriginatorElRef NMTOKEN #REQUIREDDestinationElRefs NMTOKENS #REQUIRED> Атрибуты:

ID	Идентификатор, который однозначно определяет компонент данных торговой роли транзакции IOTP.
OrginatorElRef	Содержит ссылку элемента на компонент Organisation организации, которая создала компонент данных о торговой роли и включила его в блок отклика (напр., блок отклика предложения или платежа).
DestinationElRefs	Содержит ссылку элемента на компоненты Organisation организации, которая получила компонент данных о торговой роли в блоке запроса (напр., блоков запроса платежа или доставки).

Cодержимое:

PackagedContent

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

Компонент Delivery Note

Компонент Delivery Note (накладная)содержит инструкции о доставке товаров или услу, или саму информацию о доставке. Это информация, которую частное лицо или организация, получающие накладную, могут использовать, когда осуществляется доставка. Для совместимости компонент Delivery Note должен поддерживать Plain Text, HTML и XML. Его определение представлено ниже. DeliveryNote (PackagedContent+) >

DeliveryNote ID ID #REQUIRED	xml:lang NMTOKEN #REQUIRED
DelivHandlerDelivId CDATA #IMPLIED	ContentSoftwareId CDATA #IMPLIED>

Атрибуты:

ID	Идентификатор, который однозначно определяет компонент Delivery Note транзакции IOTP.
xml:lang	Определяет язык, используемый атрибутами или дочерними элементами в рамках данного компонента, если только его значение не будет переписано атрибутом xml:lang дочернего элемента. Смотри раздел 3.8.
DelivHandlerDelivId	Опционный идентификатор, специфицированный Агентом доставки, который в случае возвращения Покупателем в другом компоненте доставки или каким-либо другим способом, позволяет Агенту доставки определить, о какой доставке идет речь. Он необходим для любого компонента доставки, вне зависимости от того содержится ли от в блоке запроса доставки.

ContentSoftwareId

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

Cодержимое:

PackagedContent

Содержит информацию декларации доставки (delivery note) в виде одного или нескольких элементов Packaged Content (смотри раздел 3.7).

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

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

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

xml:lang NMTOKEN #REQUIRED	DelivExch (True \| False) #REQUIRED
DelivAndPayResp (True \| False) #REQUIRED	ActionOrgRef NMTOKEN #IMPLIED>

Атрибуты:

ID	Идентификатор, который однозначно определяет компонент доставки транзакции.
xml:lang	Определяет язык, используемый атрибутами и дочерними элементами этого компонента, если только атрибут дочернего элемента xml:lang не перепишет это значение. Смотри раздел 3.8.
DelivExch	Индицирует факт наличия в транзакции сообщений, ассоциированных с обменом доставки. Корректные значения: о“Истинно” указывает на наличие обмена доставки. o“Ложно” указывает на отсутствие обмена доставки.

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

DelivAndPayResp

Индицирует то, чтоблок отклика доставки (смотри раздел 8.11) и блок отклика плптежа (смотри раздел 8.9) находся в одном и том же сообщении IOTP. Корректные значения: o “Истинно” указывает, что оба блока находятся в одном и том же сообщении IOTP и
o “Ложно” указывает, что каждый блок размещен в разных сообщениях IOTP.

Атрибут DelivAndPayResp не должен иметь значение “истинно”, если DelivExch = “ложно”. На практике комбинирование блока отклика доставкии блока отклика платежа имеет смысл только в случае, когда Продавец, Кассир и Агент доставки принадлежат одной организации, так как: о Кассир должен иметь доступ к информации компонента Order, с тем чтобы знать что надо доставлять и
o Кассир должен должен быть способен осуществить доставку.

ActionOrgRef

Ссылка элемента на компонент организации Агента доставки.

Cодержимое:

DeliveryData	Содержит подробности того, как будет осуществляться доставка. Смотри 7.13.1.
PackagedContent	Содержит данные "пользователя", определенные для продавца и необходимые агенту доставки в виде одного или нескольких элементов Packaged Content. Смотри раздел 3.7.

Компонент Error

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

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

сообщение, уведомляющее об ошибке. Сообщение IOTP, которое содержит компонент Error, который описывает ошибку, обнаруженную в сообщении. Определение компонента Error представлено ниже.
xml:lang NMTOKEN #REQUIREDErrorCode NMTOKEN #REQUIRED
ErrorDesc CDATA #REQUIRED Severity (Warning|TransientError|HardError) #REQUIRED

MinRetrySecs CDATA #IMPLIED

SwVendorErrorRef CDATA #IMPLIED>

Атрибуты:

ID	Идентификатор, который однозначно определяет компонент Error транзакции IOTP.
xml:lang	Определяет язык, используемый атрибутами или дочерними элементами компонента, если только значение не переписано атрибутом xml:lang дочернего элемента. Смотри раздел 3.8.
ErrorCode	Содержит код ошибки, который указывает на природу ошибки в сообщении. Допустимые значения ErrorCode приведены в секции 7.21.2.
ErrorDesc	Содержит текстовое описание ошибки на языке, заданном xml:lang. Содержимое этого атрибута определено поставщиком/разработчиком программного обеспечения, которое сгенерировало компонент Error.
Severity	Определяет степень (severity) ошибки. Допустимы следующие значения:о Warning. Индицирует, что хотя имеется ошибочное сообщение, транзакция может продолжаться.о TransientError. Индицирует, что ошибка в сообщении может быть исправлена, если ошибочное сообщение, на которое указывает элемент ErrorLocation, послать повторно.o HardError.Индицирует, что в сообщении имеется неустранимая ошибка, трпнзакция IOTP должна быть остановлена.
MinRetrySecs	Этот атрибут должен присутствовать, если Severity равен TransientError. Он равен минимальному числу полных секунд, которое приложение IOTP, получившее сообщение об ошибке, должно подождать прежде чем переадресовать сообщение, идентифицированное элементом ErrorLocation.

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

SwVendorErrorRef

Этот атрибут является ссылкой, чье значение установлено поставщиком/разработчиком программы, которая сформировала компонент Error. Он должен содержать данные, которые позволяют поставщику идентифицировать точную позицию в его прогрпмме и установить причины, которые вызвали сообщение об ошибке. Смотри также атрибут SoftwareID Id-элемента сообщения в блоке ссылки транзакции (раздел 3.3).

Cодержимое:

ErrorLocation

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

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

PackagedContent

Содержит дополнительные данные, которые могут использоваться для понимания ошибки. Его содержимое может варьироваться в зависимости от природы ошибки (смотри раздел 7.21.2) и ои поставщика/разработчика приложения IOTP. Определение f PackagedContent смотри в разделе 3.7.

Компонент Organisation

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

описать продавца, который продает товары,

идентифицировать того, кто осуществляет покупку,

идентифицировать того, кто будет доставлять товары,

обеспечивать облуживание покупателя,

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

xml:lang NMTOKEN #REQUIRED	OrgId CDATA #REQUIRED
LegalName CDATA #IMPLIED	ShortDesc CDATA #IMPLIED

LogoNetLocn CDATA #IMPLIED > Атрибуты:

ID	Идентификатор, который однозначно определяет компонент Organisation в пределах текущей транзакции IOTP.
xml:lang	Определяет язык, использованный атрибутами или дочерними элементами в пределах данного компонента, если только его значение не было изменено с помощью атрибута xml:lang дочернего элемента. Смотри раздел 3.8.
OrgId	Код, который идентифицирует организацию, описанную компонентом Organisation. Смотри 7.6.1.
LegalName	Для организаций, которые являются коммерческими компаниями, это их легальное название на языке, определенном атрибутом xml:lang. Это необходимо для организаций, чьими торговыми ролями не являются Покупатель или DelivTo.
ShortDesc	Краткое описание организации на языке, определенном атрибутом xml:lang. Это обычно имя, под которым известна организация. Например, если легальное название было "Blue Meadows Financial Services Inc.", тогда его короткое имя может быть "Blue Meadows".

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

LogoNetLocn

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

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

TradingRole	Смотри 7.6.2. Элемент торговой роли.
ContactInfo	Смотри 7.6.3. Элемент контактной информации.
PersonName	Смотри 7.6.4. Персональное имя.
PostalAddress	Смотри 7.6.5. Почтовый адрес.

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

Компонент отклика аутентификации содержит результаты аутентификационного запроса. Используется алгоритм, содержащийся в компоненте запроса аутентификации (смотри раздел 7.2) и выборанный из блока запроса аутентификации (смотри раздел 8.4). В зависимости от выбранного алгоритма, результаты его применения будут содержаться в компоненте подписи, которая подтверждает отклик аутентификации, или в элементах Packaged Content компонента отклика аутентификации. Его определение представлено ниже.
AuthenticationId CDATA #REQUIREDSelectedAlgorithmRef NMTOKEN #REQUIRED
ContentSoftwareId CDATA #IMPLIED > Атрибуты:

ID	Идентификатор, который для данной транзакции однозначно определяет компонент отклика аутентификации.
AuthenticationId	Идентификатор аутентификации, специфицированный аутентификатором, который был включен компонент запроса (смотри раздел 7.2). Это позволяет аутентификатору идентифицировать метод аутентификации.
SelectedAlgorithmRef	Ссылка элемента, которая определяет элемент алгоритма, сипользуемого для формирования отклика аутентификации.
ContentSoftwareId	Смотри раздел 14. Словарь.

Cодержимое:

PackagedContent

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

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

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

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

Временном интервале в пределах которого Кассир может начать платежную операцию;

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

следует ли предоставлять платежную расписку;

должен ли данному платежу предшествовать другой платеж. Его определение выглядит следующим образом. Payment EMPTY > Payment ID ID #REQUIRED

OkFrom CDATA #REQUIRED	OkTo CDATA #REQUIRED
BrandListRef NMTOKEN #REQUIRED	SignedPayReceipt (True \| False) #REQUIRED

StartAfterRefs NMTOKENS #IMPLIED> Атрибуты:

ID	Идентификатор, который однозначно идентифицирует платежный компонент в транзакции IOTP.
OkFrom	Дата и время в формате [UTC], после которого кассир может воспринимать на обработку блок платежного запроса (смотри раздел 8.7), содержащий компонент платежа.
OkTo	Дата и время в формате [UTC], до которого Кассир может воспринимать на обработку блок платежного запроса, содержащий компонент платежа.
BrandListRef	Ссылка элемента (смотри раздел 3.5) компонента списка видов платежа (смотри раздел 7.7) в рамках торгового блока TPO транзакции IOTP. Список видов платежа идентифицирует альтернативные способы осуществления платежа.
SignedPayReceipt	Указывает, должен ли быть подписан блок платежного отклика (смотри раздел 8.9), сгенерированный Кассиром.
StartAfter	Содержит ссылки элемента (смотри раздел 3.5) других платежных компонентов, которые описывают платежи, которые должны быть проведены до того, как будет произведен данный платеж. Если атрибут StartAfter отсутствует, тогда никаких зависимостей нет и платеж может быть проведен немедленно.

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

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

сумму платежа и его валюту;

дату и время платежа;

внутренние числовые ссылки, которые идентифицируют платеж для платежной системы;

цифровые подписи, выработанные платежным механизмом и призванные позднее подтвердить, что платеж состоялся. Если использованный платежный метод сконфигироирован соответствующим образом, то компонент платежной расписки должен содержать сообщения платежного протокола или ссылки на сообщения, которые подтверждают выполнение платежа. Точное определение содержимого платежной расписки зависит от метода платежа. Информация, содержащаяся в компоненте платежной расписки, должна отображаться или каким-либо другим способом доводиться до сведения Покупателя. Если компонент платежной расписки содержит сообщения платежного протокола, тогда они должны быть обработаны программой метода платежа,чтобы преобразовать их в формат понятный Покупателю. Определение компонента платежной расписки. PayReceipt (PackagedContent*)>

PayReceipt ID	ID #REQUIRED
PaymentRef NMTOKEN #REQUIRED	PayReceiptNameRefs NMTOKENS #IMPLIED

ContentSoftwareId CDATA #IMPLIED> Атрибуты:

ID		Идентификатор, который однозначно определяет компонент платежной расписки транзакции IOTP.
PaymentRef		Содержит ссылку элемента (смотри раздел 3.5) на компонент платежа (смотри раздел 7.9), к которому относится данная расписка.
PayReceiptNameRefs		Опционно содержит список значений атрибутов Name элементов Packaged Content, которые образуют расписку. Элементы Packaged Content могут содержать:
о	компоненты данных платежной схемы, обмен которыми производится между Кассиром и Покупателем в процессе платежа и/или
o	сам компоент платежной расписки. Заметим, что:
o	каждый компонент схемы определяет в своем приложении имена элементов Packaged Content, которые должны быть перечислены в этом атрибуте (если они нужны).
о	Если компонент платежной схемы содержит элементы Packaged Content, с именами которые совпадают с именем в PayReceiptNameRefs, тогда на такие компоненты платежной схемы должны ссылаться дайджесты в компоненте подписи платежного отклика (если используется такая подпись).

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

ContentSoftwareId

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

Cодержимое:

PackagedContent

Опционно содержит информацию платежной расписки (платежную схему) в виде элементов Packaged Content (смотри раздел 3.7). Определение его содержимого смотри в прилжении платежной схемы.

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

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

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

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

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

PaymentRef NMTOKEN #IMPLIED	ConsumerPaymentId CDATA #IMPLIED
PaymentHandlerPayId CDATA #IMPLIED	ContentSoftwareId CDATA #IMPLIED>

Атрибуты:

ID	Идентификатор, который однозначно определяет компонент схемы оплаты транзакции IOTP.
PaymentRef	Ссылка элемента (смотри раздел 3.5) компонента платежа (смотри раздел 7.9), с которым связан компонент схемы платежа. Атрибут необходим, если только компонент схемы платежа не является частью запроса состояния транзакции (смотри раздел 9.2.1).
ConsumerPaymentId	Идентификатор, специфицированный Покупателем, который в случае возвращения Кассиром в другом компоненте схемы платежа (или другим способом) позволит Покупателю определить, о каком платеже идет речь.
PaymentHandlerPayId	Идентификатор, специфицированный Кассиром, который в случае возвращения Покупателем в другом компоненте схемы платежа (или другим способом) позволит Кассиру определить, о каком платеже идет речь. Атрибут необходим для каждого компонента схемы платежа, вне зависимости от того, что содержится в блоке платежного запроса.
ContentSoftwareId	Смотри раздел 14. Словарь.

Cодержимое:

PackagedContent

Содержит протокольную информацию о схеме платежа в виде элементов Packaged Content (смотри раздел 3.7). Определение содержимого смотри в приложение по схемам платежа.

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

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

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

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

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

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

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

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

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

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

	- компонент запроса аутентификации, который был использован в аутентификации (если имеется);
	- компонент информационного запроса о торговой роли (если имеются).

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

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

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

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

блок ссылки транзакции (смотри раздел 3.3) сообщения IOTP, который содержит подпись отклика доставки;

компонент данных доставки покупателя, содержащихся в предыдущем запросе доставки (если имется);

компоненты Signature, содержащиеся в предыдущем запросе доставки (если имется);

компонент Status;

компонент Delivery Note.

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

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

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

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

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

Блок ссылки транзакции (смотри раздел 3.3) сообщения IOTP, которое содержит подпись отклика предложения

из блока TPO:

	компонент опций протокола;
	каждый из компонентов Organisation;
	каждый из компонентов списка видов платежа;

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

из блока отклика предложения:

	компонент Order;
	каждый из компонентов Payment;
	компонент Delivery;
	каждый из компонентов запроса аутентификации;
	любой компонент данных о торговой роли.

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

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

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

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

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

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

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

компонент подписи отклика предложения;

компонент платежной расписки;

компонент Payment Note;

компонент Status;

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

любой компонент данных о торговой роли.

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

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

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

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

следующие компоненты блока TPO:

	- компонент опций протоколов;
	- компонент Organisation.

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

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

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

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

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

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

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

Опции протокола представляют собой опции, которые работают с транзакциями IOTP в целом. Определение компонента протокольных опций представлено ниже.
xml:lang NMTOKEN #REQUIREDShortDesc CDATA #REQUIRED
SenderNetLocn CDATA #IMPLIEDSecureSenderNetLocn CDATA #IMPLIED
SuccessNetLocn CDATA #REQUIRED > Атрибуты:

ID	Идентификатор, которыйоднозначно идентифицирует компонент протокольных опций в транзакции IOTP.
Xml:lang	Определяет язык, используемый атрибутами или дочерними элементами в пределах компонента, если значение не переписано атрибутом xml:lang дочернего элемента.
ShortDesc	Этот атрибут содержит краткое описание транзакции IOTP на языке, заданном xml:lang. Его целью является объяснение того, какая транзакция осуществляется партнерами.

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

SenderNetLocn

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

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

SecureSenderNetLocn

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

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

SuccessNetLocn

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

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

Компонент Related To

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

	xml:lang NMTOKEN #REQUIRED
RelationshipType NMTOKEN #REQUIRED	Relation CDATA #REQUIRED

RelnKeyWords NMTOKENS #IMPLIED >
Атрибуты:

ID	Идентификатор, который однозначно jghtltkztn компонент Related To в рамках транзакции IOTP.
xml:lang	Определяет язык, использованный атрибутом или дочерним элементом в данном компоненте, если не переписан атрибутом xml:lang дочернего элемента. Смотри раздел 3.8.
RelationshipType	Определяет тип отношения. Корректными значениями являются:

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

Ссылка, в случае которой элемент Packaged Content содержит указатель на некоторый другой, не-IOTP документ. Значения RelationshipType управляются процедурами, определенными в разделе 12 IANA Considerations, которые позволяют пользователю определить свои значения атрибута.

Relation

Атрибут Relation содержит фразу на языке, определенном xml:lang, он определяет природу отношений между транзакцией, которая содержит этот компонент и другой транзакцией или другим событием. Окончательное текстовое выражение оставлено на усмотрение составителей программ IOTP.

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

RelnKeyWords

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

Cодержимое:

PackagedContent

Packaged Content (смотри раздел 3.7) содержит данные, которые идентифицируют связанные транзакции. Его формат варьируется в зависимости от значения атрибута RelationshipType.

Компонент 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.

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

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

виды платежа (смотри также раздел 11.1),

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

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

сетевые позиции Кассиров, которые воспринимают платеж в рамках платежного протокола. Определение компонента списка видов платежа представлено ниже. Атрибуты:

ID	Идентификатор, который однозначно определяет компонент списка видов платежа транзакции IOTP.
xml:lang	Определяет язык, использованный атрибутами или дочерними элементами в пределах данного компонента, если только его значение не переписано атрибутом xml:lang дочернего элемента. Смотри раздел 3.8.
ShortDesc	Текстовое описание на языке, заданном атрибутом xml:Lang, характеризующее цели списка видов платежа. Эта информация должна быть отображена у получателя списка видов платежа для того чтобы помочь сделать правильный выбор. Это привлекательно, так как позволяет Покупателю выяснить цели предлагаемого списка видов платежа, если транзакция предполагает несколько платежей.
PayDirection	Индицирует направление платежа для выбранного вида. Возможные значения:

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

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

Brand

Описывает вид платежа (Brand). Последовательность элементов Brand (смотри раздел 7.7.1) в списке видов плптежа не определяет каких-либо преоритетов. Рекомендуется, чтобы программа, которая обрабатывает этот список видов платежа представляла их в порядке предпочтения получателя.

ProtocolAmount

Это связывает конкретный вид платежа с:

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

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

CurrencyAmount	Содержит код валюты и сумму платежа;
PayProtocol	Содержит информацию о платежном протоколе и Кассире, которые могут использовать данный вид платежа.

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

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

Компонент Status

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

Status ID ID #REQUIRED	xml:lang NMTOKEN #REQUIRED
StatusType NMTOKEN #REQUIRED	ElRef NMTOKEN #IMPLIED

ProcessState (NotYetStarted | InProgress | CompletedOk | Failed | ProcessError) #REQUIRED
CompletionCode NMTOKEN #IMPLIED
ProcessReference CDATA #IMPLIEDStatusDesc CDATA #IMPLIED > Атрибуты:

ID	Идентификатор, который однозначно определяет компонент Status транзакции IOTP.
xml:lang	Определяет язык, используемый атрибутами в пределах компонента. Смотри раздел 3.8.
StatusType	Индицирует тип обмена документами, о котором сообщает компонент Status. Он может быть установлен в состояние предложение, платеж, доставка, аутентификация или “неопределено” (Undefined).

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

ElRef

Если StatusType не установлено равным Undefined (неопределено), тогда ElRef содержит ссылку элемента (смотри раздел 3.5) на компонент, для которого описан Status. Он может относиться к:
о компоненту Order (смотри раздел 7.5), если StatusType = Offer,
o компоненту Payment (смотри раздел 7.9), если StatusType = Payment,
o компоненту Delivery (смотри раздел 7.13), если StatusType = Delivery;
o компоненту запрос аутентификации (смотри раздел 7.2), если StatusType = Authentication.

ProcessState

Содержит код состояния (State Code), который индицирует текущее состояние исполняемого процесса. Допустимыми значениями ProcessState являются:
о NotYetStarted. Получен блок Request, но процесс еще не начат;
o InProgress. Обработка блока Request начата, но еще не завершена;
o CompletedOk. Обработка блока Request успешно завершена;
o Failed. Обработка блока Request не прошла из-за рабочей ошибки (Business Error) (смотри раздел 4.2)
o ProcessError. Это значение применяется, только когда компонент Status используется в связис торговым блоком информационного запроса (смотри раздел 8.12). Оно указывает, что была техническая ошибка (смотри раздел 4.1) в блоке запроса, который обрабатывается, тди другая внутренняя ошибка обработки.

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

CompletionCode

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

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

ProcessReference

Этот опционный атрибут хранит ссылку для процесса, о состоянии которого сообщается. Он может содержать следующие значения:о когда StatusType = Offer, он должен содержать OrderIdentifier компонента Order;o когда StatusType = Payment, он должен содержать PaymentHandlerPayId компонентаданных о схеме платежа;o когда StatusType = Delivery, он должен содержать DelivHandlerDelivId компонента Delivery Note;o когда StatusType = Authentication, он должен содержать AuthenticationId компонента запроса аутентификации.

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

StatusDesc

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

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

Компонент типа информационного запроса содержит информацию, которая указывает тип процесса, о котором получен запрос. Его определение представлено ниже.
ElRef NMTOKEN #IMPLIEDProcessReference CDATA #IMPLIED> Атрибуты:

ID	Идентификатор, который однозначно определяет компонент типа информационного запроса транзакции IOTP.
Type	Содержит тип информационного запроса. Допустимые значения типа запроса: o Offer. Запрос касается статуса предложения и обращен к продавцу. o Payment. Запрос касается статуса платежа и обращен к кассиру. o Delivery. Запрос касается статуса доставки и обращен к агенту доставки.
ElRef	Содержит ссылку элемента (смотри раздел 3.5) на компонент, к которому относится информационный запрос. Это: о Блок TPO, когда тип = Offer; o Компонент Payment, когда тип = Payment; o Компонент Delivery, когда тип = Delivery.
ProcessReference	Опционно содержит ссылку на процесс, о котором произведен запрос. Он должен быть установлен, если информация доступна. Для определения значений, которые он может принимать, смотри атрибут ProcessReference компонента Status (смотри раздел 7.16).

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

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

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

чтобы опционно проинформировать продавца об используемом виде платежа с целью возможной последующей коррекции предложения и заказа. В базовой версии IOTP, целостность компонентов выбора вида платежа не гарантируется. Однако модификация компонентов выбора вида платежа может привести лишь к отказу обслуживания, если сам платежный протокол безопасен и контролирует модификацию или дублирование сообщений и может противостоять любым другим атакам. Определение компонента выбора вида платежа представлено ниже. BrandListRef NMTOKEN #REQUIREDBrandRef NMTOKEN #REQUIRED ProtocolAmountRef NMTOKEN #REQUIRED
CurrencyAmountRef NMTOKEN #REQUIRED > Атрибуты:

ID	Идентификатор, который однозначно определяет компонент выбора вида платежа транзакции.
BrandListRef	Ссылка элемента (смотри раздел 3.5) компонента списка видов платежа, из которого был выбран Brand.
BrandRef	Ссылка элемента Brand компонента списка видов платежа, который был выбран из списка и использован для платежа.
ProtocolAmountRef	Ссылка элемента для Protocol Amount в пределах компонента списка видов платежа, который использован при платеже.
CurrencyAmountRef	Ссылка элемента для Currency Amount в пределах компонента списка видов платежа, который использован при платеже.

Cодержимое:

BrandSelBrandInfo,
BrandSelProtocolAmountInfo,
BrandSelCurrencyAmountInfo

Содержит любые дополнительные данные, которые могут быть необходимы при конкретном платеже
или протоколе. Смотри разделы 7.8.1, 7.8.2, и 7.8.3.

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

атрибут BrandListRef должен содержать идентификатор компонента списка видов платежа транзакции IOTP;

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

BrandRef должен относиться к ID Brand, содержащегося в компоненте списка видов платежа, на который ссылается BrandListRef

ProtocolAmountRef должен относиться к одному ID элемента, содержащемуся в атрибуте ProtocolAmountRefs элемента Brand, идентифицированного BrandRef

CurrencyAmountRef должен относиться к одному ID элемента содержащемуся в атрибуте ProtocolAmountRefs элемента Protocol Amount, идентифицированного ProtocolAmountRef. Пример компонента выбора вида платежа включен в раздел 11.2.

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

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

xml:lang NMTOKEN #REQUIRED	OrderIdentifier CDATA #REQUIRED
ShortDesc CDATA #REQUIRED	OkFrom CDATA #REQUIRED
OkTo CDATA #REQUIRED	ApplicableLaw CDATA #REQUIRED

ContentSoftwareId CDATA #IMPLIED > Атрибуты:

ID	Идентификатор, который однозначно определяет компонент Order в пределах текущей транзакции IOTP.
xml:lang	Определяет язык, использованный атрибутами или дочерними элементами в пределах компонента, если только его значение не было изменено с помощью атрибута xml:lang дочернего элемента. Смотри раздел 3.8.
OrderIdentifier	Это код, число или другой идентификатор, который автор заказа может использовать для идентификации заказа. В пределах транзакции он должен быть уникальным. Если он используется так, то нет нужды специфицировать содержимое элемента заказа, так как имеется ссылка на нужную информацию в базе данных.
ShortDesc	Краткое описание заказа на языке, определенном атрибутом xml:lang. Оно используется для упрощения выбора индивидуального заказа из списка, например, из базы данных заказов, записанных туда продавцом, покупателем и т.д..
OkFrom	Дата и время в формате [UTC], после которого предложение, сделанное Продавцом теряет силу.
OkTo	Дата и время в формате [UTC], до которого получатель может воспринимать предложение продавца не имеющим силу.
ApplicableLaw	Фраза на языке, определенном атрибутом xml:lang, которая описывает штат или страну, юристдикция которой будет использована при разрешении конфликтов и споров.
ContentSoftwareId	Смотри раздел 14. Словарь.

Cодержимое:

PackagedContent

Опционное описание заказа в виде одного или более элементов Packaged Content (смотри раздел 3.7).

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

Этот торговый компонент содержит параметр данных, которые используются при аутентификации одной торговой роли у другой. Его определение представлено ниже.
AuthenticationId CDATA #REQUIREDContentSoftwareId CDATA #IMPLIED> Если требуется, алгоритм может использовать данные вызова, содержащиеся в элементах Packaged Content из компонента запроса аутентификации. Формат Packaged Content является зависимым от алгоритма. Атрибуты:

ID	Идентификатор, который однозначно идентифицирует компонент запроса аутентификации для данной транзакции IOTP.
AuthenticationId	Идентификатор, специфицированный аутентификатором, который, если прислан организацией, которая получает запрос, позволит аутентификатору определить, какая аутентификационная процедура требуется.
ContentSoftwareId	Смотри раздел 14. Словарь

Cодержимое:

PackagedContent	Содержит данные вызова в виде одного или более элементах Packaged Content (смотри раздел 3.7), на которые следует рееагировать, используя алгоритм, опреденный элементом Algorithm.
Algorithm	Содержит информацию, которая описывает алгоритм (смотри 7.19. Компоненты подписи), который должен быть использован для генерации отклика аутентификации.

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

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

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

ID	Идентификатор, который однозначно определяет компонент информационного запроса для торговой роли в рамках транзакции IOTP.
TradingRoleList	Содержит список из одной или более торговых ролей (смотри атрибут TradingRole элемента Trading Role - раздел 7.6.2), для которых была запрошена информация.

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

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

Конфиденциальность

Сообщения шифрования работают со стандартом DES (Digital Encryption Standard), обычно используемым в настоящее время при осуществлении электронных платежей. Планируется применение супершифрования (т.e., более чем одноуровневое шифрование) особо чувствительной информации, такой как PIN-коды, и обрабатывать их так, что они никогда не появляются в виде простого текста, за исключением короткого времени перед поступлением на специальное оборудование внутри сервера перед перекодировкой с помощью нового ключа. Обработка платежа через кредитную карточку посредством системы CyberCash организована так, что продавец никогда не узнает номер кредитной карточки покупателя, если только банк не решит выдать ему эту информацию. Кроме того, сервер не хранит у себя в памяти эту информацию постоянно. Номер кредитной карточки присутствует там только во время непосредственного выполнения платежной операции.

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

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

Когда бы ни был получен компонент данных торговой роли в блоке "Отклик", идентифицировать компоненты Organisation, которые должны получить его, как идентифицированные атрибутом DestinationElRefs.

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

	- компонент данных о торговой роли, а также,
	- компонент Organisation, идентифицированной атрибутом OriginatorElRef.

MicroMint

MicroMint (при вольной интерпретации это выражение можно перевести как микромонетный двор) представляет собой еще одну платежную систему, базирующуюся на модели электронных монет. Здесь не используется общедоступный ключ шифрования. Электронные монеты в этой схеме формируются брокером, который продает их пользователям. Пользователи передают эти монеты продавцам в качестве оплаты товаров или услуг. Продавцы возвращают эти монеты брокеру, который осуществляет перевод реальных денег на счет продавца. Электронная монета представляет собой последовательность бит, которая может быть легко проверена, но которую достаточно трудно сформировать. Алгоритм MicroMint устроен так, что формирование большого числа монет стоит дешевле (из расчета на одну монету), чем формирование одной или нескольких. Брокер формирует партию монет, например раз в месяц. При этом действие прежней партии монет истекает, и они не могут более использоваться. Продавцы возвращают полученные монеты в конце каждого дня. Монеты MicroMint формируются с использованием кратных столкновений хэш-функций. Однопроходная хэш-функция H ставит в соответствие m битам строки х n бит строки y. Строка х называется исходным образом y, если H(x)=y. Пара строк (х1,х2) называются двойным столкновением, если H(x1)=H(x2)=y, где строка y имеет n бит. Если хэш-функция гарантирует достаточно высокий уровень рэндомизации, то для получения одного двойного столкновения необходимо вычислить для строки х примерно 2n/2 xэш-функций. Но при ограниченном n вычисление двойных столкновений является относительно простой задачей и для злоумышленника, по этой причине для формирования монет чаще используется вычисление k-кратных столкновений. k-кратным столкновением называется набор строк х1, х2, …, хk для которых H(x1)=H(x2)=…=H(xk)=y. Для получения k-кратного столкновения необходимо выполнить вычисление примерно 2n(k-1)/k хэш-функций. В дальнейшем будем считать, что монета характеризуется k-кратным столкновением (х1, х2, …, хk). Корректность монеты может проверить кто угодно, вычислив k хэш-функций и проверив условие. H(x1)=H(x2)=…=H(xk)=y Если в ходе вычисления хэш-функций просматривать результат, то можно выявить определенное число k-кратных столкновений, что во много раз увеличивает производительность генерации электронных монет.
Еще большего выигрыша в скорости можно достичь, применяя специфические аппаратные реализации. Предположим, что брокер хочет иметь чистый доход размером в 1 млн. долларов США (эквивалентно примерно 227 центов/месяц). Пусть доходы брокера составляют 10%, это означает, что продавец получает 0,9 цента при выкупе монеты. Таким образом, брокер должен продать миллиард монет в месяц. Если обычный клиент покупает 2500 монет в месяц, необходимо иметь 500000 клиентов. Пусть k=4 (4-кратные столкновения). Для того чтобы сформировать 230 монет, надо будет закупить специализированное оборудование стоимостью около 100000$ (что менее 10% месячного дохода). Для целей вычисления хэш-функций могут использоваться специализированные ИС, применяемые для DES-шифрования или ИС FPGA - программируемые логические матрицы. Подготовка брокером нового набора монет может продолжаться в течение всего месяца. Нетрудно понять, что злоумышленнику, использующему обычную рабочую станцию, сформировать самостоятельно достаточное число монет не по плечу. При продаже монет клиенту брокер запоминает, какому клиенту какие монеты проданы, что позволяет в будущем проконтролировать попытки злоупотреблений. Неиспользованные монеты ликвидируются в конце месяца. Ограничение времени действия монет создает определенные трудности для клиента. Но за то это ограничивает требуемые объемы баз данных, хранящих информацию о выпущенных и использованных уже монетах. Монетная система по своей природе предполагает определенное доверие между плательщиком и получателем платежа. Получатель может присвоить монету и заявить, что она уже была использована, а плательщик может предъявить претензии получателю (банку или продавцу), утверждая, что повторного использования не было, а монета просто присвоена. В сущности, это является общим свойством любых монет и сертификатов на предъявителя. Каждый раз, когда клиент осуществляет покупку, он пересылает продавцу одну или несколько монет (х1, х2, …, хk). Это может осуществляться автоматически программой WEB-броузера.

Продавец проверяет корректность монет путем вычисления k функций H(xi), что занимает совсем немного вычислительных ресурсов. При возвращении монет продавцом брокеру проверка повторяется. Существуют методы формирования монет специфических для клиента или для продавца, что снижает риски злоупотреблений (смотри “PayWord and Micromint: Two simple micropayment schemes” Ronald L. Riverst и Adi Shamir, 7 мая 1996). Мелкомасштабная атака малоэффективна, и по этой причине недостойна серьезного внимания (злоумышленник должен понести большие издержки из-за нескольких центов). Для такого рода атак для k=4 и n=54 при использовании стандартной рабочей станции требуются десятки лет. Крупномасштабное мошенничество легко детектируется из-за следующих обстоятельств.

Все фальшивые монеты теряют силу в конце месяца.

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

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

Брокер может в любой момент объявить об истечении срока годности выпущенных в оборот монет и запустить в оборот новую партию. Возможность кражи монет в ходе пересылки блокируется с помощью шифрования, что легко осуществить, так как взаимоотношения между клиентами продавцами и брокерами являются долгосрочными и доверительными. Схема MicroMint не является анонимной, поэтому брокер легко может детектировать попытки повторного использования монет. Обнаружить мелкого злоумышленника трудно, но из-за низкой цены монет это не может вызвать проблем. Генерация монет, специфических для клиента или продавца делают кражу бесполезной. Таким образом, любые злоупотребления легко обнаруживаются, но так как в MicroMint не используются подписи, выяснение отношений в суде невозможно. Для генерации монет, специфических для клиентов, последние делятся брокером на группы. Например, клиенту U даются монеты, которые дополнительно отвечают требованию h(х1, х2, …, хk)=h(U), где h - хэш-функция, формирующая 16-битовый код.

Данное решение может оказаться не слишком хорошим для больших групп, где вор всегда сможет найти клиента, желающего приобрести украденные монеты. При малых же группах брокер будет вынужден производить слишком большую вычислительную работу. Другим вариантом может быть обобщение понятия столкновения. Монета (х1, х2, …, хk) будет считаться корректной для клиента U, если образы y1=(x1), y2=(x2),…, yk=(xk) удовлетворяют условию yi+1 - yi = di (mod 2u) для i =. 1,2,..,k-1, где (d1,d2,…,dk-1)=h(U). Стандартный алгоритм формирования монет соответствует случаю, когда все значения d равны нулю. Формирование монет специфических для продавца может осуществляться согласно алгоритму, схожему с выше описанным. Существуют алгоритмы, которые позволяют сократить вычислительные издержки при массовой генерации монет сразу на несколько месяцев. Другие системы для осуществления небольших платежей, например, NetBill предлагают дополнительные возможности (например, заказы товара и шифрование информации о покупке), но они относительно дороже.

Насыщенность цвета логотипа

Существует три стандартных значения насыщенности цвета. Насыщенность цвета (включая число бит на пиксель) и соответствующее значение для Logo_Color_Depth представленны ниже в таблице.

Насыщенность цвета	Цвет логотипа
(бит на пиксель)	Значение насыщенности
4 (16 цветов)	4
8 (256 цветов)	ничего
24 (16 миллионов цветов)	24

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

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

Значение

Описание

InMsgHardError

Серьезная ошибка во взодном сообщении (Input Message Hard Error). Тип блока запроса не может быть идентифицирован или является несовместимым. Следовательно никакой однодокументный обмен не может быть идентифицирован. Это может вызвать серьезную ошибку в транзакции.

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

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

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

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

Обмен документами при доставке

Документальный обмен доставки является непосредственной реализацией торгового обмена доставки (смотри раздел 2.2.3). Он состоит из следующих шагов:

Покупатель запрашивает доставку путем формирования сообщения запроса доставки. При этом используется информация предыдущего IOTP-сообщения транзакции и затем посылает его Агенту доставки;

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

1.	Покупатель генерирует блок запроса доставки и посылает его агенту доставки, снабдив, если требуется, цифровой подписью
C а D	Запрос доставки. IotpMsg: блоки Trans Ref; подписи; запроса доставки
2.	Агент доставки проверяет компоненты Status и Order запроса доставки и опционно подпись, создает блок отклика доставки, посылает его покупателю.
C Я D	Отклик доставки. IotpMsg: блоки Trans Ref; подписи; отклика доставки
3.	Покупатель проверяет блок отклика доставки и опционный блок подпии. Опционно производит запись о транзакции на будущее.

Рис. .22. Обмен документами при доставке

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

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

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

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

Кассир посылает сообщение платежного отклика покупателю, где содержится платежная расписка. IOTP-сообщения, которые используются при платежном обмене показаны на рис. .21.

1.	Покупатель формирует блок платежного запроса, если необходимо, инкапсулирует в него сообщение платежного протокола, и посылает кассиру, снабжая при необходимости цифровой подписью
C а P	Запрос платежа. IotpMsg: блоки Trans Ref; подписи (опционный); платежного запроса
2.	Кассир обрабатывает блок платежного запроса, проверяет подпись, если таковая имеется, и начинает обмен с покупателем сообщениями (вложенными в блок платежного обмена) согласно платежному протоколу
C « P	Платежный обмен. IotpMsg: блоки Trans Ref; Pay Exchange
3.	Покупатель и кассир продолжают обмен платежными блоками, пока платеж не будет осуществлен и кассир не сформирует платежную расписку (которая опционно может быть снабщена цифровой подписью) и не пошлет ее покупателю. Эта операция завершает платежный обмен.
C Я P	Платежный отклик. IotpMsg: блоки Trans Ref; Signature (опционный); платежного отклика
4.	Покупатель проверяет, все ли в порядке с платежным откликом. Опционно могут регистрироваться все операции IOTP. После этого покупатель может остановиться или послать очередное сообщение IOTP (снабдив его, если требуется, подписью) соответствующей торговой роли

Рис. .21. Обмен платежными документами

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

Документальный обмен платежа и доставки представляет собой комбинацию последней части торгового обмена платежа (смотри раздел 2.2.2) и обмена доставки (смотри раздел 2.2.3). Он состоит из:

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

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

Кассир посылает покупателю в одном сообщении IOTP:

	- блок платежного отклика, содержащий платежную расписку, и
	- блок отклика доставки, содержащий подробности о доставленных товарах или услугах.

IOTP-сообщения, которые вовлечены в этот процесс, показаны на рис. .23.

1.	Покупатель генерирует блок платежного запроса, в который, если требуется, вкладывается сообщение платежного протокола, и посылает его кассиру, снабжая опционно цифровой подписью
C а P	Платежный запрос. IotpMsg: блоки Trans Ref; подписи; платежного запроса
2.	Кассир обрабатывает блок платежного запроса, проверяет опционную подпись и начинает обмен с покупателем в рамках платежного протокола (вкладывая эти сообщения в блоки платежного обмена)
C « P	Платежный обмен. IotpMsg: блоки Trans Ref; платежного обмена
3.	Покупатель и кассир обмениваются блоками платежного обмена до тех пор пока платежный протокол не завершит свою работу. Кассир формирует компонент платежной расписки, помещает его в блок платежного отклика, опционно формирует компонент подписи, который укладывается в блок Signature, затем использует информацию из блока отклика предложения, чтобы сформировать блок отклика отклика доставки и посылает его покупателю.
C Я P	Отклики платежа и доставки. IotpMsg: блоки Trans Ref; подписи; платежного отклика; отклика доставки
4.	Покупатель проверяет блоки платежного отклика и отклика доставки. Опционно он может вести запись всех транзакций. Здесь покупатель может остановиться или сформировать очередное сообщение и послать его соотвествующе торговой роли.

Рис. .23. Документальный обмен платежа и доставки Блоки отклика доставки и платежного отклика могут быть обхединены в одном сообщении только если кассир имеет необходимую информацию, чтобы послать блок отклика доставки. Это вероятно так, если роли продавца, кассира и агента доставки совмещены. Атрибут DelivAndPayResp компонента доставки (смотри раздел 7.13), содержащийся в блоке отклика Offer (смотри раздел 8.3), делается равным True, если блоки отклика доставки и платежного отклика объединены в одном сообщении, и равен False, если блоки отклика доставки и платежного отклика посланы в разных IOTP-сообщениях.

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

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

1.	Покупатель решает осуществить сделку и посылает информацию продавцу о том, что нужно доставить и как это лучше сделать.
C а M	Информация о том, что следует доставить (вне зоны ответственности IOTP)
2.	Продавец проверяет информацию, полученную от покупателя, добавляет информацию о том, как будет осуществляться доставка, информацию об организациях, вовлеченных в доставку и, опционно, электронную подпись, после чего отправляет все это покупателю.
C Я M	Компоненты: lоставка; jрганизации (fгент доставки, доставит туда-то); заказ, опционная подпись отклика-предложения
3.	Покупатель проверяет, корректна ли доставочная информация, получает разрешение на доставку, например путем оплаты, и посылает эти данные агенту доставки.
C а D	Запрос доставки. Компоненты: cтатус; доставка, организации: (продавец, агент доставки, DelivTo); Заказ, данные о торговой роли (опционны); опционная подпись отклика-предложения, опционная подпись платежной расписки (из платежного обмена)
4.	Агент доставки проверяет информацию и авторизацию. Запускает или диспетчеризует доставку, а также готовит и отправляет накладную покупателю, которая опционно может быть подписана.
C Я D	Отклик доставки. Компоненты: статус; накладная (Delivery Note), данные о торговой роли (опционны); опционная подпись отклика доставки
5.	Покупатель проверяет накладную и принимает товар или ждет доставки, как это указано в накладной (Delivery Note).

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

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

Компоненты организации содержат информацию об адресе доставки и ролях агента доставки и продавца:

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

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

Компонент доставки содержит информацию о том, как будет осуществлена доставка, например по почте или с помощью e-mail.

Компонент подписи предложения-отклика (Offer Response), если присутствует, электронным образом подписывает все перечисленные выше компоненты, обеспечивая их целостность.

Компонент подпись платежной расписки (Payment Receipt) предоставляет подтверждение платежа, с помощью электронной подписи компонента платежной расписки и предложения. Это используется агентом доставки для проверки того, что доставка авторизована.

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

Компонент подпись отклика доставки (Delivery Response), если присутствует, предоставляет подтверждение результатов доставки путем электронной подписи накладной (Delivery Note) и подписей любого отклика-предложения или отклика платежа, которые получил агент доставки.

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

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

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

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

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

Этот подход к обработке дублированных входных сообщений означает, что если получены два совершенно идентичных сообщения, будут посланы два идентичнх отклика. Это применимо также к информационным запросам и транзакциям Ping, когда в действительности состояние транзакции или возможность обработки сервером может измениться. Если требуется текущее состояние транзакции или сервера, тогда используется транзакция с новым значением ID-атрибута компонента MsgId. Процесс обработки входного сообщения должен проверить, свободна ли остальная система. Если сервер слишком занят, он должен выдать компонент Error с атрибутом Severity равным Transient Error и кодом ошибки равным SystemBusy, после чего вернуть отправителю входное сообщение, запрашивая тем самым повторную присылку этого сообщения спустя некоторое время. Некоторые серверы могут оказаться перегруженными из-за неожиданного всплеска загрузки. Данный подход позволяет преодолевать ситуации с кратковременными пиковыми нагрузками, запрашивая отправителя переслать сообщение несколько позже. Проверка того, что транзакция не зафиксировала ошибку и не оказалась аннулированной. Предполагается следующий контроль:

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

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

проверку формат XML;

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

проверку цифровой подписи, которая в свою очередь предполагает:

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

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

о	проверку в пределах каждого блока (помимо блока ссылок транзакции) того что:
		- атрибуты, элементы и содержимое элементов корректно;
		- значения атрибутов, элементы и содержимого элементов не противоречат друг другу в пределах блока.
о	проверку того, что комбинации блоков корректны
o	проверку того, что значения атрибутов, элементы и содержимое элементов взаимосогласованы на межблочном уровне в пределах входного сообщения с блоками, полученными или отправленными ранее. Это включает проверку уместности данного блока для этого типа транзакции.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

принимающие средства как часть депозитной операции;

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

Продавцы
	Склад		Платильщик	Получатель платежа	Покупатель	Кассир		Агент доставки
Транзакции
Покупка	Нужно				Нужно
Продавцы
	Store		Пла-тиль-щик	Получа-тель платежа	Покупатель	Кассир	Агент доставки
Возврат средств	Нужно				b) Зависит
Аутентификация	Можно		Нужна	Можно	b) Зависит
Обмен ценностями	Можно				Нужно
Отзыв			Нужно		b) Зависит
Депозит				Нужно	b) Зависит
Запрос данных	Нужно		Нужно	Нужно	Можно	Нужно	Нужно
Ping	Нужно		Нужно	Нужно	Можно	Нужно	Нужно
Торговые блоки
TPO	Нужно		Нужно	Нужно	Нужно
Выбор TPO	Нужно		Нужно	Нужно	Нужно
Запрос Auth	a) Зависит			a) Зависит	a) Зависит
Отклик Auth	a) Зависит			a) Зависит	a) Зависит
Отклик предложения	Нужно		Нужно	Нужно	Нужно
Запрос платежа					Нужно	Нужно
Платежный обмен					Нужно	Нужно
Платежный отклик					Нужно	Нужно
Запрос доставки					Нужно		Нужно
Отклик доставки					Нужно		Нужно
Продавцы
	Склад	Платильщик		Получа-тель	Покупатель	Кассир	Агент доставки
Запрос данных	Нужно	Нужно		Нужно	Нужно	Нужно	Нужно
Отклик данных	Нужно	Нужно		Нужно	Нужно	Нужно	Нужно
Запрос Ping	Нужно	Нужно		Нужно	Нужно	Нужно	Нужно
Отклик Ping	Нужно	Нужно		Нужно	Нужно	Нужно	Нужно
Подпись	Нужно	Нужно		Нужно	Ограничено	Нужно	Нужно
Ошибка	Нужно	Нужно		Нужно	Нужно	Нужно	Нужно

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

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

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

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

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

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

Обзор системы

Система CyberCash предназначена для обеспечения нескольких платежных услуг в Интернет. Чтобы получить доступ к услугам CyberCash, клиенту нужен только персональная ЭВМ, имеющая доступ к сети. Соответственно, продавцы и банкиры должны лишь незначительно изменить свои операционные процедуры, чтобы реализовать транзакции CyberCash. Вначале покупатель должен загрузить общедоступное программное обеспечение CyberCash из Интернет. Эта программа устанавливает соединение между покупателями, продавцами и их банками. Доступ к системе CyberCash еще проще, кнопки CyberCash "PAY" могут быть вставлены в популярные программы реального времени, позволяя клиенту войти в систему CyberCash, когда он пожелает осуществить оплату товара или услуги. Покупатель может не иметь до этого каких-либо отношений с CyberCash. Клиент идентифицирует свою личность через сеть. Транзакции используют информацию, введенную клиентом в свою ЭВМ, никакого ручного ввода данных для аутентификации не требуется. Покупатель лишь запускает платежную процедуру для каждой транзакции путем выбора одной из опций. Безопасность транзакций обеспечивается криптографически. Конфиденциальная информация о покупателе по каналам связи (например, продавцу) не пересылается.

Рис. .1. Схема взаимодействия субъектов сделки

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

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

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

Opaque Embedded Data

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

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

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

o	Процедуру запроса (смотри раздел 9.2.1)
o	Транзакцию Ping (смотри раздел 9.2.2)
o	Процедуру аутентификации (смотри раздел 9.1.6)

Операции IOTP

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

Рис. .7. Функциональная схема операция IOTP На приведенной выше диаграмме Интернет рассматривается в качестве транспортного механизма. Но это не всегда так. Сообщения IOTP могут транспортироваться с использованием различных механизмов. В этой версии IOTP специфицированы следующие операции IOTP (смотри раздел 9):

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

Возврат. Поддерживает возврат денег для сделанной ранее покупки.

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

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

Отзыв. Поддерживает отзыв электронного платежа из финансовой организации.

Депозит. Поддерживает депозит электронного платежа в финансовой организации.

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

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

Определение двойственного вид платежа (Dual Brand)

Двойственный вид платежа (Dual Brand) означает, что отдельный платежный инструмент может использоваться так, как если бы это были два отдельных вида платежа. Например, может существовать одна японская карта "UC" (MasterCard), которую можно использовать как UC-карту или как обычную MasterCard. Виды платежа через UC-карту и MasterCard могут иметь своих собственных, отличных друг от друга Кассиров. Это означает, что:

продавец рассматривает, например,"UC" и "MasterCard" как два вида платежа, когда предлагает список видов платежа покупателю,

покупатель выбирает вид платежа, например, "UC" или "MasterCard,

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

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

ID-атрибут Id-компонента IOTP-сообщения должен быть уникальным в пределах транзакции IOTP. Его определение представлено ниже: IotpMsgId_value ::= IotpMsgIdPrefix IotpMsgIdSuffix
IotpMsgIdPrefix ::= NameChar (NameChar)*IotpMsgIdPrefixКроме того сообщения, которые содержат: торговый блок информационного запроса, информационного отклика, запроса или отклика Ping, используют один и тот же префикс для всех сообщений, посланных Продавцом или Покупателем:<
table>о"M" - Продавец (Merchant)о"C" - Покупатель (Consumer)

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

о	"P" - Первый Кассир
o	"R" - Второй Кассир
o	"D" - Агент доставки
o	"C" - Доставка (Deliver To)

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

IotpMsgIdSuffix

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

o	Первому сообщению IOTP, посланному торговой ролью, присваивается суффикс "1".
o	Для второго и последующих IOTP-сообщений, посланных той же торговой ролью, суффикс увеличивается на 1 для каждого последующего сообщения.
o	Суффикс не может содержать начальных нулей.

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

Определение платежного инструмента

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

кредитная карта, такая как MasterCard или Visa;

дебитная карта типа MasterCard Maestro;

смарт карта, базирующаяся на системе электронных платежей, такой как Mondex, GeldKarte или Visa Cash;

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

Определение стимулирующего вида оплаты

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

во время покупки. Например, если покупатель платит с помощью "Walmart MasterCard" через сервер Walmart, то он может получить скидку в 5%, это означает, что покупатель в действительности платит меньше,

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

первый пример (получение выгоды в момент покупки), требует чтобы:

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

второй (получение выгоды от эмитента платежного средства) - не требует, чтобы отклик Offer изменился;

каждый поощрительный вид оплаты в списке, предлагаемом продавцом, должен быть идентифицирован как отдельный вид платежа. Например: "Walmart", "Sears", "Marks and Spencer" и "American Advantage Visa", будут рассматриваться как отдельные виды оплаты.

Определение вида платежа

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

платежные ассоциации и платежные системы частных фирм, например MasterCard, Visa, American Express, Diners Club, Mondex, GeldKarte, CyberCash, и т.д..

поощрительные виды платежа (смотри ниже). Сюда входят:

	- store brands, где платежный инструмент предоставляется покупателю конкретным продавцом, например Walmart, Sears или Marks and Spencer (UK)
	- совмещенные виды платежа, например American Advantage Visa, где организация использует свой собственный вид платежа обычно в сочетании с платежами рассчетной ассоциации.

Определения и выбор вида платежа

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

определения платежных инструментов и видов платежа в контексте IOTP. Вводятся опционные категории видов оплаты "Dual Brand" или "поощрительный вид платежа",

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

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

ID-атрибут блоков и компонентов в пределах транзакции IOTP также должен быть уникальным. Ниже представлено его определение: BlkOrCompId_value ::= IotpMsgId_value "." IdSuffix
IdSuffix ::= Digit (Digit)*

IotpMsgId_value

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

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

IdSuffix

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

o	Первому блоку или компоненту, посылаемому торговой ролью присваивается суффикс "1"
o	Для второго и далее блоков или компонентов ID-атрибуты увеличивается на 1 для каждого последующего сообщения.
o	Суффикс не может содержать начальных нулей.

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

Определения типов данных протокола IOTP

RespIotpMsg NMTOKEN #IMPLIED	xml:lang NMTOKEN #REQUIRED
LangPrefList NMTOKENS #IMPLIED	CharSetPrefList NMTOKENS #IMPLIED

SenderTradingRoleRef NMTOKEN #IMPLIED

SoftwareId CDATA #REQUIRED

TimeStamp CDATA #IMPLIED>

xml:lang NMTOKEN #REQUIREDRelationshipType NMTOKEN #REQUIREDRelation CDATA #REQUIREDRelnKeyWords NMTOKENS #IMPLIED>

Content NMTOKEN "PCDATA"

Transform (NONE|BASE64) "NONE">

xml:lang NMTOKEN #REQUIRED	ShortDesc CDATA #REQUIRED
SenderNetLocn CDATA #IMPLIED	SecureSenderNetLocn CDATA #IMPLIED

SuccessNetLocn CDATA #REQUIRED>

AuthenticationId CDATA #REQUIREDContentSoftwareId CDATA #IMPLIED>

AuthenticationId CDATA #REQUIREDSelectedAlgorithmRef NMTOKEN #REQUIRED
ContentSoftwareId CDATA #IMPLIED>

TradingRoleList NMTOKENS #REQUIRED>

>

xml:lang NMTOKEN #REQUIRED	OrderIdentifier CDATA #REQUIRED
ShortDesc CDATA #REQUIRED	OkFrom CDATA #REQUIRED
OkTo CDATA #REQUIRED	ApplicableLaw CDATA #REQUIRED

ContentSoftwareId CDATA #IMPLIED>

xml:lang NMTOKEN #REQUIRED	OrgId CDATA #REQUIRED
LegalName CDATA #IMPLIED	ShortDesc CDATA #IMPLIED

LogoNetLocn CDATA #IMPLIED>

>

TradingRole NMTOKEN #REQUIRED	IotpMsgIdPrefix NMTOKEN #REQUIRED
CancelNetLocn CDATA #IMPLIED	ErrorNetLocn CDATA #IMPLIED

ErrorLogNetLocn CDATA #IMPLIED>

Tel CDATA #IMPLIED	Fax CDATA #IMPLIED
Email CDATA #IMPLIED	NetLocn CDATA #IMPLIED>

Title CDATA #IMPLIED	GivenName CDATA #IMPLIED
Initials CDATA #IMPLIED	FamilyName CDATA #IMPLIED>

AddressLine1 CDATA #IMPLIED	AddressLine2 CDATA #IMPLIED
CityOrTown CDATA #IMPLIED	StateOrRegion CDATA #IMPLIED
PostalCode CDATA #IMPLIED	Country CDATA #IMPLIED

LegalLocation (True | False) 'False' >

	ID #REQUIRED
xml:lang NMTOKEN #REQUIRED	ShortDesc CDATA #REQUIRED PayDirection

(Debit | Credit) #REQUIRE>

xml:lang NMTOKEN #IMPLIED	BrandId CDATA #REQUIRED
BrandName CDATA #REQUIRED	BrandLogoNetLocn CDATA #REQUIRED
BrandNarrative CDATA #IMPLIED	ProtocolAmountRefs IDREFS #REQUIRED

ContentSoftwareId CDATA #IMPLIED>

ProtocolBrandId CDATA #REQUIRED>

	ID #REQUIRED
PayProtocolRef IDREF #REQUIRED	CurrencyAmountRefs IDREFS #REQUIRED

ContentSoftwareId CDATA #IMPLIED>

	ID #REQUIRED
Amount CDATA #REQUIRED	CurrCodeType NMTOKEN 'ISO4217-A'

CurrCode CDATA #REQUIRED>

xml:lang NMTOKEN #IMPLIED	ProtocolId NMTOKEN #REQUIRED
ProtocolName CDATA #REQUIRED	ActionOrgRef NMTOKEN #REQUIRED
PayReqNetLocn CDATA #IMPLIED	SecPayReqNetLocn CDATA #IMPLIED

ContentSoftwareId CDATA #IMPLIED >

BrandSelProtocolAmountInfo?,	BrandSelCurrencyAmountInfo?)>
	ID #REQUIRED
BrandListRef NMTOKEN #REQUIRED	BrandRef NMTOKEN #REQUIRED

ProtocolAmountRef NMTOKEN #REQUIRED

CurrencyAmountRef NMTOKEN #REQUIRED>

ContentSoftwareId CDATA #IMPLIED>

ContentSoftwareId CDATA #IMPLIED>

ContentSoftwareId CDATA #IMPLIED >

	ID #REQUIRED
OkFrom CDATA #REQUIRED	OkTo CDATA #REQUIRED
BrandListRef NMTOKEN #REQUIRED	SignedPayReceipt (True \| False) #REQUIRED

StartAfterRefs NMTOKENS #IMPLIED>

	ID #REQUIRED
PaymentRef NMTOKEN #IMPLIED	ConsumerPaymentId CDATA #IMPLIED
PaymentHandlerPayId CDATA #IMPLIED	ContentSoftwareId CDATA #IMPLIED>

	PaymentRef NMTOKEN #REQUIRED
PayReceiptNameRefs NMTOKENS #IMPLIED	ContentSoftwareId CDATA #IMPLIED>

	ID #REQUIRED
xml:lang NMTOKEN #REQUIRED	DelivExch (True \| False) #REQUIRED
DelivAndPayResp (True \| False) #REQUIRED	ActionOrgRef NMTOKEN #IMPLIED>

	NMTOKEN #IMPLIED
OkFrom CDATA #REQUIRED	OkTo CDATA #REQUIRED
DelivMethod NMTOKEN #REQUIRED	DelivToRef NMTOKEN #REQUIRED
DelivReqNetLocn CDATA #IMPLIED	SecDelivReqNetLocn CDATA #IMPLIED

ContentSoftwareId CDATA #IMPLIED>

ConsumerDeliveryId CDATA #REQUIRED>

	ID #REQUIRED
xml:lang NMTOKEN #REQUIRED	DelivHandlerDelivId CDATA #IMPLIED

ContentSoftwareId CDATA #IMPLIED >

	ID #REQUIRED
xml:lang NMTOKEN #REQUIRED	StatusType NMTOKEN #REQUIRED
ElRef NMTOKEN #IMPLIED	ProcessState (NotYetStarted \| InProgress \|
CompletedOk \| Failed \| ProcessError) #REQUIRED CompletionCode NMTOKEN #IMPLIED
ProcessReference CDATA #IMPLIED	StatusDesc CDATA #IMPLIED >

	ID #REQUIRED
Type NMTOKEN #REQUIRED	ElRef NMTOKEN #IMPLIED

ProcessReference CDATA #IMPLIED >

	NMTOKEN #REQUIRED
xml:lang NMTOKEN #REQUIRED	ErrorCode NMTOKEN #REQUIRED
ErrorDesc CDATA #REQUIRED	Severity (Warning\|TransientError\|HardError) #REQUIRED
MinRetrySecs CDATA #IMPLIED	SwVendorErrorRef CDATA #IMPLIED>

	NMTOKEN #REQUIRED
IotpMsgRef NMTOKEN #IMPLIED	BlkRef NMTOKEN #IMPLIED
CompRef NMTOKEN #IMPLIED	ElementRef NMTOKEN #IMPLIED

AttName NMTOKEN #IMPLIED>

Payment, PaySchemeData?, Org*, TradingRoleData*)>

PaymentNote?, TradingRoleData*) >

ConsumerDeliveryData?, TradingRoleData*) >

LastReceivedIotpMsgRef NMTOKEN #IMPLIED
LastSentIotpMsgRef NMTOKEN #IMPLIED>

PingStatusCode (Ok | Busy | Down) #REQUIRED
BR/P> xml:lang NMTOKEN #IMPLIEDPingStatusDesc CDATA #IMPLIED>

>

Digest+,
Attribute*,
OriginatorInfo,
RecipientInfo+ )>
>type (digest|signature) #IMPLIEDname NMTOKEN #REQUIRED>

>critical ( true | false ) #REQUIRED>

SignatureValueRef IDREF #IMPLIEDSignatureCertRef IDREF #IMPLIED
RecipientRefs NMTOKENS #IMPLIED>

#REQUIRED>

Открытый торговый протокол Интернет определяет

Семёнов Ю.А. (ГНЦ ИТЭФ), book.itep.ru Открытый торговый протокол Интернет определяет некоторое число различных операций IOTP:

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

Возврат. Производит возврат платежа для покупки, выполненной ранее.

Обмен ценностями. Включает в себя два платежа, наприммер в случае обмена валют.

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

Отзыв платежа. Осуществляет отзыв электронного платежа из финансового учрежденрия.

Депозит. Реализует депозит средств в финансовом учреждении.

Запрос. Выполняет запрос состояния операции IOTP, которая находится в процессе реализации, или уже выполнена.

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

Некоторое число организаций, выполняющих торговую функцию и

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

Оттиски (Thumbprints)

Оттиски определяются путем вычисления хэш функции SHA-1, следуя кодировке DER ASN.1 структур:

UnsignedCertificate

UnsignedCertificateRevocationList

UnsignedBrandCRLIdentifier Оттиск является тем же самым хэшем, который используется для подписи, верификации, CRL или BCI. Оттиски посылаются в сообщениях-запросах SET и могут игнорироваться получателем. Отправитель не обязан посылать все оттиски для всех сертификатов, CRL и BCI, имеющимся в его кэше, а только те, которые имеют отношение к конкретной паре сообщений запрос/отклик. Например, программа продавца не обязана посылать оттиски для всех держателей карт или всем платежным системам. Процедура отправки оттиска представлена в таблице 4.6.2.7. Таблица 4.6.2.7. Посылка оттиска

Шаг	Действие
1	Инициализировать буфер для запоминания оттисков
2	Добавить оттиск (хэш): Для каждого сертификата, который имеется в кэше отправителя и имеет отношение к обрабатываемому сообщению-отклику и для всей цепочки сертификатов добавляется оттиск (хэш), соответствующий этому сертификату. Для каждого CRL, который имеется в кэше отправителя и имеет отношение к обрабатываемому сообщению-отклику и для всей цепочки сертификатов добавляется оттиск (хэш), соответствующий этому CRL. Для каждого BCI, который имеется в кэше отправителя и имеет отношение к обрабатываемому сообщению-отклику и для всей цепочки сертификатов добавляется оттиск (хэш), соответствующий этому BCI.
3	Присылается результат работы шага 2.

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

Шаг	Действие
1	Инициализировать буфер для запоминания оттисков
2	Для каждого из них: Для сертификата, который имеет отношение к обрабатываемому сообщению-отклику и ко всей цепочке сертификатов, проверить соответствует ли оттиск (хэш) сертификата одному из полученных в сообщении-запросе. Если соответствие найдено, сертификат в кэше удаленной системы существует и его не нужно включать в отклик. Если соответствия нет или список пуст, то включить сертификат в сообщение отклик. Для CRL, который имеет отношение к обрабатываемому сообщению-отклику и ко всей цепочке сертификатов, проверить, соответствует ли оттиск (хэш) одному из оттисков, полученных в сообщении-запросе. Если соответствие имеется, то CRL в кэше удаленной системы существует и его не следует помещать в отклик. Если соответствия нет или список пуст, то данное CRL включается в отклик. Для BCI, который имеет отношение к обрабатываемому сообщению-отклику и ко всей цепочке сертификатов, проверить, соответствует ли CRL-оттиск (хэш) одному из оттисков, полученных в сообщении-запросе. Если соответствия нет или список пуст, то данное CRL включается в отклик.
3	Присылается результат работы шага 2 со списком сертификатов, CRL и BCI, которые следует послать в отклике.

Простая инкапсуляция с оператором подписи Enc(s,r,t) представляет данные, которые были сначала подписаны, а затем зашифрованы. Этот случай соответствует варианту PKCS#7 SignedData, инкапсулированных в EnvelopedData. Процедура выполняется следующим образом.

Шаг	Действие
1	Используя оператор подписи и секретный ключ объекта s, подписать содержимое группы t
2	Добавить результат шага 1 в группу t
3	Используя оператор асимметричного шифрования и общедоступный ключ получателя r, зашифровать результат шага 2
4	Послать результат работы шага 3

Другие варианты инкапсуляции осуществляются сходным образом. Асимметричный оператор шифрования E(r,t) соответствует EnvelopedData PKCS#7 для группы t, зашифрованной для объекта r. Этот оператор включает в себя быстрое симметричное шифрование основного объема данных, а также асимметричное шифрование секретного ключа предшествующего шифрования с привлечением общедоступного ключа получателя. Протоколом шифрования по умолчанию для SET является DES, а для асимметричного шифрования - RSA. Последовательность операций при асимметричном шифровании представлена в таблице 4.6.2.9. Таблица 4.6.2.9. Процедура асимметричного шифрования

Шаг	Действие
1	Инициализировать и загрузить информационные поля, зависимые от типа сообщения
2	Преобразовать информационные поля, подлежащие шифрованию, в формат DER
3	Сформировать новый ключ DES
4	Зашифровать результат работы шага 2, используя ключ DES из шага 3. Используется режим DES-CBC.
5	Инициализировать буфер зашифрованных данных с помощью кода типа данных, идентификатора алгоритма и добавить эту информацию к результату шага 4.
6	Инициализировать буфер цифрового конверта, в зависимости от получателя (128 байт)
7	Инициализировать буфер дополнительного шифрования OAEP с использование ключа из шага 3.
8	Применить OAEP для буфера цифрового конверта
9	Зашифровать результат шага 8, используя асимметричный общедоступный ключ объекта r
10	Инициализировать информационный буфер получателя посредством идентификатора алгоритма RSA и добавить туда результат работы шага 9
11	Инициализировать буфер EnvelopedData PKCS#7 и положить туда результат шага 10 и 5
12	Прислать результат шага 11

Оператор шифрования с гарантией целостности EH(r,t) подобен Е за исключением того, что цифровой конверт PKCS#7 включает в себя хэш группы t.

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

Шаг	Действие
1	Инициализировать и загрузить информационные поля, зависимые от типа сообщения
2	Преобразовать информационные поля, подлежащие шифрованию, в формат DER
3	Вычислить хэш SHA-1 результата шага 2
4	Сформировать новый ключ DES
5	Зашифровать результат работы шага 2, используя ключ DES из шага 4. Используется режим DES-CBC.
6	Инициализировать буфер зашифрованных данных с помощью кода типа данных, идентификатора алгоритма DES и добавить эту информацию к результату шага 5.
7	Инициализировать буфер цифрового конверта, в зависимости от получателя (128 байт)
8	Инициализировать буфер дополнительного шифрования OAEP с использование ключа из шага 4 и хэша, вычисленного на шаге 5.
9	Применить OAEP для буфера цифрового конверта
10	Зашифровать результат шага 9, используя асимметричный общедоступный ключ объекта r
11	Инициализировать информационный буфер получателя посредством идентификатора алгоритма RSA и добавить туда результат работы шага 10
12	Инициализировать буфер PKCS#7 и положить туда результат шага 11 и 6
13	Прислать результат шага 12

Оператор симметричного шифрования EK(k,t) шифрует открытый текст группы t с привлечением ключа k. Для целей шифрования здесь могут использоваться алгоритмы DES или CDMF. Процедура симметричного шифрования представлена в таблице 4.6.2.11. Таблица 4.6.2.11. Процедура симметричного шифрования

Шаг	Действие
1	Инициализировать и загрузить информационные поля, зависимые от типа сообщения
2	Преобразовать информационные поля, подлежащие шифрованию, в формат DER
3	Зашифровать результат работы шага 2, используя ключ k. Применяется алгоритм DES или CDMF в зависимости от того, какой из этих алгоритмов поддерживается получателем сообщения. Для DES используется режим DES-CBC.
4	Инициализировать буфер зашифрованных данных с помощью кода типа данных, идентификатора алгоритма (DES или CDMF) и добавить к этой информации результат шага 3.
5	Прислать результат шага 4

Оператор цифровой подписи S(s,t) соответствует PKCS#7 SignedData для группы t, подписанной объектом s.

Для SET алгоритмом подписи по умолчанию является RSA с хэшем SHA-1. Обычно для SET подпись делается до шифрования. Операция цифровой подписи для SignedData всегда производится над данными, представленными в формате DER (ASN.1). Операции подпись SignedData никогда не производятся для произвольных строк октетов (например, для ASCII-строк). По этой причине тип содержимого data не используется никогда. PKCS#7 требует включения в подписываемый текст двух аутентифицированных атрибутов. Такими атрибутами являются contentType и messageDigest, оба они включаются в содержимое, которое подписывается в рамках SET. SignedData имеет формат DER, и содержат октеты тэга и длины атрибутов. Исходные данные для расчета дайджеста сообщения берутся из компонента content последовательности ContentInfo. ContentInfo связывает идентификатор компонента contentType с типом компонента >content. В SET каждый тип содержимого однозначно именуется объектным идентификатором. Так как это значение не защищено от атак подмены, он также включается в authenticateAttributes. Атрибут contentType специфицирует идентификатор объекта, который соответствует значению компонента contentType последовательности ContentInfo. Атрибут messageDigest содержит значение хэшированного компонента content ContentInfo. Определение последовательности SignerInfos в PKCS#7 допускает любое число подписантов (по одному SignerInfo на каждого). SET PKCS#7 SignedData требует наличия одного подписанта для всех сообщений кроме CertReq и CertInqReq, которые требуют две подписи, когда используются для обновления сертификата. Таким образом, требования SET несколько мягче, чем PKCS#7. В компоненте SignerInfo из SignerInfos как authenticateAttributes, так и unauthenticateAttributes компоненты специфицируются опционно. В SET компонент unauthenticateAttributes последовательности SignerInfo всегда отсутствует и никогда не появляется при кодировании SignedData. Компонент же authenticateAttributes всегда присутствует и включается в процесс вычисления дайджеста.

Процедура цифровой подписи представлена в таблице 4.6.2.12. Таблица 4.6.2.12. Процедура формирования цифровой подписи

Шаг	Действие
1	Инициализировать тип SignedData, введя код версии, идентификатор алгоритма и тип содержимого, подлежащего подписанию
2	Преобразовать информацию, подлежащую подписанию в формат DER
3	Использовать результат шага 2 для инициализации компонента content из ContentInfo.
4	Инициализировать тип SignerInfo, введя код версии, идентификаторы алгоритмов вычисления и шифрования дайджеста
5	Вычислить дайджест сообщения, используя SHA-1 для результата шага 3
6	Инициализировать структуру authenticatedAttributes и занести в структуру атрибуты contentType и messageDigest. Установить компоненты type атрибутов равными идентификаторам этих атрибутов
7	Инициализировать компонент values первого атрибута типа кодом содержимого, подлежащего подписанию, а второго атрибута - значением дайджеста, вычисленного на этапе 5
8	Закодировать аутентифицированные атрибуты и зашифровать результат, используя секретный ключ отправителя. Поместить результат в SignedData
9	Выбрать соответствующие сертификаты Х.509 и CRL, необходимые для верификации подписи, и включить их в SignedData
10	Если тип сообщения требует двух подписей, повторить шаги с 4 по 9

Оператор ключевого хэширования HMAC(t,k) соответствует 160-битовому хэшу HMAC-SHA-1 для группы t при использовании секретного ключа k. Эта функция нужна для сокрытия номера счета в сертификате владельца карты. Секретный ключ известен только владельцу карты и эмитенту. Процедура ключевого хэширования представлена в таблице 4.6.2.13. Таблица 4.6.2.13. Процедура ключевого хэширования

Шаг	Действие
1	Установить ipad соответствующим буферу, который содержит 64 байта с кодами 0х36
2	Установить opad равным буферу, содержащему 64 байта с кодами 0х5С
3	Добавить нули в конец k, чтобы размер строки стал равным 64 байтам. Например, если длина k равна 20 байт, то следует добавить 44 нуля.
4	Осуществить операцию побитового исключающего ИЛИ для результата шага 3 и ipad
5	Добавить данные группы t в 64-байтовый буфер, сформированный на этапе 4
6	Вычислить хэш SHA-1 для результата шага 5 с привлечением Hash-оператора
7	Осуществить операцию побитового исключающего ИЛИ для результата шага 3 и opad
8	Добавить результат SHA-1 шага 6 к 64-байтовому буферу, заполненному в результате шага 7
9	Вычислить хэш SHA-1 для результата шага 8 с привлечением Hash-оператора
10	Прислать результат работы шага 9

Оператор хэширования H(t) соответствует 160-битовому хэшу SHA-1 для группы t.

Этот оператор соответствует параметризованному типу ASN.1 H{}. Он используется только в обработке OAEP. Оператор DigestedData DD(T) соответствует 160-битовому хэшу SHA-1 группы, вложенной в последовательность PKCS DigestedData. Протокол SET использует параметризованный тип DD{} (detached digests). Каждый тип содержимого типа дайджест в SET имеет имя, уникальный идентификатор объекта. Компонент contentType из ContentInfo делается равным значению этого идентификатора. Компонент digest из DigestedData является результатом вычисления дайджеста сообщения. Он содержит дайджест сообщения типа SET, идентифицируемый компонентом contentType из contentInfo. Дайджест вычисляется с помощью алгоритма из перечня DigestAlgorithm. Вычисление производится для полного DER-представления, включая тэг, длину в октетах и типа ASN.1. Компонент digestAlgorithm из DigestedData устанавливается равным одному из значений кодов алгоритма. Код digestAlgorithm используется получателем для проверки дайджеста сообщения. Верификация осуществляется путем независимого вычисления дайджеста сообщения и сравнения его значения с компонентом digest из DigestedData. Последовательность действий показана в таблице 4.6.2.14. Таблица 4.6.2.14. Процедура вычисления дайджеста сообщения.

Шаг	Действие
1	Установить B равным адресу группы t, для которой вычисляется дайджест
2	Установить L равным длине группы t
3	Инициализировать 160-битный буфер для хранения хэша SHA-1
4	Вычислить хэш SHA-1 для буфера, используя B и L
5	Положить результат шага 4 в поле digest DigestedData
6	Положить идентификатор хэш-алгоритма SHA-1 в digestAlgorithm
7	Установить значение версии равным нулю

Оператор связи L(t1,t2) соответствует последовательности t1 и DigestedData. Компонент связи DigestedData содержит дайджест сообщения для группы t2 и может быть представлен посредством DD(t2). Оператор связи не является симметричным и не может связать t2 с t1. Целью OAEP является обеспечение гарантии того, что отдельные фрагменты сообщения не будут извлечены из блока PKCS#7.

Существуют криптографические методы, которые позволяют определить одни биты сообщения легче, чем другие. OAEP случайным образом перераспределяет биты блока PKCS#7 так, что все биты становятся с этой точки зрения эквивалентными. Примитивы шифрования E, EH, EX и EXH объединяют RSA-шифрование и алгоритм OAEP (Bellare-Rogaway Optimal Asymmetric Encryption Padding). SET использует OAEP для получения дополнительной защиты информации о счете клиента (владельца карты, продавца или получателя) с помощью цифрового конверта. Реализация алгоритма OAEP продемонстрирована в таблице 4.6.2.15. Таблица 4.6.2.15. Описание алгоритма OAEP

Шаг	Действие
1	Подготовить дополнительные данные, как это описано в формате сообщения
2	Если используется оператор шифрования EH или EXH, вычислить хэш SHA-1 для данных подлежащих DES-шифрованию
3	Сформировать новый случайный ключ для DES-шифрования регулярной части данных
4	Объединить DES-ключ, хэш SHA-1 данных (HD) перед DES-шифрованием (если оно применяется) и любые дополнительные данные, чтобы сформировать действительный блок данных ADB (Actual Data Block).
5	Взять байт, содержащий код 0х03 (тип блока - BT), семь байтов нулей (байты верификации - V) и байт блока содержимого (BC) и положить в ADB, тем самым формируя блок данных (DB). DB= BT\|BC\|V\|ADB
6	Сгенерировать случайную 16-битовую строку E-Salt и вычислить H1(E-Salt). H1 выдает лидирующие байты хэша SHA-1
7	Вычислить А=DB Е H1(E-Salt)
8	Осуществить присвоение B= E-Salt Е H2(A). Сформировать PDB, объединив А и В. Н2 предоставляет завершающие байты хэша SHA-1
9	Присвоить I случайное значение, не равное 0х00 или 0х80
10	Зашифровать полученный блок R с помощью RSA

Алгоритм работа OAEP показан на рисунке 4.6.2.9. В DB присутствуют только информационные элементы типа атомик (в нотации ASN.1). Каждый элемент DB кодируется согласно требованиям DER, но без тэгов и октетов длины. При преобразовании из DER-формата в DB к концу блока данных могут добавляться нули (0х00). При обратном преобразовании такие заполнители удаляются.

Рис. 4.6.2.9.

Диаграмма работы OAEP Обработка ошибок Каждому сообщению-запросу должно соответствовать сообщение-отклик. Сообщения об ошибках могут соответствовать как запросам, так и откликам. Сообщение об ошибке указывает, что приславший его не смог разобрать формат полученного запроса или отклика, или при обработке потерпели неудачу верификационные тесты. Не следует путать отрицательный отклик с сообщением об ошибке. Сообщение об ошибке посылается при невозможности обработать входное сообщение. Сообщение Error не посылается, например, при непрохождении аутентификации. Причиной сигнала ошибки может быть искажение пакета при транспортировке по локальной сети или через Интернет, нелегальные значения полей сообщения или протокольные искажения. Для выявления сообщений-дубликатов достаточно использовать открытый текст, содержащийся в цифровом конверте сообщения. Реакция получателя на сообщение-дубликат зависит от свойств идемпотентности конкретного типа сообщения, от числа дубликатов, частоты их поступления и от того, кто является их отправителем. Поврежденным сообщением считается такое, которое не может быть обработано. В норме такие сообщения не должны приходить, так как имеется контроль корректности пакетов на транспортном уровне и при обнаружении любых повреждений сообщение должно быть переслано повторно. Но если такое “невозможное событие” все-таки произойдет, будет послано сообщение Error, содержащие код типа ошибки и идентификатор сообщения, ее вызвавшего. Приложение никогда не посылает сообщение Error в ответ на другое сообщение Error. Сообщения, которые не являются протокольными для SET, просто игнорируются. Если тэг типа сообщения равен 999 (указывая, что это сообщение об ошибке), приложение SET не должно ни при каких обстоятельствах посылать на него отклик. Когда приложение сталкивается с ошибкой, оно формирует Error-сообщение в следующей последовательности.

Шаг	Действие
1	Сформировать ErrorTBC следующим образом: Установить ErrorCode равным значению, указывающему на причину (см. табл. 4.6.2.16) Сформировать новый ErrorNonce Если ошибка случилась из-за того, что приложение не знает, как обрабатывать расширение сертификата или сообщения, занести в ErrorOID объектный идентификатор расширения. Если ошибка произошла из-за проблем с сертификатом, занести в ErrorThamb ThumbPrint сертификата Если ошибка является результатом неудачной верификации подписи, занести в ErrorThamb хэш сертификата ErrorMsg формируется следующим образом: заносится MessageHandler или все сообщение (но не более 20 килобайт). Выбор того, следует ли заносить все сообщение или только заголовок, оставляется на усмотрение разработчика.
2	Подписать сообщение Error, если имеется сертификат подписи
3	Вызвать формирование цифрового конверта и отправить сообщение

Для сообщения Error определены следующие поля

Имя поля	Описание
Error	Error, UnsignedError >
SignedError	S(EE, ErrorTBS)
UnsignedError	ErrorTBSНеподписанная версия Error будет использоваться, если объект не имеет сертификата подписи
ErrorTBS	{ ErrorCode, ErrorNonce, [ErrorOID], [ErrorThumb], ErrorMsg}
ErrorCode	Цифровой код, определяющий условия ошибки (см. табл. 4.6.2.16)
ErrorNonce	Разовый код, который гарантирует, что подпись генерируется для трудно предсказуемых данных
ErrorOID	Объектный идентификатор неподдерживаемых критических расширений, вызвавших ошибку
ErrorThumb	Оттиск сертификата, который вызвал ошибку или хэш сертификата, если произошла ошибка верификации подписи
ErrorMsg
MessageHeader	Заголовок сообщения, которое вызвало ошибку
BadWrapper	Цифровой конверт сообщения, которое вызвало ошибку (не более 20 килобайт)

Таблица 4.6.2.16. ErrorCode

Ошибка	Описание
unspecifiedFailure	Причина неудачи не фигурирует в списке стандартных ошибок
messageNotSupported	Этот вполне корректный тип сообщения не поддерживается получателем
decodingFailure	Произошла ошибка в процессе DER-кодирования сообщения
invalideCertificate	Сертификат, необходимый для обработки сообщения, некорректен. Поле ErrorThumb идентифицирует этот сертификат.
expiredCertificate	Время действия сертификата, необходимого для обработки сообщения, иссякло. Поле ErrorThumb идентифицирует этот сертификат.
revokedCertificate	Сертификат, необходимый для обработки сообщения, отозван. Поле ErrorThumb идентифицирует этот сертификат.
missingCertificate	Сертификат, необходимый для обработки этого сообщения, отсутствует в кэше сертификатов получателя.
signatureFailure	Цифровая подпись сообщения не может быть верифицирована
badMessageHeader	Заголовок сообщения не может быть обработан
wrapperMsgMismatch	Содержимое цифрового конверта сообщения не согласуется с внутренним содержимым сообщения.
versionTooOld	Номер версии сообщения слишком стар для получателя
versionTooNew	Номер версии сообщения слишком нов для получателя
unrecognizedExtension	Сообщение или сертификат содержит критическое расширение, которое получатель не может обработать. Поле ErrorOID идентифицирует расширение. Если расширение присутствует в сертификате, поле ErrorThumb идентифицирует сертификат
messageTooBig	Сообщение слишком длинно для получателя
signatureRequired	Неподписанная версия сообщения неприемлема
messageTooOld	Дата сообщения слишком далеко в прошлом для получателя
messageTooNew	Дата сообщения слишком близка для получателя
thumbsMismatch	Оттиск, посланный в неподписанном запросе, не согласуется с тем, что прислано запрашивающей стороне
unknownXID	Получен неизвестный RRPID
challengeMismatch	Вызов, посланный в запросе, не согласуется с вызовом в отклике

Так как сообщения Error могут посылаться, в том числе и в ответ на отклик, возникает проблема при работе с протоколами, базирующимися на алгоритмах запрос-отклик (например, HTTP). В этом случае сообщение об ошибке может посылаться в качестве запроса, на который необязательна посылка отклика. На нижележащем протокольном уровне при этом может происходить таймаут. Работа с сертификатами В работе с сертификатами участвуют девять субъектов. Иерархия этих субъектов представлена на рис. 4.6.2.10. Верхнюю позицию в иерархии занимает корневой центр сертификации. Корневой сертификат следует требованиям документа X.509 (версия 3) с некоторыми расширениями, вводимыми протоколом SET. Прежде чем система будет развернута, должны быть проделаны следующие операции:

Нужно сформировать пару #1 корневых ключей R1

Сгенерировать сертификат для корневого ключа #1 (C1)

Сформировать пару #2 корневых ключей R2

Вычислить оттиск (хэш - H2) общедоступной составляющей R2 С1 рассылается при развертывании системы и является самоподписываемым. Корневой сертификат SET доставляется приложению с помощью протокола запроса сертификата и платежного протокола. Начальное значение корневого сертификата, его общедоступный ключ или хэш общедоступного ключа могут быть доставлены и программой приложения SET. Как только приложением получен новый корневой сертификат, оно проверяет через расширение HashedRootKey связь с предыдущим корневым сертификатом. Когда приходит время заменить корневой сертификат R1, производятся следующие операции:

Вычисляется общедоступная часть корневого ключа #3 (R3)

Определяется оттиск R3 (хэш H3)

Формируется сертификат корневого ключа #2 (C2 - содержит H3) Новый корневой сертификат рассылается с использованием SET-сообщений или методик HTTP, FTP или SMTP. Приложение SET проверяет подпись, используя R2, вычисляет хэш R2 и сравнивает его с H2, полученным из расширения в С1.

Рис. 4.6.2.10. Иерархия субъектов сертификации Из списка этих субъектов один является опционным, это GCA (Геополитический центр сертификации - Geo-Political Certificate Authority).

Проверка сертификатов производится строго в соответствии с данной иерархической схемой. Доступ к корневому центру сертификации производится крайне редко, только в случае получения нового сертификата платежной системы или при обновлении корневого сертификата. При взаимодействии с ним привлекается в максимально возможной мере аппаратный контроль. Если произойдет раскрытие секретного ключа платежной системы, то RCA сформирует и разошлет новый список отмененных сертификатов CRL (Certificate Revocation List). BCA являются независимыми для каждой платежной системы и реализуются практически теми же мерами безопасности, как и RCA. Эти центры служат для формирования и рассылки геополитических и/или сертификатов владельцев карты, продавцов или платежных центров, размещенных ниже по иерархии. Они также ответственны за обновление и рассылку списков CRL и BCI, содержащие все CRL платежной системы. Геополитические центры сертификации (являются опционными) позволяют платежным системам перераспределять ответственность между отдельными географическими и политическими регионами. Эти центры ответственны за формирование и рассылку соответствующих региональных CRL. Центры сертификации владельцев карт (ССА) формируют по запросу и отсылают сертификаты владельцам платежных карт. Запрос сертификата может быть послан через WEB или по электронной почте. ССА поддерживают взаимоотношения с эмитентами карт для сертификации счетов владельцев карт. ССА также занимаются рассылкой CRL, сформированных RCA, BCA, GCA и центров сертификации платежных центров. Функции CCA может выполнять центр платежной системы, эмитента карты или какой-то иной субъект, который отвечает требованиям конкретной платежной системы. Центр МСА ответственен за рассылку сертификатов продавцам. Получатели (Acquirers) проверяют и одобряют запросы сертификатов продавца до их выдачи центром MCA. Центр PCA служит для выдачи сертификатов для платежных центров. Их функции, также как и в случае CCA, могут выполняться центрами платежной системы, получателя и т.д. Любой центр сертификации выполняет следующие функции:

Формирование и выдача сертификата

Обновление сертификатов

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

Для владельцев карты формируются только сертификаты подписи, для продавцов и платежных центров формируются сертификаты подписи и шифрования. Сертификаты для владельцев карт формируются центрами CCA. Выпуск сертификата держателя карты включает в себя следующие обмены между держателем карты и CCA (см. также рис. 4.6.2.2).

Владелец карты посылает запрос сертификата

ССА производит шифрование сертификата для защиты передачи номера платежной карты в ССА

Владелец шифрует номер своей карты, используя сертификат ССА, и посылает результат в ССА

ССА откликается посылкой формы для регистрации сертификата карты

Владелец карты заполняет форму, которая включает в себя его общедоступный ключ, и посылает форму в ССА для регистрации

ССА верифицирует полученную регистрационную информацию с привлечением эмитента карты и генерирует сертификат, подписывает его и посылает владельцу карты. Для продавцов сертификаты формируются в центрах MCA. Перед выпуском сертификата продавца запрос верифицируется банком продавца (получатель - acquirer) или центром управления платежной системы. Сертификат получается продавцом в результате последовательности следующих операций.

Продавец посылает запрос сертификата в МСА.

МСА откликается посылкой регистрационной формы.

Продавец заполняет форму и посылает ее и свой общедоступный ключ в МСА для обработки.

Банк продавца или центр управления платежной системы проверяет запрос продавца и МСА генерирует, подписывает и посылает сертификат продавцу. Сертификаты платежного центра формируются и присылаются центром PCA. Процедура генерации сертификата сходна с вариантом продавца. Банк продавца верифицирует запрос сертификата платежного центра и авторизует генерацию сертификата в РСА. Сертификаты центров сертификации формируются вышестоящими по иерархии узлами. Обновление любых сертификатов производится периодически и следует тем же алгоритмам, что и формирование совершенно нового сертификата. Регистрационная форма при обновлении сертификата может содержать существенно меньше информации. Аннулирование сертификата может производиться по разным причинам, например, из-за реального или кажущегося раскрытия секретного ключа, из-за изменения регистрационной информации или по причине истечения срока пригодности.

При аннулировании идентификатор и некоторые другие характеристики сертификата заносятся немедленно в список CRL. Последний сразу подлежит рассылке всем субъектам, которые могут использовать этот сертификат. При выполнении любой операции в рамках протокола SET производится проверка всех сертификатов, образующих иерархическую цепочку (см. рис. 4.6.2.11), начиная от конечного объекта (ЕЕ) до корневого (Root). Стрелки означают, чей сертификат использовался для подписи. Таким образом, каждый сертификат связан с сертификатом подписи субъекта его сформировавшего.

Рис. 4.6.2.11. Иерархия проверок Основной протокол Далее рассматривается протокол и обработка откликов владельца карты, продавца или платежного центра (конечный объект - EE), а также получение подписей и/или сертификатов Х.509 шифрования данных от СА (Certificate Authority). Протокол определяет процедуры получения первого сертификата или обновления предшествующего. Прежде чем запросить сертификат владелец карты должен выполнить следующее:

Получить счет в одной из платежных систем, например, в VISA или MasterCard.

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

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

Иметь URL или электронный почтовый адрес для связи с ССА.

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

Идентификатор, присланный получателем (Acquirer - банк продавца)

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

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

URL или электронный почтовый адрес для связи с MCA.

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

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

Получить банковский идентификационный номер BIN (Bank ID)

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

Объем и характер этой информации согласуется с банком продавца.

Иметь URL или электронный почтовый адрес для связи с PCA

Обзавестись прикладной программой (например, броузером), поддерживающей протокол SET. После того как приложение запущено, стартуют сертификационные обмены между владельцем карты и CCA, между продавцом и MCA, а также между платежным центром и PCA. В результате участники получают необходимые сертификаты подписи и шифрования. Так взаимодействие владельца карты и ССА предполагает следующие обмены:

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

ССА посылает приложению SET сообщение CardCInitRes.

Приложение владельца карты посылает ССА сообщение RegFormReq.

ССА отправляет сообщение RegFormRes, содержащее регистрационную форму и формулировку общих требований.

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

ССА формирует сертификат, включает его в CertRes и посылает владельцу карты. Функционирование приложения продавца и платежного центра имеет свою специфику:

Приложение SET посылает сертификационному центру СА сообщение Me-AqCInitReq, при этом используется BIN и идентификатор продавца, полученные от системного администратора продавца или платежного центра.

СА посылает приложению SET сообщение Me-AqCInitRes, содержащее регистрационную форму и формулировку общих требований.

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

Приложение SET включает в CertReq заполненную форму, новый общедоступный ключ и сертификат, подлежащий обновлению (если он имеется) и посылает это все СА.

СА формирует сертификат, включает его в CertRes и посылает продавцу или платежному центру. Схемы таких обменов для получения нового или обновления старого сертификатов представлены на рис. 4.6.2.12 и 4.6.2.13.

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

Рис. 4.6.2.12. Схема обмена сообщениями при получении сертификата между владельцем карты и ССА Если ЕЕ уже имеет регистрационную информацию, обмены CardCInitReq/Res и RegFormReq/Res могут быть опущены. При работе через WWW используется во всех случаях полный перечень обменов. После того как приложение SET инициализировано, владелец карты посылает ССА сообщение CardCInitReq, указывающее через оттиски на сертификаты, CRL и BrandCRLIdentifier, которые содержаться в его кэше сертификатов. ССА реагирует посылкой сообщения CardCInitRes, содержащего любые сертификаты, CRL и BrandCRLIdentifier, которые потребуются владельцу карты для верификации подписи, а также сертификат шифрования, используемый для последующих сообщений. Приложение SET формирует сообщение CardCInitReq следующим образом.

Шаг	Действие
1	Генерируется RRPID
2	Генерируется LID-EE
3	Формируется новый случайный Chall-EE
4	Копируется BrandID, который запомнен или получен в инициализирующем сообщении
5	Опционно заполняется поле Thumbs, которое содержит оттиски для каждого CRL, сертификатов SET, BrandCRLIdentifier и корневой сертификат, резидентный в кэше владельца карты
6	Формируется цифровой конверт сообщения, чтобы послать CardCInitReq центру ССА

Структура сообщения CardCInitReq охарактеризована в таблице 4.6.2.17. Таблица 4.6.2.17. Структура сообщения CardCInitReq

CardCInitReq	{RRPID, LID-EE, Chall-EE, BrandID, [Thumbs]}
RRPID	Идентификатор пары запрос/отклик
LID-EE	Локальный ID, сформированный для системы владельца карты
Chall-EE	Вызов владельца карты по поводу пригодности подписи, адресованный ССА
BrandID	Идентификатор платежной системы для запрошенного сертификата
Thumbs	Список оттисков сертификатов (включая корневой), CRL и BrandCRLIdentifier, которые хранятся в данный момент владельцем карты

ССА, получив CardCInitReq, выполнит следующие операции:

Шаг	Действие
1	Получить CardCInitReq из сообщения Receive
2	Проверить, что RRPID в CardCInitReq соответствует RRPID в цифровом конверте сообщения. Если проверка не прошла, присылается сообщение об ошибке с кодом ErrorCode= unknownRRPID
3	Запомнить список откликов, LID-EE, Chall-EE и RRPID, которые должны быть использованы в CardCInitRes

После того как ССА обработает CardCInitReq, он выполнит следующие шаги, для того чтобы сформировать CardCInitRes. Как и в случае SignedData, сертификаты и CRL, нужные для верификации подписи, включаются в CardCInitRes вне данных, которые должны быть подписаны. Последовательность действий представлена ниже в таблице.

Шаг	Действие
1	Сформировать структуру данных CardCInitResTBS, для этого: Скопировать RRPID, LID-EE и Chall-EE, полученные из сообщения CardCInitReq Сформировать опционно LID-CA Заполнить CAEThumb оттиском сертификата шифрования данных CCA Если BrandCRLIdentifier не специфицирован в списке оттисков, полученном в CardCInitReq, занести BrandCRLIdentifier Скопировать список оттисков из CardCInitReq
2	Подписать DER-кодированный массив кодов CardCInitResTBS, установить тип содержимого SigneadData равным id-set-content- CardCInitResTBS.Включить в SigneadData любые сертификаты, CRL или BrandCRLIdentifier, которые отсутствуют в списке оттисков.
3	Сформировать цифровой конверт сообщения и послать сообщение CardCInitRes владельцу карты

Формат отклика CardCInitRes представлен в таблице ниже.

CardCInitRes	S(CA, CardCInitResTBS)
CardCInitResTBS	{RRPID, LID-EE, Chall -EE, [LID-CA], CAEThumb, [BrandCRLIdentifier], [Thumbs]}
RRPID	Идентификатор пары запрос/отклик
LID-EE	Копируется из CardCInitReq
Chall-EE	Копируется из CardCInitReq
LID-CA	Локальный ID. Генерируется системойCCA или для нее
CAEThumb	Оттиск сертификата ключевого обмена CCA, котоый владелец карты должен использовать для шифрованияRegFormReq
BrandCRLIdentifier	Смотри секцию описания BrandCRLIdentifier
Thumbs	Копируется из CardCInitR

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

Шаг	Действие
1	Получить CardCInitRes из входного сообщения (Receive)
2	Проверить, что RRPID соответствует тому, что был послан в CardCInitReq и тому, который получен в цифровом конверте сообщения CardCInitRes. Если соответствия нет, посылается сообщение об ошибке с кодом ErrorCode равным unknownRRPID
3	Проверить, что полученный список оттисков соответствует тому, что был послан в сообщении CardCInitReq. Если соответствия нет, посылается сообщение об ошибке с кодом ErrorCode равным thumbsMismatch
4	Проверить, что полученный Chall-EE равен посланному в CardCInitReq. Если равенство отсутствует, посылается сообщение об ошибке с кодом ErrorCode равным challengeMismatch.
5	Запомнить LID-CA (если этот элемент был включен) для последующей записи в RegFormReq. Проверить, что полученный Chall-EE равен посланному в CardCInitReq.
6	Проверить, что приложение владельца карты поддерживает один из алгоритмов, перечисленных в туннельном расширении сертификата шифрования CA. Если приложение владельца карты не поддерживает ни одного общего с СА алгоритма, следует уведомить об этом пользователя и прервать дальнейшую обработку сообщения СА.

Если приложение владельца карты успешно обработало отклик CardCInitRes, оно может сформировать и послать сообщение RegFormReq. Это сообщение шифруется приложением владельца карты с использованием сертификата, полученного от ССА в CardCInitRes. Последовательность формирования и посылки RegFormReq представлена ниже в таблице.

Шаг	Действие
1	Сформировать RegFormReqData согласно следующему формату: Сформировать новый RRPID Скопировать LID-EE, посланный в CardCInitReq Сформировать новый Chall-EE2 Если такой элемент был включен в CardCInitRes, скопировать LID-CA Заполнить RequestType согласно таблице 4.6.2.19, где представлены коды поля RequestType регистрационной формы владельца карты Заполнить поле языка (Language) Опционно ввести список оттисков для каждого CRL, сертификата SET, BrandCRLIdentifier и корневого сертификата, резидентных для кэша оттисков владельца карты (если таковой имеется).
2	Сформировать структуру RegFormReqTBE: Ввести ReqFormReqData Заполнить поле PANOnly, используя PAN и ExNonce. В PAN не используется заполнитель. Сформировать хэш SHA-1 для DER-кодированного PANOnly. Установить код типа содержимого digestedData равным id-set-content-PANOnly
3	Оформить поле данных, подлежащих дополнительному шифрованию: Заполнить PAN. Если PAN имеет длину менее 19 байт, дополнить его до 19 байт Для маскирования PAN сгенерировать новый EXNonce
4	Зашифровать данные, используя оператор EXH со следующими параметрами: RegFormReqTBE в качестве данных, подлежащих шифрованию, и типом contentType данных Envelopeddata равным id-set-content-RegFormReqTBE и Результатом шага 3 в качестве данных, подлежащих шифрованиюДля шифрования используется сертификат идентифицированный CAEThumb в CardCInitRes
5	Вложить результат в цифровой конверт комбинированного сообщения и послать RegFormReq в центр СА

Структура сообщения RegFormReq представлена в таблице 4.6.2.18. Таблица 4.6.2.18. Структура RegFormReq

RegFormReq	EXH(CA, RegFormReqData, PANOnly)
RegFormReqData	{RRPID, LID-EE, Chall-EE2,[LID-CA], RequestType, Language, [Thumbs]}
PANOnly	Структуру смотри в табл. ниже
RRPID	ID пары запрос/отклик
LID-EE	Копируется из CardCInitRes
Chall-EE2	Вызов ЕЕ, имеющий целью обновление подписи СА
LID-CA	Копируется из CardCInitRes
RequestType	Смотри табл. 4.6.2.19
Language	Предпочтительный язык последующего текста
Thumbs	Списки сертификатов (включая корневой), CRL и BrandCRLIdentifier, хранимых в данный момент владельцем карты

Поля данных PANOnly

Имя поля	Описание
PAN	Номер платежной карты владельца
EXNonce	Случайное число, используемое для маскирования PAN

Таблица 4.6.2.19. Значения кодов RequestType

Тип запроса	Только сертификат подписи	Только сертификат шифрования	Оба сертификата
Начальный запрос владельца карты	1	2*	3*
Запрос обновления владельца карты	10	11*	12*

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

Шаг	Действие
1	Извлечь RegFormReq из входного сообщения
2	Заполнить PAN из данных, которые подлежат шифрованию. Это делается после удаления заполнителя.
3	Из данных RegFormReqData запомнить RequestType, RRPID, LID-EE, Chall-EE2, LID-CA, список оттисков (Thumbs) и код языка.
4	Проверить, что RRPID, полученный из цифрового конверта сообщения соответствует одному коду из RegFormReqTBE. Если соответствия нет, возвращается сообщение об ошибке с ErrorCode равным unknownRRPID

После верификации RegFormReq CCA генерирует RegFormRes следующим образом. Если верификация запроса прошла успешно, присылается регистрационная форма, уведомление о политике, URL платежной системы и логотип карты. В случае неудачи сообщается причина и опционно URL и адрес e-mail, откуда может быть получена более детальная информация. Процедура формирования RegFormRes описана ниже.

Шаг	Действие
1	Сформировать RegFormTBS в соответствии со следующей процедурой: Скопировать RRPID, RequestType, LID-EE, список оттисков и Chall-EE2 из RegFormReqData Если в CardCInitRes имеется LID-CA, скопировать его, в противном случае сформировать LID-CA для данного запроса. Сгенерировать новый Chall-CA Если BrandCRLIdentifier не специфицирован в списке оттисков, полученном в CardCInitReq, заполнить поле randCRLIdentifier. Если регистрационная форма владельца карты доступна для PAN, Language, RequestType, сформировать RegFormData в виде: Заполнить шаблон RegTemplate и PolicyText, соответствующие RequestType, PAN и Language Включить RegFormID и RegFieldSeq. В случае обновления поле RegFieldSeq может быть опущено. Опционно добавляется URL для отображения логотипа платежной системы или карты. CertReq должно быть зашифровано с помощью ключа, отличного от того, который использовался в случае RegFormReq. Внести CAEThumb с оттиском, отличным от посланного в CardCInitRes. Если подходящей регистрационной формы для владельца карты нет, сформировать структуру ReferralData: Заполнить поле причины информацией об отказе обслуживания, которая будет отображена владельцу карты. Опционно записать в поле ReferralLoc почтовый адрес и/или URL, где пользователь может получить дополнительную информацию о причине отказа обслуживания.
2	Подписать результат шага 1 (то есть данные RegFormTBS), установить contentType для SignedData равным id-set-content-RegFormTBS.
3	Сформировать цифровой конверт сообщения и послать владельцу карты RegFormRes

Структура сообщения RegFormRes представлена в таблице 4.6.2.20. Таблица 4.6.2.20. Структура RegFormRes

RegFormRes	S(CA, RegFormResTBS)
RegFormResTBS	{RRPID, LID-EE, Chall-EE2,[LID-CA], Chall-CA, [CAEThumb], RequestType, RegFormOrReferral, [BrandCRLIdentifier], [Thumbs]}
RRPID	ID пары запрос/отклик
LID-EE	Копируется из RegFormReq
Chall-EE2	Копируется из RegFormReq
LID-CA	Локальный ID. Формируется для системы СА.
Chall-CA	СА обращение по поводу пригодности сертификата запрашивающей стороны
CAEThumb	Оттиск сертификата ключевого обмена, который должен использоваться для шифрования CertReq. Если это поле отсутствует, используется сертификат, идентифицированный в CardCIntRes.
RequestType	Смотри табл. 4.6.2.19
RegFormOrReferral	Смотри табл. 4.6.2.21
BrandCRLIdentifier	Смотри описание в разделе о BrandCRLIdentifier ниже.
Thumbs	Копируется из RegFormReq

Таблица 4.6.2.21. Структура поля RegFormOrReferral

RegFormOrReferral
RegFormData	{[RegTemplate], PolicyText}
ReferralData	{RegFormID, [BrandLogoURL], [CardLogoURL], RegFieldSeq}
RegTemplate	{RegFormID, [BrandLogoURL], [CardLogoURL], RegFieldSeq}
PolicyText	Заявление, которое должно быть отображено в системе отправителя запроса вместе с RegTemplate
Reason	Заявление, связанное с запросом и отображаемое в системе отправителя запроса
ReferralURLSeq	{ReferralURL +}Опционные URL ссылок, перечисленные в порядке важности
RegFormID	Идентификатор, присвоенный СА
BrandLogoURL	URL базовой страницы расчетной системы
CardLogoURL	URL базовой страницы финансовой организации
RegFieldSeq	{RegField +}
ReferralURL	URL альтернативного СА для обработки запросов сертификатов для данного объекта
RegField	{[FieldId], FieldName, [FieldDesc], [FieldLen], FieldRequired, FieldInvisible}
FieldID	Идентификаторы объекта для полей регистрационной формы
FieldName	Одно или более имен полей, которые должны быть отображены в качестве меток для заполнения формы; текст записывается на языке, определенном в RegFormReq или Me-AqCInitReq
FieldDesc	Описание содержимого поля на языке, заданном в RegFormReq или Me-AqCInitReq; содержит дополнительную информацию для использования в случае, когда владелец карты запросит помощи при заполнении формы
FieldLen	Максимальная длина поля
FieldRequired	Булево значение, указывающее на необходимость ввода (должен ли поле заполнить владелец карты или оно будет заполнено приложением) (невидимое поле)
FieldInvisible	Булево значение, указывающее на то, что поле не должно отображаться пользователю; приложение должно заполнить FieldValue, основываясь на FieldID, или оставить его пустым

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

Шаг	Действие
1	Получить RegFormRes из входного сообщения
2	Проверить подпись. Если подпись некорректна, отправить сообщение об ошибке с ErrorCode равным signatureFailure.
3	Получить RRPID, RequestType, LID-EE, Chall-EE2, CAEThumb из RegFormTBS
4	Проверить, что RRPID является тем же самым, что и идентификатор, записанный в цифровом конверте сообщения, и совпадет с кодом, присланным в RegFormReq. Если совпадения нет, отправить сообщение об ошибке с ErrorCode равным unknownRRPID.
5	Проверить, что RequestType, LID-EE и Chall-EE2 идентичны присланным в RegFormReq. Если совпадения нет, отправить сообщение об ошибке с ErrorCode равным challengeMismatch.
6	Если был включен CAEThumb, запомнить соответствующий сертификат шифрования, использованный для шифрования CertReq.
7	Проверить, что полученные оттиски, соответствуют посланным в сообщении CardCInitReq. Если соответствия нет, отправить сообщение об ошибке с ErrorCode равным thumbsMismatch.
8	Если в RegFormTBS включены данные RegFormData то: Запоминается LID-CA Прежде чем приложение SET сформирует CertReq, отображается текст общих требований и необходимый отклик пользователя Отображаются видимые поля регистрационной формы и приглашение для заполнения их пользователем. Если RegFormRes содержит URL, отображаются логотипы платежной системы или эмитента карты. Заполняются видимые поля регистрационной формы. Если поле является необходимым, а приложение не может его заполнить, оно остается пустым, а остальная часть формы заполняется и посылается обычным порядком. После того как пользователь завершил ввод, формируется сообщение CertReq.
9	Если в RegFormResTBS включено поле ReferralData то: Отображается причина (Reason) Если включено ReferralLoc, отображаются URL или электронный адрес из ReferralLoc CertReq не формируется. Протокол переходит к формированию CardCInitReq

Пары сообщений Me-AqCInitReq/ Res используются продавцом или расчетным центром для получения регистрационной формы сертификата. Продавец или расчетный центр запускают сертификатный протокол путем посылки запроса Me-AqCInitReq. Это сообщение содержит банковскую информацию продавца или расчетного центра, тип запрашиваемого сертификата, а также сертификаты, CRL и BrandCRLIdentifier, которые хранятся в надежном сертификатном кэше. Если MCА или РСА имеют регистрационные формы на подходящем языке для указанного банка, она присылается в сообщении Me-AqCInitRes вместе с любыми сертификатами, CRL и BrandCRLIdentifier, которые могут потребоваться продавцу или расчетному центру для проверки цифровой подписи. Если MCА или РСА не имеют подходящей регистрационной формы и/или имеют дополнительную информацию относительно отклонения поступившего запроса, эти данные также заносятся в Me-AqCInitRes. Схема работы протокола сертификатов для данного случая показана на рис. 4.6.2.13.

Рис. 4.6.2.13. Схема обмена сообщениями при получении сертификата между продавцом и MCA или между платежным центром и PCA При получении Me-AqCInitRes программа конечного пользователя (ЕЕ) может послать сообщение CertReq, содержащее заполненную форму. Процедура формирования Me-AqCInitReq включает в себя следующие операции:

Шаг	Действие
1	Сформировать новый RRPID
2	Сформировать новый LID-EE
3	Сформировать новый случайный код Chall-EE
4	Занести BrandID, который хранится в приложении или получен в стартовом сообщении
5	Заполнить поле RequestType
6	Заполнить поле Language (язык)
7	Опционно создать оттиски для каждого CRL, сертификата, BrandCRLIdentifier и корневого сертификата, резидентно размещенных в кэше (если имеются)
8	Если ЕЕ (конечным пользователем) является продавец, заполнить поля BIN и ID продавца. В противном случае BIN получателя и его рабочий ID.
9	Сформировать цифровой конверт и послать сообщение Me-AqCInitReq СА.

Формат сообщения Me-AqCInitReq представлен в таблице 4.6.2.22. Таблица 4.6.2.22. Формат Me-AqCInitReq

Me-AqCInitReq	{RRPID, LID-EE, Chall-EE, RequestType, IDData, BrandID, Language, [Thumbs]}
RRPID	ID пары запрос/отклик
LID-EE	Локальный ID; формируется ЕЕ-системой или для нее
Chall-EE	Обращение EE к СА по поводу пригодности подписи
RequestType	Смотри табл. 4.6.2.24
IDData	См. табл. 4.6.2.23
BrandID	BrandID запрошенного сертификата
Langauage	Желательный язык последующих текстов
Thumbs	Список оттисков сертификатов, CRL и BrandCRLIdentifier, хранимых ЕЕ

Формат поля IDData описан в таблице 4.6.2.23. Таблица 4.6.2.23. Формат IDData

IDData	<MerchantAcquirerID, AcquirerID> (только для продавца и получателя)
MerchantAcquirerID	{MerchantBIN, MerchantBIN}
AcquirerID	{AcquirerBIN, [AcquirerBusinessID]}
MerchantBIN	Идентификационный номер банка для обработки транзакции продавца в его банке (Acquirer)
MerchantID	Идентификатор продавца, присвоенный ему его банком (Acquirer)
AcquirerBIN	Идентификационный номер банка для Acquirer (BIN получателя)
AcquirerBusinessID	Рабочий идентификационный номер банка продавца

Таблица 4.6.2.24. Значения RequestType для продавца и платежного центра

Тип запроса	Только сертификат подписи	Только сертификат шифрования	Оба сертификата
Начальный для продавца	4	5	6
Начальный для расчетного центра	7	8	9
Обновление для продавца	13	14	15
Обновление для расчетного центра	16	17	18

Получив Me-AqCInitReq, СА производит его обработку следующим образом:

Шаг	Действие
1	Выделяеть Me-AqCInitReq из входного сообщения
2	Проверяеть, что RRPID из цифрового конверта сообщения совпадает с полученным в Me-AqCInitReq. Если это не так, формируется сообщение об ошибке с errorCode unknownRRPID.
3	Запоминается RRPID, LID-EE, Chall-EE, BrandID, Language, Thumbs и IDData

Проверив корректность Me-AqCInitReq, CA формирует Me-AqCInitRes. Эта операция включает в себя следующие шаги:

Шаг	Действие
1	Сформировать сообщение Me-AqCInitResTBS: Скопировать RRPID, LID-EE и Chall-EE из Me-AqCInitReq Опционно сгенерировать LID-CA для данного вида запроса обслуживания Сгенерировать новый Chall-CA Если регистрационная форма продавца или платежного центра доступна для BIN, языка и RequestType, то: Заполнить поле RegFormData, используя RegTemplate и PolicyText, соответствующие Requesttype, BIN и Language Опционно включить URL для отображения логотипа платежной системы и/или карты Включить RegFormID и RegFieldSeq. При обновлении RegFieldSeq может быть опущено. Если СА посредством AcctData аутентифицирует продавца или расчетный центр, заполнить поле AcctDataField, указывая наименование данных, подлежащих вводу, описание, их длину и будут ли данные вводиться ЕЕ (конечным пользователем). Если соответствующая форма для продавца или расчетного центра не доступна, заполняется поле ReferralData: Включить причину отказа обслуживания, которая будет отображена для продавца или расчетного центра Опционно включить в ReferralLoc электронный адрес и/или URL, где пользователь может получить дополнительную информацию, об отказе обслуживания. Включить оттиск сертификата шифрования CA, CAEThumb. Если BrandCRLIdentifier в полученном Me-AqCInitReq не специфицирован, ввести BrandCRLIdentifier. Скопировать список оттисков (Thumbs) из Me-AqCInitReq Скопировать RequestType, полученный в Me-AqCInitReq.
2	Подписать Me-AqCInitResTBS, установить тип содержимого SignedData равным id-set-content-Me-AqCInitResTBS.
3	Сформировать цифровой конверт и послать сообщение Me-AqCInitRes продавцу или расчетному центру.

MCA и PCA используют один и тот же шаблон регистрационной формы, идентичный ССА (см.

табл. 4.6.2.25) Таблица 4.6.2.25. Шаблон регистрационной формы MCA и PCA

Me-AqCInitRes	S(CA, Me-AqCInitResTBS)
Me-AqCInitResTBS	{RRPID, LID-EE, Chall-EE, [LID-CA], Chall-CA, RequestType, RegFormOrReferral, [AcctDataField], [Thumbs]}
RRPID	ID пары запрос/отклик
LID-EE	Копируется из Me-AqCInitReq
Chall-EE	Копируется из Me-AqCInitReq
LID-CA	Локальный ID; генерируется СА системой или для нее
Chall-CA	СА обращение по поводу пригодности сертификата запрашивающей стороны
RequestType	Смотри табл. 4.6.2.24
RegFormOrReferral	Смотри табл. 4.6.2.21
AcctDataField	RegField; дополнительное поле регистрационной формы, которое следует отобразить, для того чтобы получить значение AcctData в CertReq
CAEThumb	Оттиск сертификата ключевого обмена СА, который должен использоваться для шифрования CertReq
BrandCRLIdentifier	Смотри раздел описания BrandCRLIdentifier ниже.
Thumbs	Копируется из Me-AqCInitReq

Приложение SET (продавца или расчетного центра) обрабатывает Me-AqCInitRes следующим образом:

Шаг	Действие
1	Получить Me-AqCInitRes из входного сообщения.
2	Верифицировать подпись. Если она некорректна, послать сообщение об ошибке с ErrorCode равным signatureFailure.
3	Из Me-AqCInitResTBS извлекаются и запоминаются RRPID, LID-EE, Chall-EE, CAEThumb, BrandCRLIdentifier, оттиски и TequestType
4	Проверяется, что RRPID совпадает со значением, извлеченным из цифрового конверта сообщения и кодом, посланным в Me-AqCInitReq. Если равенства нет, посылается сообщение об ошибке с ErrorCode равным unknownRRPID.
5	Проверяется, что полученный Chall-EE соответствует посланному в Me-AqCInitReq. Если соответствие отсутствует, посылается сообщение об ошибке с ErrorCode равным challengeMisMatch.
6	Проверяется, что полученный список оттисков соответствует посланному в сообщении Me-AqCInitReq. Если соответствие отсутствует, посылается сообщение об ошибке с ErrorCode равным thumbsMisMatch.
7	Если в Me-AqCInitResTBS включено поле RegFormData то: Запомнить LID-CA и Chall-CA Отобразить текст общих требований и ввод пользователя, прежде чем приложение SET сформирует CertReq Отобразить видимые поля регистрационной формы и приглашение пользователю для заполнения этих полей Если Me-AqCInitResTBS содержит URL, отобразить логотипы расчетной системы и/или карты Если присутствует поле AcctDataField, отобразить имя и описание, а также приглашение пользователю для заполнения этого поля Заполнить невидимые поля регистрационной формы. Если приложение не может заполнить поле, оно будет оставлено пустым, остальные поля будут заполнены обычным порядком и пересланы в CertReq.
8	После того как продавец или расчетный центр заполнили регистрационную форму и ввели AcctData, (если это требуется) генерируется CertReq.
9	Если в Me-AqCInitResTBS включено поле ReferrelData, то: Отображается причина Если включено поле ReferralLoc, отображается URL или электронный адрес из ReferralLoc CertReq не генерируется. Протокол продолжит работу с посылки Me-AqCInitReq

Владелец карты, системный администратор продавца или расчетного центра вводит информацию, необходимую для RegForm, а приложение SET (EE) посылает сообщение CertReq центру СА. После успешной верификации CertReq формируются сертификаты, которые посылаются ЕЕ в сообщениях CertRes. Если в регистрационной форме обнаружены ошибки, СА оповещает об этом в CertRes. Приложение SET может повторно представить исправленную регистрационную форму в новом CertReq. Владелец карты вводит ее номер, дату пригодности и другие данные, запрошенные ССА в регистрационной форме. Системный администратор продавца вводит аутентификационные данные расчетного центра и другую информацию, запрошенную МСА в регистрационной форме. Системный администратор расчетного центра вводит аутентификационные данные продавца (если таковые имеются) и другую информацию, запрошенную РСА в регистрационной форме. Запрос сертификата (CertReq) содержит в себе:

Новые общедоступные ключи.

Обновляемые сертификаты (если таковые есть).

Заполненную регистрационную форму.

Информацию об аккоунте ЕЕ

Секретные ключи, которые должен использовать СА для шифрования отклика CertRes,

Другие контрольные коды Поле данных сообщения и опционно хэш аккоунт-данных ЕЕ подписываются секретным ключом, соответствующим сертификату подписи, подлежащему обновлению (если таковой имеется) и новым секретным ключом. Симметричный ключ, используемый для этого шифрования, берется из OAEP (Bellare-Rogaway Optimal Asymmetric Encryption Padding). Все перечисленные данные шифруются с использованием общедоступного ключа. Если СА обнаружит ошибку в представленной регистрационной форме, информация о ней будет передана в сообщении CertRes и будет послан новый запрос CertReq. ЕЕ-приложение генерирует CertReq следующим образом. Это делается с использованием EncX или Enc техники в зависимости от присутствия AcctInfo. Если ЕЕ является владельцем карты, AcctInfo всегда содержит аутентификационные данные, которые могут быть, а могут и не быть затребованы СА. Me-AqCInitRes указывает, нужно ли AcctInfo в AcctInfoField.

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

Шаг	Действие
1	Если RequestType соответствует новому сертификату подписи или его обновлению, формируется пара ключей (общедоступный/секретный), необходимых для подписи сертификата
2	Если запрашивающим субъектом не является владелец карты и, если RequestType соответствует новому сертификату шифрования, формируется пара ключей (общедоступный/секретный), необходимых для сертификата шифрования.
3	Если ЕЕ является владельцем карты, генерируется 160-битовый случайный код - CardSecret.
4	Генерируется 160-битовый случайный код - EXNonce
5	Формируется CertReqTBS: Генерируется RRPID Если ЕЕ получил RegFormRes или Me-AqCInitRes, копируется RequestType из этого сообщения, в противном случае вводится требуемый RequestType. Заполняется поле RequestData Копируется LID-EE (если присутствует) и Chall-CA из предыдущего сообщения. Если его нет, генерируется новый. Генерируется новый Chall-EE3 Копируется LID-CA, (если присутствует) и Chall-CA из предыдущего сообщения. Если ЕЕ является продавец карты или расчетный центр, то: заполняется поле IDData и, если в Me-AqCInitRes включено поле AcctDataField, записывается AccData, введенная ЕЕ Если ЕЕ является продавец, занести PAN, CardExpiry и CardSecret. Сформировать EXNonce Скопировать RegForm ID, который был послан в RegFormRes или Me-AqCInitRes Если RegFieldSeq присутствовал в Me-AqCInitRes или RegFormRes, включить новую или исправленную форму.
6	Если приложение владельца карты выберет алгоритм шифрования CertRes, производится заполнение ID алгоритма и ключа в CaBackKeyData. Если общего алгоритма не найдено, процесс прерывается, о чем уведомляется пользователь. Заносится вновь сформированный общедоступный ключ, PublicKeyS и/или PublicKeyE, предназначенный для сертификации СА. Если ЕЕ является продавец или расчетный центр, а тип запроса соответствует обновлению сертификата шифрования, заполняется EEThumb с оттиском сертификата, подлежащего обновлению. Если тип запроса соответствует обновлению сертификата подписи, оттиск сертификата подписи не требуется, так как CertReq подписан им. Опционно включается список, который содержит оттиски для каждого CRL, сертификата SET, BrandCRLIdentifier и корневого сертификата, резидентно размещенных в кэше.
7	Данные, подлежащие дополнительному шифрованию, имеют следующий формат. Если ЕЕ является продавец карты, заполняется PAN, CardExpiry, CardSecretCardNonce и EXNonce в PANData0. Если ЕЕ является продавец или расчетный центр, опционно заполняется AccTData и EXNonce.
8	Данные укладываются в конверт с использованием техники EncX: Включить: Обработка а. В качестве подписанных данных CertReqTBS То, как данные подписываются зависит от RequestType. Имеется как минимум одна и допускаются две подписи, т.е. SignerInfo для CertReq. Если тип запроса относится к новому сертификату подписи, подписать данные, используя секретный ключ, соответствующий общедоступному ключу, содержащемуcя в PublicKeyS. Если тип запроса относится к обновлению сертификата подписи, подписать данные, используя секретный ключ, соответствующий общедоступному ключу, содержащемуся в PublicKeyS и, используя секретный ключ, соответствующий обновляемому сертификату. Если тип запроса относится к сертификату шифрования, подписать данные, используя секретный ключ, соответствующий существующему сертификату подписи. Если данные подписаны секретным ключом, который не соответствует сертификату, установить SignerInfo.SerialNumber равным нулю, а SignerInfo.IssuerName=”Null-DN”, т.е. RDNSequence равна кодированному NULL. Тип содержимого SignedData устанавливается равным id-set-content-CertReqTBS. b. Результат шага 6 в качестве данных, подлежащих дополнительному шифрованию Провести дополнительное шифрование, используя СА-сертификат, указанный CAEThumb в CardCInitRes или RegFormRes, если один из них был включен, или Me-AqCInitRes c. CertReqTBEX в качестве данных, подлежащих шифрованию Зашифровать CertReqTBEX и установить тип содержимого EnvelopedData равным id-set-content-CertReqTBEX
9	Сформировать цифровой конверт и послать сообщение CertReq центру СА

Если приложением ЕЕ является продавец или расчетный цент, который не имеет данных AcctData (в AcctInfo), чтобы их послать, тогда генерируется CertReq с привлечением техники Enc:

Шаг	Действие
1	Если RequestType соответствует обновлению сертификата подписи, формируется пара ключей (секретный/общедоступный) для сертификата подписи
2	Если RequestType соответствует новому или обновляемому сертификату шифрования, формируется пара ключей (секретный/общедоступный) для сертификата шифрования
3	Сгенерируется 160-битное случайное число - EXNonce
4	Данные CertReqData формируются следующим образом: Генерируется RRPID Если продавец или расчетный центр получают Me-AqCInitRes, RequestType копируется из этого сообщения, в противном случае это поле заполняется обычным путем. Заполняется поле ReqestDate Копируется LID-EE из предыдущего сообщения. Если такового нет, генерируется новое. Генерируется новое Chall-EE3 Копируется LID-CA (если имеется) и Chall-CA из предыдущего сообщения, если таковое имеется. Заполнить поле IDData Занести RegFormID, полученный из Me-AqCInitRes Занести новую или скорректированную форму RegForm Занести вновь сформированные общедоступные ключи, PublicKeyS и/или PublicKeyE, предназначенные для сертификации СА. Если RequestType соответствует обновлению сертификата шифрования, заполняется EEThumb оттиском сертификата, подлежащего обновлению. Опционно включается список, который содержит оттиски каждого CRL, сертификата SET, BrandCRLIdentifier и корневого сертификата, резидентные в кэше владельца карты.
5	Поместить данные в цифровой конверт, используя инкапсуляцию Enc: Включить: Обработка CertReqData в качестве информации, подлежащей подписыванию.То, как подписываются данные, зависит от RequestType. Имеется как минимум одна и допускаются две подписи, т.е. SignerInfo для CertReq. Если тип запроса соответствует новому сертификату подписи, данные подписываются с применением секретного ключа, составляющего пару с общедоступным ключом, который содержится в PublicKeyS. Если тип запроса соответствует обновлению сертификата подписи, данные подписываются с применением секретного ключа, составляющего пару с общедоступным ключом, который содержится в PublicKeyS, а затем посредством секретного ключа, соответствующего обновляемому сертификату. Если тип запроса соответствует сертификату шифрования, данные подписываются с применением секретного ключа, составляющего пару с общедоступным ключом, который соответствует существующему сертификату подписи. Если данные подписаны ключом, который еще не соответствует сертификату, следует установить Signer.Info.SerialNumber равным “Null-DN”. Тип содержимого SignedData делается равным id-set-content-CertReqData. Производится DER-кодирование полученной информации SignedData с целью получения CertReqTBE. Ключ DES в качестве данных, подлежащих дополнительному шифрованиюДля Enc-обработки единственной информацией, которая должна быть зашифрована, является симметричный ключ, используемый для шифрования “обычных данных”. Шифруется ключ с применением сертификата, указанного посредством CAEThumb в Mt-AqCInitRes. CertReqTBE в качестве обычных данных, подлежащих шифрованиюШифруется CertReqTBE и устанавливается ContentType равным id-set-Content-CertReqTBE.
6	Подготовить цифровой конверт и послать CertReq центру СА

Формат сообщения CertReq, генерируемого EE (End Entity) представлен ниже в таблице 4.6.2.26: Таблица 4.6.2.26. Формат CertReq

CertReq	Допускается инкапсуляция с двумя подписями. CertReqTBE и AcctInfo могут быть подписаны любым или всеми секретными ключами, соответствующими следующим сертификатам ЕЕ: секретный ключ нового сертификата подписи существующий сертификат подписи для запроса сертификата шифрования или существующий сертификат подписи для запроса обновленияЭти подписи без соответствующего сертификата являются лишь проформой; они доказывают лишь то, что ЕЕ владеет секретным ключом.
CertReqData	{RRPID, LID-EE, Chall-EE3, [LID-CA], [Chall-CA], RequestType, RequestDate, [IDData], RegFormID, [RegForm], [CABackKeyData], publicKeySorE, [EEThumb], [Thumbs]}
AcctInfo	Если отправитель запроса - владелец карты, вводится PANData0. Если отправитель запроса - продавец или получатель, вводится AcctData
RRPID	ID пары запрос/отклик
LID-EE	Копируется из RegFormRes или Me-AqCInitRes
Chall-EE3	Обращение ЕЕ по поводу обновления подписи СА
LID-CA	Копируется из RegFormRes или из Me-AqCInitRes
Chall-CA	Копируется из RegFormRes или из Me-AqCInitRes
RequestType	Смотри таблицу 4.6.2.24
RequestDate	Дата запроса сертификата
IDData	См. табл. 4.6.2.23. Опускается, если ЕЕ является владельцем карты.
RegFormID	Идентификатор, присвоенный СА
RegForm	{RegFormItems +} Имена полей копируются из RegFormRes или из Me-AqCInitRes вместе со значениями, внесенными ЕЕ
CABackKeyData	{CAAIgId, CAKey}
publicKeySorE	{[ PublicKeyS], [PublicKeyE]} Общедоступный ключ объекта. Должен быть специфицирован, по крайней мере, один ключ. Пользователь может запросить сертификат подписи, сертификат шифрования или оба эти сертификата.
EEThumb	Оттиск сертификата ключа шифрования, который обновляется
Thumbs	Списки сертификатов, включая корневой, CRL и BrandCRLIdentifier, используемые в данный момент ЕЕ.
PANData0	См. табл. 4.6.2.27
AcctData	См. табл. 4.6.2.28
RegFormItems	{FieldName, FieldValue}
CAAlgId	Идентификатор симметричного алгоритма шифрования
CAKey	Секретный ключ, соответствующий идентификатору алгоритма
PublicKeyS	Предлагаемый для сертификации общедоступный ключ подписи
PublicKeyE	Предлагаемый для сертификации общедоступный ключ шифрования
FieldName	Одно или более имен полей, которые надо отобразить в качестве заполняемой формы в системе отправителя запроса. Это текстовые поля с текстом на языке, специфицированном в RegFormReq или Me-AqCInitReq
FieldValue	Величина, введенная ЕЕ

Таблица 4.6.2.27. Формат PANData0

PANData0	{PAN, CardExpiry, CardSecret, EXNonce}
PAN	Первичный номер счета ( Primary Account Number) для данной карты
CardExpiry	Дата пригодности карты
CardSecret	Предложенная владельцем карты часть секретного ключа PANSecret. Эта величина используется для генерации TransStain.
EXNonce	Новый код (Nonce) для предотвращения атак на PANData0

Таблица 4.6.2.28. Формат AcctData

AcctData	{AcctIdentification, EXNonce}
AcctIdentification	Для продавца это поле уникально и определяется платежной системой карты (Brand) и получателем (банк продавца)
EXNonce	Новый код Nonce для предотвращения атак на PANData0

СА проверяет CertReq (EncX) следующим образом.

Шаг	Действие
1	Получить CertReq из входного сообщения Если RequestType соответствует новому сертификату подписи или сертификатам подписи и шифрования, то используется одна подпись CertReq. Верифицировать ее, используя новый общедоступный ключ, содержащийся в PublicKeyS. Если верификация не прошла, возвращается CertRes с CertStatusCode равным sigValidationFail. Если RequestType соответствует обновлению сертификата подписи или одновременному обновлению сертификатов подписи и шифрования, то используются две подписи (SignerInfos) для CertReq. Для SingerInfo с нулевым DN эмитента верифицируется подпись с использованием нового общедоступного ключа подписи, содержащегося в PublicKeyS. Если верификация не прошла, возвращается CertRes с CertStatusCode равным ValidationFail. Для SingerInfo c DN эмитента и серийным номером равными значениям из обновляемого сертификата подписи верификация подписи осущетствляется с использованием общедоступного ключа этого сертификата. Если верификация не прошла, возвращается сообщение Error с ErrorCode равным signstureFailure. Если RequestType соответствует новому или обновляемому сертификату шифрования, то для CertReq используется одна подпись. Верифицировать ее, используя общедоступный ключ сертификата подписи ЕЕ. Если верификация не прошла, возвращается сообщение Error с ErrorCode равным signatureFailure.
2	Из данных CertReqTBS запомнить RRPID, LID-EE, Chall-EE3, RequestType, LID-CA, Chall-CA, IDData, RegForm, CaBackKeyData, список оттисков и новые сертификаты подписи и/или шифрования
3	Проверить то, что RRPID и RequestDate соответствуют значениям, полученным из цифрового конверта сообщения. Если соответствия нет, выдается сообщение Error с ErrorCode равным unknownRRPID.
4	Проверить то, что полученный Chall-CA соответствует посланному в Me-AqCInitRes или RegFormRes. Если соответствия нет, выдается сообщение Error с ErrorCode равным challengeMismatch.
5	Проверить PAN (если он включен) в соответствии с политикой платежной системы (Brand), в противном случае проверить AcctData. Если соответствия нет, возвращается CertRes c кодом CertStatusCode равным rejectByIssuer.
6	Если RequestType соответствует обновлению, проверить, что сертификаты, подлежащие обновлению, не были до этого обновлены. Если проверка не прошла, возвращается CertRes c кодом CertStatusCode равным rejectedByCA.
7	Проверить то, что RegFormID корректен с точки зрения языка, RequestType и BIN или PAN. Если проверка не прошла, возвращается CertRes c кодом CertStatusCode равным rejectByCA.
8	Если отправителем CertReq является владелец карты, запомнить алгоритм и ключ, включенные в CABackKeyData, для шифрования CertRes, посылаемого владельцу карты.
9	Проверить невидимые пункты формы регистрации. Если некоторые пункты необходимы, но заполнены некорректно, вернуть CertRes с CertStatusCode равным rejectedByIssuer.
10	Если все предшествующие проверки прошли успешно, проверить все позиции регистрационной формы, проверить также, что длина, формат и типы символов правильны. Проверить, что все необходимые поля имеются. Если обнаружены какие-то ошибки, вернуть номер позиции и текст сообщений, где обнаружены ошибки в последовательности FailedItems в CertRes с CertStatusCode равным regFormAnswerMalformed.

Если верификация не прошла, СА подготавливает и отсылает сообщение CertRes c соответствующим статусом. Если обнаружены ошибки в CertReq, СА отметит эти ошибки в CertRes и приложение ЕЕ должно будет послать повторно CertReq. При полном успехе система перейдет к аутентификации в финансовом учреждении. Здесь, прежде чем формировать сертификат, проверяется запрос CertReq. Методика этой проверки зависит от типа платежной системы (Brand) и находится за пределами спецификации SET. В зависимости от результатов проверки CertReq, CertRes будет содержать сертификат или статусный код (при неуспехе). Сообщение CertRes будет подписано и в зависимости от характера данных, уложенных в него, зашифровано. Если CertRes уведомляет владельца карты об успехе, то сообщение шифруется с использованием обычного симметричного алгоритма, поддерживаемого приложениями СА и владельца карты. Если сообщение CertRes предназначено для продавца или расчетного центра или возвращает владельцу карты статусные данные, то оно подписывается, но не шифруется. Если CertReq аутентичен и корректен, а СА сформировал сертификат, используя представленный ключ, то будет возвращен CertRes с завершенным статусом. Если CertRes предназначен для владельца карты и содержит ключ (в CaBackKeyData) для шифрования CertRes, СA сформирует CertRes как SignedData. Осуществляется это следующим образом.

Шаг	Действие
1	CertResData формируется как: Копируется RRPID, LID-EE, список оттисков и Chall-EE3 из CertReq Генерируется или копируется из CertReq (если имеется) LID-CA Опционно заполняется CardLogo, URL, BrandLogo, URL, CardCurrency и/или CardholderMessage (CaMsg) CertStatusCode устанавливается равным “Request Complete” Формируется Nonce-CCA Вычисляются и заносятся оттиски EE-сертификатов, CertThumbs. Если BrandCRLIdentifier не специфицирован в списке оттисков CertReq, заполняется поле BrandCRLIdentifier.
2	Подписать и вложить данные в цифровой конверт, используя технику EncK-инкапсуляции, для CertResData в качестве данных, подлежащих подписке. Подписать данные посредством сертификата подписи СА Установить тип данных SignedData равным id-set-content-CertResData. Вставить новые сертификаты подписи и/или шифрования ЕЕ в сертифицированной части SignedData. Зашифровать подписанные данные, используя сгенерированный вектор инициализации, а также алгоритм и ключ, представленные CABackKeyData в CertReq. Установить тип содержимого EncriptedData равным id-set-content-CertResTBE
3	Сформировать цифровой конверт и послать EE CertRes.

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

Подписанное сообщение CertRes формируется следующим образом:

Шаг	Действие
1	Если СА сгенерировал сертификат, который будет включен в CertRes, выполняется формирование CertResTBS.
2	Если СА не сгенерировал сертификат, т.е. имеет статус, отличный от “Request Complete”, создается CertResData: Копируется LID-EE и Chall-EE3 из CertReq Опционно заносится EEMessage Из табл. 4.6.2.30 заносится значение CertStatusCode Если CertStatusCode установлен равным regFormAnswerMalformed, занести номера позиций (ItemNumbers) и причины (ItemReasons) для каждой ошибочной позиции (FailedItem) в регистрационной форме.
3	Сформировать цифровой конверт и послать конечному пользователю (ЕЕ) CertRes

Формат CertRes в этом случае имеет вид представленный в таблице 4.6.2.29. Таблица 4.6.2.29. Формат CertRes

CertRes	EncK-версия этого сообщения необходима только в случае, когда в CertRes включен опционный компонент CAMsg. Эта версия используется, если в CertReq включено поле CABackKeyData
CertResData	{RRPID, LID-EE, Chall-EE3, LID-CA, CertStatus, [CertThumbs], [BrandCRLIdentifier], [Thumbs]}
CABackKeyData	Копируется из CertReq
RRPID	ID пары запрос/отклик
LID-EE	Копируется из CertReq
Chall-EE3	Копируется из CertReq. Источник запроса проверяет соответствие со значением, хранящимся в памяти.
LID-CA	Копируется из CertReq. Если в CertReq его нет, то присваивается новое значение.
CertStatus	{CertStatusCode, [Nonce-CCA], EEMessage], {CaMsg], [FailedItemSeq]}
CertThumbs	Если запрос обслужен, то это список оттисков вложенных сертификатов подписей и/или шифрования
BrandCRLIdentifier	Смотри раздел об идентификаторах списков отмененных сертификатов платежной системы.
Thumbs	Копируется из CertReq.
CertStatusCode	Нумерованный код, указывающий на статус запроса сертификата
Nonce-CCA	Присутствует, если в качестве ЕЕ выступает владелец карты. Этот код представляет собой дополнительный секретный ключ, используемый совместно владельцем карты и ССА.
EEMessage	Сообщение на естественном языке, предназначенное для отображения в системе ЕЕ
CAMsg	{[CardLogoURL], [BrandLogoURL], [CardCurrency], [CardholderMsg]}
FailedItemSeq	{FailedItem+}
CardLogoURL	URL - указатель на логотип эмитента карты
BrandLogoURL	URL - указатель на логотип платежной системы
CardCurrancy	Вид валюта, хранящейся на счете владельца карты
CardholderMsg	Сообщение на естественном языке владельца карты, которое должно быть отображенопрограммой
FailedItem	{ItemNumber, ItemReason}
ItemNumber	Указывает на позицию в списке полей регистрационной формы, интерпретация которой невозможна. Значение нуль указывает на поле AcctData
ItemReason	Причина неудачи. Текстовое поле на естественном языке.

Таблица 4.6.2.30. Статусные коды для запросов сертификата

Код	Значение	Источник
requestComplete	Запрос сертификата одобрен	CA
invalidLanguage	В запросе указан неверный язык	CA
invalidBIN	Запрос сертификата отклонен из-за некорректного BIN	Эмитент или получатель
sigValidationFail	Запрос сертификата отклонен по причине некорректной подписи	CA
decryptionError	Запрос сертификата отклонен из-за ошибки дешифрования	CA
requestInProgress	Запрос сертификата обрабатывается	СА, эмитент или получатель
rejectedByIssuer	Запрос сертификата отклонен эмитентом карты	Эмитент
requestPended	Запрос сертификата ждет обработки	СА, эмитент или получатель
rejectedByAquirer	Запрос сертификата отклонен банком продавца (получателем)	Получатель
regFormAnswerMalformed	Запрос сертификата отклонен из-за неверной позиции в регистрационной форме.	CA
rejectedByCA	Запрос сертификата отклонен центром сертификации	CA
unableToEncryptCertRes	Центр сертификации не получил ключа и по этой причине не может зашифровать отклик для владельца карты	CA

Конечный пользователь ЕЕ проверяет новый сертификат следующим образом:

Шаг	Действие
1	Выделить CertRes из входного сообщения. Если CertRes содержит подписанные данные, дешифровать их и проверить подпись CertRes (см. описание методики EncK). Процедура осуществляется для полученных сертификатов CRL и BrandCRLIdentifier.
2	Проверить, что полученные оттиски соответствуют посланным в сообщении CardCInitReq. Если проверка не прошла, возвращается сообщение Error с ErrorCode равным thumbsMismatch.
3	Проверить, что LID-EE и Chall-EE соответствуют значениям, посланным в CertReq. Если проверка не прошла, возвращается сообщение Error с ErrorCode равным challengeMismatch.
4	Если CertStatusCode указывает “Certificate request complete” (с запросом сертификата все в порядке), то: Извлекаются новые сертификаты из сертификатной секции SignedData и проверяются подписи. Проверяется, что полученные CertThumbs соответствуют посланным в CertReq. Если проверка не прошла, возвращается сообщение Error с ErrorCode равным thumbsMismatch. В случае владельца карты извлекается CaMsg, отображается логотип и CardholderMsg из CaMsg и запоминается CardCurrency. Проверяется, что общедоступные ключи в сертификате соответствуют секретным ключам. Если проверка не прошла, возвращается сообщение Error с ErrorCode равным invalidCertificate. В случае владельца карты выполняются следующие дополнительные действия: Для того чтобы получить PANSecret, вычисляется (Nonce-CCAЕ CardSecret) Вычисляется уникальный идентификатор владельца карты, HMAC-SHA-1{{PAN, cardExpiry}, PANSecret}, т.е. Salted Hash, и проводится верификация того, что полученный результат соответствует значению сертификата.
5	Если CertStatusCode равен “MalFormed Registration Form Items”, это означает, что некоторые позиции регистрационной формы заполнены неверно. Для каждой ошибочной позиции приложение ЕЕ занесет в CertRes номер этой позиции и соответствующее сообщение об ошибке. ЕЕ разрешается повторить ввод для полей с ошибкой и повторно послать CertReq с новым запросом сертификата.
6	Если CertStatusCode установлен равным requestinProgress или requestPended, сертификат может быть доставлен позднее с помощью процедуры CertInqReq
7	Если CertStatusCode указывает какой-либо иной статус, отображается EEMessage.

Информационные сертификатные запросы и обработка статуса Если сертификат не возвращен немедленно в CertRes, EE может попросить прислать ему информацию о состоянии его запроса путем присылки CertReq в центр СА. Запрос CertInqRes возвращает сертификат, если он готов, или предоставляет информацию о том, когда сертификат будет прислан. Такие запросы могут посылать владелец карты, продавец или расчетный центр. Адресуются эти запросы CA, CCA, MCA или PCA (источникам сертификатов). Если CertStatusCode из CertRes равен “Certificate Request in Progress” или “Certificate Request Pending”. EE формирует CertInqReq для получения сертификата следующим образом:

Шаг	Действие
1	Копируется LID-CA3 из CertRes в поле данных “CertInqReqTBS”
2	Генерируется новый RRPID
3	Генерируется новый LID-EE
4	Генерируется новый Chall-EE3
5	Копируется LID-CA из предыдущего CertRes
6	Подписывается CertInqReqTBS. Устанавливается тип содержимого равным id-set-content-CertInqReqTBS. CertInqReq подписывается также как и CertReq.
7	Формируется цифровой конверт и посылается CertInqReq в центр СА.

Формат сообщения представлен в таблице ниже. Таблица 4.6.2.31. Формат CertInqReq

CertInqReq	S(EE, CertInqReqTBS)
CertInqReqTBS	{RRPID, LID-EE, Chall-EE3, LID-CA}
RRPID	Идентификатор пары запрос/отклик
LID-EE	Копируется из CertRes
Chall-EE3	Требование ЕЕ по поводу обновления подписи СА
LID-CA	Копируется из CertRes

Центр СА обрабатывает CertInqReq следующим образом:

Шаг	Действие
1	Из входного сообщения извлекается CertInqReq. Подпись CertInqReqTBS верифицируется также как и для CertReq. Если проверка не прошла отклик будет таким как при CertReq(EncX)
2	Проверить, что RRPID соответствует посланному в цифровом конверте. Если соответствия нет, возвращается сообщение об ошибке с ErrorCode равным unknownRRPID.
3	Используя LID-CA в качестве индекса, определяется статус CertReq.
4	Если сертификат сформирован, он посылается ЕЕ в отклике CertInqRes, в противном случае в CertInqRes возвращается актуализованный код CertStatusCode

После обработки CertInqReq СА формирует CertInqRes.

Этот отклик имеет ту же структуру и формат, что и CertRes. Обработка CertInqRes происходит аналогично. Реальный формат сертификатов определяется документом Х.509. Характеристики различных полей такого сертификата представлены в таблице 4.6.2.32. Таблица 4.6.2.32. Поля формата сертификата Х.509

Имя	Ограничения на формат и значения	Описание
Version (Версия)	Целое	Указывает на версию сертификата
SerialNumber	Целое	Уникальный порядковый номер, приписываемый СА, сформировавшим сертификат
Signature.AlgorithmIdentifier	OID и тип	Определяет алгоритм, используемый для генерации подписи сертификата
Issuer (эмитент)	Имя	Содержит уникальное имя (Distinguished Name) CA, выдавшего сертификат
Validity.notBefore	Время UTC	Специфицирует время, когда сертификат становится активным
Validity.notAfter	Время UTC	Специфицирует время, когда сертификат перестает действовать. Если это относится к сертификату владельца карты, то его время действия не может быть дольше пригодности карты.
Subject	Имя	Содержит уникальное имя объекта владельца ключа
SubjectPublicKeyInfo.algorithm. AlgorithmIdentifier	OID и тип	Специфицирует алгоритм, который может использоваться с этим ключом.
SubjectPublicKeyInfo. subjectPublicKey	Строка битов	Содержит общедоступный ключ, представленный в запросе сертификата
IssuerUniqueID		В SET не используется
SubjectUniqueID		В SET не используется
Extensions.extnId	Формат OID	Содержит расширение OID, как это определено Х.509 или SET
Extensions.critical	Булево: 0=ложно 1=истинно	Каждое описание расширения определяет то, какое значение должно принимать это поле
Extensions.extnValue		Информация расширения

Для определения позиций необходимы следующие идентификаторы объектов OID (указаны в скобках) в сертификатах SET:

countryName [2 5 4 6]

organizationName [2 5 4 10]

organizationUnitName [2 5 4 11]

commonName [2 5 4 3] Ниже представлены формальные определения атрибутов (at), которые заключают в себе уникальные имена (Subject Distinguished Name) для каждого объекта SET, указанного в расширении типа сертификата (CertificateType). OID имен (ASN.1) id-at-countryNameOBJECT IDENTIFIER ::= { id-at 6 }

id-at-organizationNameOBJECT IDENTIFIER ::= { id-at 10 }
id-at-organizationalUnitNameOBJECT IDENTIFIER ::= { id-at 11 }
id-at- commonNameOBJECT IDENTIFIER ::= { id-at 3 } Владелец карты
countryName=<Страна, где размещается финансовое учреждение, выпустившее карту>
organizationName= (идентификатор платежной системы)
organizationalUnitName=<Название финансового учреждения, выпустившее карту>
organizationalUnitName=<Опционно - название карты>
commonName=<Уникальный идентификатор владельца карты>
Если в перечне появляется два атрибута organizationalUnitName, первый из них представляет название финансового учреждения, выпустившее карту. Продавец
countryName=< Страна, где размещается банк продавца - Acquirer>
organizationName=
organizationalUnitName=<Название банка продавца>
commonName=<Имя продавца, как написано в заявлении владельца карты>
Расчетный центр
countryName=<Страна, где размещается банк продавца - Acquirer>
organizationName=
organizationalUnitName=<Название банка продавца>
commonName=<Уникальный идентификатор расчетного центра>
Центр сертификации владельца карты
countryName=<Страна, где размещается финансовое учреждение, выпустившее карту>
organizationName=
organizationalUnitName=<Описательное имя>
commonName=<Опционный уникальный идентификатор>
Центр сертификации продавца
countryName=<Страна, где размещается банк продавца - Acquirer >
organizationName=
organizationalUnitName=<Описательное имя>
commonName=<Опционный уникальный идентификатор>
Центр сертификации расчетного центра
countryName=<Страна, где размещается банк продавца - Acquirer >
organizationName=
organizationalUnitName=<Описательное имя>
commonName=<Опционный уникальный идентификатор>
Геополитический центр сертификации
countryName=<Страна геополитической организации>
organizationName=

organizationalUnitName=<Описательное имя>
commonName=<Опционный уникальный идентификатор>
Центр сертификации платежной системы (Brand)
countryName=<Страна, где размещен центр сертификации платежной системы>
organizationName=
organizationalUnitName=<Описательное имя>
commonName=<Опционный уникальный идентификатор>
Корневой центр сертификации
countryName=<Страна, где размещен корневой центр сертификации - СА>
organizationName=<Корневой центр SET>
commonName=<Опционный - уникальный ID>
Поля имен в имени субъекта сертификата определены в таблице ниже:

Country	2 символа кода страны (ISO 3166)
BrandID	:, где название продукта является опционным.
Brand Name	Платежная система карты, которая определяется разработчиками платежной системы.
Product Type	Опционное поле, которое определяет тип продукта в рамках заданной платежной системы.
Описательное имя	Это описательное имя объекта, ответственного за выпуск сертификата в рамках данного СА. Например: Название финансовой организации Название организации, выполняющей функцию СА Название платежной системы Имя объекта, ответственного за одобрение сертификатов
Официальное название карты	Это опционное поле содержит официальное название карты. Примерами могут служить, например: Frequent Flayer Program, Affinity Program и т.д.
Название финансовой организации	Имя финансовой организации, выпускающей расчетные карты
Уникальный идентификатор владельца карты	Уникальным идентификатором владельца карты в сертификате владельца является хэшированный номер его счета.
Уникальный идентификатор расчетного центра	Поле содержит BIN, за которым следует серийные номера банка продавца или расчетной системы. Поле форматировано как . Серийный номер позволяет однозначно идентифицировать каждый расчетный центр, ассоциированный с одним и тем же банком продавца (Acquirer). В пределах расчетной системы (Brand) может быть несколько сертификатов для одного BIN.

Уникальный ID владельца карты в сертификате представляет собой хэшированный номер его счета.

PAN маскируется с использованием общего секретного ключа (PANSecret), который состоит из комбинации CardSecret владельца карты и Nonce-CCA сертификационного центра. Вычисление хэша производится с привлечением алгоритма HMAC-SHA1 (RFC-2105). Функция HMAC-SHA1 определяется в терминах ключа K и текста, который кэшируется следующим образом: Hash(KЕ opad|hash((KЕipad)|text)), где Е - оператор исключающее ИЛИ, а оператор | - обозначает объединение кодов. K, text, ipad и opad определяются в SET следующим образом:

K	Равно PANSecret и представляет собой 20-байтовую строку, полученную в результате операции исключающее ИЛИ, выполненной над DER-кодированными значениями CardSecret и Nonce-CCA.
Text	Представляет собой DER-кодированную копию исходного текста, содержащего PAN и CardExpiry.Text ::= SEQUENCE {pan PAN cardExpiry CardExpiry } PAN ::= NumberString (SIZE(1..19)) CardExpiry ::= NumericString (SIZE(6)) --YYYMM Время истечения действия карты
ipad	64 байта, содержащих код 0x36
opad	64 байта, содержащих код 0x5C

K дополняется нулями до 64 байт. Результат вычисления HMAC кодируется в представлении base64, после чего производится в поле сертификата commonName. Профайлы сертификатов В таблице 4.6.2.33 представлен полный список сертификатов необходимых SET. Таблица 4.6.2.33. Типы сертификатов

Объект	Цифровая подпись	Шифрование_ключей/ шифрование_данных	ПодписьkeyCert	ПодписьCRL
Владелец карты	Х
Продавец	Х	Х
Расчетный центр	Х	Х
Центр сертификации владельца карты	Х	Х	Х
Центр сертификации продавца	Х	Х	Х
Центр сертификации расчетного центра	Х	Х	Х	Х
Геополитический центр сертификации	Х		Х	Х
Центр сертификации платежной системы			Х	Х
Корневой центр сертификации			Х	Х

ССА, MCA и PCA при совмещении функций не обязательно требуют наличия трех отдельных сертификатов. Сертификат подписи может содержать два или три различных типов сертификата. Разные СА не обязательно требуют различных сертификатов для подписи сертификатов и CRL. Поле KeyUsage может содержать:

привилегии keyCertSign и offLineCRLSign или

keyEncipherment и dataEncipherment В таблице 4.6.2.34 представлены обязательные расширения сертификата конечного пользователя (ЕЕ). Таблица 4.6.2.34.

Обязательные расширения сертификата ЕЕ.

	Сертификат владельца карты	Сертификат продавца		Сертификат расчетного центра
Расширение Х.509	Подпись	Подпись	Шифрова-ние ключа	Подпись	Шифрова-ние ключа
AuthorityKeyIdentifier	Х	Х	Х	Х	Х
KeyUsage	Х	Х	Х	Х	Х
PrivateKeyUsagePeriod	Х	Х		Х
CertificatePolicies	Х	Х	Х	Х	Х
SubjectAltName	O	O	O	O	O
BasicConstraints	Х	Х	Х	Х	Х
IssuerAltName	O	O	O	O	O
Частное расширение
HashedRootKey
CertificateType	Х	Х	Х	Х	Х
MerchantData		Х	Х
CardCertRequired					Х
Tunneling					Х
SETExtensions					Х

Х - обязательный
O - опционный Таблица 4.6.2.35. Обязательные расширения сертификатов СА

	СА				Корневой центр сертификации
Расширение Х.509	Цифровая подпись	Подпись серти-фиката	Шифрова-ние ключа	Подпись CRL	Подпись сертификата & CRL
AuthorityKeyIdentifier	Х	Х	Х	Х	Х
KeyUsage	Х	Х	Х	Х	Х
PrivateKeyUsagePeriod	Х	Х		Х
CertificatePolicies	Х	Х	Х	Х	Х
SubjectAltName	O	O	O	O	O
BasicConstraints	Х	Х	Х	Х	Х
IssuerAltName	O	O	O	O	O
Частное расширение
HashedRootKey					Х
CertificateType	Х	Х	Х	Х	Х
MerchantData
CardCertRequired
Tunneling			Х
SETExtensions

Каждый центр сертификации (за исключением MCA и CCA) поддерживает CRL и производит их рассылку. BCI (BrandCRLIdentifier), определенный SET, содержит список всех CRL в пределах данной платежной системы (Brand). Как только СА выпустит новый список CRL, соответствующий BCI актуализируется. Получение конечным пользователем BCI гарантирует, что устаревшие или скомпрометированные сертификаты не будут использованы. В CRL записываются серийные номера устаревших сертификатов. СА идентифицируется в CRL по своему уникальному имени, CRL подписывается рассылающим СА. Длина списка CRL со временем растет. Каждый СА CRL содержит в себе следующую информацию:

Номер CRL. Номера монотонно возрастают.

Список серийных номеров устаревших сертификатов.

Даты, когда конкретные сертификаты были признаны устаревшими.

Даты, когда был сформирован CRL и когда завершается срок его действия (замещается новым CRL).

Уникальное имя СА, который поддерживает данный CRL.

Эмитент и серийный номер сертификата СА, который используется для подписи данного CRL. В таблице 4.6.2.36 определен формат полей CRL и ограничения для их значений (X.509). Таблица 4.6.2.36.

Формат полей CRL и ограничения для их значений

Имя поля	Формат и ограничения на значение	Описание
CRL.version (версия)	Целое; V2	Определяет версию CRL. В настоящее время =2.
CRL.signature .algorithmIdentifier	OID и тип	Определяет алгоритм, использованный для подписи CRL
CRL.Issuer	Имя	Содержит DN субъекта для СА, который выпустил устаревший сертификат. Должен совпадать с именем субъекта в сертификате СА
CRL.thisUpdate	Время UTC	Определяет время, когда был сформирован CRL
CRL.nextUpdate	Время UTC	Определяет время, когда CRL устареет
CRL.revokedCertificate .certSerialNumber	Целое	Номер по порядку устаревшего сертификата
CRL. RevokedCertificate .revocationDate	Время UTC	Дата признания сертификата устаревшим
CRL. RevokedCertificate .extensions	Расширения	Не используется в SET
CRL.extensions	Расширения	В этом поле используются два расширения: CRLNumber и AuthorityKeyIdentifier

Следующие СA должны поддерживать CRL в рамках SET:

корневой СА - для поддержки незапланированной замены корневых сертификатов или сертификатов СА платежных систем.

СА платежных систем - для поддержки незапланированной замены или прекращения действия сертификата, выданного центром сертификации платежной системы.

геополитические СА - для поддержки незапланированной замены сертификатов CCA, MCA или PCA.

CA расчетного центра - для поддержки незапланированной замены сертификатов ключевого обмена расчетного центра. Расширение CRLNumber содержит одно целое число. Центр СА, подписывающий CRL, должен инкрементировать это число каждый раз при выпуске нового CRL. При получении нового CRL должны проводиться следующие проверки: 1. Сначала проверяется подпись:

Используется AuthorityKeyIdentifier расширения CRL для контроля корректности сертификата подписи.

Расширение KeyUsage в сертификате подписи указывает на CRLsign(6) 2. IssuerDN рассматриваемого сертификата должен соответствовать полю IssuerDN в CRL.
3. IssuerDN и устаревший certSerialNumber сравниваются с проверяемым сертификатом Следующие проверки производятся для того, чтобы выяснить, не входит ли данный сертификат в список CRL:

IssuerDN рассматриваемого сертификата должен соответствовать содержимому поля IssuerDN CRL

certSerialNumber должно соответствовать значению поля revokedCertificates.certSerialNumber списка CRL. Существующие CRL от одного и того же IssuerDN могут быть удалены, когда успешно прошел проверку CRL с более высоким значением CRLNumber. BrandCRLIdentifier BrandCRLIdentifier (BCI) представляет собой структуру, определенную SET и используемую для идентификации всех рабочих CRL заданной области ответственности сертификационного центра платежной системы.

BrandCRLIdentifier содержит в себе следующую информацию:

Номер BCI (увеличивается для каждого нового BCI)

Название платежной системы

Время пригодности BCI

Список номеров CRL (из расширения номера CRL)

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

Сертификат для:	Формируется и подписывается:
СА платежной системы	Корневой СА
Геополитический СА	СА платежной системы
ССА, МСА или РСА	Геополитический СА, если таковой имеется, в противном случае СА платежной системы

Сообщения запросы от СA форматируются согласно CertificationRequest, специфицированному в PKCS#4 версии 1.0. CertificationRequest содержит общедоступный ключ, DN субъекта и атрибуты, которые должен сертифицировать подписывающий СА. Сообщение-запрос сертификата включает в себя информацию, которая должна присутствовать в расширениях сертификата. Эта информация содержится в атрибутах запроса PKCS#10. В таблице 4.6.2.37 показаны атрибуты, которые необходимы или опционны в CertificationRequest. Таблица 4.6.2.37. Атрибуты CertificationRequest

	ССА, МСА или РСА				Геополитический центр сертификации или СА платежной системы
Атрибут SET		Сертификат подписи		Подпись CRL	Сертификат и подпись CRL
KeyUsage	X	X	X	X	X
PrivateKeyUsagePeriod	X	X		X	X
AdditionalPolicy	O	O	O	O	O
SubjectAltName	O	O	O	O	O
CertificateType	X	X	X	X	X
Tunneling			X

Х - обязательный
O - опционный При получении CertificationRequest СА должен проверить запрос и сформировать отклик в соответствии со следующей процедурой:

Шаг	Действие
1	Используя процедуру, определенную платежной системой, проверить аутентичность CertificationRequest
2	Используя общедоступный ключ, присланный в запросе, проверить подпись
3	Проверить, что уникальное имя субъекта (Distinguished Name) согласуется с форматом Certificate Subject Name
4	Используя тип сертификата и атрибуты использования ключа, проверить, что имеются необходимые атрибуты (см. таблицу 4.6.2.37)
5	Для сертификатов подписи проверить, что запрошенный PrivateKeyUsagePeriod находится в пределах допустимого диапазона пригодности по времени для подписывающего СА, и что дата notBefore в запрошенном PrivateKeyUsagePeriod находится в пределах допустимого для подписывающего СА.
6	Если какая-либо из вышеперечисленных проверок не прошла, сертификат не будет сформирован.
7	Если верификация прошла успешно, сертификат формируется с применением атрибутов, включенных в запрос. Сформированный сертификат помещается в соответствующую секцию SignedData.
8	SignedData помещается в цифровой конверт и посылается отправителю запроса. Транспортные механизмы находятся вне зоны ответственности SET.

Рассылка CRL CRL представляет собой механизм, определенный Х.509, и предназначенный для публикации и рассылки списков выведенных из употребления сертификатов, срок действия которых еще не истек. Когда корневой СА актуализует свой CRL, он посылает его каждому центру сертификации платежной системы. Когда нижерасположенный центр сертификации актуализует свой CRL, он рассылает его своим СА платежных систем. CRL рассылаются в секции SignedData сообщений CRLNotification согласно следующему алгоритму.

Шаг	Действие
1	Сформировать CRLNotificationTBS: Занести в поле данные текущую дату Занести в CRLThumbprint оттиск, несущий в себе CRL
2	Подписать содержимое, используя сертификат подписи СА. Установить тип содержимого равным id-set-content-CRLNotificationTBS
3	Внести новый CRL в CRL-секцию SignedData. Вложить CRL в сертификационную секцию сообщения.
4	Закодировать и вложить в цифровой конверт подписанное сообщение CRLNotification. Следует заметить, что это не SET-сообщение. SignedData подвергается DER-кодированию и вкладывается в цифровой конверт MIME.

CRL-Notification-сообщение содержит следующие поля:

Название поля	Описание
CRL-Notification	S(CA, CRLNotificationTBS)
CRL-NotificationTBS	{Date, CRLThumbprint}
Дата	Дата, когда сформировано сообщение
CRLThumbprint	Оттиск CRL, заключенный в CRL-секцию SignedData

При получении сообщения CRL Notification СА платежной системы проверяет и анализирует его следующим образом:

Шаг	Действие
1	Если дата раньше, чем для любого предыдущего CRL, полученного от этого СА, сообщение проигнорировать и откликнуться отправившему СА сообщением Error c кодом ошибки badDate.
2	Если CRL-оттиск не согласуется с тем, который записан в CRL-секции SignedData, сообщение проигнорировать и откликнуться отправившему СА сообщением Error c кодом thumbMismatch.
3	Запомнить модифицированный CRL и послать СА платежной системы для добавления в последующее сообщение рассылки BCI.

CA платежной системы формирует отклик CRL Notification согласно следующему алгоритму:

Шаг	Действие
1	Заполнить NotificationResTBS: Вставить дату из сообщения CRLNotification Вставить оттиск полученного CRL
2	Подписать содержимое, используя сертификат подписи центра сертификации платежной системы. Установить contenttype равным id-set-content-CRLNotificationResTBS
3	Закодировать и вложить в цифровой конверт подписанное сообщение CRLNotificationRes в форме согласованной с транспортным механизмом. Послать сообщение отклика CRLNotification запросившему СА.

Сообщение- отклик CRLNotification содержит следующие поля.

Название поля	Описание
CRL-NotificationRes	S(CA, CRLNotificationTBS)
CRL-NotificationResTBS	{Date, CRLThumbprint}
Дата	Копируется из сообщения CRLNotification
CRLThumbprint	Оттиск CRL, копируется из сообщения CRLNotification

При получении отклика CRLNotification СА проверяет то, что дата и оттиск соответствуют значениям из запроса. Если соответствия нет, посылается сообщение об ошибке, а запрос CRLNotification посылается повторно. Получение BCI BrandCRLIdentifier (BCI) является списком текущих CRL, соответствующим всем СА из зоны ответственности платежной системы (Brand). Центр сертификации платежной системы отвечает за поддержку, корректность и актуальность BCI. Каждый CA из зоны ответственности платежной системы отвечает за обновление и осуществление доступа к BCI и соответствующим спискам CRL. Эту информацию они выдают в виде откликов на запросы ЕЕ или нижестоящих СА. Центр сертификации каждой платежной системы формирует и поддерживает свой BCI и реализует механизм для рассылки этой информации. СА, например, расчетного центра должен организовать ежедневное обновление этих данных. Центр сертификации платежной системы рассылает информацию о новых CRL в виде сообщений BCI Distribution. Это сообщение является подписанным, содержащим текущую дату, BCI, соответствующие сертификаты и CRL. Сообщение BCI Distribution не формируется ежедневно, а лишь по мере необходимости. Алгоритм формирования этого сообщения представлен ниже.

Шаг	Действие
1	Заполнить BCIDistributionTBS: Ввести текущую дату Включить последнюю версию BCI
2	Подписать содержимое, используя сертификат подписи центра сертификации платежной системы. Установить contenttype равным id-set-content-BCIDistributionTBS. В CRL секцию SignedData ввести все CRL, перечисленные в BCI. В сертификатную часть вставить все сертификаты, необходимые для верификации всех CRL.
3	Закодировать и вложить в цифровой конверт подписанное сообщение BCIDistribution в форме, согласованной с транспортным механизмом.

Сообщение BCI Distribution содержит в себе следующие поля:

Название поля	Описание
BCIDistribution	S(CA, BCIDistributionTBS)
BCIDistributionResTBS	{Date, BCIDistribution}
Дата	Дата формирования сообщения
BrandCRLIdentifier	Список текущих CRL для всех СА в зоне ответственности центра сертификации платежной системы и корневого СА. Сообщение подписывается сертификационным центром платежной системы.

Обработка пришедшего сообщения BCIDistribution соответствующим СА производится согласно алгоритму, приведенному ниже:

Шаг	Действие
1	Извлечь BCIDistribution из транспортного сообщения. Проверить подпись сообщения, используя сертификат подписи СА платежной системы.
2	Если дата относится к моменту времени раньше, чем та, что в предыдущем сообщении BCIDistribution, сообщение следует выбросить.
3	Если BrandCRLIdentifier отличается от текущего, проверить подпись каждого CRL из BCI. Если подпись некорректна или список CRL из перечня BCI не включен в сообщение, оно отбрасывается.
4	Запомнить все CRL и BrandCRLIdentifier для последующей рассылки

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

TransID	{LID-C, [LID-M], XID, PReqData, [PaySysID], Language}
LID-C	Локальный ID. Метка, генерируемая системой владельца карты или для нее.
LID-M	Локальный ID. Метка, генерируемая системой продавца или для нее.
XID	Глобально уникальный идентификатор
PReqData	Дата запроса покупки. Генерируется продавцом в PInitRes или владельцем карты в PReq.
PaySysID	Используется некоторыми платежными системами для пометки транзакций
Language	Естественный язык владельца карты

TransID предоставляет несколько идентификаторов для транзакций. LID-C, LID-M и PaySysID являются идентификаторами, которые присваиваются владельцем карты, продавцом и/или платежной системой. LID-M часто используется для хранения номера заказа продавца для данной транзакции. PreqData предоставляет дату запуска транзакции. XID представляет собой идентификатор транзакции, который обычно формируется системой продавца, если только нет PInitRes, в последнем случае он формируется системой владельца карты.

XID представляет собой псевдослучайный 20 байтовый код, который должен быть уникальным. В таблице 4.6.2.38 рассмотрено, когда формируется и используется поле TransID в сообщениях SET. Таблица 4.6.2.38. Условия формирования и использование поля TransID

Сообщение	LID-C	LID-M	XID	PaySysID
PInitReq	R	C1	N/P	N/P
PInitRes	Я	Я (C2)	R	N/P
PReq	Я	Я	Я (R3)	N/P
PRes	Я	Я (C2)	Я	C4
InqReq	Я	Я	Я	C5
InqRes	Я	Я	Я	C4
AuthReq	Я	Я	Я	N/P
AuthRes	Я	Я	Я	C6
AuthRevReq	Я	Я	Я	C
AuthRevRes	Я	Я	Я	Я
CapReq	I	I	I	I
CapRes	I	I	I	I
CapRevReq	I	I	I	I
CapRevRes	I	I	I	I
CredReq	I	I	I	I
CredRes	I	I	I	I
CredRevReq	I	I	I	I
CredRevRes	I	I	I	I
PCertReq	N/P	C	N/P	N/P
PCertRes	N/P	Я	N/P	N/P
BatchAdminReq	I	I	I	I
BatchAdminRes	I	I	I	I
CardCInitReq	R	N/P	N/P	N/P
CardCInitRes	Я	N/P	N/P	N/P
Me-AdCInitReq	N/P	C	N/P	N/P
Me-AdCInitRes	N/P	Я	N/P	N/P
RegFormReq	Я	Я	N/P	N/P
RegFormRes	Я	Я	N/P	N/P
CertReq	Я	Я	N/P	N/P
CertRes	Я	Я	N/P	N/P
CertInqReq	Я	Я	N/P	N/P
CertInqRes	Я	Я	N/P	N/P

R	Поле является обязательным, генерируется отправителем сообщения и копируется в цифровой конверт.
C	Наличие поля является условным. Оно может быть сформировано для этого сообщения и задублировано в цифровом конверте. В противном случае поле копируется из предыдущего сообщения.
N/P	(Not Present) Отсутствует как в сообщении так и в цифровом конверте.
Я	Копируется из запроса или предыдущего сообщения, дублируется в цифровом конверте
I	Может присутствовать в элементе информационной структуры сообщения, отсутствует в цифровом конверте.

Примечания:

Копируется из процесса инициализации SET (если имеется)

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

Если пара PinitReq/PinitRes отсутствует, то генерируется владельцем карты.

Если послано после получения AuthRes с PaySysID

Если послано после получения PRes с PaySysID

Может быть сформировано расчетным центром для данного сообщения. Алгоритм формирования TransID представлен ниже:

Шаг	Действие
1	Если сообщение для данной транзакции получено раньше, следует запомнить все его поля.
2	Если это новая транзакция, сформировать все необходимые поля (см таблицу выше)
3	Заполнить любые опционные поля, которые могут быть сформированы данным объектом.

Обработка TransID зависит от типа сообщения. Платежная инструкция Платежная инструкция (PI) является одной из важнейших информационных структур SET.

Она используется для передачи информации, необходимой для авторизации операции платежа владельца карты расчетному центру. Данная операция служит для инициализации транзакции с привлечением традиционной платежной карты. Данные шифруются владельцем карты и посылаются через продавца получателю (банку продавца - Acquirer). Эта информация не может быть прочитана продавцом. Имеется три разновидности PI. Первые два формируются владельцем карты, третье - расчетным центром.

PIUnsigned	Формируется владельцем карты без использования сертификата подписи. Используется в сообщениях PReqUnsigned.Целостность данных обеспечивается за счет добавления хэша PI-данных, которые защищены в блоке OAEP. В данном механизме аутентификация отправителя не производится.
PIDualSigned	Формируется владельцем карты, который владеет сертификатом подписи. Используется в сообщениях PreqDualSigned. Подпись владельца карты аутентифицирует отправителя и гарантирует целостность данных.
AuthToken	Формируется расчетным центром. Продавец извлекает PI для дальнейшего вложения в AuthReq. Этот вариант используется для поддержки доставки по частям и передается назад из расчетного центра после первичной авторизации с тем, чтобы использоваться для запросов последующих авторизаций.

Платежная инструкция имеет структуру представленную в таблице 4.6.2.39. Таблица 4.6.2.39. Структура PI

PI	Владелец карты создает PIUnsigned или PIDualSigned инструкцию. Расчетный центр формирует AuthToken для поддержки поставки по частям и последовательных платежей. Продавец запишет PI для последующего вложения в AuthReq.
PIUnsigned	EXH(P, PI-OILink, PANToken)} (См. табл. 4.6.2.46)
PIDualSigned	{PISignature, EX(P, PI-OILink, PANData)} (См. табл. 4.6.2.45)
AuthToken	См. табл. 4.6.2.42
PI-OILink	L(PIHead, OIData) (см. табл. 4.6.2.40)
PISignature	SO(C, PI-TBS)
PI-TBS	{HPIData, HOIData}
HPIData	DD(PIData)
HOIData	DD(OIData)
PIData	{PIHead, PANData} (см. табл. 4.6.2.40 и 4.6.2.45)

Таблица 4.6.2.40.

Структура PIHead

PIHead	{TransIDs, Inputs, MerchantID, [InstallRecurData], TransStain, SWIdent, [AcqBackKeyData], [PIExtensions]}
TransIDs	См. выше описание TransIDs
Inputs	{HOD, PurchAmt}
MerchantID	Копируется из сертификата подписи продавца
InstallRecurData	См. табл. 4.6.2.41
TransStain	HMAC(XID, CardSecret)
SWIdent	Строка, идентифицирующая программное обеспечение (разработчик и версия), инициирующее запрос. Оно специфицируется в PI, чтобы расчетный центр знал программное обеспечение владельца карты.
AcqBackKeyData	{AcqBackAlg, AcqBackKey}
PIExtensions	Данные из расширения платежных инструкций должны быть финансовыми и важными для обработки авторизации расчетного центра, эмитента или финансовой сети

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

InstallRecurData	{InstallRecurDInd, [IRExtensions]}
InstallRecurDInd	< InstallTotalTrans, Recurring >
IRExtensions	Данные в расширении или рекурсивные данные. Они должны носить финансовый характер и должны иметь отношение к последующим процедурам авторизации продавца и расчетного центра
InstallTotalTrans	Владелец карты специфицирует максимально допустимое число авторизаций для последовательных платежей
Recurring	{RecurringFrequency, RecurringExpiry}
RecurringFrequency	Минимальное число дней между авторизациями (ежемесячная авторизация обозначается 28 днями)
RecurringExpiry	Окончательная дата, после которой никакие авторизации не разрешены

Рекуррентные данные являются компонентом платежной инструкции, которая копируется в авторизационный маркер (token). Эта информация не пересылается эмитенту. AuthToken представляет данные, необходимые расчетному центру для авторизации последующих транзакций. Расчетный центр, если необходимо, актуализует AuthToken.

Данные, содержащиеся там должны быть доступны только расчетному центру. Структура данных AuthToken представлена в таблице 4.6.2.42. Таблица 4.6.2.42. Структура AuthToken

AuthTokenData	{TransIDs, PurchAmt, MerchantID, [AcqBackKeyData], [InstallRecurData], [RecurringCount], PrevAuthDataTime, TotalAuthAmount, AuthTokenOpaque}
PANToken	Поля копируются из поля PI-Head, сформированного владельцем карты (см. табл. 4.6.2.40)
TransIDs
PurchAmt
MerchantID
AcqBackKeyData
InstallRecurData
RecurringCount	Число реализованных рекуррентных авторизаций
PrevAuthDateTime	Дата и время последней авторизации продавца в последовательности рекуррентных авторизаций
TotalAuthAmount	Полное число авторизованных в результате всех авторизаций для данного XID
AuthTokenOpaque	Невидимые данные, генерируемые расчетным центром

AuthToken формируется следующим образом:

Шаг	Действие
1	Генерируется AuthTokenTBE как: Если это первая авторизация (выполнена согласно PI) а. Заполняется из PI поля PANToken, TransIDs, PurchAmt, MerchantID и, если имеется в PI, AcqBackInfo и InstallRecurData б. RecurringCount делается равным 1 в. В PrevAuthDateTime записывается текущая дата г. В TotalAuthAmount заносится AuthAmt из авторизационного отклика, который содержит данный AuthTokenЕсли это очередная аутентификация (сгенерирована из предыдущего AuthToken) а. Заполняется из предыдущего AuthToken поля PANToken, TransIDs, PurchAmt, MerchantID и, если имеется, AcqBackInfo и InstallRecurData б. Инкрементируется на 1 RecurringCount в. В PrevAuthDateTime записывается текущая дата г. TotalAuthAmount увеличивается на AuthAmt, взятое из авторизационного отклика, который содержит данный AuthTokenЕсли это полная (reversal) аутентификация (сгенерирована из предыдущего AuthToken) а. Из предыдущего AuthToken заполняются поля PANToken, TransIDs, PurchAmt, MerchantID, PrevAuthDateTime и, если имеется, AcqBackInfo и InstallRecurData б. Если это повторное выполнение всех авторизаций (т.е. AuthNewAmt в AuthRevReq равно нулю), уменьшить RecurringCount на 1 в. Уменьшить TotalAuthAmount на AuthNewAmt из авторизацилнного отклика, который будет содержать маркер AuthToken.
2	Сформировать PANToken (см. табл. 4.6.2.46)
3	С привлечением инкапсуляции EncX уложить данные в цифровой конверт, используя P1=P2=Cert-PE в качестве s и r параметров, AuthTokenTBE (из шага 1) - в качестве параметра t и PANToken - в качестве параметра p.

Обработка AuthToken выполняется в следующем порядке:

Шаг	Действие
1	Извлечь AuthToken из EncX-конверта, используя секретный ключ расчетного центра.
2	Если это автризационный запрос и AuthToken уже использовался при авторизации, установить AuthCode равным piPreviouslyUsed
3	Если это запрос повторной авторизации (reversal request) и AuthToken не использовался при авторизации, установить AuthCode=piAuthMismatch.
4	Если это авторизационный запрос и InstallRecurData специфицирована рекурентной информацией: Проверить, что текущая дата относится ко времени раньше даты RecurringExpiry. Если проверка не прошла, установить AuthCode равным recurringExpired. Проверить, что текущая дата позднее, чем PrevAuthDate плюс число дней, специфицированное в RecurringFrequency. Если проверка не прошла, установить AuthCode равным recurringTooSoon.
5	Если это автризационный запрос и InstallRecurData специфицирована информацией Installment, реализовать специфические требования платежной системы карты.
6	Если на предыдущих шагах AuthCode не был установлен, переадресовать данные от AuthToken авторизационному процессу.

AcqCardMsg является полем, которое предоставляет механизм для посылки банком продавца сообщения владельцу карты, не информируя об этом продавца (туннелирование). Это поле может быть использовано после того, как расчетный центр получит сообщение AuthReq от продавца. Структура данных AcqCardMsg представлена в таблице 4.6.2.43. Таблица 4.6.2.43. Структура AcqCardMsg

AcqCardMsg	EncK(AcqBackKeyData, P, AcqCardCodeMsg) AcqBackKeyData предоставляется владельцем карты в PI. Зашифрованное сообщение адресуется владельцу карты.
AcqBackKeyData	Копируется из PIHead.AcqBackKeyData (см. табл. 4.6.2.40)
AcqCardCodeMsg	{AcqCardCode, AcqCardMsgData}
AcqCardCode	Числовой код
AcqCardMsgData	{[AcqCardText], [AcqCardURL], [AcqCardPhone]}
AcqCardText	Текстовое сообщение, отображаемое владельцу карты
AcqCardURL	URL HTML-сообщения, отображаемого владельцу карты
AcqCardPhone	Телефонный номер, предоставляемый владельцу карты

Для AcqCardCode определены следующие значения:

messageOfDay	Банк продавца хочет, чтобы это сообщение было передано всем
accountInfo	Информация о счете должна быть передана назад пользователю
сallCustomerService	Предлагает приложению отобразить сообщение, рекомендующее пользователю обратиться в службу обслуживания клиентов

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

Структура данных CapToken представлена в таблице 4.6.2.44. Таблица 4.6.2.44. Структура CapToken

CapToken	P1 и P2 обозначают платежные центры: P1 - отправителя P2 - получателя В данной версии SET P1 и P2 означают один и тот же расчетный центр (т.е. P1=P2)
CapTokenData	{AuthRRPID, AuthAmt, TokenOpaque}
PANToken	Смотри табл. 4.6.2.46
AuthRRPID	RRPID, который появляется в соответствующем AuthReq или AuthRevReq
AuthAmt	Действительное число авторизованных, которое может отличаться от PurchAmt владельца карты
TokenOpaque	Невидимые данные, определенные расчетным центром

Алгоритм формирования CapToken показан ниже:

Шаг	Действие
1	Если формируется в ходе авторизации, установить AuthAmt в CapTokenData равным AuthAmt в AuthRes. В противном случае, если генерируется во время повторного авторизационного процесса, занести AuthAmt в CapTokenData равным AuthNewAmt для последующей посылки в AuthRevRes
2	Занести в TokenOpaque из CapTokenData частные данные, необходимые для расчетов
3	Если продавец получает PANToken из своего банка, тогда: Занести PANToken из PI Использовать EncX инкапсуляцию с CapTokenData в нормально зашифрованной части и PANToken в дополнительно зашифрованной секцииВ противном случае: Использовать Enc инкапсуляцию с CapTokenData

Обработка CapToken производится следующим образом:

Шаг	Действие
1	Используя секретный ключ расчетного центра, извлечь CapTokenData из упаковки ЕncX или Enc.
2	Если это платежный запрос (capture request) и CapToken уже использовался в таком запросе, установить CapCode в CapResPayload равным dublicateRequest.
3	Если это аннулирование (reversal) платежного запроса, запрос кредита или отзыв кредита и CapToken ранее не использовался в платежных запросах, установить CapRevOrCredCode в поле CapRevOrCredResPayload равным originalNotFound
4	Если это аннулирование платежного запроса, а CapToken уже использовался в подобном запросе, установить CapRevOrCredCode в CapRevOrCredResPayload равным dublicateRequest.
5	Если CapCode или CapRevOrCredCode не были установлены при выполнении предыдущих шагов, переадресовать данные из CapToken процессу платежного запроса.

PANData содержит информацию, идентифицирующую определенный счет платежной карты.

Структура данных PANData представлена в таблице 4.6.2.45. Таблица 4.6.2.45. Структура PANData

PANData	{PAN, CardExpiry, PANSecret, EXNonce}
PAN	Первичный номер счета, обычно номер счета карты
CardExpiry	Дата действительности карты
PANSecrit	Секретный код, используемый совместно владельцем карты, расчетным центром и сертификационным центром владельца карты. Предотвращает атаки на PAN в сертификате владельца карты.
EXNonce	Новый код (Nonce), который препятствует атаке на PANData

Формирование PANData осуществляется согласно алгоритму, рассмотренному ниже.

Шаг	Действие
1	Занести в PAN номер счета владельца карты
2	Записать в CardExpiry дату действительности карты
3	Занести PANSecret, который был получен от СА вместе с сертификатом владельца карты. Для владельца карты без сертификата все октеты этого поля устанавливаются равными нулю.
4	Сформировать новое значение EXNonce

PANToken подобно PANData содержит информацию, идентифицирующую определенную платежную карту. PANToken используется, когда для сокрытия данных PANSecret не нужен. Структура PANToken показана в таблице 4.6.2.46. Таблица 4.6.2.46. Структура PANToken

PANToken	{PAN, CardExpiry, EXNonce}
PAN	Первичный номер счета, обычно номер счета карты
CardExpiry	Дата действительности карты
EXNonce	Новый код (Nonce), который препятствует атаке на PANData

Формирование PANToken осуществляется достаточно просто:

Шаг	Действие
1	Занести в PAN номер счета владельца карты
2	Записать в CardExpiry дату действительности карты
3	Сформировать новое значение EXNonce.

Структура SaleDetail SaleDetail соединяет в себе данные, относящиеся к текущей транзакции. Эта структура формируется как часть установления процесса между продавцом и расчетным центром. Для AuthReq, CredReq и CapReq формирование продавцом SaleDetail является опционным. Структура данных в SaleDetail показана в таблице 4.6.2.47. Таблица 4.6.2.47. Структура SaleDetail

SaleDetail	{[BatchID],[BatchSequenceNum], [PayRecurInd], [MerOrderNum], [AuthCharInd], [MarketSpecSaleData], [CommercialCardData], [OrderSummery], [CustomerReferenceNumber], [CustomerServicePhone], OktoPrintPhoneInd, [SaleExtensions]} Это поле может появляться в AuthReq с флагом CaptureNow установленным равным TRUE или в сообщениях, связанных с платежным запросом.
BatchID	Идентификация последовательности операций в системе продавец и его банк
BatchSequenceNum	Порядковый номер позиции в данной последовательности расчетных операций.
PayRecurInd	Номер типа транзакции
MerOrderNum	Номер заказа продавца
AuthCharInd	Копируется из AuthResPayload
MarketSpecSaleData	{[MarketSpecDataID], [MarketSpecCapData]}
CommercialCardData	Описание позиции в платежном запросе (см. табл. 4.6.2.48)
OrderSummary	Краткое описание заказа
CustomerReferenceNumber	Номер ссылки, присвоенный заказу владельца карты
CustomerServicePhone	Номер телефона службы обслуживания клиентов данного продавца
OKtoPrintPhoneInd	Булево число, указывающее, может ли эмитент выдавать телефон службы сервиса в ответ на запрос владельца карты.
SaleExtensions	Данные этого расширения должны быть финансовыми и важными для обработки платежного запроса расчетного центра или эмитента
MarketSpecDataID	Копируется из AuthResPayload
MarketSpecCapData
MarketAutoCap	Описание оплаты проката автомобиля (см. табл. 4.6.2.49)
MarketHotelCap	Описание оплаты гостиницы (см. табл. 4.6.2.50)
MarketTransportCap	Данные о пассажире (см. табл. 4.6.2.51)

PayRecurInd может принимать следующие значения:

unknown	Тип транзакции неизвестен
singleTransaction	Транзакция состоит из одной авторизации и платежного запроса
recurringTransaction	Транзакция состоит из нескольких авторизаций и платежных запросов, которые повторяются регулярно
installmentPayment	Транзакция состоит из нескольких авторизаций и заказов-резервирований, которые выполняются фиксированное число раз
otherMailOrder	Прочие транзакции заказов по почте

Структура коммерческих данных карты представлена в таблице 4.6.2.48. Таблица 4.6.2.48. Структура коммерческих данных карты

CommercialCardData	{[ChargeInfo], [MerchantLocation], [ShipFrom], [ShipTo], [ItemSeq]}
ChargeInfo	{[TotalFreightShippingAmount], [TotalDutyTariffAmount], [DutyTariffReference], [TotalNationalTaxAmount], [TotalLocalTaxAmount], [TotalOtherTaxAmount], [TotalTaxAmount], [MerchantTaxID], [MerchantDutyTariffRef], [CustomerDutyTariffRef], [SummaryCommodityCode], [MerchantType]}
MerchantLocation	Местоположение продавца
ShipFrom	Адрес отправки
ShipTo	Адрес получателя
ItemSeq	{Item +} Номера от 1 до 999
TotalFreightShippingAmount	Общее количество позиций, подлежащих обработке и доставке
TotalDutyTariffAmount	Полная сумма налога или тариф для заказа
DutyTariffReference	Код ссылки, приписанный налогу или тарифу для данного заказа
TotalNationalTaxAmount	Полная величина национального налога (с продаж или на добавленную стоимость), распространяющегося на данный заказ
TotalLocalTaxAmount	Размер местного налога, распространяющегося на данный заказ
TotalOtherTaxAmount	Прочие налоги, действующие для данного заказа
TotalTaxAmount	Полный размер налога для данного заказа
MerchantTaxID	Индивидуальный идентификационный номер продавца
MerchantDutyTariffRef	Код налога или тарифа, приписанный продавцу
CustomerDutyTariffRef	Код налога или тарифа, приписанный владельцу карты
SummaryCommodityCode	Код товара, приложимый ко всему заказу
MerchantType	Тип продавца
Item	{Quantity, [UnitOfMeasureCode], Descriptor, [CommodityCode], [ProductCode], [UnitCost], [NetCost], DiscountInd, [DiscountInd], [NationalTaxAmount], [NationalTaxAmount], [NationalTaxRate], [NationalTaxType], [LocalTaxAmount], [LocalTaxAmount], ItemTotalCost}
Quantity	Количество предметов или услуг данного типа
UnitOfMeasureCode	Единицы измерения для данной позиции в заказе
Descriptor	Описание позиции в заказе
CommodityCode	Код вида товара для данной позиции заказа
ProductCode	Код продукта для данной позиции заказа
UnitCost	Цена единицы товара
NetCost	Чистая цена единицы товара
DiscountInd	Указывает, распространяется ли скидка на данную позицию в заказе
DiscountAmount	Величина скидки для данной позиции заказа
NationalTaxAmount	Величина национального налога, применимого к данной позиции заказа
NationalTaxRate	Национальный налог (с продаж или на добавленную стоимость), применимый к данной позиции заказа
NationalTaxType	Ставка национального налога, действующая для данной позиции заказа
LocalTaxAmount	Величина местного налога, действующая для данной позиции заказа
OtherTaxAmount	Величина прочих налогов
ItemTotalCost	Полная цена данной строки заказа

Структура данных MarketAutoCap представлена в таблице 4.6.2.49. Таблица 4.6.2.49.

Структура MarketAutoCap

MarketAutoCap	{[RenterName], [RentalLocation], RentalDateTime, [AutoNoShow], [RentalAgreementNumber], [ReferenceNumber], [InsuranceType], [InsuranceType], [ReturnLocation], ReturnDateTime, AutoCharges}
RenterName	Имя лица, сдающего авто в аренду
RentalLocation	Адрес фирмы сдающей авто в аренду
RentalDateTime	Дата (опционно время), когда авто было взято в аренду
AutoNoShow	Числовой код, указывающий, что клиент не предъявил во время арендованную машину
RentalAgreementNumber	Номер арендного соглашения
ReferenceNumber	Код аренды
InsuranceType	Тип страховки, выбранный арендатором
AutoRateInfo	{AutoApplicableRate, [LateReturnHourlyRate], [LateReturnHourlyRate], [FreeDistance], [VehicleClassCode], [CirporateID]}
ReturnLocation	Адрес фирмы, куда следует вернуть авто (см. табл. 4.6.2.51)
ReturnDateTime	Дата (опционно время) возвращения автомобиля
AutoCharges	{RegularDistanceCharges, [LateReturnCharges], [TotalDistance], [ExtraDistanceCharges], [InsuranceCharges], [FuelCharges], [AutoTowingCharges], [OneWayDropOffCharges], [TelephoneCharges], [ViolationsCharges], [DelivaryCharges], [ParkingCharges], [OtherCharges], [TotalTaxAmount], [AuditAdjustment]}
AutoApplicableRate
LateReturnHourlyRate	Почасовая плата за опоздание возврата
DistanceRate	Помильная оплата за превышение допустимого пробега
FreeDistance	Расстояние, которое может пройти машина в день, без увеличения арендной платы.
VehicleClassCode	Класс арендуемого автомобиля
CorporateID	Корпоративный идентификационный номер, который применяется для определения арендной платы
RegularDistanceCharges	Сумма расходов за аренду (исключая расходы, перечисленные ниже)
LateReturnCharges	Сумма выплаты за возвращения автомобиля после оговоренного срока.
TotalDistance	Полный пробег автомобиля.
ExtraDistanceCharges	Сумма оплаты избыточного пробега (сверх оговоренного в договоре)
InsuranceCharges	Сумма страховки
FuelCharges	Оплата горючего
AutoTowingCharges	Оплата буксировки
OneWayDropOffCharges	Оплата одностороннего разрыва арендного договора
TelephoneCharges	Расходы использования телефона в арендованной машине
ViolationsCharges	Сумма штрафов за нарушения за время аренды автомобиля
DelivaryCharges	Оплата доставки арендованного автомобиля
ParkingCharges	Оплата парковки арендованного автомобиля
OtherCharges	Оплата расходов, не определенных в других позициях
TotalTaxAmount	Сумма налогов, связанная с арендой автомобиля
AuditAdjustment	Сумма изменения объема транзакции в результате аудита в компании, предоставляющей автомобили в аренду.
DailyRentalRate	Дневная арендная плата
WeeklyRentalRate	Арендная плата за неделю

Структура данных MarketHotelCap представлена в таблице 4.6.2.50. Таблица 4.6.2.50.

Структура MarketHotelCap

MarketHotelCap	{[ArriveDate], [RentalLocation], DepartureDate, [DurationOfStay], [FolioNumber], [PropertyPhone], [CustomerServicePhone], [ProgramCode], [HotelRateInfo], HotelCharges}
ArriveDate	Дата регистрации владельца карты в отеле
HotelNoShow	Цифровой код, указывающий, что клиент не был зарегистрирован в этом отеле своевременно
DepartureDate	Дата отбытия владельца карты из отеля
DurationOfStay	Число дней пребывания владельца карты в отеле
FolioNumber	Номер книги
PropertyPhone	Номер телефона отеля
CustomerServicePhone	Номер телефона системы обслуживания клиентов отеля или сети отелей
ProgramCode	Код, указывающий тип специальной программы пребывания клиента
HotelRateInfo	{DailyRoomRate, [DailyTaxRate]}
HotelCharges	{RoomCharges, [RoomTax], [PrepaidExpenses], [FoodBeverageCharges], [RoomServiceCharges], [MiniBarCharges], [LaundryCharges], [TelephoneCharges], [BusinessCenterCharges], [ParkingCharges], [MovieCharges], [HealthClubCharges], [GiftShopCharges], [FolioCashAdvances], [OtherCharges], [TotalTaxAmount ], [AuditAdjustment]}
DailyRoomRate	Стоимость проживания в день. В эту сумму входят налоги, если не специфицирована переменная DailyTaxRate.
DailyTaxRate	Размер налога за проживание одного дня в гостинице
RoomCharges	Полная стоимость проживания в номере с учетом дополнительных расходов, перечисленных ниже
RoomTax	Налог, взымаемый с суммы RoomCharges
PrepaidExpenses	Полный размер предоплаты
FoodBeverageCharges	Оплата еды и напитков
RoomServiceCharges	Оплата обслуживания номера
MiniBarCharges	Оплата пользования минибаром
LaundryCharges	Оплата услуг прачечной
TelephoneCharges	Плата за пользование телефоном
BusinessCenterCharges	Оплата за услуги бизнес-центра
ParkingCharges	Оплата парковки
MovieCharges	Оплата за просмотр фильмов в номере
HealthClubCharges	Оплата услуг оздоровительного клуба
GiftShopCharges	Оплата покупок в сувенирном магазине
FolioCashAdvances	Сумма, предварительно внесенная за номер
OtherCharges	Другие расходы
TotalTaxAmount	Сумма налогов, включенная в счет
AuditAdjustment	Изменение платежа в результате перепроверки расчетов в отеле

Структура данных MarketTransportCap представлена в таблице 4.6.2.51. Таблица 4.6.2.51.

Структура MarketTransportCap

MarketTransportCap	{PassangerName, DepartureDate, OrigCityAirport, [TripLegSeq], [TicketNumber], [TravelAgencyCode], [TravelAgencyName], [Restrictions]}
PassangerName	Имя пассажира, кому выдается билет
DepartureDate	Дата отбытия
OrigCityAirport	Город начала путешествия
TripLegSeq	{TripLeg +} от одной до 10 TripLeg-записей
TicketNumber	Номер билета
TravelAgencyCode	Код турагенства
TravelAgencyName	Название турагенства
Restrictions	Численный код, указывающий на ограничения выплат и расходов
TripLeg	{DateOfTravel, CarrierCode, ServiceClass, StopOverCode, DestCityAirport, [FareBasisCode], [DepartureTax]}
DateOfTravel	Дата путешествия
CarrierCode	Код перевозчика данного тура
ServiceClass	Класс услуг тура
StopOverCode	Числовой код, указывающий на допустимость остановок в пути при совершении тура
DestCityAirport	Аэропорт места назначения тура
FareBasisCode	Код базовой цены тура
DepartureTax	Налог при отбытии для данного тура

Структура данных, указывающих место (Location), представлена в таблице ниже.

Location	{CountryCode, [City], [StateProvince], [PostalCode], [LocationID]}
CountryCode	Код страны ISO 3166
City	Название города
StateProvince	Название или аббревиатура штата или провинции
PostalCode	Почтовый код
LocationID	Идентификатор, который использует продавец, чтобы специфицировать один из своих адресов

Структура данных RRTags представлена в таблице 4.6.2.52. Таблица 4.6.2.52. Структура RRTags

RRTags	{ RRPID, MerTermIDs, Date}
RRPID	Новый идентификатор пары запрос/отклик
MerTermIDs	{MerTermIDs, [TerminalID], [AgentNum], [ChainNum], [StoreNum]}
Date	Текущая дата для устаревающих записей
MerchantID	Владелец карты заносит эти данные в PIHead. Этот код копируется из MerID в сертификат подписи продавца.
TerminalID	Продавец вводит эти данные в AuthReq.
AgentNum	Продавец вводит эти данные в AuthReq.
ChainNum	Продавец вводит эти данные в AuthReq.
StoreNum	Продавец вводит эти данные в AuthReq.

Формирование RRTags производится следующим образом

Шаг	Действие
1	Формируется новый RRPID и запоминается в базе данных транзакции.
2	Заносятся MerTermIDs из записанных данных продавца, описывающих место продажи.
3	Записывается текущая дата в поле Date.

Целью BatchStatus является предоставление данных о состоянии платежной линии между расчетным центром и продавцом или для согласования объемов платежей продавца в расчетный центр.

Структура данных BatchStatus представлена в таблице 4.6.2.53. Таблица 4.6.2.53. Структура BatchStatus

BatchStatus	{OpenDateTime, [ClosedWhen], BatchDetails, [BatchExtensions]}
OpenDateTime	Дата и время открытия платежной линии
ClosedWhen	{CloseStatus, CloseDateTime}
BatchDetails	{CloseDateTime, [BrandBatchDetailsSeq]}
BatchExtensions	Данные в расширении для сообщения управления платежами должны носить финансовый характер и быть существенными для обработки административного запроса
CloseStatus	Цифровой код, указывающий статус закрытия платежной линии
CloseDateTime	Дата и время закрытия платежной линии
BatchTotals	{TransactionCountCredit, TransactionTotalAmtCredit, TransactionCountDebit, TransactionTotalAmtDebit, [BatchTotalExtensions]}
BrandBatchDetailsSeq	{BrandBatchDetails +}
TransactionCountCredit	Число транзакций, которые внесли вклад в кредит продавца.
TransactionTotalAmtCredit	Полная сумма, внесенная на счет продавца
TransactionCountDebit	Число транзакций, которые внесли вклад в дебет продавца
TransactionTotalAmtDebit	Полная сумма, снятая со счета продавца
BatchTotalExtensions	Данные расширения отклика управления платежами должны носить финансовый характер и быть существенными для обработки административного запроса.Информация, относящаяся к обработке запроса, должна появляться в расширении BatchAdminResData. Информация, имеющая отношение к состоянию платежной линии, должна лежать в расширении BatchStatus. Информация, относящаяся к деталям по конкретной позиции заказа, присутствует в расширении TransactionDetail.
BrandBatchDetails	{BrandID, BatchTotals}
BrandID	Тип платежной системы карты без типа продукта

Структура TransactionDetail служит для предоставления детальной информации о платежной линии между расчетным центром и продавцом. Формат этой структуры описан в таблице 4.6.2.54. Таблица 4.6.2.54. Структура TransactionDetail

TransactionDetail	{TransIDs, AuthRRPID, BrandID, BatchSequenceNum, [ReimbursementID], TransactionAmt, TransactionAmtType, [TransactionStatus], [TransExtensions]}
TransIDs	Идентификаторы транзакций обработки авторизации/оплаты для заданной позиции
AuthRRPID	RRPID, который присутствует в соответствующих AuthReq или AuthRevReq
BrandID	Платежная система карты (без типа продукта)
BatchSequenceNum	Порядковый номер позиции в пакете платежей
ReimbursmentID	Цифровой код, указывающий на тип оплаты для заданной позиции
TransactionAmt	Сумма для позиции, тип которой указан в TransactionAmtType. Сумма всегда обозначается положительным числом.
TransactionAmtType	Цифровой код, указывающий тип суммы (кредит или дебет)
TransactionStatus	Цифровой код, индицирующий результат прохождения транзакции для вышестоящей системы
TransExtensions	Данные в расширении для административного отклика последовательности платежей (batch) должны иметь финансовый характер и использоваться при обработке административного запроса для заданной последовательности платежей. Информация, имеющая отношение к обработке запроса должна размещаться в расширении BatchAdminResData.

Суммы в платежных сообщениях SET характеризуются тремя полями: валюта, сумма и amtExp10. Эти поля содержат ASCII-строки, формат которых охарактеризован в таблице ниже.

Поле	Определение
currency (валюта)	Значение представляется в виде строки ASCII-символов, характеризующей три цифры кода валюты (ISO 4217) Например, платеж в долларах США будет обозначен кодом 840. Возможные значения лежат в диапазоне 1-999 включительно.
amount (cумма)	Значение представляется в виде строки ASCII-символов, характеризующей сумму платежа в указанной валюте. Значение должно соответствовать положительному числу.
amtExp10	Значение представляется в виде строки ASCII-символов, характеризующей десятичный показатель степени:cумма * (10amtExp10). Значение может быть как положительным, так и отрицательным.

Для того чтобы представить сумму US $2.87 в поле PurchAmt, в поля currency, amount и amtExp10 заносятся коды 840, 250 и -2. Поля Date Даты в SET обычно указываются в форме строк, характеризующих календарную дату и время UTC в формате: YYYYMMDDHHMM[SS[.f]f]f]]]Z где Z литерал буквы Z в верхнем регистре. Таким образом, строка должна состоять из четырех цифр, характеризующих год, по две цифры, определяющие месяц, день, час (24-часовое представление) и минуту. После минут опционно могут присутствовать две цифры секунд. Если поле секунд присутствует, далее могут опционно быть прописаны доли секунды. Запись может иметь, например, форму: 20011003102853.33Z, что означает 2001 год, 03 октября, 10 часов 28 минут 53,33 секунды. Полночь отмечается датой, следующего дня. Поток платежных сообщений Основу потока платежных сообщений SET составляют пары запрос/отклик, следующие между владельцем карты и продавцом, а также между продавцом и расчетным центром. Основу обмена между владельцем карты и продавцом составляют сообщения PReq/PRes. Сообщение PRes может быть прислано немедленно или спустя некоторое время. Присылаемая информация зависит от фазы реализации протокола, в которой находится система. Авторизация продавца в расчетном центре выполняется с помощью сообщений AuthReq/AuthRes. На рис. 4.6.2.14 показан типичный пример обмена сообщениями при реализации протокола покупки.

Рис. 4.6.2.14.

Диаграмма обмена для протокола покупки На рис. 4.6.2.15 показаны все возможные сообщения, которые могут иметь место при обработке транзакции (опционные сообщения отмечены курсивом). Следует заметить, что приведенный порядок обмена является рекомендуемым, и допускается его изменение.

Рис. 4.6.2.15. Опции обмена сообщениями при покупке

Рис. 4.6.2.15а. (продолжение) Пары сообщений InqReq/InqRes позволяют владельцу карты получать информацию о состоянии транзакции. Запрос InqReq может быть послан в любое время после посылке продавцу PReq. В паре сообщений PReq/PRes владелец карты уведомляет продавца о том, что же он хочет купить. Сообщения AuthRevReq и AuthRevRes используются тогда, когда необходимо возобновить авторизацию. Сообщения CapRevReq и CAPRevRes организуют процесс отмены оплаты покупки, прежде чем сделка будет завершена. Пара CredReq и CredRes сходна с предыдущей парой, но используется после завершения сделки. Сообщения PCertReq/PCertRes обеспечивают для продавца механизм получения сертификата шифрования, который необходим для шифрования сообщения расчетному центру. BatchAdminReq и BatchAdminRes служат продавцу для открытия, закрытия и выяснения статуса транзакции его платежной линии с расчетным центром. Сообщения Error служат для уведомления об ошибках в протоколе или при обработке. Обработка запросов/откликов инициализации платежа Процедура инициализации платежа включает в себя обмен двумя сообщениями. Первоначальный запрос PInitReq посылает владелец карты, отклик PInitRes ему присылает продавец. Задачей этого обмена является получение владельцем карты сертификатов и CRL. Без такого обмена данная информация может быть получена и каким-то другим образом, например с CD-ROM. Эти сообщения посылаются после инициализации процесса SET. Сообщение-запрос PInitReq идентифицирует платежную систему карты (Brand), предоставляет локальный идентификатор владельца карты для данной транзакции, посылает переменную вызова для определения пригодности (свежести) сообщения-отклика.

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

Шаг	Действие
1	Сформировать RRPID для идентификации сообщения и установления соответствия между запросом и откликом
2	Занести в поле Language, значение которое выбрал владелец карты для данной транзакции
3	Сформировать идентификатор LID-C, который является идентификатором пары сообщений, так как XID еще не присвоен. Этому полю могут присваиваться числа натурального ряда или случайные коды.
4	Если продавец при инициации SET-процесса предоставил код LID-M, скопировать его в сообщение.
5	Сформировать новый код Chall-C
6	На основе выбранной формы платежа заполнить BrandID (из программы-магазина или из программы инициализации SET).
7	Заполнить поле BIN (первые 6 цифр номера счета владельца карты)
8	Опционно. Заполнить оттиски для сертификатов, CRL и BrandCRLIdentifier, имеющиеся у владельца карты. Сюда должен входить корневой сертификат.
9	Записать в базу данных транзакций RRPID, LID-C, LID-M (если имеется), Chall-C и оттиски (если имеются).
10	Опционно. Заполнить любые расширения PInitReq.
11	Занести все это в цифровой конверт и послать продавцу

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

PInitReq	{ RRPID, Language, LID-C, [LID-M], Chall-C, BrandID, BIN, [Thumbs], [PIRqExtensions]}
RRPID	Идентификатор пары запрос/отклик
Language	Естественный язык владельца карты
LID-C	Локальный ID. Метка, формируемая системой владельца карты или для нее.
LID-M	Копируется из сообщения инициации SET (если имеется)
Chall-C	Вызов владельца карты, служащий для гарантии новизны подписи продавца
BrandID	Выбранная владельцем карты платежная система
BIN	Номер идентификации банка из номера счета владельца карты (первые 6 цифр)
Thumbs	Оттиски списка сертификатов, CRL и BrandCRLIdentifier из кэша владельца карты
PIRqExtensions	Запрос инициализации покупки незашифрован, по этой причине эти расширения не должны содержать конфиденциальных данных.

Алгоритм обработки PInitReq продавцом представлен ниже.

Шаг	Действие
1	Извлечь запрос из входного сообщения
2	Если LID-M присутствует, найти запись транзакции, базирующуюся на LID-M. Если запись не найдена: Прислать сообщение Error c ErrorCode равным unknownLID Прервать обработку PInitReq
3	Если LID-M отсутствует, найти запись транзакции, на основе критериев, выходящим за пределы регламентаций SET. Если продавец не сформировал LID-M для этой транзакции, опционно сгенерировать LID-M и занести его в запись транзакции.
4	Сформировать новый XID
5	Занести XID, RRPID, Language, LID-C, Chall-C, BrandID и BIN в запись транзакции
6	Если оттиски присутствуют, произвести спасение записи транзакции
7	Если имеется какое-либо расширение PInitReq, произвести его обработку. Если расширение не распознано и флаг критичности равен TRUE, сформировать сообщение Error, в противном случае игнорировать расширение. Если расширение распознано, его следует обработать.

Формирование продавцом отклика PInitRes осуществляется следующим образом.

Шаг	Действие
1	Сформировать структуру данных PInitRes следующим образом: Сгенерировать TransID согласно следующей процедуре: Скопировать LID-C, XID и Language из записи транзакции Если запись транзакции содержит LID-M, скопировать его Занести текущую дату в TransIDs.PReqDate Скопировать RRPID из записи транзакции Скопировать Chall-C из записи транзакции Сформировать новый Chall-M Если оттиск для текущего BrandCRLIdentifier не получен или устарел, занести новый BrandCRLIdentifier На основе информации из PInitReq (BrandID, BIN и сертификат владельца карты) выбрать расчетный центр. Записать в PEThumb оттиск сертификата выбранного расчетного центра. Скопировать оттиски из PInitReq, если он имеется. Это позволяет владельцу карты проверить, что продавцу корректно доставлены ве посланные оттиски. Опционно: добавить любые PIRqExtensions
2	Ввести Compose SignedData. Если оттиск для Cert-PE не получен в PInitReq, включить в подпись Cert-PE.
3	Вставить все эти данные в цифровой конверт и послать владельцу карты

Информационная структура PInitRes представлена ниже в таблице 4.6.2.56. Таблица 4.6.2.56.

Структура PInitRes

PInitRes	S(M, PInitResData)
PInitResData	{TransIDs, RRPID, Chall-C, Chall-M, [BrandCRLIdentifier], PEThumb, [Thumbs], [PIRsExtensions]}
TransIDs	Смотри описание структуры TransID выше
RRPID	Идентификатор пары запрос/отклик
Chall-C	Копируется из сообщения PInitReq
Chall-M	Вызов продавца, служащий для проверки новизны подписи владельца карты
BrandCRLIdentifier	Список текущих CRL для всех СА в рамках заданной платежной системы.
PEThumb	Оттиск сертификата ключевого обмена расчетного центра.
Thumbs	Копируется из PInitReq
PIRsExtensions	Запрос инициализации покупки незашифрован, по этой причине эти расширения не должны содержать конфиденциальных данных.

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

Шаг	Действие
1	Извлечь PInitRes из входного сообщения
2	Вызвать Receive SignedData
3	Проверить TransID следующим образом: Осуществить поиск транзакции с использованием LID-C. Если поиск безуспешен: Послать сообщения Error с ErrorCode равным unknownLID Остановить обработку PInitRes Если LID-M был послан во время инициализационного процесса SET, сравнить LID-M с LID-M в записи транзакции. Если они неэквивалентны, то: Послать сообщение Error с ErrorCode равным unknownLID Остановить обработку PInitResс) Если LID-M не был послан и имеется LID-M, то: Послать сообщение Error с ErrorCode равным unknownLID Остановить обработку PInitRes
4	Сравнить RRPID со значением из записи транзакции. Если они отличаются, то: Послать сообщение Error с ErrorCode равным unknownRRPID Остановить обработку PInitRes
5	Сравнить Сhall-C со значением из записи транзакции. Если они отличаются, то: Послать сообщение Error с ErrorCode равным challengeMismatch. Остановить обработку PInitRes
6	В опционном варианте управления со стороны владельца карты из сертификата продавца извлекается его имя и отображается для пользователя. Если владелец карты одобряет кандидатуру, процесс продолжается, в противном случае обработка PInitRes прерывается.
7	Занести данные, включая TransID и Chall-M, в запись транзакции
8	Обработать BrandCRLIdentifier, если он присутствует.
9	Использовать PEThumb для идентификации сертификата шифрования (Cert-PE), чтобы использовать в PReq при шифровании данных для расчетного центра.
10	Проверить, что сертификат платежной системы продавца и сертификат расчетного центра (Cert-PE) согласуются с платежной системой владельца карты, указанной в PInitReq. Если согласия нет, владелец карты оповещается об этом, а обработка PInitReq прерывается.
11	Если поле Thubs присутствует, сравнить его значение с тем, что прислано в PInitReq. Если значения совпадают, перейти к исполнению пункта 14, в противном случае: Послать сообщение Error с ErrorCode равным thumbsMismatch Остановить обработку PInitRes
12	Если поле Thumbs отсутствует, проверить, что Thumbs не было послано в PInitReq. Если Thumbs было послано в PInitReq, о: Послать сообщение Error с ErrorCode равным thumbsMismatch Остановить обработку PInitRes
13	Если PIRsExtensions существуют, их необходимо обработать. Если они не распознаны, а флаг критичности (criticality) равен TRUE, сформировать сообщение Error, в противном случае расширения следует игнорировать.
14	Проверить Cert-PE (идентифицированный в PEThumb) для неподписанных транзакций. Если индикатор в Cert-PE не допускает неподписанных транзакций, а владелец карты не имеет сертификата, информировать его о том, что транзакция не может быть продолжена и прервать обработку.
15	Владелец карты может теперь продолжить процедуру посылкой запроса покупки.

Запросы инициализации покупки (PInitReq) несут в себе достаточно информации о владельце карты для программы продавца, чтобы выбрать сертификат платежного центра. Следует имеь в виду, что эти запросы не шифруются и соответствующие расширения не должны нести в себе конфиденциальной информации. Отклик на запрос инициализации (PInitRes) содержит копии данных из запроса PInitReq, а также сертификаты продавца и расчетного центра. Отклик подписывается продавцом, что позволяет владельцу карты быть уверенным в том, что посланная им в запросе информация дошла до продавца неискаженной (за счет просмотра копий). Отклик PInitRes также не шифруется. Обработка заказа-покупки Обмен запрос-отклик (PReq/PRes) представляет собой реализацию покупки, выполняемой владельцем карты у продавца. Данные сообщения составляют ядро протокола купли-продажи. На долю владельца карты выпадает функция платежа. Реализация запроса покупки проходит через 5 этапов (см. рис. 4.6.2.16).

Рис. 4.6.2.16. Обработка запроса покупки Прежде чем послать запрос покупки покупатель (владелец карты) должен заполнить форму заказа, одобрить условия сделки и выбрать платежную карту. Для того чтобы послать запрос продавцу, владелец карты должен иметь копию ключей расчетного центра. Обработка заказа начинается, когда программа владельца карты запрашивает копию сертификата расчетного центра. В этом сообщении содержится информация о выборе платежной системы. Когда продавец получает запрос, он присваивает транзакции уникальный идентификатор. После этого продавец пересылает свой сертификат и сертификат расчетного центра вместе с этим идентификатором владельцу карты. Программа владельца карты верифицирует полученные сертификаты и запоминает их для использования в последующей обработке заказов. Приложение владельца карты формирует данные заказа OI (Order Information) и платежные инструкции PI. OI и PI снабжаются идентификатором транзакции, для того чтобы расчетный центр мог связать их вместе при авторизации запроса продавца.

Заметим, что OI не содержит таких данных как описание товара или условий поставки. Эта информация получается на фазе сделки, предшествующей операциям SET (например, в рамках протокола IOTP). Программное обеспечение владельца карты генерирует двойную цифровую подпись для OI и PI путем вычисления дайджеста для обоих модулей данных, объединения этих дайджестов, вычисления дайджеста результата и осуществления подписи этого сообщения с привнием секретного ключа владельца карты. Дайджесты OI и PI посылаются вместе с этим сообщением. Далее программа формирует симметричный ключ и использует его для шифрования дважды подписанных PI. Затем программа шифрует номер счета владельца карты и симметричный ключ с привлечением общедоступного ключа расчетного центра. Результат составляет цифровой конверт сообщения, которое передается продавцу. Когда программа продавца получает заказ, она верифицирует сертификат подписи владельца карты, используя общедоступный ключ владельца карты и дайджест PI (заключенный в OI), проверяет цифровую подпись, чтобы убедиться в не искаженности заказа и в том, что сообщение подписано секретным ключом владельца карты. Заметим, что продавцу не обязательно выполнять авторизацию до посылки отклика владельцу карты. Последний может позднее определить, была ли выполнена авторизация, послав информационный статусный запрос. После обработки OI продавец генерирует отклик и снабжает его цифровой подписью. Этот отклик содержит в себе сертификат подписи продавца и указывает на факт получения заказа от владельца карты. Если отклик авторизации указывает на одобрение транзакции, продавец поставляет товар или услугу, указанные в заказе. Когда приложение владельца карты получает отклик на запрос покупки от продавца, сначала верифицируется сертификат подписи. Далее проверяется цифровая подпись продавца. При благоприятном исходе этих проверок выдается соответствующее сообщение и производится запись в базу данных. Состояние выполнения заказа владелец карты может выяснить путем посылки информационных статусных запросов. Сообщение PReq не обязательно следует за сообщениями PInitReq/PInitRes.

Сообщение же PRes может быть прислано до выполнения авторизации и оплаты. Если владелец карты обладает сертификатом, то для обеспечения целосности и аутентичности сообщения выполняется двойная подпись. PReq представляет собой наиболее сложное сообщение в протоколе. Оно состоит из двух частей: инструкции-заказа OI (Order Instruction) для продавца и платежной инструкции PI (Payment Instruction), которая проходит транзитом через продавца в расчетный центр. Эти две части принципиально должны подписываться независимо. Продавец получает описание заказа OD (Order Description) и PurchAmt. В PI включаются хэши OD и PurchAmt (HODINput). Расчетный центр проверяет, что хэш передан покупателем (владельцем карты) через продавца и равен хэшу, выданному продавцом в AuthReq. Некоторые владельцы карт могут не иметь сертификатов. Сообщения от таких владельцев не будут подписаны, вместо этого PIHead связывается с OIData. Целостность таких сообщений обеспечивается следующими мерами:

C PI используется OAEP

В блок OAEP включается H(PIHead) (вместе с PANData)

С PIHead используется H(OIData)

Расчетным центром производится сравнение H(OIData), присланного продавцом, с H(OIData) из PIHead. Владелец карты формирует сообщение PReq следующим образом (эти действия предпринимаются как для PReqUnsigned так и для PreqDualSigned).

Шаг	Действие
1	Извлечь PurchAmt и OD
2	Сформировать OIData следующим образом:
	a)	Если имел место обмен PInitReq/ PInitRes:	Скопировать TransIDs из PInitRes
		В противном случае:	Для формирования TransIDs владелец карты сгенерирует PreqDate (текущие дата/время), LID-C и XID
	b)	Сформировать новый RRPID, запомнить его значение для сверки с откликом продавца
		Если имел место обмен PInitReq/PInitRes:	Скопировать Chall-c из PInitRes
		В противном случае:	Сформировать новый Chall-C
	c)	Сформировать новый ODSalt
	d)	Сформировать HODInput посредством следующей процедуры: Скопировать OD из данных процесса инициализации SET Записать PurchAmt cо значением, одобренным владельцем карты на фазе инициации SET. Скопировать ODSalt из пункта 2 с) Если владелец карты намерен выполнить инсталляцию или последовательные платежи, то записать InstallRecurData Опционно: добавить любые ODExtensions
	e)	Сформировать HOD с HODInput из пункта 2 d
	f)	Если имел место обмен PInitReq/ PInitRes:	Скопировать Chall-M из PInitRes и не заполнять BrandID
		В противном случае:	Не заполнять Chall-M Записать BrandID, указав предпочтительный тип карты

	g)	Произвести записьв поле BIN с HODInput из пункта 2d

	h)	Если HODInput из шага 2.d имеет какие-то расширения OIExtensions, внести ODExtOIDs со всеми OID в ODExtensions. ODExtOIDs будут перечислены в том же порядке, что и расширения ODExtensions, таким образом продавец сможет вычислить тот же самый хэш

	i)	Опционно: добавить любые расширения OIExtensions.
3	Сформировать PIHead следующим образом:
	a)	Скопировать TransIDs, вычисленные в пункте 2.а
	b)	Сгенерировать Inputs согласно процедуре: Скопировать HOD из пункта 2.е Скопировать PurchAmt из шага 2.d.2
	c)	Скопировать MerchandID из сертификата продавца в PInitRes, или из CD-ROM-каталога
	d)	Скопировать InstallRecurData из пункта 2.d.4 (если имеется)
	e)	Сформировать TransStain, как HMAC, используя XID в качестве данных и CardSecret - в качестве ключа. Если владелец карты не имеет сертификата, использовать CardSecret, заполненный нулями.
	f)	Записать SWIdent, который получен из локальных данных. Это значение будет соответствовать коду в цифровом конверте сообщения
	g)	Если присутствует туннельное расширение Cert_PE, сформировать AcqBackInfo следующим образом: Найти туннельное расширение для алгоритма шифрования, приемлемое для владельца карты. Если такое найдено, заполнить AcqBackAlg, в противном случае, не формировать AcqBackInfo и перейти к пункту f. Сформировать новый AcqBackKey (приемлемый для AcqBackAlg)
	h)	Опционно добавить любые PIExtensions
4	Сформировать PANData
5	Сгенерировать PU-OIData c L-оператором, используя PIHead из пункта 3 (параметр t1) и OIData из пункта 2 (параметр t2)
6	Используя результат пунктов 2, 3 и 4, сгенерировать PreqDualSigned, если владелец карты имеет сертификат или PreqUnsigned, если сертификата нет.

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

Шаг	Действие
1	Сформировать PISignature: Сформировать PI-TBS: Сгенерировать HPIData в виде дайджеста PIData Сгенерировать HOIData в виде дайджеста OIData Выполнить PISinature c оператором S0, используя сертификат владельца карты (параметр s) и PI-TBS (параметр t).
2	Применить оператор EX, используя общедоступный ключ расчетного центра (параметр r), PI-OILink от владельца карты создает PReq шаг 5 (параметр t), а PANData от владельца карты создает PReq шаг 4 (параметр p)
3	Образовать PIDualSigned как объединение подписи PISignature, вычисленной в пункте 1, и шифрованных данных, полученных на шаге 2.
4	Генерируем PIData как объединение HIHead из PReq владельца карты, (см. пункт 3 предшествующей таблицы), и PANData владельца карты, которая создается в пункте 4 при формировании PReq (см. предшеств. табл.).
5	Генерируем OIDualSigned, посредством оператора L, используя OIData от владельца карты, создаем PReq - пункт 2 (параметр t1) и данные PIData, полученные в пункте 4 (параметр t2)
6	Генерируем PReqDualSigned как объединение PIDualSigned из пункта 3 и OIDualSigned из пункта 5.

Сообщение запроса покупки PReq содержит инструкцию заказа OI для продавца и платежную инструкцию для передачи транзитом в зашифрованном виде через продавца в расчетный центр. Аутентичность и целостность сообщений достигается за счет использования двойной подписи, если владелец карты имеет сертификат (PReqDualSigned). Если владелец карты не имеет сертификата, для тех же целей применяются хэши в ОАЕР-конверте (PReqUnsigned). Структура данных в случае PreqDualSigned показана в таблице 4.6.2.57. Таблица 4.6.2.57. Структура PReqDualSigned

PReqDualSigned	{PIDualSigned, OIDualSigned}
PIDualSigned	Смотри описание PI (выше)
OIDualSigned	L(OIDualSigned, PIData)
OIData	Смотри табл. 4.6.2.59
PIData	{PIHead, PANData}

Структура данных в случае PReqUnsigned показана в таблице 4.6.2.58. Таблица 4.6.2.58.

Структура PReqUnsigned

PReqUnsigned	{PIUnsigned, OIUnsigned}
PIUnsigned	Смотри описание PI (выше)
OIUnsigned	L(OIData, PIDataUnsigned)
OIData	Смотри табл. 4.6.2.59
PIDataUnsigned	{PIHead, PANToken} (см. табл. 4.6.2.40 и 4.6.2.45)

Структура данных сообщения PReq для PReqDualSigned и PreqUnsigned показана в таблице 4.6.2.59. Таблица 4.6.2.59. Структура PReq для PReqDualSigned и PreqUnsigned

OIData	{TransIDs, RRPID, Chall-C, HOD, ODSalt, [Chall-M], BrandID, BIN, [ODExtOIDs], [OIExtensions]}
TransIDs	Копируется из PInitRes, если имеется
RRPID	ID пары запрос/отклик
Chall-C	Копируется из соответствующего PInitReq (см. табл. 4.6.2.55)
HOD	DD(HODInput)Связывает OIData с PurchAmt без копирования PurchAmt в OIData, что может привести к проблемам с конфиденциальностью
ODSalt	Копируется из HODInput
Chall-M	Вызов продавца владельцу карты относительно свежести подписи
BrandID	Выбранная владельцем карты платежная система
BIN	Идентификационный номер банка из номера счета владельца карты (первые 6 цифр)
ODExtOIDs	Список объектных идентификаторов из ODExtensions
OIExtensions	Данные в расширении к OI должны относиться к обработке заказа продавцом. Информация заказа незашифрованна, по этой причине здесь не должно быть конфиденциальной информации.
HODInput	{OD, PurchAmt, PurchAmt, [InstallRecurData], [ODExtensions]}
OD	Описание заказа (Order Description). Обмен этой информацией происходит между владельцем карты и продавцом (не регламентируется SET). Здесь могут содержаться данные о качестве товара, размере, цене, адресе поставки и т.д.
PurchAmt	Число транзакций, как это определено владельцем карты. Значение должно соответствовать PIHead (табл. 4.6.2.40).
ODSalt	Новое значение Nonce, сгенерированное владельцем карты, чтобы препятствовать атакам на HOD.
InstallRecurData	См. табл. 4.6.2.41
ODExtensions	Данные в этом расширении OD должны относиться к обработке заказа продавцом. Эта информация должна быть известна независимо владельцу карты и продавцу.

При получении PReq продавец производит следующие действия.

Шаг	Действие
1	Извлекает PReq из входного сообщения
2	Если получено PReqDualSigned, производит проверку подписи; Извлекает OIData и HPData из OIDualsigned Формирует HOIData в виде дайджеста OIData Формирует PI-TBS в виде объединения HPOData из пункта А и HOIData из пункта В. Генерирует подпись с помощью оператора SO, используя сертификат владельца карты (параметр s) и PI-TBS из пункта С (параметр t). Сравнивает подпись из пункта D с PISignature. Если они не тождественны, послает сообщение Error c ErrorCode равным signatureFailure и останавливает обработку PReq. Переходит к выполнению пункта 4.
3	Если получено PReqUnsigned, проверяет, что сертификат платежной системы (Cert-PE) допускает PReqUnsigned. Если нет, то: Возвращает сообщение PRes c CompletionCode=signatureDequired (необходима подпись) Останавливает обработку PReq
4	Производит обработку TransIDs: Проводит поиск транзакций, базирующихся на XID. Если запись такой транзакции найдена Сравнивает LID-C и LID-M с записью. Если соответствия нет: Возвращает сообщение Error c ErrorCode = unknownLID Останавливает обработку PReqВ противном случае сверяет Chall-M с записью. Если соответствия нет, то: Присылает сообщение Error c ErrorCode = challengeMismatch Останавливает обработку PReqВ противном случае Формирует новую запись транзакции Спасает LID-C, PReqDate и Language Опционно формирует LID-M
5	Проверяет, что BrandID в сертификате владельца карты соответствует BrandID в PInitReq и/или OIData. Если соответствия нет, то: Присылает сообщение PRes c completionCode = orderRejected (заказ отклонен) Останавливает обработку PReq
6	Запоминает Chall-C, чтобы вернуть его в последующем PRes
7	Запоминает оставшиеся переменные из сообщения в базе данных
8	Сверяет HOD c сформированным хэшем OD, PurchAmt, ODSalt, InstallRecurData (если имеется) и ODExtensions (если имеется)
9	Начиная с этого момента, продавец может, если захочет, послать PRes владельцу карты, или ждать пока от расчетного центра не будет получено сообщение AuthRes

После обработки PReq продавец формирует отклик PRes согласно следующему алгоритму:

Шаг	Действие
1	Сформировать PResData: Заполнить поле TransIDs. Включить сюда все поля TransIDs, полученные от владельца карты или расчетного центра Скопировать RRPID из PReq (или из InqReq) Скопировать Chall-C из PReq (или из InqReq) Если для текущего BrandCRLIdentifier не получены оттиски (или они устарели), заполнить поле текущим значением BrandCRLIdentifier Сформировать PresPayloadSeq: Если запрос покупки включает в себя PurchAmt = 0, сформировать единичный PresPayload c CompletionCode = meaninglessRatio и с пустыми остальными полями. Перейти к пункту 2. Если расчетный центр отклонил заказ, сформировать PresPayload: Установить CompletionCode = orderReject Скопировать AcqCardMsg из AuthRes, если имеется. Перейти к пункту 2 Если расчетный центр еще не посылал отклик на запрос авторизации продавца, сгенерировать PresPayload c CompletionCode = orderReceived и пустыми прочими полями. Перейти к пункту 2. Если это отклик на запрос InqReq, где транзакция не была найдена, сформировать PresPayload c CompletionCode = orderNotReceived и пустыми прочими полями. Перейти к пункту 2. Если расчетный центр откликнулся на запрос авторизации продавца, сформировать PresPayloadSeq, как это описано ниже
2	Ввести Compose SignedData
3	Вставить сообщение в цифровой конверт и послать владельцу карты

Для каждой авторизации, которую провел продавец и которая не отменена, формируется PresPayload:

Шаг	Действие
1	Если выполнена только авторизация: Установить CompletionCode = authorizationPerformed Сформировать Results, как это описано ниже, опуская CapStatus и CredStatusSeq.
2	Если оплата (capture) выполнена: Установить CompletionCode = capturePerformed Сформировать Results, как это описано ниже, опуская CredStatusSeq
3	Если кредитование осуществлено; Установить CompletionCode = creditPerformed Сформировать Results, как это описано ниже
4	Опционно добавить любые PRsExtensions

Формирование поля Results производится согласно следующему алгоритму:

Шаг	Действие
1	Скопировать AcqCardMsg из AuthRes, если этот отклик имеется
2	Если позиция авторизована, сформировать AuthStatus: Скопировать AuthDate из записи транзакции Скопировать AuthCode из записи транзакции Вычислить AuthRatio, как AuthReqAmt ч PurchAmt Если в AuthRes присутствуют данные о конвертации валюты, скопировать их
3	Если позиция оплачена, сформировать CapStatus: Скопировать CapDate из записи транзакции Скопировать CapCode из записи транзакции Вычислить CapRatio, как CapReqAmt ч PurchAmt
4	Сформировать CredStatusSeq как последовательность CredStatus для каждой выполненной и не отмененной кредитной операции. Сформировать CredStatus: Скопировать CreditDate из записи транзакции Скопировать CreditCode из записи транзакции Вычислить CreditRatio, как CapRevOrCredReqAmt ё PurchAmt

Структура данных сообщения PRes, формируемого продавцом, представлена в таблице 4.6.2.60. Таблица 4.6.2.60. Структура PRes, формируемая продавцом

PRes	S(M, PresData)
PResData	{TransIDs, RRPID, Chall-C, [BrandCRLIdentifier], PresPayloadSeq}
TransIDs	Копируется из PReq
RRPID	Идентификатор пары запрос/отклик
Chall-C	Копируется из соответствующего PInitReq
BrandCRLIdentifier	Список текущих CRL для всех СА в зоне ответственности СА платежной системы
PResPayloadSeq	{PresPayload +} Одна запись для каждой выполненной авторизации. Отмена авторизации удаляет запись из PResPayload. Если не было авторизаций, появляется одна позиция с соответствующей статусной записью
PResPayload	См. табл. 4.6.2.61

Структура данных PResPayload представлена в таблице 4.6.2.61 Таблица 4.6.2.61. Структура PResPayload

PResPayload	{CompletionCode, [Results], [PrsExtensions]}
CompletionCode	Цифровой код, указывающий на состояние завершения транзакции
Results	{[AcqCardMsg], [AuthStatus], [AuthStatus], [CredStatusSeq]}
PRsExtensions	Отклик на запрос покупки не зашифрован и по этой причине не должен содержать конфиденциальную информацию
AcqCardMsg	Копируется из AuthRes (см. табл. 4.6.2.43)
AuthStatus	{AuthDate, AuthCode, AuthRatio, [CurrConv]}
CapStatus	{CapData, CapCode, CapRatio} Данные присутствуют здесь, только если CapReq соответствует выполненной авторизации. Сообщение CredRevReq удаляет эти данные.
CredStatusSeq	{CredStatus +} Данные присутствуют, только если CredReq соответствует выполненной авторизации. Сообщение CredRevReq удаляет эти данные.
AuthDate	Данные авторизации. Копируются из AuthRRTags.Date (см. табл. 4.6.2.64)
AuthCode	Цифровой код, указывающий на состояние авторизационного процесса. Копируется из AuthResPayload.
AuthRatio	AuthReqAmt ч PurchAmt
CurrConv	{CurrConvRate, CardCurr} Информация о конвертировании валюты, копируется из AuthResPayload
CapData	Дата оплаты, копируется из CapPayload
CapCode	Цифровой код, указывающий на состояние оплаты, копируется из CapResPayload
CapRatio	CapReqAmt ч PurchAmt
CreditStatus	{CreditDate, CreditCode, CreditRatio} Данные присутствуют, только если реализован запрос CreditReq. Эта информация удаляется CredRevReq
CreditDate	Дата кредита. Копируется из CapRevOrCredCode.
CreditCode	Цифровой код, указывающий на состояние кредита. Копируется из CapRevOrCredResPayload.CapRevOrCredCode. (см. табл. 4.6.2.74)
CreditRatio	CapRevOrCredReqAmt ч PurchAmt

Коды завершения (completionCode) могут принимать следующие значения (см. табл. 4.6.2.62). Таблица 4.6.2.62. Коды завершения операции

meanonglessRatio	PurchAmt=0; отношение не может быть вычислено
orderRejected	Продавец не может обработать заказ
orderReceived	Процессы авторизации отсутствуют
orderNotReceived	Информационный запрос получен до заказа
authorizationPerformed	См. AuthStatus
capturePerformed	См. CapStatus
creditPerformed	См. CreditStatus

Владелец карты обрабатывает полученный отклик PRes следующим образом.

Шаг	Действие
1	Извлекается отклик из входного сообщения
2	Чтобы проверить подпись продавца, производится обращение к Received Signed Data,
3	На основе Trans.LID-C ищется запись транзакции. Если запись не найдена: Посылается сообщение Error c ErrorCode равным unknownLID Прерывается обработка PRes
4	Сравнить значения TransIDs.XID с XID из записи транзакции. Если равенства нет: Посылается сообщение Error c ErrorCode равным unknownXID Прерывается обработка PRes
5	Сравнить значения RRPID из сообщения и записи транзакции. Если совпадения нет: Посылается сообщение Error c ErrorCode равным unknownRRPID Прерывается обработка PRes
6	Сравнить значения Chall-C из сообщения и записи транзакции. Если совпадения нет: Посылается сообщение Error c ErrorCode равным challengeMismatch Прерывается обработка PRes
7	Запомнить BrandCRLIdentifier и проверить, что перечисленные CRL содержаться в кэше. Если это не так, и перечисленные CRL относятся к элементам, чьи сертификаты использовались для верификации подписи, сообщение игнорируется, так как подпись может быть некорректной.
8	Для каждого PResPayload из PresPayloadSeq выполняются следующие действия: Если CompletionCode указывает на реализацию кредита, для каждой информационной структуры в CreditSeq представить пользователю CreditAmount (PurchAmountCredRatio) и дату кредита вместе с полученным объемом платежа (PurchAmountCapRatio). В противном случае, если CompletionCode указывает на завершение процесса платежа, представить пользователю CapCode вместе с вычисленным Capture Amount (PurchaseAmountCapRatio). В противном случае, если CompletionCode указывает на завершение процесса авторизации, представить пользователю AuthCode вместе с вычисленным Authorization Amount (PurchaseAmountAuthRatio). В противном случае сообщить результат транзакции на основе CompletionCode. Если присутствует AcqCardMsg, дешифровать и представить владельцу карты. Если там имеется URL, программа может выдать содержимое соответствующей WEB-страницы. Здесь может потребоваться обработка, зависящая от вида платежной системы.

Обработка информационных запросов Пара сообщений InqReq/ InqRes позволяет владельцу карты получать информацию о состоянии транзакции. Информационный запрос может быть послан в любое время после запроса PReq, адресованного продавцу. Запросы InqReq могут посылаться многократно. Отклик InqRes имеет тот же формат, что и PRes. Продавец должен проверять, что сертификат, сопровождающий InqRes, соответствует сертификату, использованному с PRes. Это препятствует запросам одного владельца карты о состоянии транзакций других покупок. Владелец карты без сертификатов не подписывает информационные запросы, что означает возможность нарушения целостности сообщения. Владелец карты формирует запрос InqReq следующим образом.

Шаг	Действие
1	Копируется InqReqData из предыдущего запроса Формируется новый RRPID Генерируется новый Chall-С Опционно добавляются любые InqReqExtensions
2	Если владелец карты послал подписанный PReq, вставить Compose SignedData c InqReqData
3	Вставить сообщение в цифровой конверт и послать продавцу

Структура данных запроса InqReq представлена в таблице 4.6.2.63. Таблица 4.6.2.63. Структура InqReq

InqReq
InqReqSigned	S(C, InqReqData)
InqReqData	{TransIDs, RRPID, Chall-C2, [InqRqExtensions]}
TransIDs	Копируется из самого последнего: PReq, PRes, InqReq
RRPID	Идентификатор пары запрос/отклик
Chall-C2	Новый вызов владельца карты по поводу подписи продавца.
InqRqExtensions	Информационный запрос не шифруется, по этой причине расширения не должны содержать конфиденциальной информации.

Когда продавец получает InqReq, он обрабатывает это сообщение следующим образом:

Шаг	Действие
1	Извлекается запрос из входного сообщения
2	Если получены данные InqReqData (в противоположность InqReqSigned), проверить, позволяет ли сертификат расчетного центра неподписанные транзакции. Если он этого не допускает, тогда: Прислать сообщение InqRes c CompletionCode = signatureRequired. Прервать обработку InqReqВ противном случае перейти к пункту 4.
3	Если получен InqReqSigned, проверить подпись. Если проверка подписи не прошла: Прислать сообщение Error с ErrorCode = signatureFailure Прервать обработку InqReq
4	Сравнить TransIDs со значениями из цифрового конверта сообщения. Если равенства нет: Прислать сообщение Error c ErrorCode = wrapperMsgMismatch Прервать обработку InqReq
5	Искать транзакцию в базе данных, основанную на TransIDs.XID. Если поиск неудачен: Прислать InqRes c CompletionCode = orderNotReceived. Прервать обработку InqReq
6	Если PReq был подписан, проверить, что PReq и InqReq подписаны одним и тем же владельцем карты. Если соответствия нет, то: Прислать сообщение Error c ErrorCode = unknownXID. Прервать обработку InqReq
7	Сформировать PResPayloadSeq

Авторизация платежей продавца осуществляется согласно схеме, показанной на рис. 4.6.2.17.

Рис. 4.6.2.17. Авторизация платежей Процесс авторизации проходит через три состояния. Во время обработки заказа от владельца карты продавец авторизует транзакцию. Программа продавца формирует и цифровым образом подписывает авторизационный запрос, который включает в себя сумму платежа, подлежащую авторизации, идентификатор транзакции из OI и некоторые другие данные. Запрос затем шифруется с использованием нового случайного симметричного ключа, который в свою очередь шифруется общедоступным ключом расчетного центра. Это тот самый ключ, который использовал владелец карты для шифрования цифрового конверта с платежными инструкциями. Запрос авторизации и платежные инструкции владельца карты передаются в расчетный центр. Когда расчетный центр получает авторизационный запрос, он дешифрует цифровой конверт запроса и извлекает из него симметричный ключ. Этот ключ используется для дешифрования текста запроса. Далее верифицируется сертификат подписи продавца срок его действия, а также цифровая подпись. После этого расчетный центр дешифрует цифровой конверт платежных инструкций (PI), откуда извлекается симметричный ключ и информация о счете клиента. Ключ используется для дешифрования PI. Используя общедоступный ключ владельца карты и дайджест OI (включенный в PI), проверяется цифровую подпись, чтобы убедиться, что PI не модифицированы и что они подписаны с использованием секретного ключа владельца карты. Расчетный центр проверяет, что идентификатор транзакции, полученный от продавца, соответствует идентификатору, присланному в PI. При успешном завершении этих проверок расчетный центр формирует и отсылает через финансовую сеть авторизационный запрос эмитенту карты. При получении отклика авторизации от эмитента расчетный центр генерирует и подписывает цифровым образом авторизационный отклик, который содержит отклик эмитента и копию сертификата подписи расчетного центра. Этот отклик может также включать в себя платежный маркер (capture token) с данными, которые будут нужны расчетному центру для обработки платежного запроса.

Платежный маркер вставляется в отклик только в случае, если этого требует банк продавца (Получатель). Отклик шифруется с помощью вновь сформированного секретного симметричного ключа, который в свою очередь шифруется общедоступным ключом продавца. После шифрования отклик посылается продавцу. Когда программа продавца получает авторизационный отклик из расчетного центра (РЦ), она дешифрует цифровой конверт и извлекает оттуда симметричный ключ, посредством которого дешифруется текст отклика. Продавец верифицирует сертификат подписи расчетного центра, а посредством общедоступного ключа РЦ и его цифровую подпись. Продавец запоминает авторизационный отклик и платежный маркер для последующего использования при обработке платежных запросов. Далее продавец может осуществлять доставку товаров или услуг, оговоренных в заказе. Обмен AuthReq/AuthRes возможен как для исключительно авторизованных транзакций, так и транзакций оплаты. Пара запрос/отклик автортизации предоставляет механизм авторизации сделки. В запросе авторизации продавец посылает подписанные и зашифрованные данные о покупке, а также инструкцию PI, полученную от владельца карты. Так как каждая из секций содержит хэш OD и количества (Amount), расчетный центр может проверить то, что владелец карты и продавец договорились о заказе и сумме, которые следует авторизовать. Так как PI включает данные платежной карты, необходимые для авторизации, расчетный центр может выполнить авторизацию, используя существующую финансовую сеть платежной карты. Когда продавец заранее знает, что заказ будет выполняться по частям (несколько поставок), он осуществит несколько шагов AuthReq (по одному для каждой части). Продавец устанавливает в первом AuthReq значение SubsequentAuthInd равным TRUE, что представляет собой указание на авторизацию выполнения первой части заказа. Расчетный центр пришлет в отклике AuthRes значение AuthToken. Продавец будет вынужден выполнить дополнительные запросы AuthReq для реализации последующих этапов выполнения заказа.

В каждое последующее сообщение AuthReq продавец должен включать значение AuthToken из предшествующего отклика расчетного центра. В последнем AuthReq продавец установит значение SubsequentAuthInd равным FALSE. Когда продавец обнаруживает, что заказ будет выполняться поэтапно после отправки AuthReq, он должен послать AuthRevReq, чтобы согласовать число дополнительных авторизаций, и установить SubsequentAuthInd = TRUE, для получения AuthToken в последующих откликах AuthRes. Алгоритм формирования AuthReq представлен ниже.

Шаг	Действие
1	Сгенерировать AuthTags (см. табл. ниже)
2	Сгенерировать HOD2 путем хэширования OD, PurchAmt, ODSalt, ODExtensions и, если имеется, InstallRecurData. Расчетный центр сравнит его значение с полученным в PI.
3	Сгенерировать AuthReqPayload (см. табл. ниже)
4	Опционно для одновременной авторизации и резервирования заказа: Установить CaptureNow = TRUE Сгенерировать SaleDetail (см. табл. 4.6.2.47) Опционно занести в поле BatchID значение открытой в настоящее время платежной линии (серия платежей для данного клиента) для BrandAndBIN. Это значение должно быть ассоциировано с текущей транзакцией и BatchSequenceNumber (номер платежа).Может так случиться, что банк продавца не может выполнить одновременно авторизацию и платеж для данного заказа даже при CaptureNow=TRUE. В этом случае AuthCode=captureNotSupported укажет на то, что производится только авторизация. Продавец может послать позднее запрос CapReq, чтобы выполнить платеж для данного заказа.
5	Включить CheckDigest с вычисленными продавцом H(OIData) и HOD2. H(PIData) копируется продавцом из PReq. Это поле опускается, если запрос AuthReq представляет последовательную авторизацию, базирующуюся на присланном из расчетного центра коде AuthToken.
6	Рекомендуется заполнить MThumbs путем вычисления оттисков сертификатов и CRL, хранимых продавцом. Продавец должен внести в сообщение оттиски, которые могут потребоваться позднее для верификации подписи и сертификатов расчетного центра.
7	Осуществить EncB-инкапсуляцию
8	Включить сертификаты подписи и шифрования отправителя и всей цепи сертификации вплоть до сертификата платежной системы.
9	Поместить сообщение в цифровой конверт и отправить адресату

Процедура формирования AuthTags показана в таблице ниже.

Шаг	Действие
1	Заполнить поле AuthRRTags (см. табл. 4.6.2.52)
2	Заполнить поле TransIDs. Если это последовательная авторизация и определено PaySysID, занести его значение в поле PaySysID.
3	Если это многоэтапный платеж и банк продавца задал для авторизации значение AuthRetNum, скопировать AuthRetNum из предыдущего AuthRes

Схема формирования поля данных AuthReq показана ниже.

Шаг	Действие
1	Если планируется обработка последовательных авторизаций для покупки и это не последняя авторизация, установить SubsequentAuthInd равным TRUE, в противном случае FALSE.
2	Если продавец и владелец карты договорились о рекуррентных или поэтапных платежах, заполнить поле InstallRecurData
3	Установить AuthReqAmt равным числу авторизаций
4	Опционно присвоить CardSuspect соответствущее значение, если продавец имеет какие-то подозрения относительно владельца карты.
5	Если при некотором платеже необходимы данные MerchData, добавить их в сообщение.
6	Сформировать MarketSpecAuthData, если это диктуется платежной системой карты или типом покупки.
7	Если политика платежной системы карты требует наличия AVSData, записать в это поле информацию, предоставленную владельцем карты.
8	Если политика платежной системы карты требует наличия SpecialProcessing, сгенерировать его значение.
9	Если продавец требует информацию о типе платежной карты, установить RequestCardTypeInd = TRUE.

Структура данных сообщения AuthReq представлена в таблице 4.6.2.64. Таблица 4.6.2.64. Структура AuthReq

AuthReq	EncB(M, P, AuthReqData, PI)
AuthReqData	{AuthReqItem, [Mthumbs], CaptureNow, [SaleDetail]}
PI	См. табл. 4.6.2.39.
AuthReqItem	{AuthTags, [CheckDigests], AuthReqPayload}
MThumbs	Оттиски сертификатов, CRL и BrandCRLIdentifiers, хранимые в данный момент в кэше продавца.
CaptureNow	Булева переменная, указывающая, что резервирование должно проводиться, если проведена авторизация.
SaleDetail	См. табл. 4.6.2.47
AuthTags	{AuthRRTags, TransIDs, [AuthRetNum]}
CheckDigests	{HOIData, HOD2}используется расчетным центром для аутентификации PI. Опускается, если PI = AuthToken
AuthReqPayload	См. табл. 4.6.2.65
AuthRRTags	RRTags Необходим RRPID, так как для одного PReq может потребоваться более одного цикла авторизации.
TransIDs	Копируется из соответствующего поля OIData (см. табл. 4.6.2.59)
AuthRetNum	Идентификация запроса авторизации, используемого в пределах финансовой сети.
HOIData	DD(OIData) (См. табл. 4.6.2.59) Независимый хэш, вычисляемый продавцом. Расчетный центр сравнивает это значение с копией, сформированной владельцем карты в PI.
HOD2	DD(HODInput) (См. табл. 4.6.2.59) Вычисляется независимо продавцом. Расчетный центр сравнивает это значение с копией, сформированной владельцем карты в PI.

Структура данных AuthReqPayload представлена в таблице 4.6.2.65. Таблица 4.6.2.65. Структура AuthReqPayload

AuthReqPayload	{SubsequentAuthInd, AuthReqAmt, [AVSData], [SpecialProcessing], [CardSuspect], RequestCardTypeInd, [InstallRecurData], [MarketSpecAuthData], MerchData, [ARqExtensions]}
SubsequentAuthInd	Булева переменная, указывающая на запросы со стороны продавца дополнительной авторизации из-за раздельной поставки
AuthReqAmt	Может отличаться от PurchAmt; политика банка продавца может наложить ограничение на допустимое отличие
AVSData	{[StreetAddress], Location} Адрес счета владельца карты: содержимое получается от владельца карты посредством механизмов, выходящих за пределы SET.
SpecialProcessing	Числовое поле, указывающее тип запрошенной обработки
CardSuspect	Числовое поле, указывающее, что продавец подозревает владельца карты, и на причину подозрения
RequestCardTypeInd	Указывает, что тип карты должен быть прислан в поле CardType отклика. Если информация недоступна, присылается значение unavailable(0).
InstallRecurData	См. табл. 4.6.2.41.
MarketSpecAuthData	< MarketAutoAuth, MarketHotelAuth, MarketTransportAuth > Специфические авторизационные данные рынка
MerchData	{[MerchCatCode], [MerchGroup]}
ARqExtensions	Данные в расширении авторизационного запроса должны иметь финансовый характер и относиться к процессу авторизации (или последующей оплаты заказа) расчетного центра, финансовой сети или эмитента карты.
StreetAddress	Адрес улицы владельца карты
MarketAutoAuth	{Duration}
MarketHotelAuth	{Duration, [Prestige]}
MarketTransportAuth	{} В настоящее время нет авторизационных данных для этого сегмента рынка
MerchCatCode	4-байтовый код (определен в ANSI X9.10), описывающий тип бизнеса, продукта или услуги продавца.
MerchGroup	Числовой код, идентифицирующий общую категорию продавца
Duration	Ожидаемая длительность транзакции (в днях). Эта информация помогает понять, какое время пройдет со времени авторизации до оплаты заказа (capture).
Prestige	Числовой тип приоритета, определяется платежной системы карты.

Схема обработки запроса AuthReq платежным центром представлена в таблице ниже.

Шаг	Действие
1	Извлечь запрос из транспортного сообщения
2	Дешифровать PI
3	Сравнить TransIDs из AuthTags и PIHead или AuthToken: Проверить что коды XID идентичны Проверить что коды LID-C идентичны Если LID-M присутствуют в AuthTags и PIHead, сравнить их значенияЕсли хотя бы одна из проверок не прошла, сообщение отбрасывается и возвращается AuthCode = piAuthMismatch
4	Если PI является AuthToken: Обработать AuthTokenВ противном случае, если PI подписаны: Проверить, что платежная система в подписи владельца карты согласуется с платежной системой сертификата шифрования расчетного центра. Если согласия нет, то авторизация отвергается путем отправки AuthCode = CardMerchBrandMismatch. Проверить PANData Запомнить данные из PANDataВ противном случае, если PI не подписаны: Проверить, что расчетный центр не требует подписи (путем проверки сертификата платежного центра). Если подпись требуется, отвергнуть авторизацию, послав AuthCode = signatureRequired Верифицировать хэш в EXH Запомнить данные из PANToken
5	Проверить состояние авторизации PI. Если PI была обработана и не отвергнута или отозвана, отвергнуть авторизацию, послав AuthCode = piPreviouslyUsed
6	Обработать PIHead: Проверить, что PiHeadMerchantID соответствует содержимому поля merID в расширении merchantData сертификата подписи, используемом при верификации подписи продавца для сообщения AuthReq. Если соответствия нет, авторизация отвергается и посылается отклик с AuthCode = piAuthMismatch. Это предотвращает атаки подстановки, когда PI разных продавцов меняются местами. Передать TransStain эмитенту через финансовую сеть для верификации или запоминания с последующей верификацией. Проверить хэши OIData, полученные от владельца карты и продавца. Если они не совпадают, прислать AuthCode = piAuthMismatch. Проверить, что HOD от HIHead соответствует HOD2 от AuthReqPayload, при несовпадении прислать сообщение Error c ErrorCode = HODMismatch Обработать PIExtensions. Если обнаружены неподдерживаемые расширения, сообщение отвергается путем посылки сообщения Error c кодом unrecognizedExtension Запомнить данные от PIHead
7	Если в AuthReq имеется InstallRecurData, проверить, что InstallRecurData в AuthReqPayload и в PIHead совпадают. Если это не так, отклонить авторизацию с AuthCode = InstallRecurMismatch.
8	Запомнить AcqBackInfo в безопасной локальной памяти, если таковая имеется.
9	Если captureNow=TRUE и платежная система не поддерживает этот режим, послать AuthCode = captureNotSupported
10	Выполнить авторизацию через финансовую сеть платежной карты
11	Если captureNow=TRUE, выполнить платеж через существующую финансовую сеть платежной карты
12	Продолжить формирование сообщения AuthRes

Отклик AuthRes генерируется после завершения авторизации через финансовую сеть платежной карты. AuthCode и AuthAmt извлекаются из данных, полученных через финансовую сеть платежной карты. Формирование отклика AuthRes производится по схеме, изложенной в нижеприведенной таблице.

Шаг	Действие
1	Получить необходимые данные от авторизационного процесса
2	Заполнить поле AuthTags из AuthReq. Если это необходимо, занести в поле AuthRetNum, значение, полученное из авторизационного процесса.
3	Заполнить текущее значение BrandCRLIdentifier, хранимое расчетным центром, если для текущего BrandCRLIdentifier не получен оттиск или он устарел.
4	Если Mthumbs из AuthReq указывает, что продавцу нужен новый Cert-PE шифрования информации для расчетного центра: Вставить Cert-PE в цифровой конверт PKCS#4 Вставить GKThumb в AuthResData, так как сам Cert-PE не защищен подписью
5	Заполнить поле PaySysID в TransIDs, если они получены из авторизационного процесса
6	Заполнить поле PANToken, если это необходимо для сертификата продавца,
7	Заполнить AuthResBaggage (опционно): Опционно заполнить CapToken Опционно заполнить AcqCardMsg, если соответствующие правила платежной системы требуют посылки запроса и получения ключа от владельца карты. Занести в AuthToken значения, полученные в InstallRecurData продавца, если осуществлена дополнительная авторизация (в предыдущем AuthReq SubsequentAuthInd=TRUE).Если ни одна из этих величин не присутствует, AuthResBaggage характеризуется пустой последовательностью.
8	Опционно заполнить BatchStatus, как этого требует политика платежной системы карты.
9	Если PANToken имеется, реализовать EncBX-инкапсуляцию
10	Вставить сообщение в цифровой конверт и отправить владельцу карты

Расчетный центр формирует AuthResPayload следующим образом.

Шаг	Действие
1	Сгенерировать CapResPayload
	Заполнить AuthCode и AuthAmt c привлечением результатов авторизационного процесса Если авторизация отвергнута, вернуть AuthAmt, специфицированный в предыдущем AuthReq. Если флаг CaptureNow был указан в AuthReq, но не был реализован, вернуть в случае успешной авторизации AuthCode = captureNotSupported
3	Заполнить поле CurrConv в соответствии с запрошенным владельцем карты типом валюты и с учетом текущего курса, если специфицирована валюта, отличная от используемой владельцем карты.
4	Заполнить ResponseData: Заполнить поле AuthValCodes следующим образом: записать ApprovalCode, RespReason, AuthCharInd, ValidationCode и LogRefID, если получены из авторизационного процесса. Если RequestCardTypeInd в AuthReq был установлен равным TRUE, занести в поле CardType значение, полученное из авторизационного процесса. Занести в AuthCharInd значение, присланное авторизационным процессом

Структура полей AuthRes представлена в таблице 4.6.2.66. Таблица 4.6.2.66. Структура полей AuthRes

AuthRes
AuthResData	{AuthTags, [BrandCRLIdentifier], [PEThumb], AuthResPayload}
AuthResBaggage	{[CapToken], [AcqCardMsg], [AuthToken]}
PANToken	См. табл. 4.6.2.46. Посылается, если сертификат продавца указывает на то, что информация предназначена продавцу.
AuthTags	Копируется из соответствующего AuthReq; TransIDs и AuthRetNum могут быть актуализованы с привлечением текущей информации
BrandCRLIdentifier	Список текущих CRL для всех СА в зоне ответственности СА платежной системы.
PEThumb	Оттиск сертификата расчетного центра предоставляется, если AuthReq.Mthumbs указывает то, что он нужен продавцу
AuthResPayload	См. табл. 4.6.2.67.
CapToken	См. табл. 4.6.2.44.
AcqCardMsg	Если владелец карты включил AcqBackKeyData в PIHead, расчетный центр может послать это поле продавцу в шифрованном сообщении для владельца карты. Продавец должен скопировать AcqCardMsg в любой последующий отклик PRes или InqRes, посылаемый владельцу карты.
AuthToken	Продавец использует это поле в качестве PI в последующих запросах AuthReq. См. табл. 4.6.2.42.

Структура AuthResPayload представлена ниже в таблице 4.6.2.67. Таблица 4.6.2.67. Структура AuthResPayload

AuthResPayload	{AuthHeader, [CapResPayload], [ARsExtensions]}
AuthHeader	{AuthAmt, AuthCode, ResponseData, [BatchStatus], [CurrConv]}
CapResPayload	Присылается, если CaptureNow имеет значение TRUE в AuthReq. См. табл. 4.6.2.71.
ARsExtensions	Данные в расширении к авторизационному отклику должны быть финансовыми и существенными для обработки авторизационного отклика.
AuthAmt	Копируется из AuthReqPayload.AuthReqAmt
AuthCode	Числовой код, индицирующий результат процесса авторизации
ResponseData	{[AuthValCodes], [RespReason], [CardType], [AVSResult], [LogRefID]}
BatchStatus	См. табл. 4.6.2.53.
CurrConv	{CurrConvRate, CardCurr}
AuthValCodes	{[ApprovalCode], [AuthCharInd], [ValidationCode], [MarketSpecDataID]}
RespReason	Числовой код, который указывает на объект сервиса авторизации и причину отказа (если таковая имеется)
CardType	Числовой код, который указывает на тип карты, использованной для транзакции.
AVSResult	Числовой код отклика адресной верификационной службы
LogRefID	Алфавитно-цифровые данные, ассоциируемые с авторизационной транзакцией (используется для распознавания при отзыве предшествующего запроса)
CurrConvRate	Курс обмена валюты. Значение, на которое нужно умножить AuthReqAmt, чтобы получить сумму в валюте владельца карты.
AuthReqAmt	Код валюты владельца карты в стандарте ISO 4217
ApprovalCode	Код одобрения, присваиваемый транзакции эмитентом
AuthCharInd	Числовое значение, которое указывает условия, при которых выполнена авторизация.
ValidationCode	4-байтовый алфавитно-цифровой код, вычисленный, чтобы гарантировать, что необходимые поля авторизационных сообщений присутствуют в соответствующих клиринговых сообщениях.
MarketSpecDataID	Числовой код, который указывает тип данных, специфических для рынка, представляемых при авторизации (как это определено финансовой сетью)

Список возможных значений кода AuthCode приведен ниже

approved	Запрос авторизации удовлетворен
unspecifiedFailure	Запрос авторизации не может быть обработан по причине, которая отсутствует в приведенном здесь списке.
declined	Запрос авторизации отклонен
noReply	Эмитент не откликнулся на запрос авторизации. Это значение часто указывает на временное отсутствие доступа к системе обработки данных эмитента.
callIssuer	Эмитент запрашивает телефонный вызов от продавца
amountError	Такое число транзакций не может быть обработано системой (банком продавца, финансовой сетью, эмитентом и т.д.)
expiredCard	Срок действия карты истек
invalidTransaction	Запрос не может быть обработан последующей системой (банком продавца, финансовой сетью, эмитентом и т.д.), так как тип транзакции является недопустимым.
systemError	Запрос не может быть обработан последующей системой (банком продавца, финансовой сетью, эмитентом и т.д.), так как запрос содержит в себе некорректные данные.
piPreviouslyUsed	Платежная инструкция (PI) в запросе авторизации использовалась для первичной авторизации (отклик, сформированный расчетным центром).
recurringTooSoon	Минимальное время между авторизациями для рекуррентной транзакции еще не истекло (отклик, сформированный расчетным центром).
recurringExpired	Дата истечения действия для рекуррентной транзакции наступила (отклик, сформированный расчетным центром)
piAuthMismatch	Дата в PI от владельца карты не согласуется с данными в OD от продавца.
installRecurMismatch	InstallRecurData в PI от владельца карты не согласуется с InstallRecurData в OD от продавца.
captureNotSupported	Расчетный центр не поддерживает платеж (capture).
signatureRequired	Опция неподписанной PI не поддерживается расчетным центром для данной платежной системы.
cardMerchBrandMismatch	Платежная система в сертификате подписи владельца карты не согласуется с платежной системой сертификата шифрования расчетного центра.

Обработка продавцом отклика AuthRes производится следующим образом.

Шаг	Действие
1	Получить отклик из входного сообщения
2	Извлечь запись транзакции и сравнить с AuthTags: Проверить, что XID соответствует транзакции. Если соответствия нет, сообщение отвергается с Error = unknownXID Проверить, что LID-M и, если имеется в записи транзакции, LID-C согласуются с содержимым записи транзакции. Если соответствия нет, сообщение отвергается, а в журнал операций расчетного центра записывается Error = unknownLID.
3	Если в сообщение включен BrandCRLIdentifier, запомнить CRL.
4	Обработать AuthResPayload
5	Проверить, что GKThumb соответствует существующему сертификату шифрования расчетного центра, если GKThumb имеется. Если соответствия нет, актуализовать кэш сертификата с использованием текущего сертификата
6	Если BatchStatus присутствует, обработать и запомнить данные.
7	Обработать AuthResBaggage: Запомнить CapToken, если это поле присутствует Если имеется AcqCardMsg, запомнить его для отправки владельцу карты Запомнить AuthToken, если имеется, для последующей авторизации.Если в AuthReq SubsequentAuthInd = TRUE, будет возвращено AuthToken
8	Если присутствует PANToken, записать его в безопасную локальную память
9	Продолжить обработку оплаты заказа и/или отклика на покупку, в зависимости от результатов авторизации и временных рамок продавца для возвращения отклика на покупку.

Алгоритм обработки AuthResPayload представлен ниже.

Шаг	Действие
1	Обработать ARsExtensions, если они имеются. Если неподдерживаемое расширение помечено как критическое, расчетный центр производит запись в журнал Error = unrecognizedExtension, а сообщение игнорируется.
2	Обрабатать CapResPayload: Обработать CRsPayExtensions. Если имеется нераспознанное расширение, помеченное как критическое, отвергнуть AuthRes, а расчетный центр делает запись в журнал Error = unrecognizedExtension Обработать CapCode с целью определения результата Обработать SaleDetail в соответствии с политикой платежной системы карты Для успешной оплаты заказа, записать CapCode и CapAmt.Если делался запрос оплаты (capture), будет возвращен CapResPayload
3	Если имеется CurrConv, запомнить его для переадресации владельцу карты
4	Обработать AuthCode, AuthAmt и ResponseData: Для определения результата обрабатывается AuthCode. Запомнить AuthCode и AuthAmt для получения успешного результата. Запомнить ValidationCode для успешного исхода, если это поле имеется. Запомнить AuthValCode, если имеется. Запомнить AVSResult, если имеется. Запомнить LogRefID, если имеется.

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

Последний вариант называется referral (откладывание) и индицируется значением callissuer(4) в AuthCode. При получении отклика referral продавец может обратиться в свой банк по телефону (вне пределов протокола SET). После идентификации транзакции банк свяжет продавца с эмитентом. В результате этого телефонного вызова эмитент может преобразовать авторизацию в одобрение путем посылки продавцу кода ApprovalCode. Программное обеспечение продавца позволяет оператору сервера продавца вводить код одобрения. Последующая обработка транзакции будет производиться так, как если бы кодом отклика был approved(0). При этом код отклика не переписывается. Программа расчетного центра обрабатывает отложенные авторизации как одобрение за исключением случаев, когда AuthCode = callIssuer и когда оплата (capture) не осуществляется, до тех пор пока продавец не получит от эмитента кода ApprovalCode. Программа расчетного центра обрабатывает все последующие сообщения для транзакций, как если бы транзакция была одобрена, при условии посылки продавцом корректного кода ApprovalCode. Запрос авторизации несет в себе необходимую информацию от продавца к расчетному центру для формирования сообщения-запроса авторизации, которое может быть обработано банком продавца. Отклик на запрос авторизации несет в себе информацию от расчетного центра, относящуюся к обработке запроса авторизации. Пары сообщений AuthRevReq/AuthRevRes (Autorization Reversal Request/Response) используются только для сокращения или аннулирования полученной ранее авторизации. Эта пара опционных сообщений не может применяться для ликвидации разделения авторизации, выполненной ранее. Необходимость разделения авторизации возникает тогда, когда поставка в рамках сделки должна быть выполнена поэтапно. Данные сообщения могут посылаться когда угодно после авторизации и до осуществления платежа (capture). Для реализации разделения или ликвидации авторизации продавец посылает запрос AuthRevReq, который уменьшает значение AuthAmt и устанавливает переменную SubsequentAuthInd = TRUE.

Расчетный центр возвращает AuthToken в отклике AuthRevRes. Маркер AuthToken будет использоваться для авторизации покупок при последующих частичных поставках. Запрос/отклик платежа (CapReq/CapRes) Пара сообщений CapReq/CapRes предоставляет механизм выполнения платежа. Обмен этими сообщениями происходит между продавцом и расчетным центром. Транзакция обработки платежных запросов проходит через три состояния (см. рис. 4.6.2.18).

Рис. 4.6.2.18. Обработка платежных запросов После завершения обработки заказа владельца карты продавец осуществляет запрос платежа. Между запросами авторизации и запросом платежа может быть достаточно большая задержка. Программа продавца генерирует платежный запрос, снабженный цифровой подписью. Этот запрос содержит итоговую сумму транзакции, ее идентификатор из OI и другую информацию о транзакции. Запрос шифруется с использованием вновь сформированного симметричного ключа, который в свою очередь шифруется с привлечением общедоступного ключа расчетного центра. Запрос платежа и опционно платежный маркер (capture token), если таковой был включен в авторизационный отклик, пересылаются в расчетный центр. В общем случае в одном сообщении может быть заключено несколько платежных запросов. Когда расчетный центр получает запрос платежа, он дешифрует цифровой конверт, извлекает из него симметричный ключ и дешифрует с его помощью текст платежного запроса. Далее посредством общедоступного ключа продавца верифицируется его цифровая подпись. Расчетный центр дешифрует платежный маркер (если таковой имеется) и использует платежный запрос и маркер для формирования клирингового запроса, который направляется эмитенту карты через платежную систему кредитной карты. После этого расчетный центр генерирует платежный отклик, снабженный цифровой подписью. Этот отклик содержит в себе копию сертификата подписи расчетного центра. Отклик шифруется с использованием нового симметричного ключа и переправляется продавцу. Когда продавец получает платежный отклик из расчетного центра (РЦ), он дешифрует цифровой конверт, извлекает из него симметричный ключ и с его помощью дешифрует полученный текст отклика.

Далее верифицируется сертификат подписи расчетного центра и цифровая подпись РЦ. Продавец запоминает платежный отклик для последующего использования при контроле платежей, поступающих из его банка. Пары запросов CapReq/CapRes предоставляют механизм завершения ранее авторизованного денежного платежа. Размер платежа определяется на фазе обмена авторизационными сообщениями. Продавец не должен посылать запрос CapReq для ранее успешно прошедших платежей. Возможно осуществление платежей с помощью пар сообщений, выходящих за пределы протокола SET. Формирование запроса CapReq продавцом осуществляется следующим образом.

Шаг	Действие
1	Заполнить поле CapRRTags
2	Опционно заполнить поля AuthReqData и AuthResPayload. Процедура опускается, если информация содержится в CapToken
3	Рекомендуется заполнить MThumbs всех сертификатов для расчетного центра, куда посылается это сообщение, для CRL и для BrandCRLIdentifier
4	Заполнить один или более CapItem в CapSeq следующим образом. Для каждого CapItem: Заполнить TransIDs и AuthRRPID платежной позиций предшествующих сообщений в каждой транзакции. Заполнить CapPayload Заполнить SaleDetail, как это требует политика платежной системы карты. Если CapToken нет, или отсутствует авторизация в расчетном центре, копировать CapTokenItem из соответствующего AuthReqItem запроса AuthReq и из AuthResPayload отклика AuthRes
5	Заполнить CapTokSeq с помощью CapToken из соответствующих сообщений AuthRes, полностью тождественных с CapItem в CapSeq. Если CapToken для транзакции отсутствует, заносится нуль.
6	В дополнительные позиции инкапсуляции EncBX заносятся PANToken, если продавец получил PANToken
7	Опционно заполняется CRqExtensions
8	Если включено PANToken, использовать EncBХ-инкапсуляцию
9	Если PANToken не включено, использовать EncB-инкапсуляцию
10	Вложить сообщение в цифровой конверт и послать владельцу карты

Генерация CapPayload осуществляется согласно алгоритму.

Шаг	Действие
1	Занести в поле CapDate текущее значение даты
2	Занести в CapReqAmt сумму выплаты
3	Скопировать AuthResPayload из соответствующего AuthRes
4	Опционно заполнить CPayExtensions

Формат сообщения CapReq представлен в таблице 4.6.2.68 Таблица 4.6.2.68.

Формат CapReq

CapReq	CapTokenSeq является внешним “багажом”. Если имеется маркер PANToken, он должен соответствовать одному CapItem и одному CapToken в CapTokenSeq.
CapReqData	{CapRRTags, [MThumbs], CapItemSeq, [CRqExtensions]}
CapTokenSeq	{[CapToken] +} Один или более CapTokens, соответствующие один-в-один CapItems в CapItemSeq. Любой CapToken может быть опущен, т.е. может равняться нулю.
PANToken	См. табл. 4.6.2.46.
CapRRTags	RRTags. Новый RRPID и Date
MThumbs	Оттиски сертификатов, CRL и BrandCRLIdentifier, хранящиеся в кэше продавца.
CapItemSeq	{CapItem +} Один или более CapItem в упорядоченном массиве
CRqExtensions	Данные в расширении запроса платежа (capture) должны иметь финансовый характер и быть существенными для сообщения capture, посланного расчетному центру, финансовой сети или эмитенту. Данные в этом расширении относятся ко всем позициям запроса оплаты capture. Данные, относящиеся к специфическим позициям, должны помещаться в CapPayload
CapToken	Копируется из соответствующего AuthRes или AuthRevRes
CapItem	{TransIDs, AuthRRPID, CapPayload}
TransIDs	Копируется из соответствующего AuthRes или AuthRevRes
AuthRRPID	RRPID, который появляется в соответствующем AuthReq или AuthRev
CapPayload	См. табл. 4.6.2.69.

Структура данных CapPayload представлена в таблице 4.6.2.69. Таблица 4.6.2.69. Структура CapPayload

CapPayload	{CapDate, CapReqAmt, [AuthReqItem], [AuthResPayload], [SaleDetail], [CPayExtensions]}
CapDate	Дата платежа - это дата транзакции, которая появится в уведомлении владельца карты.
CapReqAmt	Сумма платежа, затребованная продавцом, может отличаться от AuthAmt. Это сумма транзакции (до конвертации валюты), которая появится в уведомлении владельца карты.
AuthReqItem	См. табл. 4.6.2.64. Поле необходимо, если соответствующий маркер CapToken отсутствует или система расчетного центра/банка продавца не содержит подходящих данных для авторизационного запроса.
AuthResPayload	См. табл. 4.6.2.67. Поле необходимо, если соответствующий маркер CapToken отсутствует или система расчетного центра/банка продавца не содержит подходящих данных для авторизационного отклика.
SaleDetail	См. табл. 4.6.2.47.
CPayExtensions	Данные в расширении запроса платежа (capture) должны иметь финансовый характер и быть существенными для сообщения capture, посланного расчетному центру, финансовой сети или эмитенту. Данные этого расширения приложимы к индивидуальным позициям платежного запроса. Данные, относящиеся ко всему запросу, помещаются в расширение CapReqData.

Расчетный центр, получив запрос CapReq, обрабатывает его следующим образом.

Шаг	Действие
1	Извлечь запрос из входного сообщения
2	Обработать CRqExtensions. Если какое-либо неподдерживаемое расширение имеет критический флаг, отбросить сообщение, послав сообщение Error = unrecognizedExtension
3	Для каждого CapItem обработать платеж и сформировать CapResItem с суммой из обрабатываемого платежа и кодом CapCode, соответствующим успеху или неудаче: Обработать CapPayload Если CapToken присутствует: Проверить CapToken. Если CapToken некорректен, отклонить платеж, возвратив для данной позиции CapCode = invalidCapToken Проверить, что CapToken не был еще обработан. Если проверка не прошла, отклонить платеж, прислав CapCode = invalidCapToken Обработать TokenOpaque В противном случае, если допустимы платежи без CapToken: Если AuthReqItem и AuthResPayload отсутствуют, отклонить платеж, послав CapCode = authDataMissing Сверить AuthReqItem и AuthResPayload с записями транзакции. Если соответствия нет, платеж отвергается путем посылки CapCode = invalidAuthData. В противном случае, если платежи без CapToken не поддерживаются, платеж отклоняется посылкой CapCode = missingCapToken Проверить TransIDs Извлечь запись транзакции Проверить, что XID согласуется с записью транзакции. Если согласия нет, то платеж отклоняется посылкой CapCode = unknownXID Сверить LID-C и, если имеется, LID-M со значениями из записи транзакции. Если совпадения нет, то транзакция терпит неудачу, посылается CapCode = unknownLIDf) Обработать платеж для заданной позиции через существующую финансовую сеть карты и записать результат.

Расчетный центр обрабатывает CapPayLoad следующим образом.

Шаг	Действие
1	Обработать CPayExtensions. Если неизвестное расширение помечено как критическое, сообщение отвергается и возвращается сообщение Error unrecognizedExtension
2	Запомнить SaleDetail
3	Проверить, что BatchID является открытой платежной линией для BrandAndBIN. Если платежная линия неизвестна, отклонить платеж с посылкой CapCode = batchUnknown. Если линия не открыта, отклонить платеж с CapCode = batchClosed
4	Проверить, что идентификатор BatchSequenceNum является уникальным в рамках платежной линии. Если идентификатор не уникален, отклонить платеж путем возвращения CapCode = batchUnknown.

Расчетный центр формирует отклик CapRes согласно следующему алгоритму.

Шаг	Действие
1	Получить данные о платеже от платежного процесса
2	Скопировать CapRRTags из CapReq
3	Заполнить текущее значение BrandCRLIdentifier, имеющееся в расчетном центре, если оттиск для текущего BrandCRLIdentifier не получен или устарел.
4	Если MThumbs указывают, что продавцу для шифрования информации нужен новый Cert-PE: Вложить Cert-PE в цифровой конверт PKCS#7 Вложить GKThumb в AuthResData, так как сам Cert-PE не защищен подписью
5	Опционно занести в поле BatchSequenceNum состояние текущих платежных линий
6	Скопировать BatchID и BatchSequenceNum из SaleDetail в CapResPayload
7	Заполнить CapResSeq. Для каждого CapItem в соответствующем CapReq заполнить CapResItem следующим образом: Скопировать TransIDs из соответствующего CapReqItem Скопировать AuthRRPID из соответствующего CapReqItem, если он имеется Заполнить CapResPayload
8	Опционно заполнить CRsExtensions
9	Вставить сообщение в цифровой конверт и послать продавцу

Генерация CapResPayload осуществляется следующим образом.

Шаг	Действие
1	Заполнить CapCode и CapAmt результатами обработки соответствующего CapReqItem
2	Скопировать BatchID и BatchSequenceNum из соответствующего CapReqItem
3	Опционно заполнить CRsPayExtensions

Структура сообщения-отклика CapRes показана в таблице 4.6.2.70. Таблица 4.6.2.70. Структура CapRes

CapRes	Enc(P, M, CapResData)
CapResData	{CapRRTags, [BrandCRLIdentifier], [PEThumb], [BatchStatusSeq], CapResItemSeq, [CRsExtensions]}
CapRRTags	RRTag>s; копируется из CapReq
BrandCRLIdentifier	Список текущих CRL для всех СА в области ответственности платежной системы СА.
PEThumb	Оттиск сертификата расчетного центра, предоставляемый, если CapReqData.Mthumbs указывает на то, что продавец в нем нуждается.
BatchStatusSeq	{BatchStatus +}
CapResItemSeq	{CapResItem +} Заказ соответствует CapReq
CRsExtensions	Данные в расширении платежного отклика должны иметь финансовый характер и быть важными для осуществления платежа или последующего возврата денег.
BatchStatus	См. табл. 4.6.2.53.
CapResItem	{TransIDs, AuthRRPID, CapResPayload}
TransIDs	Копируется из соответствующего CapReq
AuthRRPID	RRPID, который появился в соответствующем AuthReq или AuthRevReq, копируется из соответствующего CapReq
CapResPayload	См. табл. 4.6.2.71.

Структура данных CapResPayload представлена в таблице 4.6.2.71. Таблица 4.6.2.71. Структура CapResPayload

CapResPayload	{CapCode, CapAmt, [BatchID], [BatchSequenceNum], [CRsPayExtensions]}
CapCode	Цифровой код, указывающий на состояние платежа
CapAmt	Копируется из соответствующего CapReq
BatchID	Идентификатор для установления платежной линии между продавцом и его банком. Копируется из соответствующего CapReq
BatchSequenceNum	Порядковый номер позиции в текущей последовательности платежей; копируется из соответствующего CapReq
CRsPayExtensions	Данные в расширении поля данных платежного отклика должны иметь финансовый характер и быть важными для осуществления платежа ли последующего возврата денег.

Продавец обрабатывает отклик CapRes следующим образом.

Шаг	Действие
1	Извлекается отклик из входного сообщения
2	Обрабатывается CRsExtensions, если таковые имеются. Если не узнанное расширение помечено как критическое, в рабочий журнал заносится запись Error = unrecognizedExtension, а сообщение CapRes отбрасывается
3	Извлекается запись транзакции и производится сравнение CapRRTags: Проверяется, что XID соответствует транзакции. Если это не так, сообщение отвергается и посылается отклик Error = unknownXID Проверяется, что LID-M и, если присутствует в записи транзакции, LID-C согласуются с записью транзакции. Если согласия нет, сообщение отвергается и посылается отклик Error = unknownLID
4	Если в сообщение включен BrandCRLIdentifier, запомнить все CRL.
5	Проверить, что GKThumb согласуется с сертификатом шифрования платежного центра (если GKThumb имеется). Если это не так, актуализовать кэш сертификата с использованием текущего сертификата.
6	Для каждого CapResItem в CapResSeq: Обрабатывается CRsPayExtensions. Если неузнанное расширение помечено как критическое, в рабочий журнал заносится запись Error = unrecognizedExtension, а сообщение CapRes отбрасывается. Обработать CapCode для получения результата операции Для успешного платежа запомнить CapCode и CapAmt, ассоциированные с AuthRRPID.
7	Если BatchStatusSeq присутствует, обработать и запомнить каждое значение BatchStatus

В таблице ниже представлены допустимые значения CapCode.

success	Платежная позиция обработана расчетным центром успешно
unspecifiedFailure	Причина неудачи неизвестна
duplicateRequest	Платежный запрос для данной транзакции уже был обработан (для XID и AuthRRPID)
authExpired	Авторизационный запрос был обработан слишком давно в прошлом. Это время определяется политикой платежной системы карты.
authDataMissing	В платежном запросе отсутствует авторизационная информация
invalidAuthData	Авторизационная информация для данной транзакции некорректна
capTokenMissing	Для обработки данной позиции необходимо поле CapToken, а его нет
invalidCapToken	Поле CapToken некорректно для данной транзакции
batchUnknown	Расчетный центр не знает о существовании платежной линии для данной позиции
batchClosed	Платежная линия для данной позиции закрыта
unknownXID	Не распознан идентификатор XID
unknownLID	Не распознан идентификатор LID

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

Шаг	Действие
1	Сформировать CapRevOrCredRRTags с новым RRPID и текущей датой.
2	Рекомендуется заполнить MThumbs путем вычисления оттисков сертификатов и CRL, имеющихся у продавца. Продавец должен заполнить оттиски в сообщении, которые могут быть затем нужны для верификации подписей и сертификатов, присылаемых расчетным центром.
3	Заполнить одну или более позиций в CredRevOrCredReqItems: Скопировать TransIDs из соответствующего CapRes. Скопировать AuthRRPID из самого последнего запроса (settlement), если имеется. Скопировать CapPayload из самого последнего запроса (settlement), (т.е. CapReq, CapRevReq, CredReq или CredRevReq). Заполнить NewBatchID, если кредитная линия транзакции закрыта. Заполнить CapRevOrCredReqData с текущей датой и временем Опционно заполнить CapRevOrReqAmt с новой суммой, которая может отличаться от значений, содержащихся в AuthAmt из CapToken и CapReqAmt из CapPayload. Опционно установить новое значение NewAccountInd, если сделка состоится для нового счета владельца карты, как это специфицировано в PANToken. Опционно заполнить CRvRqItemExtensions
4	Опционно заполнить CRvRqExtensions

Структура данных CapRevOrCredReqData описана в таблице 4.6.2.72. Таблица 4.6.2.72. Структура CapRevOrCredReqData

CapRevOrCredReqData	{CapRevOrCredRRTags, [MThumbs], CapRevOrCredReqItemSeq, [CRvRqExtensions]}
CapRevOrCredRRTags	RRTags.Новый идентификатор RRPID и Date для данной пары.
MThumbs	Оттиски сертификатов, CRL и BrandCRLIdentifier, хранящиеся в кэше продавца
CapRevOrCredReqItemSeq	{CapRevOrCredReqItem +}Один или более CapRevOrCredReqItem в виде упорядоченного массива
CRvRqExtensions	Данные расширения отзыва платежа или запроса кредита должны иметь финансовый характер и играть важную роль для обработки этих сообщений расчетным центром или эмитентом.
CapRevOrCredReqItem	{TransIDs, AuthRRPID, CapPayload, [NewBatchID], CapRevOrCredReqDate, [CapRevOrCredReqAmt], NewAccountInd, [CRvRqItemExtensions]}
TransIDs	Копируется из соответствующего CapRes.Поле необходимо, если соответствующий маркер CapToken отсутствует или не содержит подходящих данных авторизационного запроса
CapPayload	См. табл. 4.6.2.69
NewBatchID	Это поле специфицирует новый идентификатор платежной линии; оно используется для запросов отзыва платежа для позиций, реализованных в рамках платежной линии, которая была закрыта. BatchID >в CapPayload идентифицирует исходную платежную линию.
CapRevOrCredReqDate	Дата подачи запроса
CapRevOrCredReqAmt	В кредитных запросах сумма запрашиваемого кредита, которая может отличаться от AuthAmt в CapToken и CapReqAmt в CapPayload
NewAccountInd	Указывает, что новый номер счета специфицирован в PANToken; когда это поле установлено, новый номер счета будет записан поверх информации о старом номере счета в CaptureToken или авторизационных данных, хранимых банком продавца. Использование этого поля является предметом политики платежной системы карты или банка продавца.
CRvRqItemExtensions	Данные в расширении поля данных отзыва платежа или запроса кредита должны иметь финансовый характер и быть важными для осуществления отзыва платежа или кредита расчетным центром

Расчетный центр обрабатывает CapRevOrCredReqData следующим образом.

Шаг	Действие
1	Обрабатываются CRvRqxtensions. Если неподдерживаемое расширение помечено как критическое, возвращается отклик Error = unrecognizedExtensions, а обрабатываемое сообщение отбрасывается.
2	Обрабатывается каждое CapRevOrCredItem: Обрабатываются CRvRqItemExtensions. Если неподдерживаемое расширение помечено как критическое, возвращается отклик Error = unrecognizedExtensions Извлекается запись транзакции и производятся сравнения с TransIDs в CapRevOrCredItem Проверяется, что XID соответствует предшествующей транзакции. Если это не так, сообщение отбрасывается и посылается сообщение Error = unknownXID. Проверяется соответствие LID-C с записью транзакции. Если соответствия нет, сообщение отбрасывается и посылается отклик Error = unknownLID Проверяется CapPayload на соответствие записи транзакции. Если равенства нет, позиция отбрасывается и возвращается CapRevOrCredCode = capDataMismatch. Если установлен идентификатор NewBatchID, проверить, что BatchID является открытой платежной линией для BrandAndBIN. Если платежная линия закрыта, возвращается код CapRevOrCredCode = batchClosed. Если платежная линия неизвестна, возвращается код CapRevOrCredCode = batchUnknown. Запоминается CapRevOrCredAmt Если установлен NewAccountInd, использовать номер счета в PANToken для работы с расчетной картой в финансовой сети.
3	На основе TransIDs в AuthRevTags извлекается запись транзакции.

Расчетный центр формирует CapRevOrCredResData с помощью следующей последовательности операций.

Шаг	Действие
1	Заполнить поле CapRevOrCredTags
2	Заполнить текущий BrandCRLIdentifier, хранимый расчетным центром, если оттиск BrandCRLIdentifier не получен или устарел.
3	Если Mthumb указывает, что продавец нуждается в новом Cert-PE при шифровании информации для расчетного центра, то: Ввести Cert-PE в цифровой конверт PKCS#7 Ввести GKThumb в AuthResData, так как сам Cert-PE не защищен подписью
4	Опционно ввести BatchStatus в поле BatchStatusSeq для каждой платежной линии, чье состояние запрошено.
5	Для каждой позиции в соответствующем CapRevOrCredItems заполнить поле CapRevOrCredResItem следующим образом: Скопировать TransIDs из соответствующего CapRevOrCredReqItem Если доступно, скопировать RRPID из соответствующего CapRevOrCredItemЗаполнить CapRevOrCredResPayload следующим образом: Занести в CapRevOrCredCode результат кредита или отзыва платежа Занести в CapRevOrCredActualAmt действительную сумму кредита или отзыва Если имеется, скопировать BatchID и BatchSequanceNum из соответствующего CapRevOrCredReqItem Опционно заполнить CRvRsPayExtensions
6	Опционно заполнить CRvRsExtensions

Структура данных CapRevOrCredResData имеет формат, описанный в таблице 4.6.2.73. Таблица 4.6.2.73.

Структура CapRevOrCredResData

CapRevOrCredResData	{CapRevOrCredRRTags, [BrandCRLIdentifier], [PEThumb], [BatchStatusSeq], CapRevOrCredResItemSeq, [CRvRsExtensions]
CapRevOrCredRRTags	RRTags; копируется CapRevOrCredRRTags из соответствующего поля CapRevOrCredReqData
BrandCRLIdentifier	Список текущих CRL для всех СА в зоне ответственности СА платежной системы.
PEThumb	Оттиск сертификата расчетного центра, поставляемого, если CapRevOrCredReq.MThumbs указывает, что продавец в нем нуждается
BatchStatusSeq	{BatchStatus +}
CapRevOrCredResItemSeq	{CapRevOrCredResItem +} Один или более CapRevOrCredResItem в упорядоченном массиве
CRvRsExtensions	Данные в расширении поля данных отклика на запрос отзыва платежа или кредита должны иметь финансовый характер и быть важными для осуществления отзыва платежа или кредита расчетным центром
BatchStatus	См. табл. 4.6.2.53.
CapRevOrCredResItem	{TransIDs, AuthRRPID, CapRevOrCredResPayload}
TransIDs	Копируется из соответствующего CapRevOrCredReqData.AuthReqData.AuthTags
AuthRRPID	RRPID, который появляется в соответствующем AuthReq или AuthRevReq
CapRevOrCredResPayload	См. табл. 4.6.2.74

Структура данных CapRevOrCredResPayload представлена в таблице 4.6.2.74. Таблица 4.6.2.74. Структура CapRevOrCredResPayload

CapRevOrCredResPayload	{CapRevOrCredCode, CapRevOrCredActualAmt, [BatchID], [BatchSequenceNum], [CRvRsPayExtensions]}
CapRevOrCredCode	Числовой код, характеризующий состояние отзыва платежа или кредита.
CapRevOrCredActualAmt	Копируется из соответствующего CapRevOrCredReqItem.
BatchID	Идентификатор платежной линии сделки для банка продавца
BatchSequenceNum	Порядковый номер позиции в последовательности платежей
CRvRsPayExtensions	Расширение поля данных отклика на запрос отзыва платежа или кредита должны иметь финансовый характер и быть важными для обработки отклика на отзыв платежа или кредит.

Допустимые значения кода CapRevOrCredCode представлены ниже

success	Позиция была успешно обработана расчетным центром
unspecifiedFailure	Причина неудачи не специфицирована
duplicateRequest	Запрос отзыва платежа или кредита для данной транзакции был уже обработан (XID и AuthRRPID)
originalProcessed	Запрос платежа для данной позиции был уже обработан
originalNotFound	Специфицированная позиция расчетным центром не обнаружена
capPurged	Информация о платеже была удалена из памяти транзакций расчетного центра
missingCapData	Информация о платеже отсутствует в запросе отзыва платежа или кредита
missingCapToken	Необходимый для обработки данной позиции маркер CapToken отсутствует в запросе отзыва платежа или кредита
invalidCapToken	Маркер CapToken некорректен
batchUnknown	Платежная линия для данной позиции расчетному центру неизвестна
batchClosed	Платежная линия для данной позиции уже закрыта

Обработка продавцом CapRevOrCredResData осуществляется следующим образом.

Шаг	Действие
1	Обработать CRvRsExtensions. Если какое-то нераспознанное расширение помечено как критическое, сообщение отбрасывается и посылается отклик Error = unrecognizedExtension.
2	Обработать CapRevOrCredTags
3	Извлечь запомненную запись транзакции и обработать TransIDs следующим образом: Проверить, что XID согласуется с данными из записи транзакции. Если согласия нет, сообщение отбрасывается, а в журнал операций записывается Error = unknownXID Проверить, что LID-C и LID-M согласуются с данными записи транзакции. Если согласия нет, сообщение отбрасывается, а в журнал операций записывается Error = unknownLID.
4	Если в сообщение включен BrandCRLIdentifier, запомнить CRL.
5	Проверить, что GKThumb согласуется с существующим сертификатом шифрования расчетного центра, если GKThumb присутствует. Если соответствия нет, актуализовать кэш сертификата с использованием текущего сертификата.
6	Для каждого BatchStatus в batchStatusSeq обработать BatchStatus и запомнить результат
7	Обработать каждый CapRevOrCredResItem в CapRevOrCredResItems следующим образом Обработать CRvRsPayExtensions. Если какое-либо не узнанное расширение помечено как критическое, сообщение отвергается и посылается отклик Error = unrecognizedExtension Извлечь записи транзакции, используя TransIDs. Если не удается найти транзакцию с подходящим TransIDs, отвергнуть сообщение и записать в журнал операций Error = unknownXID Сравнить LID-C и LID-M с данными в сообщении. Если согласия нет, сообщение отбрасывается, а в журнал операций записывается Error = unknownLID. Обработать CapRevOrCredPayload следующим образом: Обработать CapRevOrCredCode для получения результата Если предоставление кредита или отзыв платежа прошел успешно, записать CapCode и CapAmt Обработать BatchID и BatchSequenceNum, если таковые имеются

Пара сообщений CapRevReq/ CapRevRes служит для сокращения или аннулирования суммы предшествующего платежа. Они используются после осуществления оплаты и до того, как записи платежа продавца и его банка устареют. Обмен такими сообщениями носит опционный характер. Сообщение CapRevReq может быть послано когда угодно после запроса платежа, направленного расчетному центру. Структура данных в запросе CapRevReq представлена в таблице 4.6.2.75. Таблица 4.6.2.75. Структура CapRevReq

CapRevReq	CapTokenSeq является внешним “багажом”. Если PANToken содержится в сообщении, поле должно соответствовать одной записи в CapRevData.CapRevOrCredReqItemSeq и одному маркеру CapToken в CapTokenSeq
CapRevData	CapRevOrCredReqData
CapTokenSeq	{[CapToken] +}Один или более CapTokens, при полном соответствии последовательности CapRevOrCredReqItem в CapRevOrCredReqData.CapRevOrCredReqItemSeq. Заметим, что только маркер CapToken может быть опущен; т.е., может быть нулем (NULL)
PANToken	См. табл. 4.6.2.46
CapToken	Копируется из соответствующего AuthRes или AuthRevRes

Структура отклика показана ниже CapRevRes.

CapRevRes	Enc(P,M, CapRevResData)
CapRevResData	CapRevOrCredResData

Пары сообщений CredReq/CredRes используются для возвращения кредита по оплаченным ранее транзакциям. Они могут применяться вместо CapRevReq/Res, когда записи о конкретной транзакции у продавца и в расчетном центре оказались удаленными или устаревшими. Такая последовательность сообщений используется продавцом, который может послать запрос CredReq в любое время после согласования номера счета с банком продавца. Формирование запроса CredReq осуществляется в следующей последовательности.

Шаг	Действие
1	Генерируется информация CredReqData
2	Для каждой позиции CapRevOrCred в CapRevOrCredItems заполнить позицию в CapTokSeq следующим образом: Если доступно, записать CapToken для соответствующей транзакции. В противном случае (если недоступно), записать NULL.Результатом этого шага будет CapTokSeq с соответствием один-к-одному между позициями в CredReqData и CapTokSeq
3	Если доступно или необходим новый PAN, заполнить PANToken в дополнительную нишу EncBX-инкапсуляции. Если PANToken имеется, только одна позиция может присутствовать как в CredReqData, так и CapTokSeq
4	Если PANToken имеется, использовать EncBX-инкапсуляцию, в противном случае EncB-инкапсуляцию.
5	Вставить сообщение в цифровой конверт и послать владельцу карты

Структура запроса CredReq показана в таблице 4.6.2.76. Таблица 4.6.2.76. Структура CredReq

CredReq	<EncB(M, P, CredReqData, CapTokenSeq), EncBX(M, P, CredReqData, CapTokenSeq, PANToken)> CapTokenSeq является внешним “багажом”. Если PANToken имеется, он должен соответствовать одной записи в CredReqData.CapRevOrCredReqItemSeq и одной CapToken в CapTokenS
CredReqData	CapRevOrCredReqData ; см. табл. 4.6.2.72.
CapTokenSeq	{[CapToken] +} Один или более CapTokens в соответствии один-к-одному с CapRevOrCredReqItem последовательностью в CapRevOrCredReqData.CapRevOrCredReqItemSeq. Заметим, что любой маркер CapToken может быть опущен, т.е., может быть NULL
PANToken	См. табл. 4.6.2.46
CapToken	Копируется из соответствующего AuthResили AuthRevRes

Расчетный центр обрабатывает полученный CredReq следующим образом.

Шаг	Действие
1	Извлекается запрос из входного сообщения
2	Для каждой позиции, для которой продавец получил маркер CapToken: Проверяется присутствие CapToken. Если CapToken отсутствует, позиция отвергается и присылается CapRevOrReqCode = capTokenMissing Проверяется CapToken
3	Для каждой транзакции в сообщении реализовать кредитную операцию, используя существующую финансовую сеть платежной карты, как это специфицировано в содержимом CapRevOrCredItem.

Формирование CredRes осуществляется в следующей последовательности.

Шаг	Действие
1	Получить отклик из финансовой сети платежной карты
2	Сгенерировать CredResData, как это описано в CapRevOrCredResData, используя результаты из финансовой сети платежной карты. Заполнить RRTags, полученные в запросе
3	Включить Enc-инкапсуляцию для полученных результатов
4	Поместить сообщение в цифровой конверт и отправить владельцу карты

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

CredRes	Enc(P, M, CredResData)
CredResData	CapRevOrCredResData; см. табл. 4.6.2.74.

Продавец обрабатывает CredRes за два шага:

Получается отклик CredRes из входного сообщения

Обрабатывается CredResData, как это описано в CapRevOrCredResData. Для каждого CapRevOrCredResItem проверяется CapRevOrCredCode, чтобы определить результат и записать успешно проплаченную сумму. Сообщения CredRevReq/CredRevRes обеспечивают для продавца механизм отзыва предоставленного ранее кредита.

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

Шаг	Действие
1	Сформировать CredRevReqData, как это описано в разделе CapRevOrCredReq
2	Для каждой позиции CapRevOrCred в CapRevOrCredItem заполнить позицию в CapTokSeq следующим образом: Если доступен, занести CapToken для соответствующей транзакции В противном случае, если маркер не доступен, записать NULL
3	Если доступен или необходим новый PAN, занести PANToken в дополнительную нишу EncBX-инкапсуляции.Если PANToken в наличии, только одна позиция может присутствовать как в CredRevReqData, так и в CapTokSeq.
4	Если PANToken присутствует, включить EncBX-инкапсуляцию. В противном случае - EncB-инкапсуляцию.
5	Вставить сообщение в цифровой конверт и направить владельцу карты

Структура запроса CredRevReq показана в таблице 4.6.2.77. Таблица 4.6.2.77. Структура CredRevReq

CredRevReq	CapTokenSeq является внешним “багажом”. Если PANToken имеется, он должен соответствовать одной записи в CredRevReqData.CredRevReqSeq и однму маркеру CapToken в CapTokenSeq.
CredRevReqData	CapRevOrCredReqData; см. табл. 4.6.2.72
CapTokenSeq	{[CapToken] +} Один или более CapTokens, в соответствии один-к-одному с CredRevReqItem в CapRevOrCredReqData.CapRevOrCredReqItemSeq. Заметим, что любой CapToken может быть опущен, т.е. может быть NULL
PANToken	См. табл. 4.6.2.46
CapToken	Копируется из соответствующего AuthRes<=2> или AuthRevRes

Расчетный центр обрабатывает запрос CredRevReq следующим образом.

Шаг	Действие
1	Выделить запрос из входного сообщения
2	Для каждой позиции, для которой продавец получил CapToken: Проверить присутствие CapToken. Если CapToken отсутствует, отвергнуть позицию, послав CapRevOrReqCode = capTokenMissing Проверить CapToken
3	Для каждой транзакции в сообщении выполнить отзыв кредита, используя существующую финансовую сеть расчетной карты, как это специфицировано содержимым CapRevOrCredItem

Формирование отклика CredRevRes осуществляется в следующей последовательности.

Шаг	Действие
1	Получить отклик из финансовой сети платежной карты
2	Сформировать CredRevResData, как это описано в разделе CredRevOrCredResData, используя результаты из финансовой сети карты. Заполнить RRTags, полученные в запросе.
3	Включить для полученного результата Enc-инкапсуляцию
4	Вложить отклик в цифровой конверт и отправить владельцу карты

Отклик CredRevRes имеет достаточно простой формат:

CredRevRes	Enc(P, M, CredRevResData)
CredRevResData	CredRevOrCredResData; См. табл. 4.6.2.74.

Продавец обрабатывает полученный отклик следующим образом

Шаг	Действие
1	Извлекается отклик из входного сообщения
2	Обрабатывается CredRevResData, как это описано в разделе о CapRevOrCredResData. Для каждого CapRevOrCredResItem проверяется CapRevOrCredCode, чтобы определить результат и записать сумму успешного платежа.

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

Шаг	Действие
1	Заполнить PCertTags, как это описано в разделе о RRTags табл. 4.6.2.52.
2	Рекомендуется заполнить отклики Mthumbs путем вычисления оттисков сертификатов и CRL, хранящихся у продавца. Продавец должен занести оттиски в сообщение, которое может потребоваться позднее для верификации подписей и сертификатов, предоставленных расчетным центром. Включение этого поля служит оптимизации с целью уменьшения передач сертификатов и CRL в последующих сообщениях из расчетного центра.
3	Заполнить BrandIDSeq одним или более BrandIDandBIN, для которого необходимы сертификаты: Заполнить поле BrandID Опционно заполнить поле BIN
4	Опционно заполнить поле PCRqExtensions
5	Ввести S (см. описание оператора подпись выше)
6	Вложить сообщение в цифровой конверт и отправить владельцу карты

Формат сообщения-запроса PCertReq представлен в таблице 4.6.2.78.

PCertReq	S(M, PCertReqData)
PCertReqData	{PCertTags, [MThumbs], BrandAndBINSeq, [PCRqExtensions]}
PCertTags	RRTags. Новый RRPID для этого PCertReq, MerTermIDs, поставляемый продавцом, и текущая дата
MThumbs	Оттиски сертификатов расчетного центра, хранящиеся в кэше продавца.
BrandAndBINSeq	{BrandAndBIN +} Продавец запрашивает сертификаты расчетного центра для платежных систем карты, если оттиск текущего сертификата отсутствует в MThumbs
PCRqExtensions	Запрос сертификата расчетного центра не шифруется, поэтому это расширение не должно содержать конфиденциальной информации
BrandAndBIN	{BrandID, [BIN]}
BrandID	Платежная система карты (без указания типа).
BIN	Идентификационный номер банка для обработки транзакции продавца в расчетном центре.

Таблица 4.6.2.78. Структура сообщения PCertReq Расчетный центр обрабатывает PCertReq следующим образом

Шаг	Действие
1	Расчетный центр получает PCertReq из входного сообщения
2	Обрабатываются расширения PCRqExtensions. Если встречается нераспознанное расширение, помеченное как критическое, прислается отклик unrecognizedExtensions, а PCertReq отбрасывается.
3	Обрабатывается BrandIDSeq и MThumbs
4	Формируется и посылается PCertRes

Формирование PCertRes осуществляется в следующей последовательности

Шаг	Действие
1	Скопировать PCertTags из PCertReq в PCertRes
2	Для каждого BrandAndBIN в BrandIDSeq из PCertReq: Если доступен корректный сертификат: Заполнить соответствующий сертификат шифрования расчетного центра Cert-PE Занести в PCertCode, соответствующий PCertResItem c “успешным” кодом PCertCode Занести в CertThumb оттиск присланного сертификата В противном случае, если сертификаты недоступны, так как не поддерживается данная платежная система, занести PCertCode, соответствующего PСertResItem c кодом PCertCode = brandUnsupported и опустить CertThumb В противном случае, если платежная система поддерживается, но BIN неизвестен, занести в поле PCertCode соответствующего PсertResItem код PCertCode = unknownBIN и опустить CertThumb В противном случае занести в поле PCertCode соответствующего PCertResItem код PCertCode = unspecifiedFailure и опустить CertThumb
3	Для каждой платежной системы, для которой необходим сертификат, прислать текущее значение BrandCRLIdentifier, если только Mthumbs не содержит оттиска для текущего BrandCRLIdentifier
4	Опционно заполнить PCRqExtensions

Структура сообщения-отклика PCertRes представлена в таблице 4.6.2.79. Таблица 4.6.2.79. Структура PCertRes

PCertRes	S(P, PCertResTBS)
PCertResTBS	{PCertTags, [BrandCRLIdentifierSeq], PCertResItems, [PCRsExtensions]}
PCertTags	RRTags; копируется из PCertReq.
BrandCRLIdentifierSeq	{BrandCRLIdentifier +}
PCertResItems	{PCertResItem +}Один или более статусных кодов и оттисков сертификатов, которые возвращаются в соответствии один к одному с PCertReq.BrandAndBINSeq
PCRsExtentions	Сертификатный отклик расчетного центра не шифруется, по этой причине данное расширение не должно содержать конфиденциальных данных.
BrandCRLIdentifier	Список текущих CRL для всех CA в зоне ответственности CA платежной системы. См. раздел о BrandCRLIdentifier
PCertResItem	{PCertCode, [CertThumb]}
PCertCode	Цифровой код, указывающий результат PCertReq
CertThumb	Оттиск возвращенного сертификата

Продавец обрабатывает PCertRes следующим образом.

Шаг	Действие
1	Извлекается отклик из входного сообщения
2	Обрабатываются PCRsExtensions. Если встречается нераспознанное расширение, помеченное как критическое, присылается отклик unrecognizedExtensions и отбрасывается PCertRes
3	Извлекаются сертификаты из Cert-PE
4	Проверяются сертификаты в Cert-PE путем сравнения их с CertThumbs в PCertResItems. Отбрасываются все сертификаты, которые не прошли сверку.
5	Обработатывается каждый BrandCRLIdentifier из присланной последовательности таких идентификаторов.
6	Продолжается обработка сообщений, которые ожидали сертификатов, присланных в PCertRes.

Стандартизованы следующие значения PcertCode, собранные в таблице 4.6.2.80. Таблица 4.6.2.80. Значения PCertCode

success	Запрос обработан успешно
unspecifiedFailure	Запрос не прошел из-за неспецифицированной причины
brandNotSupported	Запрос не прошел из-за того, что платежная система, специфицированная в PCertReq, не поддерживается
unknownBIN	Запрос не прошел из-за того, что BIN, специфицированный в PCertReq, не поддерживается.

Управление платежными линиями (Batch) Продавец посылает запросы управления платежными линиями расчетному центру для того, чтобы осуществлять контроль над последовательностями платежей расчетных транзакций. Операция управления платежной линией включает в себя обмен двумя сообщениями BatchAdminReq (запрос продавца в расчетный центр) и BatchAdminRes (отклик расчетного центра). Запрос может включать в себя инструкции открыть, очистить или закрыть платежную линию, а также передать или запросить информацию о состоянии платежной линии. Отклик несет в себе информацию о состоянии или запрошенные данные. Платежная линия формируется расчетным центром, когда продавец открывает ее для накопления транзакций и сумм. Все транзакции, которые проплачиваются, объединяются в специфическую группу (платежную линию - batch) или группу по умолчанию, если не определена специальная платежная линия (группа платежей). Следует учитывать, что в группу платежей могут входить операции, выполненные в рамках различных платежных систем.

Поддержка групп платежей позволяет продавцу и расчетному центру улаживать проблемы, связанные с различными несогласованностями. Если продавец контролирует содержимое групп платежей, каждая платежная линия открывается прежде, чем транзакции ассоциируются с ней путем включения BatchID и BatchSequenceNum в платежные транзакции. Продавец может также закрыть платежную линию в соответствии с требованиями бизнеса. Транзакции не ассоциируются с платежной линией после ее закрытия. Продавец может также иметь возможность удалить все транзакции из открытой платежной линии. Очистка платежной линии не означает ее закрытия. Если содержанием платежных линий управляет расчетный центр, продавец не должен вставлять BatchID и BatchSequenceNum в платежные транзакции. Открытие и закрытие платежной линии контролируется в этом случае расчетным центром, который может включать BatchID и BatchSequenceNum в возвращаемую структуру SaleDetail. Продавец при этом не может удалять транзакции из группы или закрывать платежные линии, определенные идентификаторами BatchID, сформированными расчетным центром. Продавец может запросить статусную информацию для любой платежной линии, которая имеет известный BatchID. Расчетный центр возвращает BatchStatus для запрошенной платежной линии. Продавец может запросить BatchStatus для определенных платежных систем или итоговый баланс для конкретной платежной линии. Если продавец управляет содержимым платежной линии, тогда он может предоставлять информацию BatchStatus расчетному центру для любого BatchID. Расчетный центр проверяет данные, предоставленные продавцом в BatchStatus путем сверки с информацией, накопленной у него. При этом продавец получит отклик, в котором будет отражено соответствие этих сумм. Если продавец предоставляет информацию о транзакции расчетному центру, последний выдает состояние серии платежей в отклике BatchAdminRes, который следует за BatchAdminReq. Продавец формирует запрос BatchAdminReq в следующем порядке.

Шаг	Действие
1	Если это первое сообщение, направленное расчетному центру после получения нового секретного ключа, или если это первое сообщение в данный день, в цифровой конверт этого сообщения следует вложить сертификаты для секретных ключей и цепочку сертификатов платежной системы, выбранных продавцом для подписи и шифрования сообщений BatchAdmin.
2	Сформировать RRTags
3	Если новая платежная линия открыта: Установить BatchOperation = open Занести в поле BatchID идентификатор для неиспользуемой платежной линии. Опционно занести в поле BrandAndBIN последовательность BrandID и опционно BIN, чтобы ограничить список транзакций, которые могут появиться в данной группе платежей. Установить ReturnBatchSummeryIndicator = FALSE Опустить все остальные поля сообщения
4	Если платежная линия (группа платежей) пуста: Установить BatchOperation = purged Занести в BatchID идентификацию для неиспользуемой платежной линии Опционно занести в BrandandBIN последовательность BrandID и опционно BIN, чтобы ограничить список транзакций, которые удаляются из группы платежей. Установить ReturnBatchSummeryIndicator = FALSE Опустить все остальные поля сообщения
5	Если платежная линия закрыта: Установить BatchOperation = closed Занести в BatchID идентификацию для открытой платежной линии Установить ReturnBatchSummeryIndicator = FALSE Опустить все остальные поля сообщения
6	Если нужно запросить состояние платежной линии у расчетного центра: Опустить BatchOperation Занести в BatchID идентификацию для платежной линии Опционно занести в BrandandBIN последовательность BrandID и опционно BIN, чтобы ограничить объем статусной информации, возвращаемой в BatchAdminRes. Установить ReturnBatchSummeryInd = TRUE Опустить все остальные поля сообщения
7	Если нужно запросить детальные данные о платежной линии у расчетного центра: Опустить BatchOperation Занести в BatchID идентификацию платежной линии Опционно занести в BrandandBIN последовательность BrandID и опционно BIN, чтобы ограничить список транзакций, которые удаляются из группы (платежной линии). Если необходима итоговая информация платежной линии, установить ReturnBatchSummeryInd = TRUE, в противном случае = FALSE Если это первый (или единственный) запрос в последовательности, установить StartingPoint =0, в противном случае установить StartingPoint равным значению NextSequence, полученному в предшествующем отклике BatchAdminRes для данной последовательности. Занести MaximumItems наибольший номер позиции, которую нужно послать в BatchAdminRes Опустить все остальные поля сообщения
8	Если нужно послать состояние платежной линии расчетному центру: Опустить BatchOperation Занести в BatchID идентификацию для платежной линии Опустить BrandandBIN Установить ReturnBatchSummeryInd = FALSE Сформировать BatchStatus: Занести в поле BatchTotals значения для всех транзакций данной группы (batch) Опционно занести BrandID и BatchTotals в BranchBatchDetails для одной или более платежных систем, используемых в рамках платежной линии.f) Опустить все остальные поля сообщения
9	Если нужно передать расчетному центру детальные данные о платежной линии: Опустить BatchOperation Занести в BatchID идентификацию для платежной линии Опустить BrandandBIN Установить ReturnBatchSummeryInd = FALSE Если это последний (или единственный) запрос в последовательности, установить StartingPoint =0, в противном случае установить NextStartingPoint равным значению, позволяющему расчетному центру проверить, что группа платежей принята в правильной последовательности. Заполнить TransactionDetail для набора позиций платежной линии. Если NextStartingPoint = 0, опционно сформировать BatchStatus: Занести в BatchTotals значения для всех транзакций платежной линии. Опционно занести BrandID и BatchTotals в BranchBatchDetails для одной или более платежных систем, используемых в рамках платежной линии.h) Если продавец хочет прервать передачу BranchBatchDetails, установить значение поля MaximumItem равным 0, в противном случае опустить это поле.
10	Реализовать операцию подписи для результата шагов 1-9, используя сертификат подписи продавца для любой платежной системы, известной расчетному центру.
11	Включить сертификат шифрования продавца для той же платежной системы, что была выбрана на предшествующем шагу. Общедоступный ключ этого сертификата будет использоваться расчетным центром при дешифровке сообщений BatchAdminRes.
12	Зашифровать BatchAdminReqTBE, используя сертификат расчетного центра и установить тип содержимого равным id-set-content-BatchAdminReqTBE.
13	Вложить сообщение в цифровой конверт и послать владельцу карты

Структура запроса BatchAdminReq представлена в таблице 4.6.2.81. Таблица 4.6.2.81. Структура BatchAdminReq

BatchAdminReq	Enc(M, P, BatchAdminReqData)
BatchAdminReqData	{BatchAdminRRTags, [BatchID], [BrandAndBINSeq], [BatchOperation], ReturnBatchSummaryInd, [ReturnTransactionDetail], [BatchStatus], [TransDetails], [BARqExtensions]}
BatchAdminRRTags	RRTags. Новый идентификатор RRPID и Date (дата)
BatchID	Идентификатор платежной линии для счета банка продавца
BrandAndBINSeq	{BrandAndBIN +}
BatchOperation	Числовая величина, указывающая на операцию, которая должна быть выполнена в рамках платежной линии
ReturnBatchSummaryInd	Обозначает, что в BatchAdminRes должны быть возвращены итоговые данные.
ReturnTransactionDetail	{StartingPoint, MaximumItems, ErrorsOnlyInd, [BrandID]} Если специфицирован BrandID, присылаются данные только для позиций, определяемых платежной системой карты.
BatchStatus	См. табл. 4.6.2.53.
TransDetails	{NextStartingPoint, TransactionDetailSeq}
BARqExtensions	Данные в расширении административного сообщения платежной линии должны иметь финансовый характер и быть важными для обработки административных запросов.
BrandAndBIN	{BrandID, [BIN]}
StartingPoint	Нуль указывает на то, что следует прислать данные для первой группы позиций, в противном случае NextStartingPoint предшествующего BatchAdminRes
MaximumItems	Максимальное число позиций, которые следует прислать в этой группе.
ErrorsOnlyInd	Булево число, индицирующее, следует ли присылать только позиции с состоянием ошибки.
BrandID	Тип платежной системы (без указания типа продукта).
NextStartingPoint	Нуль индицирует, что это последняя группа позиций, в противном случае, используется значение, идентифицирующее начальную точку следующей группы позиций.
TransactionDetailSeq	{TransactionDetail +}
BIN	Идентификационный номер банка для обработки транзакций продавца.
TransactionDetail	См. табл. 4.6.2.54

Расчетный центр обрабатывает запрос BatchAdminReq следующим образом.

Шаг	Действие
1	Выделить запрос из входного сообщения
2	Проверить подпись. Если проверка не прошла, присылается отклик Error c ErrorCode = signatureFailure.
3	Проверить, что RRPID в BatchAdminReq соответствует RRPID в цифровом конверте сообщения. Если проверка не прошла, присылается отклик Error c ErrorCode = unknownRRPID.
4	Если BatchOperation = open: Проверить, что BatchID еще не открыт. Если это не так, установить BAStatus = batchAlreadyOpen. Проверить, что BatchID доступен. Если это не так, установить BAStatus = batchIDUnavailable. Если имеется BrandIDSeq: Проверить, что каждый BrandID поддерживается. Если это не так, установить BAStatus = brandNOTSupported. Проверить, что каждый BIN поддерживается. Если это не так, установить BAStatus = unknownBIN. Запомнить платежные системы и BIN, которые можно использовать для данной платежной линии. Открыть платежную линию для использования продавцом и установить BAStatus = success. Продолжить процесс посылкой BatchAdminResЛюбые другие поля, присутствующие в сообщении BatchAdminReq будут игнорироваться, когда BatchOperation = open.
5	Если BatchOperation = purge: Проверить, что BatchID уже открыт. Если это не так, установить BAStatus = unknownbatchID. Если BrandIDSeq присутствует: Проверить, что каждый BatchID относится к данной платежной линии. Если это не так, установить BAStatus = brandBatchMismatch. Проверить, что каждый BIN относится к данной платежной линии. Если это не так, установить BAStatus = unknownBIN. Удалить все транзакции платежной линии, ассоциированные со специфицированной платежной системой и BIN. В противном случае, удалить все транзакции из группы платежей Установить BAStatus = success Продолжить работу посылкой сообщения BatchAdminResЛюбые другие поля, присутствующие в сообщении BatchAdminReq, будут игнорироваться, когда BatchOperation = purge.
6	Если BatchOperation = close: Проверить, что BatchID уже открыт. Если это не так, установить BAStatus = unknownbatchID. Установить BAStatus = success Продолжить работу посылкой сообщения BatchAdminResЛюбые другие поля, присутствующие в сообщении BatchAdminReq будут игнорироваться, когда BatchOperation = close.
7	Если BatchOperation опущено, а возвращенное значение ReturnBatchSummaryInd = TRUE: Проверить, что BatchID доступен. Если это не так, установить BAStatus = batchIDUnavailable. Если BrandAndBIN включен: Проверить, что каждый BatchID относится к данной платежной линии. Если это не так, установить BAStatus = brandBatchMismatch. Проверить, что каждый BIN относится к данной платежной линии. Если это не так, установить BAStatus = unknownBIN. Вычислить BatchTotals и заполнить структуры данных BrandBatchDetails для каждого специфицированного значения BrandAndBIN. Вычислить BatchTotals для платежных систем, включенных в BrandAndBIN, или для всех транзакций, если BrandAndBIN отсутствует. Заполнить BatchTotals в структурах данных BatchStatus вычисленными значениями. Если TransmissionStatus и SettlementInfo доступны в клиринговой системе, используемой расчетным центром, занести эту информацию в BatchAdminRes. Если StartingPoint опущено, установить BAStatus = success и продолжить работу посылкой отклика BatchAdminRes, в противном случае перейти к следующему шагу.NextStartingPoint и TransactionDetailSeq игнорируются, если ReturnBatchSummaryInd = TRUE.
8	Если включено поле StartingPoint: Если MaximumItem установлен равным 0, аннулировать любую предшествующую информацию для данной платежной линии и установить BAStatus = success и продолжить работу посылкой отклика BatchAdminRes. Проверить, что BatchID доступен. Если это не так, установить BAStatus = batchIDUnavailable. Если StartingPoint не равен нулю, проверить, что StartingPoint равен NextStartingPoint, присланном в предыдущем отклике BatchAdminRes. Если StartingPoint равен нулю, установить указатель на начало списка платежей, в противном случае установить указатель согласно содержимому StartingPoint. Если имеется BrandAndBIN: Проверить, что каждый BatchID имеет отношение к данной платежной линии. Если это не так, установить BAStatus = brandBatchMismatch. Проверить, что каждый BIN имеет отношение к данной платежной линии. Если это не так, установить BAStatus = unknownBIN. Если специфицировано поле MaximumItems, заполнить TransactionDetail вплоть до MaximumItems из текущей позиции и установить NextStartingPoint в позицию, из которой можно получить данные для последующих транзакций. Если система достигла конца списка платежей, установить NextStartingPoint = 0. Выбор позиции ограничивается BrandandBIN и ErrorOnlyInd.f) Установить BAStatus = success и продолжить работу посылкой отклика BatchAdminRes
9	Если код BatchOperation опущен, а BatchStatus имеется: Проверить, что BatchID доступен. Если это не так, установить BAStatus = batchIDUnavailable. Если имеется поле BrandBatchDetails: Проверить, что каждый BatchID имеет отношение к данной платежной линии. Если это не так, установить BAStatus = brandBatchMismatch. Проверить, что каждый BIN имеет отношение к данной платежной линии. Если это не так, установить BAStatus = unknownBIN. Вычислить BatchTotals и заполнить информационные структуры BrandBatchDetails для каждого специфицированного BrandAndBIN. Вычислить BatchTotals для платежных систем, включенных в BrandAndBIN или для всех транзакций, если BrandAndBIN отсутствует. Для любого значения BatchTotals, которое не согласуется с приведенным в сообщении BatchAdminReq, занести вычисленные значения в BatchTotals информационной структуры BatchStatus. Если какое-либо итоговое значение не согласовано, установить BAStatus = totalsOutOfBalance и перейти к следующему пункту. Если поле TransactionDetails опущено, установить BAStatus = success и продолжить работу посылкой отклика BatchAdminRes
10	Если код BatchOperation опущен и включено поле TransactionDetails: Проверить, что BatchID доступен. Если это не так, установить BAStatus = batchIDUnavailable. Если указатель StartingPoint не равен нулю и не согласуется с NextStartingPoint из предыдущего BatchAdminReq, установить BAStatus = unknownStartingPoint. Если NextStartingPoint не равен нулю, запомнить TransactionDetails, скопировать NextStartingPoint в сообщение BatchAdminRes и установить BAStatus = success. Продолжить работу посылкой отклика BatchAdminRes. Проверяется соответствие полученных транзакций с теми, что хранятся в расчетном центре. Если отличие обнаружено, установить BAStatus = totalsOutOfBalance. Продолжить работу посылкой отклика BatchAdminRes. Опционно установить BAStatus = stopItemDetail, чтобы проинформировать продавца о том, что расчетный центр не желает обрабатывать позиции в данной последовательности платежей (batch). Продолжить работу посылкой отклика BatchAdminRes. Установить BAStatus = success и продолжить работу посылкой отклика BatchAdminRes.Последовательность BrandAndBIN игнорируется.

Формирование отклика BatchAdminRes осуществляется согласно следующему алгоритму.

Шаг	Действие
1	Если BAStatus не установлен равным success (успех) или MaximumItems в BatchAdminReq установлен равным 0, аннулировать любую информацию в рамках платежной линии для заданной последовательности запросов BatchAdmin, посланных ранее продавцом.
2	Используя сертификат расчетного центра, запустить операцию подписи для BatchAdminResData.
3	Зашифровать BatchAdminResTBE, используя сертификат шифрования, поставляемый продавцом, и установить код типа содержимого равным id-set-content-BatchAdminResTBE.
4	Вложить сообщение в цифровой конверт и послать владельцу карты.

Структура отклика BatchAdminRes представлена в таблице 4.6.2.82. Таблица 4.6.2.82. Структура BatchAdminRes

BatchAdminRes	Enc(P, M, BatchAdminResData)
BatchAdminResData	{BatchAdminTags, BatchID, [BAStatus], [BatchStatus], [TransmissionStatus], [SettlementInfo], [TransDetails], [BARsExtensions]}
BatchAdminTags	RRTags; копируется из предшествующего BatchAdminReq
BatchID	Идентификатор платежной линии между продавцом и его банком.
BAStatus	Числовой код, указывающий на состояние открытой платежной линии.
BatchStatus	См. табл. 4.6.2.53.
TransmissionStatus	Числовое значение, индицирующее состояние передачи данных из расчетного центра системе вышестоящего уровня
SettlementInfo	{SettlementAmount, SettlementType, SettlementAccount, SettlementDepositDate}
TransDetails	{NextStartingPoint, TransactionDetailSeq}
BARsExtensions	Данные расширения административного отклика должны носить финансовый характер и иметь значение для обработки административного запроса по поводу платежной линии. Информация, относящаяся к обработке запроса, должна появляться в расширении BatchAdminResData; информация, относящаяся к состоянию платежной линии, должна содержаться в расширении BatchStatus; информация, относящаяся к информационным деталям позиции в пределах платежной линии должна содержаться в расширении TransactionDetail.
SettlementAmount	Занесенная через сеть на счет продавца сумма
SettlementType	Числовой код, указывающий тип суммы
SettlementAccount	Счет продавца
SettlementDepositDate	Дата, когда сумма SettlementAmount будет занесена или снята со счета продавца
NextStartingPoint	Нуль индицирует, что это последняя группа позиций, в противном случае, для идентификации начальной точки следующей группы позиций используется скрытое значение
TransactionDetailSeq	{TransactionDetail +}
TransactionDetail	См. табл. 4.6.2.54..

В ниже приведенной таблице представлены стандартизованные значения поля ReimbursementID

unspecified	Неизвестное значение
standard	Стандартная скорость обмена
keyEntered	Скорость обмена для транзакций key-entered (ввод с клавиатуры)
electronic	Скорость обмена для электронных транзакций
additionalData	Скорость обмена для транзакций, которые включают в себя дополнительные клиринговые данные
enhancedData	Скорость обмена для транзакций, которые включают в себя усовершенствования (такие как данные дополнительной авторизации).
marketSpecific	Скорость обмена для транзакций в пределах специфического сегмента рынка (такого как пассажирский транспорт).

Продавец получает и обрабатывает BatchAdminRes следующим образом.

Шаг	Действие
1	Извлекается отклик BatchAdminRes из входного сообщения.
2	Верифицируется подпись. Если проверка не прошла, присылается сообщение Error с ErrorCode = signatureFailed.
3	Проверяется, что RRPID в BatchAdminReq соответствует RRPID в цифровом конверте. Если проверка не прошла, присылается сообщение Error с ErrorCode = unknownRRPID.
4	Если BAStatus не равен success, а продавец передает или запрашивает подробности о платежной линии, аннулировать любую информацию, запомненную для данной платежной линии и перезапустить процесс, если детальные данные о платежах по-прежнему нужны.
5	Если продавец получает детальные данные о платежной линии, запомнить NextStartingPoint для использования в последующих откликах BatchAdminRes. Значение нуль указывает, что все подробности о платежной линии переданы.
6	Если продавец передает детальные данные о платежной линии, проверить, что NextStartingPoint согласуется со значением, посланным в BatchAdminReq. Если согласия нет, послать BatchAdminReq с MaximumItems = 0, чтобы расчетный центр аннулировал детали платежной линии, посланные ранее, после чего повторить посылку этих деталей расчетному центру в последующей серии запросов BatchAdmin.
7	Запомнить детали из запроса BatchAdmin и передать их расчетным процедурам продавца.

Для реализации протокола SET в конкретных приложениях можно использовать утилиту Wallet () фирмы Microsoft (Microsoft Commerce Server).

Следует учитывать, что, так как система SET является достаточно сложной и дорогостоящей, а продавец должен платить за каждую операцию с кредитной карточкой, то через систему SET проходят платежи, превышающие 10$. Для осуществления более мелких платежей используются другие схемы (например, First Virtual, CyberCoin, DigiCash () или Millicent - ). Схема First Virtual () предназначена для продажи дешевых программных продуктов или услуг. Она предполагает регистрацию клиента, при которой он сообщает номер своей кредитной карточки и получает регистрационный номер (PIN). При покупке клиент вводит свой индивидуальный номер и, если он верен, немедленно получает доступ к нужному ему продукту. Позднее First Virtual связывается с клиентом по электронной почте, уведомляет о цене покупки, предоставляя ему одобрить или нет снятие соответствующей суммы с его кредитной карточки. Эта система зиждется на полном доверии и честности обеих сторон. Система CyberCash () базируется на схеме, сходной с SET. Здесь также используется специальное программное обеспечение со стороны клиента и продавца. Клиент при регистрации получает бесплатно программу CyberCash Wallet и заполняет идентификационную и платежную информацию. Данная информация в зашифрованном виде будет храниться на ЭВМ клиента. Эти данные посылаются при нажатии клиентом клавиши “оплатить”. Система предоставляет клиенту ряд дополнительных услуг, например просмотр баланса последних операций. Назад:
Оглавление:
Вперёд:

P- отклик на ping

Отклик на ping P1. Для минимизации избыточности здесь не используется никаких криптографических методов. #####################################################################
Отправитель: CyberServer
Получатель: CyberApp
#####################################################################
Пример сообщения: $$-CyberCash-0.8-$$
type: ping-response
id: myCyberCashID [если присутствует в P1]
transaction: 12312313
date: 19950121100505.nnn
server-date: 19950121100506.nnn
swseverity: fatal/warning [отсутствует, если все в порядке]
swmessage; Говорит CyberApp, что оно использует устаревший протокол.
Данный текст отображается для пользователя. [Присутствует только при наличии SWSeverity.]
response-code: success/failure/etc.
message;
Свободный текст комментария об ошибке или успехе.
Этот текст должен быть отображен отправителю его прикладной программой CyberCash.
supported-versions: 08.win, 0.81win, 0.8mac $$-CyberCash-End-7Tm/djB05pLIw3JAyy5E7A==-$$
#####################################################################
swversion не включается в P1 по соображениям секретности, по этой причине swseverity и swmessage присутствуют, только если сервер может сказать, что эти вещи устарели.
supported-versions позволяет клиенту знать как можно быстрее, какие версии поддерживаются приложением, а какие нет.

P- ping

Простая проверка доступности сервера со стороны клиента. Здесь для минимизации избыточности не используется никаких криптографических методов. #####################################################################
Отправитель: CyberApp
Получатель: CyberServer
#####################################################################
Пример сообщения:
$$-CyberCash-0.8-$$
type: ping
id: myCyberCashID [optional]
transaction: 123123213
date: 19950121100505.nnn
$$-CyberCash-End-7Tm/djB05pLIw3JAyy5E7A==-$$ #####################################################################
id является опционным, так как персона может быть еще не установлена.

Packaging HTML

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

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

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

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

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

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

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

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

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

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

Платеж

Кассир проверяет, может ли он принять или выполнить платеж путем идентификации компоненты платежа в полученном им блоке платежного запроса. Затем, используя 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-атрибуту идентифицированного элемента вылютной суммы. Если не обнаружено ни одной или более одной подходящей ссылки элемента, возникает состояние ошибки.
	- проверяется совместимость элементов в списке видов платежа. В частности, элементы выбранного вида платежа, суммы, платежного протокола и валютной суммы являются дочерними элементами идентифицированного компонента списка видов платежа. Если это не так, то это ошибка.

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

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

Платежное сообщение отклика

Помимо блока ссылок транзакции (смотри раздел 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, содержащиеся в блоке платежного запроса (если имеются).

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

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

1.	Покупатель решает что-то купить и посылает информацию об этой операции (запрос предложения) Продавцу, напр., используя HTML.
C а M	Информация о том, что покупается (вне рамок стандарта IOTP)
2.	Продавец решает, какой тип и протокол платежа следует предложить, записывает эти данные в компонент Brand List и посылает покупателю.
C Я M	Компоненты: список типов платежей (Brand List)
3.	Покупатель выбирает тип платежа, протокол и вид валюты, формирует компонент выбор типа и посылает его продавцу.
C а M	Компонент: Выбор из списка типов платежа (Brand List Selection)
4.	Продавец проверяет выбор типа, определяет сумму платежа, опционно подписывает документ и посылает его Покупателю.
C Я M	Компонент: Платеж; Организации (продавец и кассир); опционная подпись отклика-предложения, которая подтверждает другие компоненты.
5.	Покупатель проверяет объявленную сумму платежа и, если согласен, посылает запрос кассиру.
C а P	ЗАПРОС ПЛАТЕЖА. Компоненты: Статус, Платеж; Организации (продавец и Кассир); Информация о торговых ролях (опционно); опционная подпись отклика-предложения, которая подтверждает все прочие компоненты. Данные о схеме платежа.
6.	Кассир проверяет информацию, включая опционную подпись и, если все в порядке, начинает обмен компонентами данных по схеме платежа с целью выбора типа и протокола платежа.
C « P	ПЛАТЕЖНЫЙ ОБМЕН. Компонент: Данные о схеме платежа
7.	Как только обмен протокольными платежными сообщениями завершится, Кассир посылает Покупателю платежную расписку, которая опционно подписывается, с целью подтверждения платежа.
C « P	ОТКЛИК на ПЛАТЕЖ. Компоненты: Статус, платежная расписка; платежное заявление; данные о торговых ролях (опционно); опционная подпись отклика-предложения; опционная подпись платежной расписки, которая связывает платеж и предложение
8.	Покупатель проверяет платежную расписку

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

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

Компонент выбора типа платежа содержит выбор покупателя. Тип платежа, протокол, вид валюты, сумма и возможно протокольно зависимая информация посылается продавцу. Эта информация используется для модификации данных предложения (Offer Exchange). Например, продавец может предложить скидку, с тем, чтобы стимулировать использование карточки накопления (store card).

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

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

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

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

Компонент платеж содержит данные о сумме платежа, валюте и направлении оплаты (кто кому).

Компонент подпись "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).

Подписи и хэши

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

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

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

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

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

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

Получение логотипов

Ниже описано, как извлекать логотипы для отображения их программой 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, которая извлекает логотип, в зависимости от размера и цвета, который желательно иметь.

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

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

o	Инициировать транзакции (смотри раздел 4.6.1). Среди них могут быть:
		- платеж, связанный с транзакцией
		- инфраструктурные транзакции.
o	Воспринять и обработать сообщение, полученное от другой торговой роли (смотри раздел 4.6.2). Сюда входит:
		- идентификация того, принадлежит ли сообщение транзакции, запущенной ранее;
		- обработка дублированных сообщений;
		- генерирование переходных ошибок, если сервер, который обрабатывет входное сообщение перегружен;
		- обработка сообщения, если оно не имеет ошибок и, если необходимо, посылка отклика партнеру по результатам обработки.
o	Аннулировать текущую транзакцию, если поступил соответствующий запрос, например от пользователя (смотри раздел 4.6.3).
o	Повторно передать сообщение, если ожидаемый отклик не пришел своевременно (смотри раздел 4.6.4).

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

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

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

Последовательности сообщений MM*

Последовательности сообщений CM* представляют собой первичную систему покупок с помощью кредитных карт CyberCash для безопасной обработки денежных оплат клиентами системы. Однако продавцы, которые авторизованы их банком для получения оплаты товаров и услуг, могут также получать оплату по телефону, по почте или наличными. Чтобы исключить для продавца необходимость иметь вторую параллельную систему обработки этих платежей, определены последовательности сообщений MM1 - MM6, которые служат для организации таких менее безопасных транзакций. Сообщения MM* очень похожи на последовательность сообщений CM*, но закрытая секция покупателя на самом деле подписана продавцом, при этом не требуется какого-либо дополнительного CyberCash ID покупателя или ссылки на его кредитную карту.

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

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

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

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

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

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

o	TimedOutRcvr, если транзакция может быть восстановлена позднее, или
o	TimedOutNoRcvr, если транзакция невосстановима.

PR- запрос платежа (payment-request)

Это сообщение является первым, которое определено CyberCash в процессе торговой сделки со стороны продавца. Собственно покупка произведена, так как мы собираемся ее оплатить. #####################################################################
Отправитель: MerchantApp
Получатель: CyberApp
#####################################################################
Пример сообщения: $$-CyberCash-0.8-$$
type: payment-request
merchant-ccid: ACME-012
merchant-order-id: 1231-3424-234242
merchant-date: 19950121100505.nnn
note;
Товары ACME Покупка 4 пар "Rocket Shoes" по цене $39.95 каждая.
Доставка и вручение $5.00 Общая цена: 164.80 Доставить по адресу: Wily Coyote 1234 South St. Somewhere, VA 12345
merchant-amount: usd 164.80
accepts: visa:CC001, master:CC001,amex:CC001,JCPenny:VK005,macy:VK006
url-pay-to: http://www.ACME.com/CybercashPayment
>url-success: http://www.ACME.com/ordersuccess
>url-fail: http://www.ACME.com/orderfail
merchant-signed-hash:
a/0meaMHRinNVd8nq/fKsYg5AfTZZUCX0S3gkjAhZTmcrkp6RZvppmDd/P7lboFLFDBh
Ec0oIyxWeHfArb3OtkgXxJ7qe0Gmm/87jG5ClGnpBnw0dY7qcJ6XoGB6WGnD $$-CyberCash-End-lSLzs/vFQ0BXfU98LZNWhQ==-$$ Скрытая секция здесь отсутствует.
#####################################################################
При формировании подписанного продавцом хэша используется секретный ключ продавца. Хэш формируется для полей: type, merchant-ccid, merchant-order-id, date, note, merchant-amount, accepts, url-pay-to, url-success, url-fail
##################################################################### Это сообщение подписывается продавцом, но покупатель не может непосредственно проверить эту подпись. Когда платеж произведен, Покупатель подписывает хэш (полученный непосредственно покупателем) платежа. Если соответствия не будет, CyberCash блокирует платежную операцию. accepts: Программа клиента распознает только одно слово имени карты из поля accepts сообщения PR1. Например, MasterCard
AmericanExpress
Распознаны как
Master card
American express
Не распознаны. MasterCard и masterCard распознаются оба как master card.
За типом карты следует указатель ключа. Для основного ряда кредитных карт это будет CC*. Клиент может использовать или игнорировать * номер по своему выбору. Для личной карты это будет VK*, где * представляет собой ключ CheckFree, который следует использовать. Карты разделяются запятыми, указатель ключа следует за типом карты и двоеточием. url-pay-to указывает, куда следует послать CH1. url-fail и url-success несут информацию о том, где броузер должен искать данные в случае успеха или неудачи.

Прикладные сообщения и уведомления об ошибках

Оказалось необходимо ввести в систему CyberCash сообщения номера утилиты, статуса запроса, и специального уведомления об ошибке. Желательно иметь возможность проверять коннективность, с некоторой точностью синхронизовать часы и определять версии протокола и приложения клиента. Это сделано с помощью сообщения P1, посылаемого клиентом серверу и отклика P2, возвращаемого сервером клиенту. Клиенты должны быть способны определить состояние предшествующих транзакций, когда клиент или продавец закрэшился во время сессии или произошла потеря информации в ходе или по завершении транзакции. Определены два сообщения-запроса о транзакции TQ1 и TQ2. Один из них осуществляет запрос, а второй аннулирует транзакцию, если она не завершена. Откликом на оба эти запроса является сообщение TQ3, посылаемое сервером. Так как система работает в режиме запрос-отклик, имеется две ситуации, когда необходимы специальные сообщения об ошибках. Если запрос оказался не интерпретируемым или имеет неизвестный код типа, посылается уведомление об ошибке UNK1. Если отклик оказался не интерпретируемым или имеет неизвестный код типа или имела место какая-то другая ошибка, которая должна быть зафиксирована в журнале событий сервера CyberCash. Клиент или продавец направляют серверу диагностические сообщения DL1 или DL2.

использования ID-атрибутов

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

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

подписи IOTP

Пример использования подписи проиллюстрирован ниже на рис. .11, где показано как взаимодействуют различные компоненты и элементы друг с другом. Для целей иллюстрации была использована базовая торговая транзакция. Применение элементов и атрибутов аналогично для всех типов транзакций IOTP. Элемент Manifest в компоненте подписи содержит дайджесты TransRefBlock (не покаазан); ID-компонента транзакции (не покаазан); компонентов организаций (Продавца, Кассира, Агента доставки); компонент списка видов платежа; компонент заказа, платежный компонент, компонент доставки и компонент выбора вида платежа (если покупка зависит от вида платежа).

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

Пример выбора вида платежа

Для оплаты через 'British Airways' MasterCard для выше приведенного варианта и платежного протокола SET список вида платежа будет иметь вид: CurrencyAmountRef='M1.9' >

Примеры логотипа для сетевой позиции

Если логотип сетевой позиции равен "ftp://logos.xzpay.com", тогда:

"ftp://logos.xzpay.com/medium.gif" извлечет логотип среднего размера с 256 цветами

"http://logos.xzpay.com/small4.gif" извлечет логотип малого размера с 16 цветами Организации, которые делают логотип доступными для работы с IOTP должны всегда допускать размеры "small" и "medium" и использовать формат "gif".

Примеры сообщений

Простое сообщение от клиента: $$-CyberCash-0.8-$$
id: DONALD-69
transaction: 918273645
date: 199512250102
cyberkey:CC1001
opaque: GpOJvDpLH62z+eZlbVkhZJXtTneZH32Qj4T4IwJqv6kjAeMRZw6nR4f0OhvbTFfPm+GG
aXmoxyUlwVnFkYcOyTbSOidqrwOjnAwLEVGJ/wa4ciKKI2PsNPA4sThpV2leFp2Vmkm4
elmZdS0Qe350g6OPrkC7TKpqQKHjzczRRytWbFvE+zSi44wMF/ngzmiVsUCW01FXc8T9
EB8KjHEzVSRfZDn+lP/c1nTLTwPrQ0DYiN1lGy9nwM1ImXifijHR19LZIHlRXy8=
$$-End-CyberCash-End-jkn38fD3+/DFDF3434mn10==-$$ Сообщение от продавца: $$-CyberCash-a.b.c-extra-$$
merchant-ccid: acme-69
merchant-date: 19951231115959
merchant-transaction: 987654321
label: value labelx: multiple line
value...
# Комментарий
# еще одна строка комментария
label; text with a real
multi-line
format !
merchant-cyberkey: CC1001
merchant-opaque: C1Q96lU7n9snKN5nv+1SWpDZumJPJY+QNXGAm3SPgB/dlXlTDHwYJ4HDWKZMat+VIJ8y
/iomz6/+LgX+Dn0smoAge7W+ESJ6d6Ge3kRAQKVCSpbOVLXF6E7mshlyXgQYmtwIVN2J
66fJMQpo31ErrdPVdtq6MufynN8rJyJtu8xSNolXlqIYNQy5G2I3XCc6D3UnSErPx1VJ
6cbwjLuIHHv58Nk+xxt/FyW7yAMwUb9YNcmOj//6Ru0NiOA9P/IiWczDe2mJRK1uqVpC
sDrWehG/UbFTPD26trlYRnnY
$$-CyberCash-End-kchfiZ5WAUlpk1/v1ogwuQ==-$$

Примеры видов платежа

Данный пример содержит три образца XML для компонента списка видов платежа:

вариант с просой кредитной карточкой;

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

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

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

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

сформировать и послать аутентификатору сообщение-отклик аутентификации или

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

атрибут ProcessState компонента Status = CompletedOk, в случае успешного завершения проверки, или

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

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

Если аутентификатор получает от Покупателя сообщение IOTP, содержащее блок Cancel, тогда аутентифицируемый может обратиться к сетевому узлу CancelNetLocn, специифицированному элементом торговой роли в компоненте Organisation для аутентификатора, указанного в блоке опций торгового протокола.
Получив сообщение платежного запроса, кассир должен проверить, авторизован ли данный платеж (смотри раздел 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.1). Получив сообщение платежного обмена, покупатель также должен выполнить некоторые действия по платежному документальному обмену (смотри раздел 9.1.3.1). По получении сообщения платежного отклика и отклика доставки транзакция завершена. Если покупатель получает сообщение IOTP, содержащее блок Cancel, информация, содержащаяся в сообщении должна быть доведена до сведения покупателя и более никаких действий не предпринимается. Если кассир получает сообщение IOTP, содержащее блок Cancel, тогда покупатель вероятно обратится в сетевой узел CancelNetLocn, специфицированный элементом торговой роли в компоненте Organisation для кассира. Если продавец получает сообщение IOTP, содержащее блок Cancel, тогда покупатель должен прервать операцию платежа. В этом случае покупатель вероятно обратится в сетевой узел CancelNetLocn, специфицированный элементом торговой роли в компоненте Organisation для продавца. Здесь он может предпринять какие-то дальнейшие действия.

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

сформировать и послать покупателю сообщение-отклик доставки или

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

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

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

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

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

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

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

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

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

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

Привязка кредитных карт (Binding Credit Cards)

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

Процесс авторизации кредитной карты и расчета

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

(1)	авторизация: продавец контактирует со своим покупателем, который в свою очередь получает от банкира, выпустившего кредитную карту, подтверждение или отрицание своей кредитоспособности. Эти данные он пересылает продавцу.
(2)	приобретение (capture): платежная информация для покупки вводится продавцом в расчетный документ.
(3)	оплата (clearance): обработка перечня товаров. Это вызывает появление товаров из перечня в записи о покупке для данной кредитной карты. Эта запись посылается банку, предоставившему кредитную карту покупателю.
(4)	урегулирование (settlement): межбанковская операция по пересылке денежных средств.
(5)	удаление (void): продавец отменяет шаг 2 (или 6), сумма оплаты удаляется из расчетного документа. Операция должна быть выполнена до осуществления оплаты.
(6)	кредит (credit): продавец вводит отрицательную сумму оплаты в расчетный документ. Эта сумма появится в записи о покупке владельца кредитной карты.

Четвертый шаг (settlement) реализуется исключительно в банковской среде. CyberCash 0.8 формирует сообщения для реализации шагов 1, 1&2, 2, 5 и 6. это справедливо для систем работы с кредитными картами, где данные о сделке накапливаются в банке или в системе продавец-банк. CyberCash 0.8 поддерживает такие системы. Другие системы работы с кредитными картами требуют того, чтобы все данные о сделке хранились у продавца. Такие системы часто называются "терминальными покупками" ("terminal capture"). Это делает операции 2, 5 и 6 внутренними для продавца, но требует сообщений для выполнения операции 3. Такие сообщения о денежных расчетах будут включены в будущие версии CyberCash для приложений продавца и сервера.

Простой пример, базирующийся на кредитной карте

Этот простой пример включает в себя:

только основные виды платежей с помощью кредитной карты;

одну цену и одну валюту;

одного Кассира и

один платежный протокол. PayDirection='Debit' >
BrandLogoNetLocn='ftp://otplogos.mastercard.com/mastercardcredit'
ProtocolAmountRefs='M1.33'>

BrandLogoNetLocn='ftp://otplogos.visa.com/visacredit' ProtocolAmountRefs='M1.33'>

BrandLogoNetLocn='ftp://otplogos.amex.com' ProtocolAmountRefs ='M1.33' >

PayReqNetLocn='http://www.example.com/etill/sccd1' >

CyberCash Inc. представляет собой компанию,

Семёнов Ю.А. (ГНЦ ИТЭФ), book.itep.ru CyberCash Inc. представляет собой компанию, базирующуюся в штате Вирджиния и основанную в августе 1994. Целью компании является посредничество в сфере платежей через Интернет. CyberCash выполняет функцию посредника, через которого осуществляются финансовые операции между покупателем, продавцом и их банками. Важно то, что до начала операции участники могут не иметь никаких отношений друг с другом. CyberCash является третьей стороной, которая гарантирует надежную проводку платежа от одного партнера к другому.

Протокол микроплатежей MPTP (Micro Payment Transfer Protocol)

Разработчики технологии WWW, HTML и XML (группа W3C; ) разработали проект платежного протокола, который является модификацией алгоритма Pay-Word, предложенного Ривестом и Шамиром (“PayWord and MicroMint - Two Simple Micropayment Schemes”, R.L. Rivest and A.Shamir; ). Электронная коммерция предполагает рекламу, продажу материальных и нематериальных товаров. Материальные товары требуют доставки, что усложняет процедуру купли-продажи. Торговля через Интернет требует минимизации времени отклика для клиента. Кроме того, важно, чтобы издержки, сопряженные с торговыми операциями, составляли небольшую долю стоимости покупки, что становится весьма критично при низкой стоимости приобретаемого товара или услуги. При проектировании новых торговых систем следует учитывать, что процедуры верификации электронной подписи могут выполняться на стандартной рабочей станции со скоростью около 1000/сек, а вычисление однопроходной хэш-функции занимает примерно 10 мксек. Контроль хэш-функции в 100 раз быстрее, чем верификация RSA-подписи, и в 10000 раз быстрее формирования RSA-подписи. Таким образом, современная персональная ЭВМ вполне успешно может решать любые торговые операции даже в режиме сервера, который обслуживает десятки и сотни клиентов одновременно. Время отклика в любом случае не будет превышать одной секунды. Работа в реальном масштабе времени предлагает на два порядка более высокие требования, чем работа в режиме off-line. Протокол MPTP является асинхронным (большинство операций выполняются в режиме off-line). MPTP не делает различия между покупателем и продавцом. Протокол предполагает существование посредника-брокера (B; банкира), который контролирует счета участников сделок. Под брокером может подразумеваться любая организация, способная работать со счетами достаточно большого числа клиентов при минимальных издержках. Брокером может быть сервис-провайдер (ISP), телефонная компания или банк. При разработке протокола принимались во внимание следующие риски.

Злоупотребление кредитом (осуществление платежей через счет без реального намерения платить)

Мошенничество (например, направление фиктивного платежного поручения).

Неавторизованный отзыв платежа

Неавторизованная модификация заказа

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

Дублирование платежного поручения (клиентом или третьим лицом)

Отказ от услуги (клиент или продавец отказываются использовать свои счета)

Отказ выполнения платежа

Недоставка (платеж получен, а товар не доставлен). Протокол поддерживает любую политику платежей, которая может согласовываться покупателем (С) и продавцом (М).
Классическим объектом политики является, например, требование предоплаты. При обслуживании малоценных покупок целесообразен определенный уровень доверия и соответствующий ему уровень риска. При этом продавец мониторирует случаи отказов при платежах, выявляя недобросовестных покупателей. Стандартная схема работы с кредитной картой в данном случае является чрезмерно избыточной. Алгоритм платежа в MPTP основан схеме PayWord (1996 г.), где вычисляется цепочка значений хэш-функций c привлечением схемы MD5 или SHA. Полученные значения имеют 128 или 160 бит, допускается и меньшая длина. Схема PayWord является кредитной и практически реализует схему электронных монет. Пользователь запрашивает у брокера (банкира) счет и сертификат, передав ему по безопасному каналу номер своей кредитной карты, общедоступный ключ шифрования и адрес доставки (например, E-mail или IP-адрес). Брокер при этом посылает сертификат покупателя СП, который имеет вид: СП = [B, ID, AП, PKП, E, IП]SKB где B - идентификатор (имя) брокера; ID - идентификатор покупателя; AП - адрес доставки; PKП - общедоступный ключ покупателя; Е - время истечения действия сертификата (брокер может обновлять его, например, раз в месяц); IП - дополнительная информация, задаваемая брокером, например, серийный номер сертификата, лимит кредита и т.д.; SKB - секретный ключ брокера. Сертификат СП получен путем шифрования содержимого квадратных скобок с помощью SKB. В некоторых других платежных схемах сертификат формируется клиентом-покупателем. Сертификат устанавливает связь между общедоступным ключом покупателя и его счетом для заданного общедоступного ключа брокера. Предполагается, что общедоступный ключ брокера известен всем участникам платежного процесса. Генерация пар общедоступный-секретный ключ осуществляется каждым участником независимо. Данная схема не гарантирует анонимности (AП!), более того, здесь имеется риск утечки информации о номере кредитной карты пользователя. Сертификат гарантирует продавцу, что платежные слова (payWord) покупателя будут выкуплены брокером. Далее будем предполагать, что чтение одной страницы на коммерческом сервере продавца стоит один рубль (стоимость одного платежного слова согласуется на фазе инсталляции сессии). Когда пользователь обращается к коммерческой странице продавца, его броузер определяет, является ли данный вызов первым в этот день.

Если это первое обращение, программа покупателя формирует и подписывает обязательство, сопряженное с цепочкой платежных слов w1, w2, …, wn, где wn выбирается случайным образом. Значение n определяется клиентом. Все остальные платежные слова вычисляются рекурсивно, согласно соотношению: wi = H(wi+1) для i= n-1, n-2,…,0. Здесь w0 является корнем цепочки платежных слов, а не платежным словом. H - представляет собой однопроходную хэш-функцию типа MD5 или SHA. После этого клиент передает программе продавца обязательство и свой сертификат, программа верифицирует эти данные, используя общедоступный ключ брокера. i-платеж (для i = 1, 2, …) продавцу состоит из пары чисел (wi,i). Продавец может проверить это посылку, используя значение wi-1. Стоимость всех платежных слов (PayWord) w1, w2, …, wn идентична. Каждый платеж не предполагает каких-либо вычислений в программе покупателя и лишь одну хэш-операцию в программе продавца. Платежи должны быть индексированы в соответствии с порядком (i) сформированных платежных слов. Это исключает повторное использование платежных слов. Но возможна передача после платежного слова wi платежного слова wi+10, это будет означать оплату очередной покупки стоимостью 10 рублей (если одно платежное слово стоит один рубль). В конце каждого дня продавец передает брокеру последнее платежное сообщение за этот день (wl, L) каждого из покупателей, добавляя к нему соответствующее обязательство. Брокер снимает со счета покупателя L рублей (L платежных слов) и переводит их на счет продавца. Предполагается, что существует всего несколько брокерских центров на страну. Практически все операции выполняются в режиме off-line, а брокер не получает даже сообщений о каждом платеже (а только о последнем за данный день). Заметим, что в данной системе не специфицируется явно то, за какой товар или услугу осуществлен платеж. В некоторых платежных схемах обязательство выполняет функцию электронной кредитной карты или чека.

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

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

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

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

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

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

- идентификацию и проверку подписей. Это включает операционную организацию, идентифицирующую компоненты подписи, которые содержат ссылки на операционную организацию (смотри 6.3.1). В зависимости от выполняемой IOTPтранзакции (смотри раздел 9) может идентифицироваться одна или две подписи;

- проверку того, что компоненты подписи корректны. Это включает проверку того, что существуют элементы дайджеста в элементе Manifest, который относится к обязательным торговым компонентам (смотри раздел 6.3.3.1).

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

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

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

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

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

блоку ссылок транзакции (смотри раздел 3.3) первого сообщения IOTP, которое содержит подпись. Это связывает IotpTransId с информацией о сообщении IOTP, содержащемся в Id-компоненте сообщения (смотри раздел 3.3.2). Необходима проверка того, что каждый компонент подписи содержит элементы дайджеста, которые относятся к корректным данным. Элементы Digest, которые должны присутствовать, зависят от торговой роли организации, генерирующей цифровую подпись:

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

- элементы дайджеста должны присутствовать во всех компонентах блока запроса, вне зависимости от компонента выбора вида платежа, который является опционным;

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

	- компонента подписи, сформированной продавцом и, опционно
	- один или более компонентов подписи, сформированной предыдущим Кксиром в транзакции.

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

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

проверка того, что блок подписи присутствует и содержит один или более компонентов подписи;

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

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

проверка компонента Signature, который содержит идентифицированный элемент RecipientInfo в виде:

	- используются атрибуты SignatureValueRef и SignatureAlgorithmRef, чтобы идентифицировать, соответственно: элемент Value, который содержит подпись, подлежащую проверке и элемент алгоритма подписи, который характеризует алгоритм вычисления подписи, предназначенный для ее верификации, затем
	- если элемент алгоритма подписи указывает, что использована асимметричная криптография, тогда для идентификации сертификата применяется SignatureCertRef;
	- если элемент алгоритма подписи указывает, что использована симметричная криптография, тогда для идентификации корректного значения общего ключа используется содержимое элемента RecipientInfo;
	- используется специфицированный алгоритм подписи для проверки того, что элемент Value правильно подписывает элемент Manifest;
	- проверется, что элементы Digest в элементе Manifest вычислены правильно. При этом предполагается, что компоненты или блоки, на которые ссылается дайджест, были получены организацией, выполняющей проверку подписи.

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

Далее при объяснении поиска ошибок в последовательностях блоков выражение типа "относится к транзакции 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) ошибка, в противном случае,
		- если блок состояния аутентификации получен для той же самой транзакции раньне, то это предупреждение (а не ошибка).
o	Блок выбора TPO (только для продавца) прооверяется следующим образом:
		- если блок выбора TPO не относится к транзакции IOTP, которая распознана, то это серьезная (Hard) ошибка, в противном случае,
		- если блок выбора TPO не относится к транзакции IOTP, где блок TPO и отклик предложения (в одном сообщении) были посланы ранее, то это серьезная (Hard) ошибка, в противном случае,
		- если блок выбора TPO относится к транзакции IOTP, где только блок TPO (т.e. без отклика на предложение) был послан ранее, то это серьезная (Hard) ошибка, в противном случае,
		- если блок выбора TPO для того же блока TPO получен ранее, то это серьезная (Hard) ошибка.
o	Блок запроса платежа (только для кассира) проверяется следующим способом:
		- если блок запроса платежа относится к транзакции IOTP, которая не распознана, тогда все в порядке, в противном случае
		- если блок запроса платежа относится к транзакции IOTP, которая не связана с платежом, то это серьезная (Hard) ошибка, в противном случае
		- если был предшествующий платеж, который не прошел с кодом завершения недопускющим восстановление, то это серьезная (Hard) ошибка, в противном случае
		- если предыдущий платеж еще в работе, то это серьезная (Hard) ошибка.
o	Блок платежного обмена (только для кассира) проверяется следжующим образом:
		- если блок платежного обмена не относится к транзакции IOTP, которая распознана, то это серьезная (Hard) ошибка, в противном случае
		- если платежный обмен не относится к транзакции IOTP, где такой обмен уже был, то это серьезная ошибка (Hard).
o	Запрос доставки (только для агентов доставки). Если блок запроса доставки относится к транзакции IOTP, которая распознана сервероим, то это серьезная ошибка.

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

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

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

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

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

"Блок запроса" используется в связи с блоком запроса платежа (смотри раздел 8.7) или блоком запроса доставки (смотри раздел 8.10), если не специфицировано обратного;

"Блок отклика" используется в связи с блоком платежного отклика (смотри раздел 8.9) или блоком отклика доставки (смотри раздел 8.11);

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

"Операционная организация" используется в отношении Кассира или Агента доставки, которые реализуют операцию;

"Подписант операции" используется в отношении организации, которая подписаладанные об операции с целью ее авторизации;

"Верификатор операции" используется в отношении организаций, которые верифицируют данные, чтобы определить, авторизованы ли они для выполнения операции;

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

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

Крайне важно проверить, что сообщение имее корректную XML-форму и идентификатор транзакции (IotpTransID-атрибут компонента TransId) в сообщении IOTP может быть распознан, так как IotpTransId будет нужен при формировании отклика. Если входное сообщение сформировано некорректно, тогда генерируется компонент Error с атрибутом Severity равным HardError и код ошибки XmlNotWellFrmd. Если входное сообщение сформировано правильно, но IotpTransId не может быть идентифицировано, генерируется компонент Error с :

o	атрибутом Severity = HardError и кодом ошибки (ErrorCode) = AttMissing,
o	содержимым PackagedContent, включающим в себя "IotpTransId" потерянного атрибута.

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

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

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

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

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

проверку того, что значение каждого атрибута в каждом элементе блока согласуется с правилами спецификации IOTP;

проверку того, что содержимое каждого элемента согласуется с правилами спецификации IOTP;

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

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

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

проверки того, что комбинации блоков и/или компонентов, присутствующих в сообщении IOTP, согласуются с правилами спецификации;

проверки взаимосогласованности атрибутов и содержимого элементов в блоках сообщения IOTP;

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

R- отклик регистрации

Это сообщение предоставляет отклик об успехе или неудаче R1. #####################################################################
Отправитель: CyberServer
Получатель: CyberApp
##################################################################### Пример сообщения:
$$-CyberCash-0.8-$$
transaction: 12312313
date: 19950121100505.nnn
opaque:
r1XfjSQt+KJYUVOGU60r7voFrm55A8fP5DjJZuPzWdPQjGBIu3B6Geya8AlJfHsW11u8
dIv1yQeeYj/+l9TD1dXW21/1cUDFFK++J2gUMVv8mX1Z6Mi4OU8AfsgoCliwSkWmjSOb
kE62sAlZTnw998cKzMFp70TSlI3PEBtvIfpLq5lDCNbWidX8vFZV0ENUmMQ9DTP3du9w
fsFGvz1mvtHLT/Gj8GNQRYKF4xiyx4HYzTkSMhgU5B/QDLPS/SawIJuR86b9X0mwsr0a
gbGTzECPJTiKkrhxxMG/eymptsVQSLqNaTCx6w==
$$-CyberCash-End-kchfiZ5WAUlpk1/v1ogwuQ==-$$
#####################################################################
Скрытый ключ. Тот же самый, что и ключ сессии для R1 в случае той же транзакции и того же соединения (ID может отсутствовать).
#####################################################################
Содержимое скрытой секции:
type: registration-response
server-date: 19950121100506.nnn
requested-id: MyRequestedCCID
response-id: CyberCashHandle
>email: myemail@myemailhost.com
response-code: success/failure/etc.
pubkey:
0VdP1eAUZRrqt3Rlg460Go/TTs4gZYZ+mvI7OlS3l08BVeoms8nELqL1RG1pVYdDrTsX
E5L+wcGCLEo5+XU5zTKkdRUnGRW4ratrqtcte7e94F+4gkCN06GlzM/Hux94
swseverity: fatal/warning [отсутствует, если все в порядке]
swmessage; Говорит CyberApp, что оно является устаревшим. Этот текст отображается для пользователя [присутствует только, если имеется SWSeverity].
message;
Произвольный текст уведомления об успехе или неудаче.
Этот текст должен быть отображен для владельца приложения CyberCash...
В принципе текст включает в себя: duplicate-id (дублированный ID), bad-signature (ошибочная подпись) или ill-formed-registration (некорректная регистрация). Объяснение:

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

R- регистрация

Описание: Это исходное сообщение, посылаемое для формирования новой персоны CyberCash. #########################################################
Отправитель: CyberApp
Получатель: CyberServer
#####################################################################
Пример сообщения: $$-CyberCash-0.8-$$
transaction: 123123213
date: 19950121100505.nnn
cyberkey: CC1001
opaque:
FrYOQrD16lEfrvkrqGWkajM1IZOsLbcouB43A4HzIpV3/EBQM5WzkRJGzYPM1r3noBUc
MJ4zvpG0xlroY1de6DccwO9j/0aAZgDi9bcQWV4PFLjsN604j3qxWdYn9evIGQGbqGjF
vn1qI1Ckrz/4/eT1oRkBBILbrWsuwTltFd84plvTy+bo5WE3WnhVKsCUJAlkKpXMaX73
JRPoOEVQ3YEmhmD8itutafqvC90atX7ErkfUGDNqcB9iViRQ7HSvGDnKwaihRyfirkgN
+lhOg6xSEw2AmYlNiFL5d/Us9eNG8cZM5peTow==
$$-CyberCash-End-kchfiZ5WAUlpk1/v1ogwuQ==-$$
#####################################################################
Скрытый ключ: Сгенерирован с использованием общедоступного ключа CyberCash, идентифицированного в CyberKey.
#####################################################################
Содержимое скрытой секции:
type: registration
swversion: 0.8win
content-language: en-us
requested-id: MyRequestedCCID
email: myemail@myemailhost.com
pubkey:
0VdP1eAUZRrqt3Rlg460Go/TTs4gZYZ+mvI7OlS3l08BVeoms8nELqL1RG1pVYdDrTsX
E5L+wcGCLEo5+XU5zTKkdRUnGRW4ratrqtcte7e94F+4gkCN06GlzM/Hux94
signature:
v6JGmxIwRiB6iXUK7XAIiHZRQsZwkbLV0L0OpVEvan9l59hVJ3nia/cZc/r5arkLIYEU
dw6Uj/R4Z7ZdqO/fZZHldpd9+XPaqNHw/y8Arih6VbwrO5pKerLQfuuPbIom
#####################################################################
подпись покрывает следующие поля: transaction, date, cyberkey, type, swversion, content-language, requested-id, email, pubkey
#####################################################################
Объяснение:
content-language (язык содержимого) берется из поля заголовка MIME (смотри RFC-1766) и соответствует языку, на котором должно быть написано сообщение (в настоящее время допустимо пока только en-us). swversion используется для проверки, не является ли приложение клиента устаревшим.

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

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

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

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

Работа с кредитной картой

При использовании системы CyberCash для транзакций с применением кредитной карточки, покупателю, решившему произвести покупку, достаточно кликнуть на клавише CyberCash "PAY" панели продавца. Продавец посылает покупателю счет, который содержит информацию о покупке, отображаемую на экране дисплея покупателя. (Смотри описание сообщения PR1). Покупатель добавляет номер своей кредитной карточки и другую информацию путем выбора соответствующих пунктов из списка кредитных карт, зарегистрированных на его CyberCash-персону. Вся эта информация снабжается электронной подписью покупателя, реализуемой посредством программы СyberCash, шифруется, и передается продавцу вместе с хэш-кодом счета. (Смотри описание сообщения CH1.) При получении этого сообщения, продавец добавляет туда информацию авторизации, которая шифруется, снабжается электронной подписью продавца и пересылается серверу CyberCash. (Смотри описание сообщений CM1 & CM2). Сервер CyberCash может аутентифицировать все подписи для подтверждения того, что покупатель и продавец согласились с корректностью счета и правильностью суммы стоимости сделки. Сервер CyberCash переадресует соответствующую информацию в банк, сопровождая ее запросом на производство платежа в пользу продавца, включая его авторизацию. Банк дешифрует и обрабатывает полученную информацию, после чего осуществляет соответствующую операцию с кредитной карточкой. Отклик банка передается серверу CyberCash, который присылает продавцу электронную квитанцию (смотри описание сообщения CM6) часть которой продавец переадресует покупателю (смотри описание сообщения CH2). На этом транзакция завершается.

Расширение IOTP

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

Размер Logo

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

Размер в пикселях	Размер логотипа значение
32 x 32 или 32 x 20	exsmall (сверх малый)
53 x 33	small (малый)
103 x 65	medium (средний)
180 x 114	large (большой)
263 x 166	exlarge (сверх большой)

Регистрация персоны и нахождение приложения

Первым шагом, который должен сделать клиент, чтобы использовать CyberCash, является регистрация персоны с помощью своего приложения. Это делается с помощью сообщения R1, описанного ниже. Сервер CyberCash откликается сообщением R2. Когда приложение покупателя узнает, что оно устарело, оно может воспользоваться запросом GA1, посылаемым серверу, и получить в отклике GA2 подписанную версию самого себя.

SET и другие системы осуществления платежей

Семёнов Ю.А. (ГНЦ ИТЭФ), book.itep.ru Идеальная платежная система должна отвечать следующим требованиям:

Безопасность системы должна препятствовать воровству денег на всех этапах выполнения операции.

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

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

Схема и реализация должны быть простыми (не нужно использовать сложных протоколов)

Система должна быть открытой (протоколы и тесты программ должны быть общедоступны).

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

Должна предоставлять достаточное количество данных для целей аудита.

Система должна быть свободной, то есть не иметь ограничений владельца. Ни одна из существующих платежных систем не отвечает всем этим требованиям в полной мере. Существует много платежных схем, например: А. Электронные монеты
Б. Электронные чеки
В. Электронные переводы (трансферты) Разумеется, могут существовать и методы, сочетающие в себе любые комбинации этих схем. Эти методы должны работать не только с традиционными деньгами, но с их заменителями, акциями, облигациями, золотыми слитками, товарами и услугами. Во всех моделях помимо основных участников - продавца и покупателя, необходим посредник. Назовем его банкиром (кассиром). Теперь рассмотрим названные выше платежные модели более подробно. Модель электронных монет Эта схема моделирует традиционную денежную систему. Банкир формирует цифровые сертификаты, называемые монетами, и приобретаемые участниками сделок. Эти сертификаты могут быть банкиром выкуплены. Клиенты используют эти сертификаты (монеты) для расчетов как обычные деньги. Эту модель достаточно трудно реализовать из-за проблемы повторного использования сертификатов для покупок. Есть у этой модели и преимущества, например, плательщик не должен иметь контакт с банкиром в реальном масштабе времени в момент платежа, да и уровень конфиденциальности здесь вполне приемлем. Модель электронных чеков Данная модель с хорошей точностью воспроизводит практику применения обычных чеков.
Клиент заполняет электронный чек, который представляет собой платежное поручение. Этот чек подписывается электронным образом и передается партнеру (например, продавцу), который предъявляет его банкиру. Банкир проверяет корректность чека, наличие необходимых средств на счете клиента, заполнившего чек, и, если все в порядке, переводит средства на счет продавца. Преимуществом этой модели является простота, легкость разрешения любых споров, а также отсутствие требование выполнения всех операций в реальном масштабе времени. Уровень конфиденциальности здесь также вполне разумен. Модель электронных переводов Данная модель простейшая из описанных. Плательщик выдает платежное поручение банкиру, снабжая его электронной подписью. Банкир верифицирует платежное поручение, проверяет наличие средств и, если все в порядке, осуществляет перевод денег. Операция со стороны плательщика выполняется в реальном масштабе времени. Эта модель прозрачна, получатель перевода не должен быть доступен в реальном масштабе времени. Схема хороша для начисления зарплаты, но совершенно не приемлема для торговли через Интернет. Теперь рассмотрим требования к безопасности платежной системы. В случае работы через Интернет эти требования должны быть достаточно жестки, так как сами транспортные протоколы TCP/IP практически не предоставляют сколько-нибудь существенной защиты.

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

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

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

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

Это позволит ему отвести обвинения в осуществлении неавторизованных платежных операций.

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

Система должна противостоять фальсификации расписок банкира.

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

Конфликты между клиентами должны разрешаться без участия банкира.

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

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

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

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

Severity = Hard Error

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

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

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

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

	- сформироать сообщение с компонентом Error и атрибутом Severity = Warning, после чего послать его со следующим сообщением (если такое имеется) торговой роли, которая прислала сообщение об ошибке с неверным значением MinRetrySecs и
	- использовать величину MinRetrySecs, установленное поставщиком/ разработчиком приложения IOTP.

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

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

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

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

разработчик приложения IOTP должен:

	- продолжеть транзакцию как обычно или
	- прервать транзакцию, выработав сообщение с компонентом Error и атрибутом Severity = HardError (смотри раздел 7.21.1.3).

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

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

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

Скрытая часть

Скрытая часть сообщения состоит из одного блока символов, представленных в кодировке base64 (смотри RFC-1521). Данные в закрытой секции всегда сначала шифруются, а затем кодируются. Скрытая часть сообщения выделяется метками "opaque" или "merchant-opaque" в зависимости оттого, клиент или продавец зашифровал эти данные. Для сообщений, приходящих на сервер, скрытые данные шифруются согласно алгоритму DES CBC с помощью случайного ключа транзакции, при этом ключ DES шифруется посредством алгоритма RSA с привлечением одного из общедоступных ключей сервера. Зашифрованный с помощью RSA ключ DES размещается в первой части поля, закодированного с помощью base64. Соответствующий исходящий отклик сервера может быть зашифрован с помощью DES с применением ключа транзакции. В этом случае достаточно открытых данных, чтобы идентифицировать транзакцию, а покупатель и продавец имеют ключ транзакции, полученный вместе с входным сообщением. Подпись необязательна в скрытой части сообщения отклика. Знание ключа транзакции является достаточным для аутентификации. Для формирования отклика необходимо знать секретный ключ сервера, чтобы заполучить ключ транзакции. Предполагается, что если кто-то исказил скрытую часть отклика, вероятность того, что это будет незамечено пренебрежимо мала. Кто-то может повредить открытую часть сообщения, но это не окажет никакого воздействие, так как все сообщение будет просто отвергнуто.

Словарь

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

Имя	Описание
Аутентификатор	Организация, которая запрашивает аутентификацию другой организации
Аутентифицируемый	Организация, которая осуществляет аутентификацию у аутентификатора
Рабочая ошибка (Business Error)	Смотри компонент Status.
Вид платежа (Brand)	Вид платежа представляет собой идентификатор определенного типа платежного инструмента. Список видов платежа явлется перечнем платежных опций, которые предоставляются продавцом покупателю и из которого последний выбирает вид оплаты. Каждый вид платежа может иметь разных кассиров. Примеры видов платежей включают в себя:о частные и корпоративные виды платежей, например MasterCard, Visa, American Express, Diners Club, American Express, Mondex, GeldKarte, CyberCash, и т.д.. вльготные виды платежа (смотри ниже). Последние включают в себя:o магазинные виды платежа, где платежный инструмент предоставляется покупателю конкретным продавцом, например Walmart, Sears или Marks and Spencer (UK)o комбинированные виды платежа, например American Advantage Visa, где компания использует свою собственную системы о платы, которая совмещается с каким-то корпоративным видом платежей.
Покупатель	Организация, которая обычно платит за товары или услуги.
ContentSoftwareId	Содержит информацию, которая идентифицирует программу, генерирующую содержимое элемента. Ее целью является помощь в разрешении проблем совместимости, которые могут возникнуть в результате несоответствия между сообщениями, выработанными различными программами. Это текстовая строка на языке, определенном xml:lang. Этот идентификатор должен содержать как минимум: наименования разработчика программы название программы версию программы и структуру программыРекомендуется, чтобы этот атрибут включался всякий раз, когда программа, которая сформировала содержимое, не может быть идентифицирована атрибутом SoftwareID Id-компонента сообщения (смотри раздел 3.3.2)
Агент обслуживания		Организация, которая обслуживает покупателя, обычно от имени продавца. Примеры обслуживания покупателя включают в себя, реагирование на задачи, которые ставит покупатель в ходе реализации транзакций IOTP, в которых он участвует.
Агент доставки		Организация, которая непосредственно доставляет товары или услуги покупателю от имени продавца. Доставка может иметь цифровую форму (напр., в виде сообщений [MIME]), или физическую форму с привлечением почты или курьеров.
Документальный обмен		Документальный обмен состоит из последовательности сообщений, которыми обмениваются партнеры в рамках одного или двух торговых операций одновременно. Документальные обмены могут комбинироваться, образуя конкретную транзакцию IOTP.
Двойственный вид платежа (Dual Brand)		Двойственный вид платежа означает, что один платежный инструмент может использоваться так, как будто имеются два независимых вида платежа. Например, японская карта "UC" MasterCard может быть использована как UC-карта или как обычная MasterCard. Платежи с помощью UC-карты и MasterCard могут иметь разных Кассиров. Это означает, что:o Продавец рассматривает, например "UC" и "MasterCard" как два независимых вида платежа, когда предлагает Покупателю список видов платежей, Покупатель выбирает вид платежа, например "UC" или "MasterCard,o Приложение IOTP Покупателя определяет, какой платежный инструмент подходит для выбранного вида платежа, и делает свой выбор.
Блок Error		Блок Error сообщает, что в полученном сообщении IOTP обнаружена техническая ошибка. Обычно технические ошибки вызываются ошибками в XML или сбоями в процессе обработки сообщения. Часто генерация или получение блока Error вызывает прерывание транзакции. Эти ошибки отличаются от рабочих ошибок (Business Error), о которых сообщается в компонентах Status. Последние ошибки также могут привести к срыву выполнения транзакции.
Блок Exchange		Блок Exchange посылается при торговом обмене от одной торговой роли к другой. Он содержит один или более торговых компонентов. Блоки Exchange при торговом обмене всегда посылаются после блоков Request и до блока Response (отклика). Соджержимое блока Exchange зависит от типа торгового обмена.
Сообщение IOTP		Сообщение IOTP является самой внешней структурой, в которую помещаются документы, которыми обмениваются торговые роли, принимающие участие в сделке. Это хорошо сформатированный XML-документ. Документы, которые содержат сообщение, состоят из:o блок ссылок транзакции, служащий для однозначной идентификации, частью которой является сообщение IOTP;o опционный блок Signature, который служит для цифровой подписи торговых блоков или компонентов, связанных с транзакцией IOTP;o опционный блок Error для уведомления о технических ошибках, содержащихся в предыдущем полученном сообщении IOTP иo последовательность торговых блоков IOTP, которые несут данные, необходимые для выполнения транзакции.
Транзакция IOTP		Транзакция IOTP (Internet Open Trading Protocol) представляет собой набор IOTP-сообщений, передаваемых торговыми ролями. Правила о том, что могут содержать IOTP-сообщения, определяются типом транзакции.
Тип транзакции IOTP		Тип транзакции идентифицирует ее разновидность. Примерами транзакции могут служить: покупка, возврат денег, аутентификация, отзыв, депозит. Типы транзакции IOTP определяет:o торговые обмены, которые могут включаться в транзакцию;o то, как эти торговые обмены могут комбинироваться, чтобы обеспечить достижение цели транзакции;o какие торговые блоки могут быть включены в IOTP-сообщения, образующие транзакцию.
Продавец		Организация, которая предоставляет товары или услуги, и получает выгоду от платежей за них
Агент обслуживания Покупателя		Организация, которая вовлекается в диалог с покупателем от имени продавца с целью разрешения возникающих проблем
Организация		Компания или частное лицо, которое принимает участие в сделке и выполняет определенную торговую роль. Организации могут выполнять и несколько торговых ролей в одной сделке
Кассир		Организация, которая физически получает платеж от покупателя для продавца
Платежный инструмент		Платежный инструмент представляет собой средство, с помощью которого покупатель платит за товары или услуги, предлагаемые продавцом. Это может быть, например: кредитная карта, такая как MasterCard или Visa; > дебетная карта, такая как MasterCard's Maestro; смарт-карта, базирующаяся на электронном платежном инструменте, таком как Mondex, GeldKarte или Visa Cash электронный платежный счет, базирующийся на программе, такой как CyberCash's CyberCoin или DigiCash.Все платежные инструменты имеют номер, обычно это номер счета, с помощью которого платежный инструмент может быть идентифицирован.
Льготный вид платежа		Льготный вид платежа предполагает, что, если покупатель воспользуется этим видом оплаты, тогда он получит дополнительную выгду, которая может быть реализована двумя путями: в момент покупкиse. Например, если покупатель платит с помощью "Walmart MasterCard" на WEB-сайте Walmart, тогда он получает скидку 5%, а это означает, что покупатель в действительности заплатит меньше, от эмитента платежного инструмента (карты), когда платеж появится в ведомости. Например, если сумма платежей с использованием данного платежного инструмента превысила некоторое значение.В списке видов платежа, предлагаемом продавцом, каждый льготный вид должен идентифицироваться, как независимый.
Компонент Receipt (расписка)		Компонент Receipt является записью об успешном завершении торгового обмена. Примеры компонентов Receipt включают в себя: платежные расписки и накладные при доставке (Delivery Notes). Их содержимое зависит от технологии выполнения торгового обмена. Например, платежная расписка SET (Secure Electronic Transaction) состоит из платежных сообщений SET, которые фиксируют результат оплаты.
Блок запроса		Блок запроса является торговым блоком, который содержит запрос начала торгового обмена. Торговые компоненты в блоке запроса могут быть подписаны с помощью блока Signature, что позволит идентифицировать отправителя. Авторизация начала торгового обмена может быть выполнена с помощью подписей, содержащихся в компонентах Receipt, которые вложены в блоки откликов предыдущего торгового обмена. Примерами блоков запроса могут служить запросы платежа и запросы доставки
Блок отклика		Блок отклика является торговым блоком, который указывает, что торговый обмен завершился. Он посылается торговой ролью, которая получила блок запроса, торговой роли. Блок отклика содержит компонент Status с информацией о завершении торгового обмена, например, он указывает, завершился ли торговый обмен успешно. Для некоторых торговых обменов блок отклика содержит компонент Receipt (расписка). Компоненты Receipt могут цифровым образом подписывать сообщение с использованием блока Signature, что делает завершение торгового обмена неопровержимым. Примеры блоков отклика включают в себя отклики предложения, платежа и доставки.
Блок подписи		Блок подписи является торговым блоком, который содержит одну или более цифровых подписей в виде компонентов Signature. Компонент Signature может цифровым образом подписывать любой блок или компонент в любом сообщении IOTP
Компонент Status		Компонент Status содержит информацию, которая описывает состояние торгового обмена. До завершения торгового обмена компонент Status может указывать на то, как он проходит. Если же торговый обмен завершился, компонент Status может говорить лишь об успешном завершении или о наличии рабочей ошибки. Рабочая ошибка указывает, что продолжение торгового обмена невозможно, так как нарушено какое-то правило, например, "нет достаточных средств". При этом не предполагается каких-либо технических ошибок, связанных с содержимым или форматом IOTP-сообщения в транзакции.
Техническая ошибка		Смотри блок Error.
Торговый блок		Торговый блок состоит из одного или более торговых компронент. Один или более торговых блоков может содержаться в IOTP-сообщениях, которые пересылаются в форме XML-документов от одной торговой роли к другой. Сущетсвует три типа торговых блоков:o блок Request, o блок Exchange или o блок Response
Торговый компонент		Торговый компонент является собранием XML-элементов и атрибутов. Торговые компоненты являются дочерними элементами Торговых блоков. Примерами торговых компонентов являются: Предложение, Список видов платежей, Платежная расписка, Доставка [информации], Сумма платежа
Торговый обмен		Торговый обмен предполагает обмен последовательностью документов, пересылаемых между торговыми ролями. Документы могут иметь форму торговых блоков или они могут быть пересланы каким-то другим образом, например, путем ввода данных на WEB-странице. Каждый торговый обмен состоит из трех главных частей: посылки блока запроса торговой ролью (инициатором) другой торговой роли (получателю); опционного обмена одним или более блоков между инициатором и получателем до тех пор, пока торговая роль, которая получила блок запроса, не отправит блок отклика инициатору. Примерами торговых обменов/услуг могут служить: платеж, где покупатель осуществляет платеж кассиру; доставка, где покупатель запрашивает, и опционно получает, товар или услугу от агента доставки; аутентификация, где любая торговая роль может запросить и получить информацию о другой торговой роли; предложение, которое получает покупатель от продавца, имеет целью предложить какую-то торговую сделку (транзакцию).
Торговая роль		Торговая роль идентифицирует различные способы, которыми организации могут участвовать в сделке. Существует пять торговых ролей: Покупатель, Продавец, Кассир, Агент доставки и Агент обслуживания покупателя.
Блок ссылок транзакции		Блок ссылок транзакции идентифицирует транзакцию IOTP. Он содержит данные, которые идентифицируют: тип транзакции; транзакцию IOTP, снабжая ее уникальным идентификатором; сообщение IOTP, снабжая его уникальным идентификатором.Блок ссылок транзакции может также содержать ссылки на другие транзакции, которые, вообще говоря, могут и не быть транзакциями IOTP

Смарт-карты EMV

Семёнов Ю.А. (ГНЦ ИТЭФ), book.itep.ru В основу данной спецификации легли разработки компаний Europay, MasterCard и Visa (EMV) в марте, 1998 года. Следует принимать во внимание, что данная технология будет использоваться не только для финансовых операций. Планируется ее применения для проездных билетов и контроля доступа к ЭВМ. В перспективе можно предположить, что эта техника будет использоваться для идентификации личности, например, вместо паспорта.

IEC 512-2:1979	Спецификации для электромеханических компонентов оборудования - Часть 2: Тесты сопротивления контактов, тесты проверки изоляции и перегрузок
FIPS Pub 180-1:1995	Стандарт на безопасные хэши. Спецификация терминала платежных систем для карт с интегральными схемами
ISO 639:1988	Коды названий языков
ISO 3166:1997	Коды названий стран
ISO 4217:1995	Коды валют и фондов
ISO/IEC 7811-1:1995	Идентификационные карты - Метод записи - Часть 1: Тиснение
ISO/IEC 7811-3:1995	Идентификационные карты - Метод записи - Часть 3: Положение вытисненных символов на картах ID-1
ISO/IEC 7813:1995	Идентификационные карты - Карты для финансовых операций
ISO/IEC DIS 7816-1:1998	Идентификационные карты - Карты с интегральными схемами, имеющими внешние контакты.
	Часть 1:	Физические характеристики ISO/IEC DIS 7816-2:1998
	Часть 2:	Размеры и положение контактов
ISO/IEC 7816-3:1989	Часть 3:	Электрические сигналы и протоколы передачи
ISO/IEC 7816-3:1992	Часть 3:	Протокол типа T=1, асинхронный полудуплексный протокол блочной передачи
ISO/IEC 7816-3:1994	Часть 3:	Выбор типа протокола
ISO/IEC 7816-4:1995	Часть 4:	Команды обмена
ISO/IEC 7816-5:1994	Часть 5:	Процедура для выработки прикладных идентификаторов
ISO/IEC 7816-6:1996	Часть 6:	Информационные элементы
ISO 8731-1:1987	Часть 1:	Алгоритмы аутентификации сообщений (DEA)
ISO 8372:1987	Обработка информации. Режимы работы для 64-битовых блочных алгоритмов шифрования/дешифрования
ISO/IEC 8825:1990	Информационная технология. Соединение открытых систем. Спецификация базовых правил кодирования для синтаксической нотации ASN.1
ISO 8583:1987	Сообщения банковских карт - Спецификации сообщений - Содержимое финансовых транзакций
ISO 8583:1993	Сообщения транзакций банковских карт - Спецификации сообщений
ISO 8859:1987	Обработка сообщений - 8-битовые графические символьные наборы
ISO/IEC 9796-2: 1997	Информационная технология - Методы безопасности - Схема восстановления сообщений с цифровой подписью. Часть 2: Механизм использования хэш-функций
ISO/IEC 9797:1994	Информационная технология - Методы безопасности - Механизм информационной целостности, использующий функцию криптографической проверки на базе алгоритма блочного шифра
ISO/IEC 10116: 1997	Информационная технология - режимы работы алгоритмов n-битовых блочных шифров
ISO/IEC 10118-3: 1998	Информационная технология - Методы безопасности - хэш-функции

Рис. 4.6.4.1. Расположение контактов на лицевой стороне карты

Рис. 4.6.4.2. Положение контактов (все контакты имеют размер 1,7х2,0 мм) Всего на карте 8 контактов. На рис. 4.6.4.1 обязательные контакты представлены закрашенными прямоугольниками. Контакты C4 и С8 не используются и могут отсутствовать, контакт же С6 используется для программирования на фазе изготовления. Сопротивление для этого контакта по отношению к любым другим контактом должно превышать 10 Мом при напряжении 5 В. Таблица 4.6.4.1.

Контакт	Назначение	Контакт	Назначение
С1	VCC - напряжение питания	С5	GND - земля
С2	RST - сброс	С6	Не используется
С3	CLK - тактовые импульсы	С7	Вход/Выход (I/O)

VCC - напряжение питания 5 ± 0,5В при токе 50 мА при любых частотах работы микросхемы. В таблице 4.6.4.2 представлены параметры входных информационных сигналов VIH- Высокий уровень входного сигнала
VIL- Низкий уровень входного сигнала
VOH- Высокий уровень выходного сигнала
VOL- Низкий уровень выходного сигнала
tR- Время нарастания сигнала
tF- Время спада сигнала Таблица 4.6.4.2

	Минимум	Максимум
VIH	0,7xVcc	Vcc
VIL	0	0,8 В
tR и tF	-	1,0 мксек

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

	Условия	Минимум	Максимум
VOH	-20мкА	0,7xVcc	Vcc
VOL	0< IOL < 1мА, Vcc = min	0	0,4 В
tR и tF	C IN(терминала) =30пФ макс	-	1,0 мксек

В таблице 4.6.4.4 перечислены требования на параметры тактовых импульсов. ICC может работать корректно при скважности тактовых импульсов в диапазоне (44-56)% и значении тактовой частоты от 1 до 5 МГц. Таблица 4.6.4.4

	Минимум	Максимум
VIH	Vcc-0,7В	Vcc
VIL	0	0,5 В
tR и tF	-	9% тактового периода

В таблице 5 представлены характеристики сигнала сброса (RST). Таблица 4.6.4.5

	Минимум	Максимум
VIH	Vcc-0,7В	Vcc
VIL	0	0,6 В
tR и tF	-	1,0 мксек

ICC выдерживает уровни сигнала на шине RST от -0,3В до Vcc+0,3В. ICC откликается на сигнал сброса асинхронно.

Микросхема может также противостоять импульсам тока через цепь питания до 100 мА длительностью 400 нсек и с интегральным зарядом 40 нАсек. Любая транзакция для карты начинается с ее вставления в интерфейсное устройство IFD (Interface Device) и активации контактов карты. Далее следует сброс микросхемы ICC в исходное состояние и установление связи между ICC и IFD. Только после этого начинает реализовываться конкретная транзакция. Любая транзакция завершается дезактивацией контактов и удалением ICC из интерфейсного устройства. После вставления карты в IFD терминал проверяет, что все сигнальные контакты находятся в состоянии L (низкий логический уровень - VOL). IFD контролирует корректность положения ICC с точностью ±0,5мм. Если карта позиционирована правильно, производится активация контактов в соответствии с порядком, представленном на рис. 4.6.4.3.

Рис. 4.6.4.3. Последовательность активации контактов ICC Через некоторое время после подачи на ICC напряжения питания Vcc начинают поступать тактовые импульсы. В исходный момент времени (сразу после вставления карты уровень сигналов на шине I/O является низким (L). Далее уровень этой шины может быть неопределенным (обозначено на рисунке серым прямоугольником), но после прихода 200 тактов этот уровень становится высоким (H). При этом уровень на шине RST остается низким (L). Терминал IFD устанавливает свой драйвер I/O в режим приема не позднее поступления 200-го такта. После этого выполняется процедура сброса (Reset). ICC откликается на команду RESET асинхронно. Время, когда на ICC начинают поступать тактовые импульсы, называется T0. Терминал поддерживает в это время уровень шины RST в низком состоянии.

Рис. 4.6.4.4. Диаграмма реализации "холодного" сброса После прихода 40000-45000 тактов после Т0 шина RST переходит в состояние H. Этот момент времени называется T1. Начало отклика на Reset со стороны ICC наступает спустя 400-40000 тактов после T1 (время t1). Если за это время отклик со стороны ICC не поступает, терминал в пределах 50 мсек деактивирует контакты микросхемы на карте.

Диаграмма холодного сброса ICC показана на рис. 4.6.4.4. Команда сброса может поступать и в процессе обычной работы - так называемый "теплый" сброс. Временная диаграмма такого сброса показана на рис. 4.6.4.5.

Рис. 4.6.4.5. Временная диаграмма "теплого" сброса Следует учитывать, что при теплом сбросе напряжение питание Vcc имеет рабочий уровень, шина RST имеет уровень H, состояние шины I/O может быть любым. После перехода шины RST в состояние L (момент времени T0') на шине I/O не позднее чем через 200 тактов должен установиться уровень H. В момент Т1' шина RST переходит в состояние H, после чего завершается процедура сброса аналогично "холодному" варианту. Процедура деактивации контактов ICC показана на рис. 4.6.4.6. В момент начала этой процедуры напряжение питание Vcc имеет рабочий уровень, шина RST имеет уровень H, состояние шины I/O может быть любым. Сигналом к началу процесса является переход шины RST в низкое состояние. Через некоторое время состояние шины I/O должно стать низким, прекращается подача тактовых импульсов, после чего с небольшой задержкой напряжение питания Vcc становится равным нулю и процедура в пределах 100 мсек завершается. При гальваническом отключении контактов Vcc должно быть не более 0,4 В. По завершении процедуры карта может быть извлечена из интерфейсного устройства.

Рис. 4.6.4.6. Временная диаграмма дезактивации контактов ICC Исходная длительность такта на шине I/O определяется как: t = 372/f секунд, где f частота в Гц. В общем случае t определяется как: t = F/(Df), где f частота в Гц, F и D параметры, которые могут варьироваться, но обычно F=372, а D=1. f лежит в пределах (1-5) МГц.

Рис. 4.6.4.7. Диаграмма передачи символов по шине I/O Перед началом передачи символа шина I/O должна находиться в состоянии H. Для передачи любого символа требуется 10 бит (смотри рисунок 4.6.4.7). Стартовый бит должен иметь уровень L и номер 1. Последний бит представляет собой бит четности (нечет). Стартовый бит детектируется путем стробирования шины I/O.

Время стробирования составляет 0, 2 t. Время между началами передачи последовательных символов составляет t(10±0,2) плюс время выдержки. Во время выдержки ICC и терминал должны находиться в режиме приема. (H). Определены два протокола: символьный (Т=0) и блочный (Т=1). ICC поддерживает один из этих протоколов, терминалы поддерживают оба. Тип протокола определяется значением символа TD1. При отсутствии в ATR TD1 рабочим считается протокол Т=0. Физический уровень обмена должен согласовываться с обоими протоколами. Минимальный интервал между лидирующими битами двух последовательных символов, посылаемых ICC, равно 12t. Максимальный интервал между стартовыми битами двух последовательных символов (Work Waiting Time) не должно превышать (960хDxWI) t (параметры D и WI пересылаются с помощью символов TA1 и TC2, соответственно). Если это время будет превышено, терминал не позднее, чем спустя 960t должен начать процесс дезактивации. В режиме T=0, если ICC или терминал детектировали при передаче/приеме символа ошибку четности, шина I/O переводится в состояние L, чтобы передающая сторона узнала об ошибке. На транспортном уровне терминала TTL (Terminal Transport Layer) данные всегда передаются через шину I/O так, что старший байт следует первым. Будет ли первым старший бит, определяется символом TS, возвращаемым в ответ на команду сброс ATR. Такой отклик может содержать строку символов. При отклике на сброс минимальное время между стартовыми битами последовательных символов составляет 9600t. ICC передает все символы отклика в пределах 19200 t. Это время измеряется между стартовым битом первого символа TS и после 12 t от начала последнего символа. Число символов в отклике зависит от транспортного протокола и поддерживаемых управляющих параметров. ICC может опционно поддерживать более одного транспортного протокола, но одним из таких протоколов должен быть Т=0 или Т1. Символы, присылаемые в рамках ATR, представлены в таблице 4.6.4.6. Таблица 4.6.4.6. Базовый ATR для T=0

Символ	Значение	Примечания
TS	3B или 3F	Указывает на прямую или инверсную схему передачи бит
T0	6x	Присутствуют TB1 и TC1; х обозначает число исторических байтов
TB1	00	VPP не требуется
TC1	00 - FF	Указывает на необходимость дополнительного времени выдержки. FF имеет специальное назначение.

Если поддерживается только протокол типа T=1 (блочный асинхронный транспортный протокол), то используемые символы отклика ATR содержатся в таблице 4.6.4.7. Следует иметь в виду, что ICC может поддерживать более одного транспортного протокола. Таблица 4.6.4.7. Базовый ATR для T=1

Символ	Значение	Примечания
TS	3B или 3F	Указывает на прямую или инверсную схему
T0	Ex	Присутствуют TB1 - TD1; х обозначает число исторических байтов
TB1	00	VPP не требуется
TC1	00 - FF	Указывает на необходимость дополнительного времени выдержки. FF имеет специальное назначение.
TD1	81	TA2 - TC2 отсутствуют; TD2 присутствует; должен работать протокол T=1
TD2	31	TA3 и TB2 присутствуют; TC3 и TD3 отсутствуют; должен работать протокол T=1
TA3	10 - FE	Возвращает IFSI, что указывает на начальное значение размера информационного поля для ICC и IFSC равное 16-254 байтам
TB3	Старший полубайт =0-4 Младший полубайт =0-5	BWI = 0-4 CWI = 0-5
TCK		Контрольный символ

Интерфейсы могут поддерживать отклики, не описанные в данной спецификации. Максимальное число символов в отклике, включая TS, не должно превышать 32. TS служит для синхронизации терминала и для определения логической схемы интерпретации последующих символов. Инверсная логическая схема предполагает, что логической единице на шине I/O соответствует уровень L, а старший бит данных передается первым. Прямая схема предполагает, что логической единице на шине I/O соответствует уровень H, а первым передается младший бит. Первые четыре бита LHHL используются для синхронизации. ICC может прислать ATR, содержащий TS, который имеет одно из следующих значений:
(H)LHHLLLLLLH - инверсная схема, значение 3F.
(H)LHHLHHHLLH - прямая схема, значение 3B
Последний бит этих кодов Н является битом четности (смотри рис. 4.6.4.7). T0 - символ формата. Старший полубайт (b5-b8) используется для определения того, присутствуют ли последующие символы TA1-TD1. Если биты b5-b8 установлены в состояние логической единицы, TA1-TD1 присутствуют. Младший полубайт (b1-b4) содержит число опционных исторических байтов (0-15).

Смотри таблицу 4.6.4.8. Таблица 4.6.4.8

	b8	b7	b6	b5	b4	b3	b2	b1
Только Т=0	0	1	1	0	X	X	X	X
Только Т=1	1	1	1	0	X	X	X	X

Символы интерфейса TA1- TC3 передают информацию, которая используется при обмене между терминалом и ICC. Они определяют значения параметров F, D, I, P и N, а также IFSC, BWI (Block Waiting time Integer) и CWI (Character Waiting time Integer). Информация, содержащаяся в TA1, TB1, TC1, TA2 и TB2 будут применяться для всех последующих обменов вне зависимости от используемого протокола. TA1 служит для передачи значений FI и DI, где FI используется для задания значения F (параметр, определяющий тактовую частоту). DI служит для задания значения D, используемого для настройки частоты следования бит. По умолчанию FI=1 и DI=1, что означает F=372, а D=1. Если ТА1 присутствует в ATR (b5 в T0 равен 1) и TA2 прислан с b5=0, то терминал воспринимает ATR, если TA1=11, и немедленно реализует указанные F и D. ТВ1 несет в себе значения PI1 и II, где PI1 специфицировано в битах b1-b5 и используется для программирования значения напряжения P, необходимого ICC. PI0=0 означает, что VPP не подключено к ICC. II специфицируется в битах b6 и b7 и служит для определения максимального тока, потребляемого ICC. Этот параметр не используется, если PI1 = 0. TC1 несет в себе величину N, которая используется для задания дополнительной выдержки (guardtime) между символами. Это время будет добавлено к минимальной выдержке. N может принимать значения 0-255 t. TD1 указывает, должны ли быть переданы еще интерфейсные байты, и содержит информацию о типе протокола. Старший полубайт используется для индикации наличия символов TA2 - TD2. Биты b5-b8 принимают значение логической единицы, если указанные выше символы присутствуют. Младший полубайт указывает протокол, который будет использован для последующих обменов. ATR не содержит TD1, если используется только Т=0. Для T=1 TD1=81 указывает на наличие TD2. Наличие или отсутствие TA2 говорит о работе ICC в специфическом или согласованном режиме, соответственно.

Базовый отклик ATR не содержит ТА2. ТВ2 передает PI2, который используется для определения величины программируемого напряжения Р, необходимого ICC. Если этот символ присутствует, значение, указанное в PI1 (ТВ1), заменяется на новое. По умолчанию ТВ2 отсутствует. ТС2 специфичен для протокола типа Т=0 и несет в себе значение WI (Waiting time Integer), которое используется для определения максимального интервала между началом передачи любого символа, посланного ICC, и началом предыдущего символа, поступившего от ICC или терминала. Время выдержки вычисляется по формуле 960xDxWI. По умолчанию ТС2 отсутствует, а WI=10. Терминал воспринимает ATR, содержащий ТС2=0А. Он отвергает ATR, несущий в себе ТС2=00 или ТС2>0А. TD2 указывает, будут ли еще переданы какие-либо интерфейсные байты, а также определяет тип протокола, используемого далее. Старший полубайт используется для указания наличия символов ТА3 - TD3. Биты b5-b8 устанавливаются в единичное состояние при наличии ТА3 - TD3. Младший полубайт указывает тип протокола, применяемый в последующих обменах. При Т=1 он равняется 1. По умолчанию при Т=0 ATR не содержит TD2, в противном случае ATR содержит TD2=31 (T=1). ТА3 несет в себе информацию о размере поля данных для ICC (IFSI) и специфицирует длину информационного поля INF блоков, которые могут быть получены картой. Этот символ характеризует длину IFSC в байтах и может содержать коды в интервале 0х01-0хFE. Значения 0х00 и 0хFF зарезервированы на будущее. По умолчанию ATR содержит ТА3 со значение в диапазоне 0х10-0хFE, если Т=1, IFSC лежит в интервале 16-254 байта. Если ТА3 содержит недопустимый код, ATR терминалом отвергается. ТВ3 характеризует значения CWI и BWI, используемые для вычисления CWT и BWT, соответственно. ТВ3 имеет две части. Младший полубайт (b1-b4) используется для определения значения CWI, а старший полубайт (b5-b8) - BWI. По умолчанию ATR несет в себе ТВ3, при этом младший полубайт содержит код 0-5, а старший - 0-4, если Т=1, указывая, что CWI=0-5, а BWI=0-4.

Формат ТВ3 показан в таблице 4.6.4.9. Таблица 4.6.4.9

	b8	b7	b6	b5	b4	b3	b2	b1
Только Т=1	0	X	X	X	0	Y	Y	Y

XXX лежит в интервале 000-100, а YYY - 000- 101 Терминал отвергает ATR, не содержащий ТВ3 или указывающий на значения BWI больше 4 и/или CWI больше 5, или 2CWI<(N+1). TC3 индицирует тип блока кода детектирования ошибки. Тип кода определяется битом b1 (b2-b8 - не используются). По умолчанию ATR не содержит ТС3. Терминал воспринимает ATR с ТС3=00, и отбрасывает любые-другие ATR, содержащие другие значения ТС3. ТСК (контрольный символ) имеет значение, которое позволяет проверить целостность данных, пересылаемых в ATR. Значение TCK таково, что исключающее ИЛИ всех байтов от Т0 до ТСК включительно должно давать код 0. По умолчанию ATR не содержит ТСК, если используется только Т=0, во всех других случаях ТСК должен присутствовать. Терминал воспринимает ATR ICC без TCK, если только Т=0. Во всех остальных случаях терминал отвергнет ATR без, или с некорректным ТСК. Если ТСК некорректно, терминал инициирует последовательность дезактивации не позднее 480 t после начала ТСК. Если терминал отверг холодный АТR, он не отвергает карту немедленно, а инициирует "теплый" сброс в пределах 4800t. Если терминал отверг теплый ATR, он в пределах 4800 t запускает процедуру дезактивации. Если во время отклика на холодный или теплый сброс интервал между двумя последовательными символами превысит 9600t, терминал прерывает сессию путем инициализации дезактивации спустя 14400t после стартового бита последнего полученного символа. Если отклик на холодный или теплый сброс не завершился в пределах 19200t, терминал спустя 24000t (от начала TS) запускает процедуру дезактивации карты. Если терминал обнаруживает ошибку по четности при передаче символа ATR, он прерывает сессию карты и спустя 4800t инициирует процедуру дезактивации.

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

Элемент Packaged Content будет в норме необходим, однако он может быть опущен там, где достаточная информация о покупке может быть получена из атрибута ShortDesc. Если необходимо полное описание заказа, могут использоваться несколько элементов Packaged Content. Хотя сумма и валюта вероятно присутствуют в элементах Packaged Content описания заказа, они содержатся в торговых компонентах, связанных с платежом (список видов платежа, выбор вида платежа и платеж). Это означает, что важно, чтобы сумма, которая действительно дожна быть уплачена, была четко отображена для Покупателя. Для совместимости разные реализации должны поддерживать как минимум Plain Text, HTML и XML, что облегчит отображение.

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

В системе CyberCash особое внимание уделяется вопросам безопасности. Система использует самые современные технологии шифрования и способна адаптировать любые новые схемы шифрования, которые появятся в будущем.
Система CyberCash для работы с кредитными картами версии 0.8 предоставляет достаточную защиту платежных сообщений, как это описано в разделах 1.2, 2.2.4 и 2.2.5. Система не обеспечивает достаточной защиты от нечестного продавца (здесь вне конкуренции протокол SET). Следует не выпускать из внимания ЭВМ, на которых работают различные части системы, в противном случае нельзя добиться приемлемого уровня безопасности.

Ссылки

[ISO 4217]	Codes for the representation of currencies and funds
[ISO 8583]	Financial transaction card originated messages - Interchange message specifications, 1993-12-15.
[RFC-822]	Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC- 822, UDEL, August 1982.
[RFC-1521]	Borenstein, N., and N. Freed, "MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC- 1521, Bellcore, Innosoft, September 1993.
[RFC-1766]	Alvestrand, H., "Tags for the Identification of Languages", UNINETT, March 1995.

Назад:
Оглавление:
Вперёд:

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

o	определение того, следует ли использовать электронную подпись;
o	конфиденциальность данных;
o	безопасность платежного протокола.

Сообщение CM- post-auth-capture

Сообщение аналогично CM1 за исключением того, что оно имеет другой тип и снабжено полем кода авторизации (которое включено в подпись). #####################################################################
Отправитель: MerchantApp
Получатель: CyberServer
#####################################################################
Пример сообщения: $$-CyberCash-0.8-$$
merchant-ccid: ACME-012 merchant-transaction: 123123
merchant-date: 19950121100705.nnn
merchant-cyberkey: CC1001
cyberkey: CC1001
opaque: EDD+b9wAfje5f7vscnNTJPkn1Wdi7uG3mHi8MrzLyFC0dj7e0JRjZ2PmjDHuR81kbhqb
nX/w4uvsoPgwM5UJEW0Rb9pbB39mUFBDLPVgsNwALySeQGso0KyOjMxNs1mSukHdOmDV
4uZR4HLRRfEhMdX4WmG/2+sbewTYaCMx4tn/+MNDZlJ89Letbz5kupr0ZekQlPix+pJs
rHzP5YqaMnk5iRBHvwKb5MaxKXGOOef5ms8M5W8lI2d0XPecH4xNBn8BMAJ6iSkZmszo
QfDeWgga48g2tqlA6ifZGp7daDR81lumtGMCvg==
merchant-opaque: 6BVEfSlgVCoGh1/0R+g1C143MaA6QLvKpEgde86WWGJWx45bMUZvaAu4LVeqWoYCqSGf
aWKUF7awol0h1i1jtgieyAcXB8ikvRJIsupSAwsRMyoNlekR6tucvfv/622JY7+n7nGO
dGbMzP0GJImh2DmdPaceAxyOB/xOftf6ko0nndnvB+/y2mFjdUGLtFQP/+3bTpZttZXj
j7RO1khe1UrAIk2TGQJmNw+ltsu0f42MgsxB8Q31vjPtoiPi5LEmD0Y4jlpJ7Jg2Ub84
F9vJhYpmzNkdiJUe83Hvo/xfJRbhafJpXFEsUZwQK0jU1ksU6CQd2+CPBB+6MxtsHoxJ
mjD6ickhd+SQZhbRCNerlTiQGhuL4wUAxzGh8aHk2oXjoMpVzWw2EImPu5QaPEc36xgr
mNz8vCovDiuy3tZ42IGArxBweasLPLCbm0Y=
$$-CyberCash-End-7Tm/djB05pLIw3JAyy5E7A==-$$ #####################################################################
Содержимое скрытой секции продавца: type: post-auth-capture
authorization-code: a12323
order-id: 1231-3424-234242
merchant-amount: usd 10.00
pr-hash: 7Tm/djB05pLIw3JAyy5E7A==
pr-signed-hash: a/0meaMHRinNVd8nq/fKsYg5AfTZZUCX0S3gkjAhZTmcrkp6RZvppmDd/P7lboFLFDBh
Ec0oIyxWeHfArb3OtkgXxJ7qe0Gmm/87jG5ClGnpBnw0dY7qcJ6XoGB6WGnD
id: myCyberCashID
transaction: 78784567
date: 19950121100505.nnn
merchant-signature: vxyEF1ZHn5Rgmtms3H3t/+UB6RAvZQA1AdddjvlS0H75N1x83FyJuh8V9Ok6t4EUQQZ6
Mnptzc6phJi3Ar0s0oumELsdc8upJdXpNpJV021PGJXfDKfHP0heJIWLodXr
#####################################################################

Ключ закрытой секции продавца генерируется из общедоступного ключа шифрования CyberCash, идентифицируемого в merchant-cyberkey.
Закрытая секция сообщения покупателя (Opaque) - смотри CH1.
#####################################################################
Содержимое закрытой секции и подпись: (в точности как в CH1) swversion: 0.8win
amount: usd 10.00
card*: [в случае успешного BC4 (включает в себя card-salt, номер карты и срок действия карты)]
Подпись: 48SBKUfojyC9FDKCwdCYNvucgiDxYO9erZW4QndIXZRyheTHXH8OeIhwUkyLmgQSD/UK
+IX9035/jUkdNPOxUQq9y/beHS1HU9Fe0wlzfXYRtnjlqvQX+yUfQ4T7eNEs
#####################################################################
Подпись продавца покрывает следующие поля:
merchant-ccid, merchant-transaction, merchant-date, merchant-cyberkey, type, authorization-code, order-id, merchant-amount, pr-hash, pr-signed-hash, id, transaction, date, cyberkey
##################################################################### Подпись продавца гарантирует целостность большей части сообщения. Проверка подписи покупателя гарантирует, что закрытая секция сообщения не была повреждена или заменена.

Сообщение IOTP выбора TPO

Сообщение выбора TPO используется только в документальном обмене предложения, зависящего от вида платежа. Помимо блока ссылок транзакции (смотри раздел 3.3), это сообщение включает в себя блок выбора TPO (смотри раздел 8.1), который описан ниже. Блок выбора TPO (смотри раздел 8.2) содержит:

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

Сообщение IOTP

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

	SigBlk?,
	ErrorBlk?,
	( AuthReqBlk \|
		AuthRespBlk \|
		AuthStatusBlk \|
		CancelBlk \|
		DeliveryReqBlk \|
		DeliveryRespBlk \|
		InquiryReqBlk \|
		InquiryRespBlk \|
		OfferRespBlk \|
		PayExchBlk \|
		PayReqBlk \|
		PayRespBlk \|
		PingReqBlk \|
		PingRespBlk \|
		TpoBlk \|
		TpoSelectionBlk
	)*

) >
xmlns CDATA
'iotp:ietf.org/iotp-v1.0'
Содержимое: TransRefBlkсодержит информацию, которая характеризует сообщение IOTP в пределах операции IOTP (смотри раздел 3.3)

AuthReqBlk, AuthRespBlk,	Торговые блоки.
DeliveryReqBlk	Торговые блоки присутствуют в сообщениях IOTP, а само содержимое
DeliveryRespBlk	торгового блока зависит от типа выполняемой операции IOTP
ErrorBlk	смотри определение каждой операции в разделе 9.
InquiryReqBlk,
InquiryRespBlk,
OfferRespBlk, PayExchBlk,
PayReqBlk	Полные определения каждого торгового блока описаны в разделе 8.
PayRespBlk, PingReqBlk, PingRespBlk, SigBlk, TpoBlk, TpoSelectionBlk

Атрибуты:

Xmlns

Определение [XML Namespace] для сообщений IOTP.

Аннулирует возврат денег, если сообщение

Аннулирует возврат денег, если сообщение получено до окончательного расчета. Сообщение аналогично сообщению CM1 за исключением того, что оно имеет другой код типа и снабжено полем номера ссылки возврата (retrieval-reference-number field) (которое включается в подпись). #####################################################################
Отправитель: MerchantApp
Получатель: CyberServer
#####################################################################
Пример сообщения: $$-CyberCash-0.8-$$
merchant-ccid: ACME-012
merchant-transaction: 123123
merchant-date: 19950121100705.nnn
merchant-cyberkey: CC1001
cyberkey: CC1001
opaque: EDD+b9wAfje5f7vscnNTJPkn1Wdi7uG3mHi8MrzLyFC0dj7e0JRjZ2PmjDHuR81kbhqb
nX/w4uvsoPgwM5UJEW0Rb9pbB39mUFBDLPVgsNwALySeQGso0KyOjMxNs1mSukHdOmDV
4uZR4HLRRfEhMdX4WmG/2+sbewTYaCMx4tn/+MNDZlJ89Letbz5kupr0ZekQlPix+pJs
rHzP5YqaMnk5iRBHvwKb5MaxKXGOOef5ms8M5W8lI2d0XPecH4xNBn8BMAJ6iSkZmszo
QfDeWgga48g2tqlA6ifZGp7daDR81lumtGMCvg==
merchant-opaque:
6BVEfSlgVCoGh1/0R+g1C143MaA6QLvKpEgde86WWGJWx45bMUZvaAu4LVeqWoYCqSGf
aWKUF7awol0h1i1jtgieyAcXB8ikvRJIsupSAwsRMyoNlekR6tucvfv/622JY7+n7nGO
dGbMzP0GJImh2DmdPaceAxyOB/xOftf6ko0nndnvB+/y2mFjdUGLtFQP/+3bTpZttZXj
j7RO1khe1UrAIk2TGQJmNw+ltsu0f42MgsxB8Q31vjPtoiPi5LEmD0Y4jlpJ7Jg2Ub84
F9vJhYpmzNkdiJUe83Hvo/xfJRbhafJpXFEsUZwQK0jU1ksU6CQd2+CPBB+6MxtsHoxJ
mjD6ickhd+SQZhbRCNerlTiQGhuL4wUAxzGh8aHk2oXjoMpVzWw2EImPu5QaPEc36xgr
mNz8vCovDiuy3tZ42IGArxBweasLPLCbm0Y=
$$-CyberCash-End-7Tm/djB05pLIw3JAyy5E7A==-$$
#####################################################################
Содержимое скрытой секции продавца: type: void
retrieval-reference-number: 432112344321
order-id: 1231-3424-234242
merchant-amount: usd 10.00
pr-hash: WATCQuH2q17lRuoxD78YBg==
pr-signed-hash: 8zqw0ipqtLtte0tBz5/5VPNJPPonfTwkfZPbtuk5lqMykKDvThhO0ycrfT7eXrn/hLUC
kXoSctahEVdw1KBJbp0EVr1zVzcN9Aa7m2fJgxNfiisTgIRW+PMaa78rn+Ov
id: myCyberCashID
transaction: 78784567
date: 19950121100505.nnn
Подпись продавца: lkjladjslkjflsakjflkjsdljflsakjflkjsdljflsakjflkj flsakjflkjsdljflsakjflkjsdljflsajflksdjflksdjflsdjssf=

#####################################################################
Ключ закрытой секции продавца генерируется из общедоступного ключа шифрования CyberCash, идентифицируемого в Merchant-CyberKey.
Закрытая секция сообщения покупателя (Opaque) - смотри CH1.
#####################################################################
Содержимое закрытой секции и подпись: (в точности как в CH1) swversion: 0.8win
amount: usd 10.00
card*: [из успешного bc4 (содержит card-salt, номер карты и срок ее действия)]
Подпись: 48SBKUfojyC9FDKCwdCYNvucgiDxYO9erZW4QndIXZRyheTHXH8OeIhwUkyLmgQSD/UK
+IX9035/jUkdNPOxUQq9y/beHS1HU9Fe0wlzfXYRtnjlqvQX+yUfQ4T7eNEs
#####################################################################
Подпись продавца покрывает следующие поля: merchant-ccid, merchant-transaction, merchant-date, merchant-cyberkey, type, retrieval-reference-number, order-id, merchant-amount, pr-hash, pr-signed-hash, id, transaction, date, cyberkey
#####################################################################<> Подпись продавца гарантирует целостность большей части сообщения. Проверка корректности подписи покупателя гарантирует, что невидимая часть сообщения клиента не была изменена или замещена.

Сообщение-отклик аутентификации 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, содержащиеся в блоке отклика аутентификации. Не следует предполагать, что все торговые роли могут поддерживать цифровую подпись данных. В частности не нужно думать, что эта опция поддерживается Покупателем.

Сообщение-отклик доставки

Сообщение-отклик доставки содержит блок отклика доставки и опционно блок подписи. Блок отклика доставки содержит:

один компонент накладной (Delivery Note) (смотри раздел 7.15), который содержит инструкции по доставке товаров или услуг. Блок подписи (отклик доставки) Блок подписи должен содержать один компонент подписи, который содержит элементы дайджеста, которые относятся к:

Id-компоненту транзакции (смотри раздел 3.3.1) сообщения, которое содержит подпись отклика Delivery;

блок ссылок транзакции (смотри раздел 3.3) сообщения, которое содержит подпись отклика доставки;

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

компоненты подписи, содержащиесчя в блоке запроса доставки (если имеется);

компонент Status;

компонент накладной (Delivery Note)

Сообщение отклик на предложение 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:

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

следующие компоненты блока отклика предложения:

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

Сообщение платежного обмена IOTP

Помимо блока ссылок транзакции (смотри раздел 3.3), это сообщение включает в себя блок платежного обмена. Блок платежного обмена (смотри раздел 8.8) включает в себя:

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

Сообщение платежного отклика и отклика доставки

Содержимое этого сообщения включает в себя:

блок платежного отклика,

опционный блок подписи (платежный отклик) и

блок отклика доставки. Содержимое блока платежного отклика то же, что и в платежном отклике при платежном документальном обмене (смотри раздел 9.1.3.4). Блок SIGNATURE (отклик PAYMENT) Содержимое этого блока то же, что и в блоке Signature (платежный отклик) при платежном документальном обменее (смотри раздел 9.1.3.4). Содержимое блока отклика доставки то же, что и в блоке отклика доставки при платежном документальном обменее (смотри раздел 9.1.4.3).

Сообщение платежного запроса IOTP

Содержимое этого сообщения то же, что и для запроса при платежном документальном обмене (смотри раздел 9.1.3.2).

Сообщение платежного запроса

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

блок платежного запроса и

опционный блок подписи Блок платежного запроса (смотри раздел 8.7) состоит из:

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

	- компонент Status
	- компонент Payment для выполняемого платежа

следующих компонентов блока TPO:

	- компоненты Organisation с ролями Продавец и Кассир, которые были пересланы в блоке платежного запроса;
	- компонент списка видов платежа, т.e. список видов платежа, указанный в атрибуте BrandListRef компонента Payment;

одного компонента выбора вида платежа, т.e. компонента выбора вида платежа, где атрибут BrandListRef указывает на список видов платежа. Этот компонент может быть:

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

опционного компонента платежной схемы (смотри раздел 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), тогда они должны обе быть скопированы в блок подписи сообщения платежного запроса.

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

Помимо блока ссылок транзакции (смотри раздел 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)

Сообщение 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 в блоке подписи дополнительно содержит элемент дайджеста для блока состояния аутентификации.

Сообщение TPO

Сообщение используется только в документальном обмене предложения, зависящего от вида платежа. Помимо блока ссылок транзакции (смотри раздел 3.3), в это сообщение входит блок опций торгового протокола (смотри раздел 8.1), который описан ниже. Блок TPO (TRADING PROTOCOL OPTIONS) Блок опций торгового протокола (смотри раздел 8.1) должен содержать следующие торговые компоненты:

Один компонент протокольных опций, который определяет опции, относящиеся ко всей транзакции. Смотри раздел 7.1.

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

Компоненты Organisation (смотри раздел 7.6), со следующими ролями:

	- Продавец, который сделал предложение
	- Покупатель, который осуществляет транзакцию
	- Кассир. "ID" компонента организщации-кассира содержится в атрибуте PhOrgRef компонента платежа (Payment).

Если транзакция IOTP включает доставку, тогда блок TPO должен содержать:

Компоненты Organisation со следующими ролями:

	- Агент доставки (DeliveryHandler), который осуществляет доставку товаров или услуг;
	- DelivTo т.e. лицо или организация, куда нужно выполнить доставку.

Блоки подписи и состояния аутентификации Если за документальным обменом Offer следует обмен аутентификации, тогда сообщение TPO может также содержать:

блок состояния аутентификации (смотри раздел 8.6) и

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

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

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

блок опций торгового протокола (смотри раздел 8.1),

блок запроса Authentication (смотри раздел 8.4) и

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

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

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

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

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

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

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

Сообщение запроса доставки IOTP

Сообщение запроса доставки IOTP состоит из:

блок запроса доставки и

опционный блок подписи Блок запроса доставки (смотри раздел 8.10) содержит:

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

	- компонент Status (смотри раздел 7.16)
	- компонент Order (смотри раздел 7.5)
	- компонент Organisation (смотри раздел 7.6) с ролями: Продавец, Агент доставки и DeliverTo
	-компонент Delivery (смотри раздел 7.13)

следующий компонент из блока платежного отклика:

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

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

Сообщения покупателя о покупке, содержащие данные о кредитной карте

Вообще, подключение CyberCash к покупке с помощью кредитной карты происходит после того как пользователь определит, что же он, в конце концов, покупает. Когда клиент нажимает клавишу CyberCash "payment", продавец посылает покупателю сообщение PR1 в виде тела типа MIME риложение/cybercash. Если покупатель желает продолжить процедуру, он отвечает продавцу сообщением CH1. Продавец реагирует, послав отклик CH2. В паузе между посылкой CH1 и получением CH2, продавец обычно контактирует с сервером CyberCash посредством сообщений CM*.

Сообщения продавца о покупке, связанные с кредитной картой

Продавец представляет покупки через кредитную карту, делает корректировки и выражает предпочтения через последовательность CM*. Вообще, цикл, сопряженный с кредитной картой включает авторизацию для покупки, включение покупки в перечень на оплату и собственно осуществление оплаты. Имеется возможность удалить определенную позицию из перечня или аннулировать всю сделку (смотри раздел 5.1.). Авторизации всегда осуществляется клиентом через отклики-сообщения CM1 или CM2. Если приобретение выполняется получателем (acquirer) или каким-то другим объектом между сервером CyberCash и получателем, это делается посредством сообщений CM3 или CM2 в зависимости от соглашения между продавцом и объектом, осуществляющим приобретение. Возвраты обрабатываются с помощью сообщений CM5. Сообщение CM4 служит для возврата покупки или возврата до оплаты сделки. CM6 является форматом сообщения, используемого для откликов на все другие CM*-сообщения. Последовательности MM* были также применены для оплат, осуществляемых продавцом, как описано в разделе 3.4.7 Современные система оплаты предполагают, что продавец знает номер кредитной карточки. Таким образом, чтобы работать с этими системами, предусмотрены специальные обходные сообщения, которые позволяют снабдить продавца нужной информацией, в противном случае CyberCash делает все, чтобы скрыть номер кредитной карты от продавца. Смотри разделы 3.4.8 и 3.4.9. Это делает получение такой информации контролируемым. Многие современные продавцы работают в режиме "terminal capture", где авторизации получаются продавцом.

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

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

два обычных вида платежа через кредитную карту и два льготных вида платежа.

два платежных протокола:

	- SET (Secure Electronic Transactions) смотри [SET] и
	- SCCD (Secure Channel Credit Debit) смотри [SCCD].

BrandLogoNetLocn='ftp://otplogos.mastercard.com' ProtocolAmountRefs='M1.7 M1.8'>

BrandLogoNetLocn='ftp://otplogos.visa.com' ProtocolAmountRefs='M1.7 M1.8'>

BrandLogoNetLocn='ftp://otplogos.britishairways.co.uk'
BrandNarrative='Double air miles with British Airways MasterCard'
ProtocolAmountRefs ='M1.7 M1.8' >

BrandLogoNetLocn='ftp://otplogos.walmart.com'
BrandNarrative='5% off with your Walmart Card on purchases over $150'
ProtocolAmountRefs='M1.8'>

238djqw1298erh18dhoire

238djqw1298erh18dhoire

ProtocolName='Secure Electronic Transaction Version 1.0'
PayReqNetLocn='http://www.example.com/etill/set1' >

8ueu26e482hd82he82

ProtocolName='Secure Channel Credit/Debit'
PayReqNetLocn='http://www.example.com/etill/sccd1' >

82hd82he8226e48ueu

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

Ниже представлен достаточно сложный пример, который включает в себя:

платежи, использующие Mondex, GeldKarte, CyberCash или DigiCash;

в валютах, в список которых входят доллары США, британские фунты, итальянские лиры, немецкие марки и канадские доллары;

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

более одного Кассира для случаев использования Mondex или CyberCash;

поддержка более чем одной версии CyberCash для платежного протокола CyberCoin. PayDirection='Debit'>
BrandLogoNetLocn='ftp://otplogos.mondex.com' ProtocolAmountRefs='M1.17 M1.18'>

BrandLogoNetLocn='ftp://otplogos.geldkarte.co.de' ProtocolAmountRefs='M1.19'>

BrandLogoNetLocn='http://otplogos.cybercash.com' ProtocolAmountRefs ='M1.20'>

BrandLogoNetLocn='http://otplogos.digicash.com'
BrandNarrative='5% off with your Walmart Card on purchases over $150'
ProtocolAmountRefs='M1.22'>

CurrencyAmountRefs='M1.25 M1.29'>

CurrencyAmountRefs='M1.26 M1.27 M1.28 M1.30'>

CurrencyAmountRefs='M1.23 M1.24 M1.27 M1.28 M1.29 M1.30'>

CurrencyAmountRefs='M1.23 M1.24 M1.27 M1.28 M1.29 M1.30'>

ProtocolName=' Mondex IOTP Protocol Version 1.0'
PayReqNetLocn='http://www.mxbankus.com/etill/mx' >

ProtocolName='Mondex IOTP Protocol Version 1.0'
PayReqNetLocn='http://www.mxbankuk.com/vserver' >

PayReqNetLocn='http://www.cybercash.com/ccoin' >

PayReqNetLocn='http://www.cybercash.com/ccoin' >

PayReqNetLocn='http://www.example.com/pgway'>

ProtocolName='DigiCash Protocol Version 1.0'
PayReqNetLocn='http://www.example.com/digicash' >

Ссылки

[Base64]	Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[DOM-HASH]	Maruyama, H., Tamura, K. and N. Uramoto, "Digest Values for DOM (DOMHASH)", RFC 2803, April 2000.
[DNS]	Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[DNS]	Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[DSA]	The Digital Signature Algorithm (DSA) published by the National Institute of Standards and Technology (NIST) in the Digital Signature Standard (DSS), which is a part of the US government's Capstone project.
[ECCDSA]	Elliptic Curve Cryptosystems Digital Signature Algorithm (ECCDSA). Elliptic curve cryptosystems are analogues of public-key cryptosystems such as RSA in which modular multiplication is replaced by the elliptic curve addition operation. See: V. S. Miller. Use of elliptic curves in cryptography. In Advances in Cryptology - Crypto '85, pages 417-426, Springer-Verlag, 1986.
[HMAC]	Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[HTML]	Berners-Lee, T. and D. Connolly, "Hypertext Markup Language - 2.0", RFC 1866, November 1995.
[HTML]	Hyper Text Mark Up Language. The Hypertext Mark-up Language (HTML) is a simple mark-up language used to create hypertext documents that are platform independent. See the World Wide Web (W3C) consortium web site at: http://www.w3.org/MarkUp/
[HTTP]	Berners-Lee, T., Fielding, R. and H. Frystyk, "Hypertext Transfer Protocol -- HTTP/1.0", RFC-1945, May 1996.
[HTTP]	Fielding, R., Gettys, J., Mogul, J., Frystyk, T. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1.", RFC-2616, June 1999.
[IANA]	The Internet Assigned Numbers Authority. The organisation responsible for co-ordinating the names and numbers associated with the Internet. See http://www.iana.org/
[ISO4217]	ISO 4217: Codes for the Representation of Currencies. Available from ANSI or ISO.
[IOTPDSIG]	Davidson, K. and Y. Kawatsura, "Digital Signatures for the v1.0 Internet Open Trading Protocol (IOTP)", RFC-2802, April 2000.
[MD5]	Rivest, R., "The MD5 Message-Digest Algorithm", RFC-1321, April 1992.
[MIME]	Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, August 1982.
[MIME]	Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC-2045, November 1996.
[MIME]	Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC-2046, November 1996.
[MIME]	Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text" RFC-2047, November 1996.
[MIME]	Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", RFC-2048, November 1996.
[MIME]	Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples" RFC-2049, November 1996.
[OPS]	Open Profiling Standard. A proposed standard which provides a framework with built-in privacy safeguards for the trusted exchange of profile information between individuals and web sites. Being developed by Netscape and Microsoft amongst others.
[RFC1738]	Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource Locators (URL)", RFC-1738, December 1994.
[RFC2434]	Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC-2434, October 1998.
[RSA]	RSA is a public-key cryptosystem for both encryption and authentication supported by RSA Data Security Inc. See: R. L. Rivest, A. Shamir, and L.M. Adleman. A method for obtaining digital signatures and public-key cryptosystems. Communications of the ACM, 21(2): 120-126, February 1978.
[SCCD]	Secure Channel Credit Debit. A method of conducting a credit or debit card payment where unauthorised access to account information is prevented through use of secure channel transport mechanisms such as SSL/TLS. An IOTP supplement describing how SCCD works is under development.
[SET]	Secure Electronic Transaction Specification, Version 1.0, May 31, 1997. Supports credit and debit card payments using certificates at the Consumer and Merchant to help ensure authenticity. Download from: .
[SSL/TLS]	Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC-2246, January 1999.
[SHA1]	[FIPS-180-1]"Secure Hash Standard", National Institute of Standards and Technology, US Department Of Commerce, April 1995. Also known as: 59 Fed Reg. 35317 (1994). See http://www.itl.nist.gov/div897/pubs/fip180-1.htm
[UTC]	Universal Time Co-ordinated. A method of defining time absolutely relative to Greenwich Mean Time (GMT). Typically of the form: "CCYY-MM-DDTHH:MM:SS.sssZ+n" where the "+n" defines the number of hours from GMT. See ISO DIS8601.
[UTF16]	The Unicode Standard, Version 2.0. The Unicode Consortium, Reading, Massachusetts. See ISO/IEC 10646 1 Proposed Draft Amendment 1
[X.509]	ITU Recommendation X.509 1993 \| ISO/IEC 9594-8: 1995, Including Draft Amendment 1: Certificate Extensions (Version 3 Certificate)
[XML	Recommendation for Namespaces in XML, World Wide Web Namespace] Consortium, 14 January 1999, "http://www.w3.org/TR/REC-xml-names"
[XML]	Extensible Mark Up Language. A W3C recommendation. See http://www.w3.org/TR/1998/REC-xml-19980210 for the 10 February 1998 version.

Назад:
Оглавление:
Вперёд:

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

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

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

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

Как торговые компоненты формируются в торговые блоки и сообщения 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.

Таблица описанных сообщений

C = Приложение Покупателя, M = Приложение Продавца, S = Сервер CyberCash

FLOW	Раздел	Имя
C->S	4.2.1	BC.1 bind-credit-card
S->C	4.2.2	BC.4 bind-credit-card-response
C->M	4.3.2	CH.1 credit-card-payment
M->C	4.3.3	CH.2 credit-card-response
M->S	4.4.8	CD.1 запрос данных о кредитной карте
S->M	4.4.9	CD.2 отклик на запрос о кредитной карте
M->S	4.4.1	CM.1 только аутентификация
M->S	4.4.2	CM.2 auth-capture
M->S	4.4.3	CM.3 post-auth-capture
M->S	4.4.4	CM.4 void
M->S	4.4.5	CM.5 возврат
S->M	4.4.6	CM.6 отклик на платеж
C->S	4.5.7	DL.1 диагностическая запись
M->S	4.5.7	DL.2 диагностическая запись продавца
C->S	4.1.3	GA.1 получение приложения
S->C	4.1.4	GA.2 получение отклика приложения
M->S	4.4.7	MM.1 только аутентификация продавца
M->S	4.4.7	MM.2 merchant-auth-capture
M->S	4.4.7	MM.3 merchant-post-auth-capture
M->S	4.4.7	MM.4 merchant-void
M->S	4.4.7	MM.5 merchant-return
S->M	4.4.7	MM.6 отклик продавца на процедуру оплаты
C->S	4.5.1	P.1 ping
S->C	4.5.2	P.2 отклик на ping
M->C	4.3.1	PR.1 запрос платежа
C->S	4.1.1	R.1 регистрация
S->C	4.1.2	R.2 отклик на регистрацию
C->S	4.5.3	TQ.1 запрос о состоянии транзакции
C->S	4.5.4	TQ.2 аннулирование транзакции
S->C	4.5.5	TQ.3 отклик на транзакцию
S->C, S->M, M->C	4.5.6	UNK.1 неизвестная ошибка

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

К техническим ошибкам относятся ошибки, которые не зависят от значения сообщения. Это означает, что они могут влиять на любую попытку передачи. Обычно они обрабатываются стандартным образом с ограниченным числом опций для пользователя. Такие ошибки могут быть: o повторная попытка передачи;
o аннулирование транзакции. Когда связь работает достаточно хорошо, техническая ошибка индицируется компонентом Error (смотри раздел 7.21) в блоке Error (смотри раздел 8.17), посланным партнером, который детектировал ошибку в сообщении IOTP, партнеру, пославшему ошибочное сообщение. Если связь слишком плохая, сообщение, которое было послано, может не достичь адресата. В этом случае может произойти таймаут. Коды ошибок, соответствующие техническим ошибкам записываются в компоненте Error, где перечисляются различные технические ошибки, которые могут случиться.

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

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

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

	( TransRefBlk,
	SigBlk?,
	ErrorBlk?,
	( AuthReqBlk \|
		AuthRespBlk \|
		AuthStatusBlk \|
		CancelBlk \|
		DeliveryReqBlk \|
		DeliveryRespBlk \|
		InquiryReqBlk \|
		InquiryRespBlk \|
		OfferRespBlk \|
		PayExchBlk \|
		PayReqBlk \|
		PayRespBlk \|
		PingReqBlk \|
		PingRespBlk \|
		TpoBlk \|
		TpoSelectionBlk
	)*

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

Блок запроса аутентификации (Authentication Request Block)

Блок отклика аутентификации (Authentication Response Block)

Блок состояния доставки

Блок Cancel

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

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

Блок Error

Блок информационного запроса

Блок информационного отклика

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

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

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

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

Блок подписи

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

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

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

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

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

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

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

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

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

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

Компонент организации

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

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

Компонент платежа

Компонент схема платежа

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

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

Компонент данных доставки

Компонент накладной

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

Компонент сертификата

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

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

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

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

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

Рис. .1. Торговые роли в IOTP Определены следующие роли:

Покупатель. Человек (или организация), который получает товар или услугу и платит за это.

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

Оператор платежей. Субъект, который получает платеж от потребителя в пользу торговой фирмы или физического лица.

Оператор доставки. Субъект, который доставляет товар или предоставляет услугу потребителю от торговой фирмы или лица.

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

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

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

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

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

ID	Идентификатор, который однозначно определяет торговый блок информационного отклика транзакции.
LastReceivedIotpMsgRef	Содержит ссылку элемента (смотри раздел 3.5) на Id-компонент (смотри раздел 3.3.2) последнего сообщения, которое получил данный сервер от покупателя. Если до этого не получено от покупателя ни одного сообщения, этот атрибут должен содержать значение (Null). Данный атрибут предназначен для отладочных целей.
LastSentIotpMsgRef	Содержит ссылку элемента (смотри раздел 3.5) на Id-компонент (смотри раздел 3.3.2) последнего сообщения, которое послал данный сервер покупателю. Если до этого не послано ни одного сообщения покупателю, данный атрибут должен содержать значение (Null). Этот атрибут предназначен для отладочных целей.

Cодержимое:

Status	Содержит статусную информацию об успехе или неудаче (смотри раздел 4.2) определенного торгового обмена (т.e., предложения, платежа или доставки).
PaySchemeData	Компонент Payment Scheme (смотри раздел 7.10), который содержит специфические информационные запросы по поводу платежной схемы. Он присутствует, когда атрибут Type атрибута StatusType компонента Status равен Payment.

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

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

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

Cодержимое:

InquiryType	Компонент тип информационного запроса (смотри раздел 7.18), который содержит код типа запроса.
PaySchemeData	Компонент платежная схема (Payment Scheme) (смотри раздел 7.10), который содержит специфические данные конкретных информационных запросов о платежной схеме. Он присутствует, когда атрибут Type компонента типа запроса равен Payment.

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

Протокол Интернет для торговли (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.

1.	Покупатель (С) решает сделать покупку и шлет информацию о заказе продавцу (М), например в формате HTML.
C а M	Данные: информация о том, что покупается (запрос Предложения) - формат запроса не определен в рамках IOTP
2.	Продавец проверяет информацию, выданную Покупателем, формирует предложение, опционно его подписывает и посылает Покупателю.
C Я M	Отклик на Предложение. Компоненты: Статус; Организации (покупатель, DelivTo, продавец, кассир, Агент обслуживания покупателя); Заказ; Платеж; Доставка; TradingRoleData подпись отклика-предложения (опционно)
3.	Покупатель проверяет информацию от продавца и решает, стоит ли осуществлять покупку.

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

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

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

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

o	Компонент Заказа (Order Component) содержит описания товаров или услуг, предмет сделки, если покупателя устроит соглашение. Эта информация посылается Продавцом покупателю.
o	Компонент оплаты (Payment Component), генерируемый продавцом, содержит детали того сколько надо платить, в какой валюте и кто должен платить кому, например покупатель может попросить вернуть деньги. Заметим, что число платежей в сделке может быть больше одного.
o	Компонент Доставки (Delivery Component), также генерируемый продавцом, используется, если товары или услуги требуют доставки. Он содержит информацию о том, как будет осуществляться доставка, например с помощью обычной или электронной почты.
o	Компонент данных о торговых ролях содержит информацию, которую продавец хочет довести до сведения другой торговой роли, такой как Кассир или Агент доставки.
o	Компонент подпись "отклика на предложение", если присутствует, подписывает все выше перечисленные компоненты с целью гарантии их целостности.

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

низкая стоимость сделки может не требовать подписи

сумма оплаты может варьироваться в зависимости от фирмы и используемого протокола оплаты

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

обмен ценностями включает два платежа

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

Используя [HTML] страницы, как часть "практики" покупателей.

Используя стандарт OPS (Open Profiling Standard), который был недавно предложен,

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

Как компоненты Заказа в последней версии IOTP.

TQ- аннулирование транзакции

Запрос клиента серверу в связи с аннулированием транзакции. #####################################################################
Отправитель: CyberApp
Получатель: CyberServer
#####################################################################
Пример сообщения: $$-CyberCash-0.8-$$
id: MyCyberCashID
date: 19950121100505.nnn
transaction: 12312314
cyberkey: CC1001
opaque: VFaztHuj757Jrv+JxZFsHORy/zgkrxhBCu9cPdE04c1NnXzVlGOHygpSl+UGbUvnhkYl
21QQaHkaE3geccRk03cqFYoLNRCclImcsyeIZCgVt+2dJTj1V+E7R7ePQtCj+0gY42+V
L5BWhVtmDQFyg1DdJ6n3S/er6ZuObAjpcAogG+T1Na5dJmrTA1wRMiYVkqhXi2KMYdur
3U47P8ZGUza7W0MST3DgvviN0kVhtmHEnm515mo6NTQdfdxw9WZpy6vMqrBGk2nTgi2c
bnf+muO0+kiNPXVvEzRrO8o=
$$-CyberCash-End-kchfiZ5WAUlpk1/v1ogwuQ==-$$
#####################################################################
Скрытый ключ: полученный из ключа шифрования CyberCash, заданного CyberKey
#####################################################################
Содержимое скрытой секции:
type: transaction-cancel
swversion: 0.8win
begin-transaction: 1234
end-transaction: 4321
Подпись: kD7DEav2uLQIYMtP9gbhYaBUpB2a5whNwnK2eXbbyTCf56F6dl3DIVf7D8Z4WxbY2YZn
ByRIKeqlhmss7fbdnBiDYmKfOuc+I4bi/Oslml5riaciQhTd2JdHG+PCcHwZ
#####################################################################
Подпись защищает следующие поля: id, date, transaction, cyberkey, type, swversion, begin-transaction, end-transaction
#####################################################################
Объяснение:<> Это попытка клиента аннулировать предыдущую транзакцию или транзакции.<> begin-transaction и end-transaction могут совпадать. Запрос аннулирования транзакции (TQ.2) определен для взаимодействия клиента с сервером. Этот запрос позволяет клиенту запросить состояние операции и предотвратить операцию, если она еще не осуществлена.

TQ- отклик транзакции (transaction-response)

Отклики, генерируемые TQ1 или TQ2 #####################################################################
Отправитель: CyberServer
Получатель: CyberApp
#####################################################################
Пример сообщения: $$-CyberCash-0.8-$$
id: mycybercashid
date: 19950121100505.nnn
transaction: 12312314
server-date: 19950121100505.nnn
opaque: eFXRL+H0J5q318M21wRdtcbhu9WCyLysQkeF9oIcjtbstymx343bbt0EAtU1gcJaUKJZ
3skgvwrhcxU4bFcE68OPlUXAvLq10I3MczPYPsiGrsU0K4bZtQvDZmn727QQAfONBm5s
s1yjIha+Fj481BJQs0CTYc3ju90lAjCYgirXtnnR6yJXoDO75b7UjthvHSnrTWVZvktX
PvTuUCYzbXSFoYvwFM3Y+yHqSHlmWutYKQpYze8zbUSDQfmwTCJyw3aY2JasZ+xMP/CD
JWbCA+gCLBYCnvzM/ExKTZTFD3xr5JBfNbV4p6CiK6lsfRFD7maAK6TSVnWjwCEJNpOv
fyllfWD04fT7LINQcjJiQK1Pk/912Tk6Q35eRaQZorwv2hnY/7By2OkPyFdAqFL+D0H6
TqzxmdEjEFKxi/PPT1+Cs/Nszy8wZzaGg8iWATfARY6stl+02dDhwOoFXSBNvchlVrcI
IlvhumSIQs29Pntj3DbkYo4IEmmN/qi1vnzld22q7lA1q/CQakyc7jlQUFISx76buqwy
35XiC9Yn8flE4Va14UxMf2RCR1B/XoV6AEd64KwPeCYyOYvwbRcYpRMBXFLyYgWM+ME1
+yp7c66SrCBhW4Q8AJYQ+5j5uyO7uKyyq7OhrV0IMpRDPjiQXZMooLZOifJPmpvJ66hC
VZuWMuA6LR+TJzWUm4sUP9Zb6zMQShedUyOPrtw1vkJXU1vZ5aI8OJAgUcLEitcD+dsY
Df4CzA00fC10POkJ58HZB/pSBfUrHAa+IqMHyZkV/HBi9TjTwmktJi+8T9orXS0jSvor
dMTGWn0ifETy2VXt
$$-CyberCash-End-0QXqLlNxrn4GNQPPk9AO1Q==-$$
#####################################################################
Скрытый ключ. Ключ сессии из TQ1/TQ2 для текущих значений транзакции и ID.
#####################################################################
Содержимое скрытой секции: type: transaction-response
response-code: success/failure/etc.
message; текстовое сообщение, посылаемое сервером покупателю.
swseverity: fatal/warning
swmessage; Сообщение, указывающее, что программа CyberApp является устаревшей. Может содержать несколько строк.
report-fee: usd 0.15 [если не равно нулю] transaction-1: old-transaction-number
transaction-status-1: success/failure/pending/cancelled/etc.
server-date-1: 19951212125959.nnn
date-1: 19950121100505.nnn
type-1: auth-only/etc. Оплата отчета (Report-fee) представляет собой уведомление о том, что данный отчет имеет цену и его предоставление зависит от оплаты.
Транзакции с заданным номером может соответствовать несколько транзакций (аутентификация, оплата и т.д.). Термины

"исходная транзакция"			относится к платежу или другой транзакции, которая была запрошена или аннулирована. Заметим, что эта транзакция в действительности не является резидентной для сервера.
"request"			относится к запрашивающим сообщениям TQ.2 или TQ.1.
id:			идентификатор сообщения-запроса
date:			дата сообщения-запроса
transaction:			транзакция сообщения-запроса
server-date:			текущая дата/время
type:			Отклик транзакции
response-code:			код отклика для сообщения-запроса, может быть одним из:
	"success"		означает, сообщение прошло успешно. Не подразумевает требования присылки состояния запроса.
	"failure-hard"		означает, что сообщение-запрос не прошло из-за некорректного формата или по какой-то другой причине.
	"failure-swversion"		означает, что запрос не был обработан из-за проблем ревизии программного обеспечения.
message:			сообщение используется только для транзакции TQ, а не к состоянию транзакций, статус или аннулирование которых были запрошены. Сообщение формируется на основании кода отклика:
	"success"		сообщение проигнорировано.
	"failure-hard"		используется стандартное сообщение уведомление о неудаче.
	"failure-swversion"		в случае фатальной ошибки используется стандартное сообщение типа swversion
swseverity:			относится к сообщению-запросу
swmessage:			относится к сообщению-запросу - для полей запрос/отмена ('N' берется из ряда от 1 до N)
transaction-N:			номер исходной транзакции, или, если исходной транзакции на сервере нет, то номер транзакции запроса состояния транзакции с заданным номером. Состояние исходной транзакции может быть одним из:
		"success"	исходная транзакция была успешно проведена. Если запросом было сообщение TQ.2, аннулирование не производится.
		"failure"	исходная транзакция не была реализована. Если запросом было сообщение TQ.2, аннулирование не производится.
		"pending"	исходная транзакция все еще обрабатывается и окончательный результат пока не известен.
		"canceled"	исходная транзакция была аннулирована сервером. Последующий приход исходной транзакции не будет обрабатываться, но будет послан отклик "failure-canceled".
server-date-1:			поле server-date из исходной транзакции. Опускается, если исходная транзакция на сервере отсутствует.
date-1:			поле даты исходной транзакции. Опускается, если исходная транзакция на сервере отсутствует.
type-1:			поле типа исходной транзакции. Опускается, если исходная транзакция на сервере отсутствует.

TQ- запрос транзакции

Запрос клиента серверу о состоянии транзакции. #####################################################################
Отправитель: CyberApp
Получатель: CyberServer
#####################################################################
Пример сообщения: $$-CyberCash-0.8-$$
id: MyCyberCashID
date: 19950121100505.nnn
transaction: 12312314
cyberkey: CC1001
opaque: VFaztHuj757Jrv+JxZFsHORy/zgkrxhBCu9cPdE04c1NnXzVlGOHygpSl+UGbUvnhkYl
>21QQaHkaE3geccRk03cqFYoLNRCclImcsyeIZCgVt+2dJTj1V+E7R7ePQtCj+0gY42+V
L5BWhVtmDQFyg1DdJ6n3S/er6ZuObAjpcAogG+T1Na5dJmrTA1wRMiYVkqhXi2KMYdur
3U47P8ZGUza7W0MST3DgvviN0kVhtmHEnm515mo6NTQdfdxw9WZpy6vMqrBGk2nTgi2c
bnf+muO0+kiNPXVvEzRrO8o=
$$-CyberCash-End-kchfiZ5WAUlpk1/v1ogwuQ==-$$
#####################################################################
Скрытый ключ. Генерируется ключом шифрования CyberCash, идентифицированным CyberKey
#####################################################################
Содержимое скрытой секции: type: transaction-query
swversion: 0.8win
begin-transaction: 1234
end-transaction: 4321
Подпись: jJfFsKvOxLaV87gxu7lIPet3wIDwh1H2F61reYC9jmUrS6WAtUVFG9aCNuTEBoMixF0X
vD5oPfyheJRIlnL6i0c4o/bfyO3edKAacmWjTmKt6/4y9p3qgvKkSX8r9aym
#####################################################################
Подпись содержит в себе поля: id, date, transaction, cyberkey, type, swversion, begin-transaction, end-transaction
#####################################################################
Объяснение:
Это запрос клиента сообщить ему о состоянии предшествующей транзакции или транзакций. begin-transaction и end-transaction могут совпадать.

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

Этот уровень ошибки указывает фундаментальную проблему в транспортном механизме, через который осуществляется передача в IOTP. Все ошибки транспортного уровня являются техническими и индицируются явно на транспортном уровне, как "No route to destination" из TCP/IP или через таймаут, когда не получено отклика на посланный запрос. Единственно разумным автоматическим действием, когда сталкиваешся с ошибками транспортного уровня, является попытка повторной передачи, а после нескольких попыток информирование пользователя об этом. Неявная индикация ошибки, которая может быть получена, является зависимой от транспортной среды и для принятия решения относительно конкретных действий следует обращаться к документации транспортного приложения IOTP. Таймауты здесь являются функцией как транспорта так и платежной системы, если в запрос инкапсулирована платежная информация. Для выяснения параметров таймаутов и повторных передач рекомендуется обращаться к документации по транспортной и платежной системам. Часто нет способа непосредственно проинформировать партнера об ошибках транспортного уровня, при таких обстоятельствах такие события должны регистрироваться и, если автоматическое восстановление системы не сработало, а в процесс вовлечен человек-пользователь, его следует проинформировать об инциденте.

Транзакции IOTP

Базовая версия протокола IOTP поддерживает три типа транзакций. Среди них:

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

Транзакции IOTP, которые включают в себя один или более платежей. В частности: - Депозит
- Покупка
- Возврат денег
- Отзыв сделки
- Обмен ценностями

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

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

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

Транзакция аутентификации и платежа

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

Аутентификация. Это прямая реализация аутентификации торгового обмена;

Предложение (Offer), зависимое от вида платежа. Это торговый обмен предложения, объединенный с платежным обменом выбора вида платежа. Его целью является обеспечение Продавца информацией о выборе вида платежа;

Предложение, не зависимое от вида платежа. Это также торговый обмен предложения (Offer). Однако в этом случае содержимое отклика Offer не зависит от выбора вида платежа;

Платеж. Это непосредственная реализация платежной части торгового обмена;

Доставка. Это прямая реализация обмена доставки;

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

Рис. .17. Блок-диаграмма обмена сообщениями платежа и аутентификации Допустимые комбинации документального обмена зависят от конкретного типа транзакции IOTP. Далее рассматриваются методы обработки рабочих ошибок (Business Errors) в процессе документального обмена (смотри раздел 4.2).

UNK- неизвестная ошибка

Это отклик, который посылается, когда запрос так плох, что вы не можете определить его тип или этот тип не известен. Отклик посылается Продавцом Клиенту или Сервером Продавцу, или Сервером Клиенту. #####################################################################
Отправитель: MerchantApp или CyberServer
Получатель: CyberApp или MerchantApp
#####################################################################
Пример сообщения: $$-CyberCash-0.8-$$
type: unknown-error
unknown-error-message:
Текст сообщения о причинах ошибки, которое следует представить пользователю. (Не найден CyberCash-обработчик, проверка целостности обработчика не прошла, специфицирована неизвестная версия протокола, специфицирован неизвестный тип и т.д.)
{
server-date: 19950121100506.nnn [если послано сервером]
}
или
{
merchant-date: 19950121100506.nnn [если послано продавцом]
}
x-id: mycybercashID
x-transaction: 123123213
x-date: 19950121100505.nnn
x-cyberkey: CC1001
x-opaque: 2DqiOQfGRZjzddWpEZwGsJnoTsp9Yiri8DE9cPUMPsJ7lTFuE4XHi4QfN2cAipDB2G/G
9hr7Hj4u4xfMky7nPvJurClZejkI8eNp8iXLtrfS4DhR4yCFQjCiKk0dh83p+DDsFVV7
TI3Du2B15sQS+SdaoPwkfVDnJv4Y+b7vu2cN7bG7exCkBapBcJZbReNaWX5sf+U8ypfw
5V6QdMOzNXpef3z+cTTWfGOtmn9T1Pwo1Yi9ObyIf/wiK+IPb+bBZ9UwLZSB+qVMfJmX
GnHXO3AnA/PD+jKYCtsm2Gxv2WB3CuezOyzPtORuqLp5ubgnLBF9aBBjxwLdbn+cp5sm
lw51IHbmo1Jj7H6wyNnRpEjy4tM73jcosBfGeQDHxgyH1uaiFNr2D+WvmuYo7eun2dsy
Wve2O/FwicWHvkg5aDPsgOjzetsn1JCNZzbW
$$-CyberCash-End-7Tm/djB05pLIw3JAyy5E7A==-$$ Это сообщение посылается в качестве отклика, когда не удается найти или понять тип сообщения. Оно всегда имеет в начале поля типа и unknown-error-message. Любые поля запроса, которые удается распознать, копируются с префиксами "x-" в сообщение UNK1, посылаемое в качестве отклика. Таким образом, если появляется x-opaque, это означает, что в исходном запросе было поле opaque и т.д. Так как покупатель инициирует обмен с продавцом и сервером, а продавец запускает обмен с сервером, это сообщение будет послано только покупателю продавцом или сервером покупателю или продавцу. Оно должно быть записано для отладочных целей. Вам может быть нужно отслеживать отказы обслуживания посредством сообщений UNK1.

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

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

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

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

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

Связанные с проверкой согласованности блоков и компонентов.

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

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

Этот уровень ошибки указывает на фундаментальную техническую проблему с 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.

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

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

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

аналогично, дата OkTo может быть раньше чем дата OkTo компонента Payment (смотри раздел 7.9). Продавец в контексте Интернет-коммерции в исходный момент с анонимными покупателями выявляет условия предложения на WEB-странице. Для того чтобы получить товар или услуги покупатель должен согласиться с этими условиями. Если предложение ограничено временными рамками, рекомендуется, чтобы продавцы взаимодействовали с покупателями и сообщали им условия заказа в понятной для них форме:

предложение ограничено по времени;

временные метки OkFrom и OkTo специфицируют время действия предложения;

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

Выбор Покупателем льготных видов платежа

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

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

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

Покупатель непосредственно вводит этот код. Это располагает к ошибкам и неудобно для клиента, кроме того покупателю надо как-то передать этот код. Этот подход не рекомендуется,

Используется один из идентификаторов вида платежа, определенных в IOTP и предварительно загруженных в приложение покупателя,

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

	- сертификат SET для видов платежа, которые используют этот протокол оплаты;
	- код предоставляется платежной программой, которая работает с конкретным методом оплаты, это может быть приложимо к, например, GeldKarte, Mondex, CyberCash и DigiCash,

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

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

Если входное сообщение может быть идентифицировано, как корректное, то проверяется, не получалось ли раньше точно такое же сообщение. Под идентичностью здесь подразумевается, что все блоки, компонентя, элементы, значения атрибутов и элементы содержимого тождественны. Рекомендуемым способом проверки идентичности сообщений является проверка равентства их [DOM-HASH]. Если получено сообщение, прежде чем его исследовать, нужно проверить, завершилась ли обработка предыдущего. Если обработка не завершилась, генерируется компонент Error с атрибутом Severity = TransientError и кодом ошибки = MsgBeingProc, чтобы указать, что сообщение обрабатывается и послать его обратно отправителю, с предложением повторной присылки поздее.

XML Document Prolog

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

...[ZEBR_TAG_br