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

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

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

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

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

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

TimedOutNoRcvr

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

Команды

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

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

Эти 5 байт вместе с байтами данных образуют командный блок протокольной информации C-TPDU для Т=0.

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

Таблица 4.6.4.10. Отклик терминала на процедурный байт

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

Во всех случаях после реализации операции TTL ждет прихода процедурного байта или статусного сообщения.

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

Рис. 4.6.4.8. Структура командного APDU.

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

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

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

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

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

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

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

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

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

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

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

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

Таблица 4.6.4.14.

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

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

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

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

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

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

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

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

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

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

В общих чертах базовый процесс состоит из:

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

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

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

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

Покупатель, например, может:

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

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

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

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

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

Компоент Payment Note

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

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

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

Атрибуты:

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

Cодержимое:

PackagedContent

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

Компонент Certificate

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

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

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

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

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

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

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

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

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

Атрибуты:

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

Cодержимое:

PackagedContent

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

Компонент Delivery Note

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

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

<!ELEMENT DeliveryNote (PackagedContent+) >

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

Атрибуты:

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

ContentSoftwareId

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

Cодержимое:

PackagedContent

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

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

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

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

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

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

Атрибуты:

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

xml:lang

Определяет язык, используемый атрибутами и дочерними элементами этого компонента, если только атрибут дочернего элемента xml:lang не перепишет это значение. Смотри раздел 3.8.

DelivExch

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

о“Истинно” указывает на наличие обмена доставки.
o“Ложно” указывает на отсутствие обмена доставки.

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

DelivAndPayResp

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

o “Истинно” указывает, что оба блока находятся в одном и том же сообщении IOTP и
o “Ложно” указывает, что каждый блок размещен в разных сообщениях IOTP.

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

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

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

ActionOrgRef

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

Cодержимое:

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

Компонент Error

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

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

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

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

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

MinRetrySecs CDATA #IMPLIED

SwVendorErrorRef CDATA #IMPLIED>

Атрибуты:

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

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

SwVendorErrorRef

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

Cодержимое:

ErrorLocation

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

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

PackagedContent

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

Компонент Organisation

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

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

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

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

обеспечивать облуживание покупателя,

описать того, кто будет Кассиром.

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

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

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

xml:lang NMTOKEN #REQUIRED	OrgId CDATA #REQUIRED
LegalName CDATA #IMPLIED	ShortDesc CDATA #IMPLIED

LogoNetLocn CDATA #IMPLIED >

Атрибуты:

ID	Идентификатор, который однозначно определяет компонент Organisation в пределах текущей транзакции IOTP.
xml:lang	Определяет язык, использованный атрибутами или дочерними элементами в пределах данного компонента, если только его значение не было изменено с помощью атрибута xml:lang дочернего элемента. Смотри раздел 3.8.
OrgId	Код, который идентифицирует организацию, описанную компонентом Organisation. Смотри 7.6.1.
LegalName	Для организаций, которые являются коммерческими компаниями, это их легальное название на языке, определенном атрибутом xml:lang. Это необходимо для организаций, чьими торговыми ролями не являются Покупатель или DelivTo.
ShortDesc	Краткое описание организации на языке, определенном атрибутом xml:lang. Это обычно имя, под которым известна организация. Например, если легальное название было "Blue Meadows Financial Services Inc.", тогда его короткое имя может быть "Blue Meadows".

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

LogoNetLocn

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

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

Cодержимое:

TradingRole	Смотри 7.6.2. Элемент торговой роли.
ContactInfo	Смотри 7.6.3. Элемент контактной информации.
PersonName	Смотри 7.6.4. Персональное имя.
PostalAddress	Смотри 7.6.5. Почтовый адрес.

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

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

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

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

Атрибуты:

ID	Идентификатор, который для данной транзакции однозначно определяет компонент отклика аутентификации.
AuthenticationId	Идентификатор аутентификации, специфицированный аутентификатором, который был включен компонент запроса (смотри раздел 7.2). Это позволяет аутентификатору идентифицировать метод аутентификации.
SelectedAlgorithmRef	Ссылка элемента, которая определяет элемент алгоритма, сипользуемого для формирования отклика аутентификации.
ContentSoftwareId	Смотри раздел 14. Словарь.

Cодержимое:

PackagedContent

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

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

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

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

Временном интервале в пределах которого Кассир может начать платежную операцию;

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

следует ли предоставлять платежную расписку;

должен ли данному платежу предшествовать другой платеж.

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

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

OkFrom CDATA #REQUIRED	OkTo CDATA #REQUIRED
BrandListRef NMTOKEN #REQUIRED	SignedPayReceipt (True \| False) #REQUIRED

StartAfterRefs NMTOKENS #IMPLIED>

Атрибуты:

ID	Идентификатор, который однозначно идентифицирует платежный компонент в транзакции IOTP.
OkFrom	Дата и время в формате [UTC], после которого кассир может воспринимать на обработку блок платежного запроса (смотри раздел 8.7), содержащий компонент платежа.
OkTo	Дата и время в формате [UTC], до которого Кассир может воспринимать на обработку блок платежного запроса, содержащий компонент платежа.
BrandListRef	Ссылка элемента (смотри раздел 3.5) компонента списка видов платежа (смотри раздел 7.7) в рамках торгового блока TPO транзакции IOTP. Список видов платежа идентифицирует альтернативные способы осуществления платежа.
SignedPayReceipt	Указывает, должен ли быть подписан блок платежного отклика (смотри раздел 8.9), сгенерированный Кассиром.
StartAfter	Содержит ссылки элемента (смотри раздел 3.5) других платежных компонентов, которые описывают платежи, которые должны быть проведены до того, как будет произведен данный платеж. Если атрибут StartAfter отсутствует, тогда никаких зависимостей нет и платеж может быть проведен немедленно.

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

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

сумму платежа и его валюту;

дату и время платежа;

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

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

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

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

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

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

<!ELEMENT PayReceipt (PackagedContent*)>

<!ATTLIST PayReceipt ID	ID #REQUIRED
PaymentRef NMTOKEN #REQUIRED	PayReceiptNameRefs NMTOKENS #IMPLIED

ContentSoftwareId CDATA #IMPLIED>

Атрибуты:

ID		Идентификатор, который однозначно определяет компонент платежной расписки транзакции IOTP.
PaymentRef		Содержит ссылку элемента (смотри раздел 3.5) на компонент платежа (смотри раздел 7.9), к которому относится данная расписка.
PayReceiptNameRefs		Опционно содержит список значений атрибутов Name элементов Packaged Content, которые образуют расписку. Элементы Packaged Content могут содержать:
о	компоненты данных платежной схемы, обмен которыми производится между Кассиром и Покупателем в процессе платежа и/или
o	сам компоент платежной расписки. Заметим, что:
o	каждый компонент схемы определяет в своем приложении имена элементов Packaged Content, которые должны быть перечислены в этом атрибуте (если они нужны).
о	Если компонент платежной схемы содержит элементы Packaged Content, с именами которые совпадают с именем в PayReceiptNameRefs, тогда на такие компоненты платежной схемы должны ссылаться дайджесты в компоненте подписи платежного отклика (если используется такая подпись).

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

ContentSoftwareId

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

Cодержимое:

PackagedContent

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

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

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

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

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

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

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

PaymentRef NMTOKEN #IMPLIED	ConsumerPaymentId CDATA #IMPLIED
PaymentHandlerPayId CDATA #IMPLIED	ContentSoftwareId CDATA #IMPLIED>

Атрибуты:

ID	Идентификатор, который однозначно определяет компонент схемы оплаты транзакции IOTP.
PaymentRef	Ссылка элемента (смотри раздел 3.5) компонента платежа (смотри раздел 7.9), с которым связан компонент схемы платежа. Атрибут необходим, если только компонент схемы платежа не является частью запроса состояния транзакции (смотри раздел 9.2.1).
ConsumerPaymentId	Идентификатор, специфицированный Покупателем, который в случае возвращения Кассиром в другом компоненте схемы платежа (или другим способом) позволит Покупателю определить, о каком платеже идет речь.
PaymentHandlerPayId	Идентификатор, специфицированный Кассиром, который в случае возвращения Покупателем в другом компоненте схемы платежа (или другим способом) позволит Кассиру определить, о каком платеже идет речь. Атрибут необходим для каждого компонента схемы платежа, вне зависимости от того, что содержится в блоке платежного запроса.
ContentSoftwareId	Смотри раздел 14. Словарь.

Cодержимое:

PackagedContent

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

блок ссылки транзакции (смотри раздел 3.3) сообщения IOTP, который содержит подпись отклика доставки;

компонент данных доставки покупателя, содержащихся в предыдущем запросе доставки (если имется);

компоненты Signature, содержащиеся в предыдущем запросе доставки (если имется);

компонент Status;

компонент Delivery Note.

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

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

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

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

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

Блок ссылки транзакции (смотри раздел 3.3) сообщения IOTP, которое содержит подпись отклика предложения

из блока TPO:

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

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

из блока отклика предложения:

	компонент Order;
	каждый из компонентов Payment;
	компонент Delivery;
	каждый из компонентов запроса аутентификации;
	любой компонент данных о торговой роли.

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

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

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

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

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

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

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

компонент подписи отклика предложения;

компонент платежной расписки;

компонент Payment Note;

компонент Status;

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

любой компонент данных о торговой роли.

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

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

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

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

следующие компоненты блока TPO:

	- компонент опций протоколов;
	- компонент Organisation.

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

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

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

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

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

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

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

Атрибуты:

ID	Идентификатор, которыйоднозначно идентифицирует компонент протокольных опций в транзакции IOTP.
Xml:lang	Определяет язык, используемый атрибутами или дочерними элементами в пределах компонента, если значение не переписано атрибутом xml:lang дочернего элемента.
ShortDesc	Этот атрибут содержит краткое описание транзакции IOTP на языке, заданном xml:lang. Его целью является объяснение того, какая транзакция осуществляется партнерами.

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

SenderNetLocn

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

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

SecureSenderNetLocn

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

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

SuccessNetLocn

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

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

Компонент Related To

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

<!ELEMENT RelatedTo (PackagedContent) >

<!ATTLIST RelatedTo ID ID #REQUIRED	xml:lang NMTOKEN #REQUIRED
RelationshipType NMTOKEN #REQUIRED	Relation CDATA #REQUIRED

RelnKeyWords NMTOKENS #IMPLIED >
Атрибуты:

ID	Идентификатор, который однозначно jghtltkztn компонент Related To в рамках транзакции IOTP.
xml:lang	Определяет язык, использованный атрибутом или дочерним элементом в данном компоненте, если не переписан атрибутом xml:lang дочернего элемента. Смотри раздел 3.8.
RelationshipType	Определяет тип отношения. Корректными значениями являются:

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

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

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

Relation

Атрибут Relation содержит фразу на языке, определенном xml:lang, он определяет природу отношений между транзакцией, которая содержит этот компонент и другой транзакцией или другим событием. Окончательное текстовое выражение оставлено на усмотрение составителей программ IOTP.

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

RelnKeyWords

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

Cодержимое:

PackagedContent

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

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

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

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

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

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

содержит дайджесты одного или более блоков или компонентов в одном или нескольких IOTP-сообщениях в пределах одной транзакции IOTP и помещает результат в элемент Digest;

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

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

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

Подпись отклика предложения,

Подпись отклика платежа,

Подпись отклика доставки, или

Подпись отклика аутентификации.

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

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

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

виды платежа (смотри также раздел 11.1),

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

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

сетевые позиции Кассиров, которые воспринимают платеж в рамках платежного протокола.

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

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

<!ATTLIST BrandList ID ID #REQUIRED

xml:lang NMTOKEN #REQUIREDShortDesc CDATA #REQUIRED

PayDirection (Debit | Credit) #REQUIRED>

Атрибуты:

ID	Идентификатор, который однозначно определяет компонент списка видов платежа транзакции IOTP.
xml:lang	Определяет язык, использованный атрибутами или дочерними элементами в пределах данного компонента, если только его значение не переписано атрибутом xml:lang дочернего элемента. Смотри раздел 3.8.
ShortDesc	Текстовое описание на языке, заданном атрибутом xml:Lang, характеризующее цели списка видов платежа. Эта информация должна быть отображена у получателя списка видов платежа для того чтобы помочь сделать правильный выбор. Это привлекательно, так как позволяет Покупателю выяснить цели предлагаемого списка видов платежа, если транзакция предполагает несколько платежей.
PayDirection	Индицирует направление платежа для выбранного вида. Возможные значения:

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

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

Cодержимое:

Brand

Описывает вид платежа (Brand). Последовательность элементов Brand (смотри раздел 7.7.1) в списке видов плптежа не определяет каких-либо преоритетов. Рекомендуется, чтобы программа, которая обрабатывает этот список видов платежа представляла их в порядке предпочтения получателя.

ProtocolAmount

Это связывает конкретный вид платежа с:

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

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

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

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

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

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

Компонент Status

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

<!ELEMENT Status EMPTY >

<!ATTLIST Status ID ID #REQUIRED	xml:lang NMTOKEN #REQUIRED
StatusType NMTOKEN #REQUIRED	ElRef NMTOKEN #IMPLIED

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

Атрибуты:

ID	Идентификатор, который однозначно определяет компонент Status транзакции IOTP.
xml:lang	Определяет язык, используемый атрибутами в пределах компонента. Смотри раздел 3.8.
StatusType	Индицирует тип обмена документами, о котором сообщает компонент Status. Он может быть установлен в состояние предложение, платеж, доставка, аутентификация или “неопределено” (Undefined).

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

ElRef

Если StatusType не установлено равным Undefined (неопределено), тогда ElRef содержит ссылку элемента (смотри раздел 3.5) на компонент, для которого описан Status. Он может относиться к:

о компоненту Order (смотри раздел 7.5), если StatusType = Offer,
o компоненту Payment (смотри раздел 7.9), если StatusType = Payment,
o компоненту Delivery (смотри раздел 7.13), если StatusType = Delivery;
o компоненту запрос аутентификации (смотри раздел 7.2), если StatusType = Authentication.

ProcessState

Содержит код состояния (State Code), который индицирует текущее состояние исполняемого процесса. Допустимыми значениями ProcessState являются:

о NotYetStarted. Получен блок Request, но процесс еще не начат;
o InProgress. Обработка блока Request начата, но еще не завершена;
o CompletedOk. Обработка блока Request успешно завершена;
o Failed. Обработка блока Request не прошла из-за рабочей ошибки (Business Error) (смотри раздел 4.2)
o ProcessError. Это значение применяется, только когда компонент Status используется в связис торговым блоком информационного запроса (смотри раздел 8.12). Оно указывает, что была техническая ошибка (смотри раздел 4.1) в блоке запроса, который обрабатывается, тди другая внутренняя ошибка обработки.

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

CompletionCode

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

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

ProcessReference

Этот опционный атрибут хранит ссылку для процесса, о состоянии которого сообщается. Он может содержать следующие значения:о когда StatusType = Offer, он должен содержать OrderIdentifier компонента Order;o когда StatusType = Payment, он должен содержать PaymentHandlerPayId компонентаданных о схеме платежа;o когда StatusType = Delivery, он должен содержать DelivHandlerDelivId компонента Delivery Note;o когда StatusType = Authentication, он должен содержать AuthenticationId компонента запроса аутентификации.

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

StatusDesc

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

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

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

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

Атрибуты:

ID	Идентификатор, который однозначно определяет компонент типа информационного запроса транзакции IOTP.
Type	Содержит тип информационного запроса. Допустимые значения типа запроса: o Offer. Запрос касается статуса предложения и обращен к продавцу. o Payment. Запрос касается статуса платежа и обращен к кассиру. o Delivery. Запрос касается статуса доставки и обращен к агенту доставки.
ElRef	Содержит ссылку элемента (смотри раздел 3.5) на компонент, к которому относится информационный запрос. Это: о Блок TPO, когда тип = Offer; o Компонент Payment, когда тип = Payment; o Компонент Delivery, когда тип = Delivery.
ProcessReference	Опционно содержит ссылку на процесс, о котором произведен запрос. Он должен быть установлен, если информация доступна. Для определения значений, которые он может принимать, смотри атрибут ProcessReference компонента Status (смотри раздел 7.16).

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

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

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

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

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

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

<!ELEMENT BrandSelection (BrandSelBrandInfo?, BrandSelProtocolAmountInfo?,

BrandSelCurrencyAmountInfo?) >

<!ATTLIST BrandSelection ID ID #REQUIRED

BrandListRef NMTOKEN #REQUIRED

BrandRef NMTOKEN #REQUIRED

ProtocolAmountRef NMTOKEN #REQUIRED
CurrencyAmountRef NMTOKEN #REQUIRED >

Атрибуты:

ID	Идентификатор, который однозначно определяет компонент выбора вида платежа транзакции.
BrandListRef	Ссылка элемента (смотри раздел 3.5) компонента списка видов платежа, из которого был выбран Brand.
BrandRef	Ссылка элемента Brand компонента списка видов платежа, который был выбран из списка и использован для платежа.
ProtocolAmountRef	Ссылка элемента для Protocol Amount в пределах компонента списка видов платежа, который использован при платеже.
CurrencyAmountRef	Ссылка элемента для Currency Amount в пределах компонента списка видов платежа, который использован при платеже.

Cодержимое:

BrandSelBrandInfo,
BrandSelProtocolAmountInfo,
BrandSelCurrencyAmountInfo

Содержит любые дополнительные данные, которые могут быть необходимы при конкретном платеже
или протоколе. Смотри разделы 7.8.1, 7.8.2, и 7.8.3.

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

атрибут BrandListRef должен содержать идентификатор компонента списка видов платежа транзакции IOTP;

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

BrandRef должен относиться к ID Brand, содержащегося в компоненте списка видов платежа, на который ссылается BrandListRef

ProtocolAmountRef должен относиться к одному ID элемента, содержащемуся в атрибуте ProtocolAmountRefs элемента Brand, идентифицированного BrandRef

CurrencyAmountRef должен относиться к одному ID элемента содержащемуся в атрибуте ProtocolAmountRefs элемента Protocol Amount, идентифицированного ProtocolAmountRef.

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

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

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

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

xml:lang NMTOKEN #REQUIRED	OrderIdentifier CDATA #REQUIRED
ShortDesc CDATA #REQUIRED	OkFrom CDATA #REQUIRED
OkTo CDATA #REQUIRED	ApplicableLaw CDATA #REQUIRED

ContentSoftwareId CDATA #IMPLIED >

Атрибуты:

ID	Идентификатор, который однозначно определяет компонент Order в пределах текущей транзакции IOTP.
xml:lang	Определяет язык, использованный атрибутами или дочерними элементами в пределах компонента, если только его значение не было изменено с помощью атрибута xml:lang дочернего элемента. Смотри раздел 3.8.
OrderIdentifier	Это код, число или другой идентификатор, который автор заказа может использовать для идентификации заказа. В пределах транзакции он должен быть уникальным. Если он используется так, то нет нужды специфицировать содержимое элемента заказа, так как имеется ссылка на нужную информацию в базе данных.
ShortDesc	Краткое описание заказа на языке, определенном атрибутом xml:lang. Оно используется для упрощения выбора индивидуального заказа из списка, например, из базы данных заказов, записанных туда продавцом, покупателем и т.д..
OkFrom	Дата и время в формате [UTC], после которого предложение, сделанное Продавцом теряет силу.
OkTo	Дата и время в формате [UTC], до которого получатель может воспринимать предложение продавца не имеющим силу.
ApplicableLaw	Фраза на языке, определенном атрибутом xml:lang, которая описывает штат или страну, юристдикция которой будет использована при разрешении конфликтов и споров.
ContentSoftwareId	Смотри раздел 14. Словарь.

Cодержимое:

PackagedContent

Опционное описание заказа в виде одного или более элементов Packaged Content (смотри раздел 3.7).

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

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

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

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

Атрибуты:

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

Cодержимое:

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

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

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

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

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

Атрибуты:

ID	Идентификатор, который однозначно определяет компонент информационного запроса для торговой роли в рамках транзакции IOTP.
TradingRoleList	Содержит список из одной или более торговых ролей (смотри атрибут TradingRole элемента Trading Role - раздел 7.6.2), для которых была запрошена информация.

Конфиденциальность

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

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

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

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

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

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

Когда бы ни был получен компонент данных торговой роли в блоке "Отклик", идентифицировать компоненты Organisation, которые должны получить его, как идентифицированные атрибутом DestinationElRefs.

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

	- компонент данных о торговой роли, а также,
	- компонент Organisation, идентифицированной атрибутом OriginatorElRef.

MicroMint

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

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

Монеты MicroMint формируются с использованием кратных столкновений хэш-функций. Однопроходная хэш-функция H ставит в соответствие m битам строки х n бит строки y. Строка х называется исходным образом y, если H(x)=y. Пара строк (х1,х2) называются двойным столкновением, если H(x1)=H(x2)=y, где строка y имеет n бит. Если хэш-функция гарантирует достаточно высокий уровень рэндомизации, то для получения одного двойного столкновения необходимо вычислить для строки х примерно 2n/2 xэш-функций. Но при ограниченном n вычисление двойных столкновений является относительно простой задачей и для злоумышленника, по этой причине для формирования монет чаще используется вычисление k-кратных столкновений.

k-кратным столкновением называется набор строк х1, х2, …, хk для которых H(x1)=H(x2)=…=H(xk)=y. Для получения k-кратного столкновения необходимо выполнить вычисление примерно 2n(k-1)/k хэш-функций. В дальнейшем будем считать, что монета характеризуется k-кратным столкновением (х1, х2, …, хk). Корректность монеты может проверить кто угодно, вычислив k хэш-функций и проверив условие.

H(x1)=H(x2)=…=H(xk)=y

Если в ходе вычисления хэш-функций просматривать результат, то можно выявить определенное число k-кратных столкновений, что во много раз увеличивает производительность генерации электронных монет.
Еще большего выигрыша в скорости можно достичь, применяя специфические аппаратные реализации. Предположим, что брокер хочет иметь чистый доход размером в 1 млн. долларов США (эквивалентно примерно 227 центов/месяц). Пусть доходы брокера составляют 10%, это означает, что продавец получает 0,9 цента при выкупе монеты. Таким образом, брокер должен продать миллиард монет в месяц. Если обычный клиент покупает 2500 монет в месяц, необходимо иметь 500000 клиентов. Пусть k=4 (4-кратные столкновения). Для того чтобы сформировать 230 монет, надо будет закупить специализированное оборудование стоимостью около 100000$ (что менее 10% месячного дохода). Для целей вычисления хэш-функций могут использоваться специализированные ИС, применяемые для DES-шифрования или ИС FPGA - программируемые логические матрицы. Подготовка брокером нового набора монет может продолжаться в течение всего месяца. Нетрудно понять, что злоумышленнику, использующему обычную рабочую станцию, сформировать самостоятельно достаточное число монет не по плечу. При продаже монет клиенту брокер запоминает, какому клиенту какие монеты проданы, что позволяет в будущем проконтролировать попытки злоупотреблений. Неиспользованные монеты ликвидируются в конце месяца. Ограничение времени действия монет создает определенные трудности для клиента. Но за то это ограничивает требуемые объемы баз данных, хранящих информацию о выпущенных и использованных уже монетах. Монетная система по своей природе предполагает определенное доверие между плательщиком и получателем платежа. Получатель может присвоить монету и заявить, что она уже была использована, а плательщик может предъявить претензии получателю (банку или продавцу), утверждая, что повторного использования не было, а монета просто присвоена. В сущности, это является общим свойством любых монет и сертификатов на предъявителя. Каждый раз, когда клиент осуществляет покупку, он пересылает продавцу одну или несколько монет (х1, х2, …, хk). Это может осуществляться автоматически программой WEB-броузера.

Продавец проверяет корректность монет путем вычисления k функций H(xi), что занимает совсем немного вычислительных ресурсов. При возвращении монет продавцом брокеру проверка повторяется. Существуют методы формирования монет специфических для клиента или для продавца, что снижает риски злоупотреблений (смотри “PayWord and Micromint: Two simple micropayment schemes” Ronald L. Riverst и Adi Shamir, 7 мая 1996). Мелкомасштабная атака малоэффективна, и по этой причине недостойна серьезного внимания (злоумышленник должен понести большие издержки из-за нескольких центов). Для такого рода атак для k=4 и n=54 при использовании стандартной рабочей станции требуются десятки лет. Крупномасштабное мошенничество легко детектируется из-за следующих обстоятельств. Все фальшивые монеты теряют силу в конце месяца.Фальшивые монеты могут быть сформированы после того, как брокер выбросил на рынок новую партию монет в начале месяца.Брокер может обнаружить присутствие фальшивок из-за того, что некоторые фальшивые монеты неизбежно не соответствуют ни одной из настоящих, которые все зарегистрированы.Брокер может в любой момент объявить об истечении срока годности выпущенных в оборот монет и запустить в оборот новую партию. Возможность кражи монет в ходе пересылки блокируется с помощью шифрования, что легко осуществить, так как взаимоотношения между клиентами продавцами и брокерами являются долгосрочными и доверительными. Схема MicroMint не является анонимной, поэтому брокер легко может детектировать попытки повторного использования монет. Обнаружить мелкого злоумышленника трудно, но из-за низкой цены монет это не может вызвать проблем. Генерация монет, специфических для клиента или продавца делают кражу бесполезной. Таким образом, любые злоупотребления легко обнаруживаются, но так как в MicroMint не используются подписи, выяснение отношений в суде невозможно. Для генерации монет, специфических для клиентов, последние делятся брокером на группы. Например, клиенту U даются монеты, которые дополнительно отвечают требованию h(х1, х2, …, хk)=h(U), где h - хэш-функция, формирующая 16-битовый код.

Данное решение может оказаться не слишком хорошим для больших групп, где вор всегда сможет найти клиента, желающего приобрести украденные монеты. При малых же группах брокер будет вынужден производить слишком большую вычислительную работу. Другим вариантом может быть обобщение понятия столкновения. Монета (х1, х2, …, хk) будет считаться корректной для клиента U, если образы y1=(x1), y2=(x2),…, yk=(xk) удовлетворяют условию yi+1 - yi = di (mod 2u) для i =. 1,2,..,k-1, где (d1,d2,…,dk-1)=h(U). Стандартный алгоритм формирования монет соответствует случаю, когда все значения d равны нулю. Формирование монет специфических для продавца может осуществляться согласно алгоритму, схожему с выше описанным. Существуют алгоритмы, которые позволяют сократить вычислительные издержки при массовой генерации монет сразу на несколько месяцев. Другие системы для осуществления небольших платежей, например, NetBill предлагают дополнительные возможности (например, заказы товара и шифрование информации о покупке), но они относительно дороже.

Насыщенность цвета логотипа

Существует три стандартных значения насыщенности цвета. Насыщенность цвета (включая число бит на пиксель) и соответствующее значение для Logo_Color_Depth представленны ниже в таблице.

Насыщенность цвета	Цвет логотипа
(бит на пиксель)	Значение насыщенности
4 (16 цветов)	4
8 (256 цветов)	ничего
24 (16 миллионов цветов)	24

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

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

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

Значение

Описание

InMsgHardError

Серьезная ошибка во взодном сообщении (Input Message Hard Error). Тип блока запроса не может быть идентифицирован или является несовместимым. Следовательно никакой однодокументный обмен не может быть идентифицирован. Это может вызвать серьезную ошибку в транзакции.

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

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

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

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

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

Обмен документами при доставке

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

Покупатель запрашивает доставку путем формирования сообщения запроса доставки. При этом используется информация предыдущего IOTP-сообщения транзакции и затем посылает его Агенту доставки;

Агент доставки посылает сообщение отклика доставки покупателю. Это сообщение содержит детали отклика агента на запрос и опционно цифровую подпись.

Схема обмена сообщениями представлена на рис. .22.

1.	Покупатель генерирует блок запроса доставки и посылает его агенту доставки, снабдив, если требуется, цифровой подписью
C а D	Запрос доставки. IotpMsg: блоки Trans Ref; подписи; запроса доставки
2.	Агент доставки проверяет компоненты Status и Order запроса доставки и опционно подпись, создает блок отклика доставки, посылает его покупателю.
C Я D	Отклик доставки. IotpMsg: блоки Trans Ref; подписи; отклика доставки
3.	Покупатель проверяет блок отклика доставки и опционный блок подпии. Опционно производит запись о транзакции на будущее.

Рис. .22. Обмен документами при доставке

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

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

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

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

Кассир посылает сообщение платежного отклика покупателю, где содержится платежная расписка.

IOTP-сообщения, которые используются при платежном обмене показаны на рис. .21.

1.	Покупатель формирует блок платежного запроса, если необходимо, инкапсулирует в него сообщение платежного протокола, и посылает кассиру, снабжая при необходимости цифровой подписью
C а P	Запрос платежа. IotpMsg: блоки Trans Ref; подписи (опционный); платежного запроса
2.	Кассир обрабатывает блок платежного запроса, проверяет подпись, если таковая имеется, и начинает обмен с покупателем сообщениями (вложенными в блок платежного обмена) согласно платежному протоколу
C « P	Платежный обмен. IotpMsg: блоки Trans Ref; Pay Exchange
3.	Покупатель и кассир продолжают обмен платежными блоками, пока платеж не будет осуществлен и кассир не сформирует платежную расписку (которая опционно может быть снабщена цифровой подписью) и не пошлет ее покупателю. Эта операция завершает платежный обмен.
C Я P	Платежный отклик. IotpMsg: блоки Trans Ref; Signature (опционный); платежного отклика
4.	Покупатель проверяет, все ли в порядке с платежным откликом. Опционно могут регистрироваться все операции IOTP. После этого покупатель может остановиться или послать очередное сообщение IOTP (снабдив его, если требуется, подписью) соответствующей торговой роли

Рис. .21. Обмен платежными документами

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

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

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

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

Кассир посылает покупателю в одном сообщении IOTP:

	- блок платежного отклика, содержащий платежную расписку, и
	- блок отклика доставки, содержащий подробности о доставленных товарах или услугах.

IOTP-сообщения, которые вовлечены в этот процесс, показаны на рис. .23.

1.	Покупатель генерирует блок платежного запроса, в который, если требуется, вкладывается сообщение платежного протокола, и посылает его кассиру, снабжая опционно цифровой подписью
C а P	Платежный запрос. IotpMsg: блоки Trans Ref; подписи; платежного запроса
2.	Кассир обрабатывает блок платежного запроса, проверяет опционную подпись и начинает обмен с покупателем в рамках платежного протокола (вкладывая эти сообщения в блоки платежного обмена)
C « P	Платежный обмен. IotpMsg: блоки Trans Ref; платежного обмена
3.	Покупатель и кассир обмениваются блоками платежного обмена до тех пор пока платежный протокол не завершит свою работу. Кассир формирует компонент платежной расписки, помещает его в блок платежного отклика, опционно формирует компонент подписи, который укладывается в блок Signature, затем использует информацию из блока отклика предложения, чтобы сформировать блок отклика отклика доставки и посылает его покупателю.
C Я P	Отклики платежа и доставки. IotpMsg: блоки Trans Ref; подписи; платежного отклика; отклика доставки
4.	Покупатель проверяет блоки платежного отклика и отклика доставки. Опционно он может вести запись всех транзакций. Здесь покупатель может остановиться или сформировать очередное сообщение и послать его соотвествующе торговой роли.

Рис. .23. Документальный обмен платежа и доставки

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

Атрибут DelivAndPayResp компонента доставки (смотри раздел 7.13), содержащийся в блоке отклика Offer (смотри раздел 8.3), делается равным True, если блоки отклика доставки и платежного отклика объединены в одном сообщении, и равен False, если блоки отклика доставки и платежного отклика посланы в разных IOTP-сообщениях.

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

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

1.	Покупатель решает осуществить сделку и посылает информацию продавцу о том, что нужно доставить и как это лучше сделать.
C а M	Информация о том, что следует доставить (вне зоны ответственности IOTP)
2.	Продавец проверяет информацию, полученную от покупателя, добавляет информацию о том, как будет осуществляться доставка, информацию об организациях, вовлеченных в доставку и, опционно, электронную подпись, после чего отправляет все это покупателю.
C Я M	Компоненты: lоставка; jрганизации (fгент доставки, доставит туда-то); заказ, опционная подпись отклика-предложения
3.	Покупатель проверяет, корректна ли доставочная информация, получает разрешение на доставку, например путем оплаты, и посылает эти данные агенту доставки.
C а D	Запрос доставки. Компоненты: cтатус; доставка, организации: (продавец, агент доставки, DelivTo); Заказ, данные о торговой роли (опционны); опционная подпись отклика-предложения, опционная подпись платежной расписки (из платежного обмена)
4.	Агент доставки проверяет информацию и авторизацию. Запускает или диспетчеризует доставку, а также готовит и отправляет накладную покупателю, которая опционно может быть подписана.
C Я D	Отклик доставки. Компоненты: статус; накладная (Delivery Note), данные о торговой роли (опционны); опционная подпись отклика доставки
5.	Покупатель проверяет накладную и принимает товар или ждет доставки, как это указано в накладной (Delivery Note).

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

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

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

Компоненты организации содержат информацию об адресе доставки и ролях агента доставки и продавца:

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

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

Компонент доставки содержит информацию о том, как будет осуществлена доставка, например по почте или с помощью e-mail.

Компонент подписи предложения-отклика (Offer Response), если присутствует, электронным образом подписывает все перечисленные выше компоненты, обеспечивая их целостность.

Компонент подпись платежной расписки (Payment Receipt) предоставляет подтверждение платежа, с помощью электронной подписи компонента платежной расписки и предложения. Это используется агентом доставки для проверки того, что доставка авторизована.

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

Компонент подпись отклика доставки (Delivery Response), если присутствует, предоставляет подтверждение результатов доставки путем электронной подписи накладной (Delivery Note) и подписей любого отклика-предложения или отклика платежа, которые получил агент доставки.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

принимающие средства как часть депозитной операции;

выдающие средства при отмене сделки.

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

Продавцы
	Склад		Платильщик	Получатель платежа	Покупатель	Кассир		Агент доставки
Транзакции
Покупка	Нужно				Нужно
Продавцы
	Store		Пла-тиль-щик	Получа-тель платежа	Покупатель	Кассир	Агент доставки
Возврат средств	Нужно				b) Зависит
Аутентификация	Можно		Нужна	Можно	b) Зависит
Обмен ценностями	Можно				Нужно
Отзыв			Нужно		b) Зависит
Депозит				Нужно	b) Зависит
Запрос данных	Нужно		Нужно	Нужно	Можно	Нужно	Нужно
Ping	Нужно		Нужно	Нужно	Можно	Нужно	Нужно
Торговые блоки
TPO	Нужно		Нужно	Нужно	Нужно
Выбор TPO	Нужно		Нужно	Нужно	Нужно
Запрос Auth	a) Зависит			a) Зависит	a) Зависит
Отклик Auth	a) Зависит			a) Зависит	a) Зависит
Отклик предложения	Нужно		Нужно	Нужно	Нужно
Запрос платежа					Нужно	Нужно
Платежный обмен					Нужно	Нужно
Платежный отклик					Нужно	Нужно
Запрос доставки					Нужно		Нужно
Отклик доставки					Нужно		Нужно
Продавцы
	Склад	Платильщик		Получа-тель	Покупатель	Кассир	Агент доставки
Запрос данных	Нужно	Нужно		Нужно	Нужно	Нужно	Нужно
Отклик данных	Нужно	Нужно		Нужно	Нужно	Нужно	Нужно
Запрос Ping	Нужно	Нужно		Нужно	Нужно	Нужно	Нужно
Отклик Ping	Нужно	Нужно		Нужно	Нужно	Нужно	Нужно
Подпись	Нужно	Нужно		Нужно	Ограничено	Нужно	Нужно
Ошибка	Нужно	Нужно		Нужно	Нужно	Нужно	Нужно

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

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

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

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

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

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

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

Обзор системы

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

Вначале покупатель должен загрузить общедоступное программное обеспечение CyberCash из Интернет. Эта программа устанавливает соединение между покупателями, продавцами и их банками. Доступ к системе CyberCash еще проще, кнопки CyberCash "PAY" могут быть вставлены в популярные программы реального времени, позволяя клиенту войти в систему CyberCash, когда он пожелает осуществить оплату товара или услуги. Покупатель может не иметь до этого каких-либо отношений с CyberCash. Клиент идентифицирует свою личность через сеть.

Транзакции используют информацию, введенную клиентом в свою ЭВМ, никакого ручного ввода данных для аутентификации не требуется. Покупатель лишь запускает платежную процедуру для каждой транзакции путем выбора одной из опций. Безопасность транзакций обеспечивается криптографически. Конфиденциальная информация о покупателе по каналам связи (например, продавцу) не пересылается.

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

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

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

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

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

Opaque Embedded Data

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

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

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

o	Процедуру запроса (смотри раздел 9.2.1)
o	Транзакцию Ping (смотри раздел 9.2.2)
o	Процедуру аутентификации (смотри раздел 9.1.6)

Операции IOTP

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

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

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

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

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

Возврат. Поддерживает возврат денег для сделанной ранее покупки.

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

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

Отзыв. Поддерживает отзыв электронного платежа из финансовой организации.

Депозит. Поддерживает депозит электронного платежа в финансовой организации.

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

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

Определение двойственного вид платежа (Dual Brand)

Двойственный вид платежа (Dual Brand) означает, что отдельный платежный инструмент может использоваться так, как если бы это были два отдельных вида платежа. Например, может существовать одна японская карта "UC" (MasterCard), которую можно использовать как UC-карту или как обычную MasterCard. Виды платежа через UC-карту и MasterCard могут иметь своих собственных, отличных друг от друга Кассиров. Это означает, что:

продавец рассматривает, например,"UC" и "MasterCard" как два вида платежа, когда предлагает список видов платежа покупателю,

покупатель выбирает вид платежа, например, "UC" или "MasterCard,

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

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