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

Клиентская диагностическая запись о плохом сообщении от продавца или сервера.

$$-CyberCash-0.8-$$
id: MyCyberCashID
date: 19950121100505.nnn
transaction: 1234
cyberkey: CC1001

opaque:

#####################################################################
Скрытый ключ. Генерируется из ключа шифрования 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: [если невозможно дешифровать]

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

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

Документальный обмен аутентификации является непосредственной реализацией торгового обмена аутентификации (смотри раздел 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.

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

Идентификацию компонента 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. Ее определение представлено ниже:

<!ELEMENT TransId EMPTY >

<!ATTLIST TransId ID	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. Его определение выглядит следующим образом.

<!ELEMENT MsgId EMPTY >

<!ATTLIST MsgId ID ID #REQUIRED	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 по платежным методам, где описаны методы использования данного элемента.

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

Атрибуты:

ContentSoftwareId

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

Cодержимое:

PackagedContent

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

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

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

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

Атрибуты:

ContentSoftwareId

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

Cодержимое:

PackagedContent

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

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

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

<!ELEMENT ConsumerDeliveryData EMPTY>
<!ATTLIST ConsumerDeliveryData ID ID #REQUIRED
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, например:

<Algorithm ID=A1 type="digest" name="urn:ibm:dom-hash">

<Parameter type='AlgorithmRef'>A2</Parameter> </Algorithm>
<Algorithm ID=A2 type="digest" name="urn:fips:sha1"> </Algorithm>
<Algorithm ID=A3 type="signature" name="urn:ibm:hmac">
Элемент DIGEST Атрибут LocatorHREF идентифицирует элемент IOTP, который подписан цифровым образом. Он состоит из: значения ID-атрибута IotpTrans ID-компонента транзакции, за которым следует:символ "#", за которым следуетссылка элемента (смотри раздел 3.5) на элемент транзакции IOTP, который является субъектом дайджеста. Прежде чем анализировать структуру атрибута LocatorHREF, он должен быть объединен со значением атрибута LocatorHrefBase элемента Manifest (смотри непосредственно выше). Элемен атрибут Должен существовать один и только один элемент атрибута, который содержит атрибут Type со значением типа подписи и содержимым равным одному из: OfferResponse, PaymentResponse, DeliveryResponse, AuthenticationRequest, AuthenticationResponse, PingRequest или PingResponse; в зависимости от типа подписи. Значения содержимого элемента атрибута управляются процедурой, определенной в разделе 12 (IANA), и допускающей определение значений пользователем. Атрибут Critical должен быть установлен равным true. Элемент ORIGINATORINFO Атрибут OriginatorRef элемента OriginatorInfo должен всегда присутствовать и содержать ссылку элемента (смотри раздел 3.5) на компонент Organisation организации, которая сформировала компонент Signature. Элемент RECIPIENTINFO Атрибут RecipientRefs содержит список ссылок (смотри раздел 3.5), указывающих на организации, которые должны будут проверить подлинность подписи.

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

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

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

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

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

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

Отклик доставки, когда Агент доставки генерирует накладную (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). Назад:
Оглавление:
Вперёд:

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

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

<!ELEMENT PostalAddress EMPTY >

<!ATTLIST PostalAddress xml:lang	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 по платежным методам, где описаны методы использования данного элемента.

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

Атрибуты:

ContentSoftwareId

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

Cодержимое:

PackagedContent

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

Элемент Brand

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

<!ELEMENT Brand (ProtocolBrand*, PackagedContent*) >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 содержит информацию о том, куда и как должны доставляться товары или услуги. Его определение представлено ниже.

<!ELEMENT DeliveryData (PackagedContent*) >

<!ATTLIST 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), предоставляемая агенту доставки продавцу.

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

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

<!ELEMENT ContactInfo EMPTY >

<!ATTLIST ContactInfo xml:lang	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 (фамилия) должны присутствоать. Его опредление представлено ниже.

<!ELEMENT PersonName EMPTY >

<!ATTLIST PersonName xml:lang	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).

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

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

Атрибуты:

Name

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

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

Атрибут имени может быть опущен, например, если имеется только один элемент 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.

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

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

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

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, торговый блок, торговый компонент, элемент и атрибут, где обнаружена ошибка.

<!ELEMENT ErrorLocation EMPTY >

<!ATTLIST ErrorLocation ElementType	NMTOKEN #REQUIRED
IotpMsgRef NMTOKEN #IMPLIED	BlkRef NMTOKEN #IMPLIED
CompRef NMTOKEN #IMPLIED	ElementRef NMTOKEN #IMPLIED

AttName NMTOKEN #IMPLIED>

Атрибуты:

ElementType	Имя типа элемента, где обнаружена ошибка. Например, если элемент декларирован как <!ELEMENT Org, тогда его имя - "Org".
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), котоый может быть использован для этого видв валюты и сумм платежа.

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

<!ELEMENT ProtocolAmount (PackagedContent*) >
<!ATTLIST ProtocolAmount ID ID #REQUIRED
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.

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

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

<!ELEMENT ProtocolBrand (PackagedContent*) >

<!ATTLIST ProtocolBrand ProtocolId CDATA #REQUIRED

ProtocolBrandId CDATA #REQUIRED >

Атрибуты:

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. Определение элемента представлено ниже:

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

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.

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

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

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

сумму.

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

<!ELEMENT CurrencyAmount EMPTY >
<!ATTLIST CurrencyAmount ID ID #REQUIRED
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.

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