Размер Logo

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

Размер в пикселях	Размер логотипа значение
32 x 32 или 32 x 20	exsmall (сверх малый)
53 x 33	small (малый)
103 x 65	medium (средний)
180 x 114	large (большой)
263 x 166	exlarge (сверх большой)

Регистрация персоны и нахождение приложения

Первым шагом, который должен сделать клиент, чтобы использовать CyberCash, является регистрация персоны с помощью своего приложения. Это делается с помощью сообщения R1, описанного ниже. Сервер CyberCash откликается сообщением R2.

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

SET и другие системы осуществления платежей

Семёнов Ю.А. (ГНЦ ИТЭФ), book.itep.ru

Идеальная платежная система должна отвечать следующим требованиям:

Безопасность системы должна препятствовать воровству денег на всех этапах выполнения операции.

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

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

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

Система должна быть открытой (протоколы и тесты программ должны быть общедоступны).

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

Должна предоставлять достаточное количество данных для целей аудита.

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

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

А. Электронные монеты
Б. Электронные чеки
В. Электронные переводы (трансферты)

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

Модель электронных монет

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

Модель электронных чеков

Данная модель с хорошей точностью воспроизводит практику применения обычных чеков.
Клиент заполняет электронный чек, который представляет собой платежное поручение. Этот чек подписывается электронным образом и передается партнеру (например, продавцу), который предъявляет его банкиру. Банкир проверяет корректность чека, наличие необходимых средств на счете клиента, заполнившего чек, и, если все в порядке, переводит средства на счет продавца. Преимуществом этой модели является простота, легкость разрешения любых споров, а также отсутствие требование выполнения всех операций в реальном масштабе времени. Уровень конфиденциальности здесь также вполне разумен. Модель электронных переводов Данная модель простейшая из описанных. Плательщик выдает платежное поручение банкиру, снабжая его электронной подписью. Банкир верифицирует платежное поручение, проверяет наличие средств и, если все в порядке, осуществляет перевод денег. Операция со стороны плательщика выполняется в реальном масштабе времени. Эта модель прозрачна, получатель перевода не должен быть доступен в реальном масштабе времени. Схема хороша для начисления зарплаты, но совершенно не приемлема для торговли через Интернет. Теперь рассмотрим требования к безопасности платежной системы. В случае работы через Интернет эти требования должны быть достаточно жестки, так как сами транспортные протоколы TCP/IP практически не предоставляют сколько-нибудь существенной защиты. Никто кроме владельца счета не может иметь к нему доступа, и никто не должен иметь возможности имитировать работу владельца счета.Плательщик должен иметь возможность доказать третьей стороне, что платеж произведен и предоставить данные о предмете платежа. Это необходимо в случае конфликта, когда клиент либо не получил оплаченный товар, либо, например, не удовлетворен его качеством. Здесь нужно учитывать возможность случайного или преднамеренного искажения сообщений при их передаче.Получатель платежа должен иметь возможность доказать третей стороне, какую сумму, когда, за что и от кого он получил. Это нужно для разрешения возможных конфликтов с клиентом.Банкир должен иметь возможность доказать третьей стороне, что он при работе со счетами строго следовал платежным поручениям.

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

Severity = Hard Error

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

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

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

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

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

	- сформироать сообщение с компонентом Error и атрибутом Severity = Warning, после чего послать его со следующим сообщением (если такое имеется) торговой роли, которая прислала сообщение об ошибке с неверным значением MinRetrySecs и
	- использовать величину MinRetrySecs, установленное поставщиком/ разработчиком приложения IOTP.

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

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

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

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

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

	- продолжеть транзакцию как обычно или
	- прервать транзакцию, выработав сообщение с компонентом Error и атрибутом Severity = HardError (смотри раздел 7.21.1.3).

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

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

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

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

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

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

Скрытая часть

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

Скрытая часть сообщения выделяется метками "opaque" или "merchant-opaque" в зависимости оттого, клиент или продавец зашифровал эти данные.

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

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

Словарь

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

Имя	Описание
Аутентификатор	Организация, которая запрашивает аутентификацию другой организации
Аутентифицируемый	Организация, которая осуществляет аутентификацию у аутентификатора
Рабочая ошибка (Business Error)	Смотри компонент Status.
Вид платежа (Brand)	Вид платежа представляет собой идентификатор определенного типа платежного инструмента. Список видов платежа явлется перечнем платежных опций, которые предоставляются продавцом покупателю и из которого последний выбирает вид оплаты. Каждый вид платежа может иметь разных кассиров. Примеры видов платежей включают в себя: о частные и корпоративные виды платежей, например MasterCard, Visa, American Express, Diners Club, American Express, Mondex, GeldKarte, CyberCash, и т.д.. вльготные виды платежа (смотри ниже). Последние включают в себя: o магазинные виды платежа, где платежный инструмент предоставляется покупателю конкретным продавцом, например Walmart, Sears или Marks and Spencer (UK) o комбинированные виды платежа, например American Advantage Visa, где компания использует свою собственную системы о платы, которая совмещается с каким-то корпоративным видом платежей.
Покупатель	Организация, которая обычно платит за товары или услуги.
ContentSoftwareId	Содержит информацию, которая идентифицирует программу, генерирующую содержимое элемента. Ее целью является помощь в разрешении проблем совместимости, которые могут возникнуть в результате несоответствия между сообщениями, выработанными различными программами. Это текстовая строка на языке, определенном xml:lang. Этот идентификатор должен содержать как минимум: наименования разработчика программы название программы версию программы и структуру программы Рекомендуется, чтобы этот атрибут включался всякий раз, когда программа, которая сформировала содержимое, не может быть идентифицирована атрибутом SoftwareID Id-компонента сообщения (смотри раздел 3.3.2)
Агент обслуживания		Организация, которая обслуживает покупателя, обычно от имени продавца. Примеры обслуживания покупателя включают в себя, реагирование на задачи, которые ставит покупатель в ходе реализации транзакций IOTP, в которых он участвует.
Агент доставки		Организация, которая непосредственно доставляет товары или услуги покупателю от имени продавца. Доставка может иметь цифровую форму (напр., в виде сообщений [MIME]), или физическую форму с привлечением почты или курьеров.
Документальный обмен		Документальный обмен состоит из последовательности сообщений, которыми обмениваются партнеры в рамках одного или двух торговых операций одновременно. Документальные обмены могут комбинироваться, образуя конкретную транзакцию IOTP.
Двойственный вид платежа (Dual Brand)		Двойственный вид платежа означает, что один платежный инструмент может использоваться так, как будто имеются два независимых вида платежа. Например, японская карта "UC" MasterCard может быть использована как UC-карта или как обычная MasterCard. Платежи с помощью UC-карты и MasterCard могут иметь разных Кассиров. Это означает, что: o Продавец рассматривает, например "UC" и "MasterCard" как два независимых вида платежа, когда предлагает Покупателю список видов платежей, Покупатель выбирает вид платежа, например "UC" или "MasterCard, o Приложение IOTP Покупателя определяет, какой платежный инструмент подходит для выбранного вида платежа, и делает свой выбор.
Блок Error		Блок Error сообщает, что в полученном сообщении IOTP обнаружена техническая ошибка. Обычно технические ошибки вызываются ошибками в XML или сбоями в процессе обработки сообщения. Часто генерация или получение блока Error вызывает прерывание транзакции. Эти ошибки отличаются от рабочих ошибок (Business Error), о которых сообщается в компонентах Status. Последние ошибки также могут привести к срыву выполнения транзакции.
Блок Exchange		Блок Exchange посылается при торговом обмене от одной торговой роли к другой. Он содержит один или более торговых компонентов. Блоки Exchange при торговом обмене всегда посылаются после блоков Request и до блока Response (отклика). Соджержимое блока Exchange зависит от типа торгового обмена.
Сообщение IOTP		Сообщение IOTP является самой внешней структурой, в которую помещаются документы, которыми обмениваются торговые роли, принимающие участие в сделке. Это хорошо сформатированный XML-документ. Документы, которые содержат сообщение, состоят из: o блок ссылок транзакции, служащий для однозначной идентификации, частью которой является сообщение IOTP; o опционный блок Signature, который служит для цифровой подписи торговых блоков или компонентов, связанных с транзакцией IOTP; o опционный блок Error для уведомления о технических ошибках, содержащихся в предыдущем полученном сообщении IOTP и o последовательность торговых блоков IOTP, которые несут данные, необходимые для выполнения транзакции.
Транзакция IOTP		Транзакция IOTP (Internet Open Trading Protocol) представляет собой набор IOTP-сообщений, передаваемых торговыми ролями. Правила о том, что могут содержать IOTP-сообщения, определяются типом транзакции.
Тип транзакции IOTP		Тип транзакции идентифицирует ее разновидность. Примерами транзакции могут служить: покупка, возврат денег, аутентификация, отзыв, депозит. Типы транзакции IOTP определяет: o торговые обмены, которые могут включаться в транзакцию; o то, как эти торговые обмены могут комбинироваться, чтобы обеспечить достижение цели транзакции; o какие торговые блоки могут быть включены в IOTP-сообщения, образующие транзакцию.
Продавец		Организация, которая предоставляет товары или услуги, и получает выгоду от платежей за них
Агент обслуживания Покупателя		Организация, которая вовлекается в диалог с покупателем от имени продавца с целью разрешения возникающих проблем
Организация		Компания или частное лицо, которое принимает участие в сделке и выполняет определенную торговую роль. Организации могут выполнять и несколько торговых ролей в одной сделке
Кассир		Организация, которая физически получает платеж от покупателя для продавца
Платежный инструмент		Платежный инструмент представляет собой средство, с помощью которого покупатель платит за товары или услуги, предлагаемые продавцом. Это может быть, например: кредитная карта, такая как MasterCard или Visa; > дебетная карта, такая как MasterCard's Maestro; смарт-карта, базирующаяся на электронном платежном инструменте, таком как Mondex, GeldKarte или Visa Cash электронный платежный счет, базирующийся на программе, такой как CyberCash's CyberCoin или DigiCash. Все платежные инструменты имеют номер, обычно это номер счета, с помощью которого платежный инструмент может быть идентифицирован.
Льготный вид платежа		Льготный вид платежа предполагает, что, если покупатель воспользуется этим видом оплаты, тогда он получит дополнительную выгду, которая может быть реализована двумя путями: в момент покупкиse. Например, если покупатель платит с помощью "Walmart MasterCard" на WEB-сайте Walmart, тогда он получает скидку 5%, а это означает, что покупатель в действительности заплатит меньше, от эмитента платежного инструмента (карты), когда платеж появится в ведомости. Например, если сумма платежей с использованием данного платежного инструмента превысила некоторое значение. В списке видов платежа, предлагаемом продавцом, каждый льготный вид должен идентифицироваться, как независимый.
Компонент Receipt (расписка)		Компонент Receipt является записью об успешном завершении торгового обмена. Примеры компонентов Receipt включают в себя: платежные расписки и накладные при доставке (Delivery Notes). Их содержимое зависит от технологии выполнения торгового обмена. Например, платежная расписка SET (Secure Electronic Transaction) состоит из платежных сообщений SET, которые фиксируют результат оплаты.
Блок запроса		Блок запроса является торговым блоком, который содержит запрос начала торгового обмена. Торговые компоненты в блоке запроса могут быть подписаны с помощью блока Signature, что позволит идентифицировать отправителя. Авторизация начала торгового обмена может быть выполнена с помощью подписей, содержащихся в компонентах Receipt, которые вложены в блоки откликов предыдущего торгового обмена. Примерами блоков запроса могут служить запросы платежа и запросы доставки
Блок отклика		Блок отклика является торговым блоком, который указывает, что торговый обмен завершился. Он посылается торговой ролью, которая получила блок запроса, торговой роли. Блок отклика содержит компонент Status с информацией о завершении торгового обмена, например, он указывает, завершился ли торговый обмен успешно. Для некоторых торговых обменов блок отклика содержит компонент Receipt (расписка). Компоненты Receipt могут цифровым образом подписывать сообщение с использованием блока Signature, что делает завершение торгового обмена неопровержимым. Примеры блоков отклика включают в себя отклики предложения, платежа и доставки.
Блок подписи		Блок подписи является торговым блоком, который содержит одну или более цифровых подписей в виде компонентов Signature. Компонент Signature может цифровым образом подписывать любой блок или компонент в любом сообщении IOTP
Компонент Status		Компонент Status содержит информацию, которая описывает состояние торгового обмена. До завершения торгового обмена компонент Status может указывать на то, как он проходит. Если же торговый обмен завершился, компонент Status может говорить лишь об успешном завершении или о наличии рабочей ошибки. Рабочая ошибка указывает, что продолжение торгового обмена невозможно, так как нарушено какое-то правило, например, "нет достаточных средств". При этом не предполагается каких-либо технических ошибок, связанных с содержимым или форматом IOTP-сообщения в транзакции.
Техническая ошибка		Смотри блок Error.
Торговый блок		Торговый блок состоит из одного или более торговых компронент. Один или более торговых блоков может содержаться в IOTP-сообщениях, которые пересылаются в форме XML-документов от одной торговой роли к другой. Сущетсвует три типа торговых блоков: o блок Request, o блок Exchange или o блок Response
Торговый компонент		Торговый компонент является собранием XML-элементов и атрибутов. Торговые компоненты являются дочерними элементами Торговых блоков. Примерами торговых компонентов являются: Предложение, Список видов платежей, Платежная расписка, Доставка [информации], Сумма платежа
Торговый обмен		Торговый обмен предполагает обмен последовательностью документов, пересылаемых между торговыми ролями. Документы могут иметь форму торговых блоков или они могут быть пересланы каким-то другим образом, например, путем ввода данных на WEB-странице. Каждый торговый обмен состоит из трех главных частей: посылки блока запроса торговой ролью (инициатором) другой торговой роли (получателю); опционного обмена одним или более блоков между инициатором и получателем до тех пор, пока торговая роль, которая получила блок запроса, не отправит блок отклика инициатору. Примерами торговых обменов/услуг могут служить: платеж, где покупатель осуществляет платеж кассиру; доставка, где покупатель запрашивает, и опционно получает, товар или услугу от агента доставки; аутентификация, где любая торговая роль может запросить и получить информацию о другой торговой роли; предложение, которое получает покупатель от продавца, имеет целью предложить какую-то торговую сделку (транзакцию).
Торговая роль		Торговая роль идентифицирует различные способы, которыми организации могут участвовать в сделке. Существует пять торговых ролей: Покупатель, Продавец, Кассир, Агент доставки и Агент обслуживания покупателя.
Блок ссылок транзакции		Блок ссылок транзакции идентифицирует транзакцию IOTP. Он содержит данные, которые идентифицируют: тип транзакции; транзакцию IOTP, снабжая ее уникальным идентификатором; сообщение IOTP, снабжая его уникальным идентификатором. Блок ссылок транзакции может также содержать ссылки на другие транзакции, которые, вообще говоря, могут и не быть транзакциями IOTP

Смарт-карты EMV

Семёнов Ю.А. (ГНЦ ИТЭФ), book.itep.ru

В основу данной спецификации легли разработки компаний Europay, MasterCard и Visa (EMV) в марте, 1998 года. Следует принимать во внимание, что данная технология будет использоваться не только для финансовых операций. Планируется ее применения для проездных билетов и контроля доступа к ЭВМ. В перспективе можно предположить, что эта техника будет использоваться для идентификации личности, например, вместо паспорта.

IEC 512-2:1979	Спецификации для электромеханических компонентов оборудования - Часть 2: Тесты сопротивления контактов, тесты проверки изоляции и перегрузок
FIPS Pub 180-1:1995	Стандарт на безопасные хэши. Спецификация терминала платежных систем для карт с интегральными схемами
ISO 639:1988	Коды названий языков
ISO 3166:1997	Коды названий стран
ISO 4217:1995	Коды валют и фондов
ISO/IEC 7811-1:1995	Идентификационные карты - Метод записи - Часть 1: Тиснение
ISO/IEC 7811-3:1995	Идентификационные карты - Метод записи - Часть 3: Положение вытисненных символов на картах ID-1
ISO/IEC 7813:1995	Идентификационные карты - Карты для финансовых операций
ISO/IEC DIS 7816-1:1998	Идентификационные карты - Карты с интегральными схемами, имеющими внешние контакты.
	Часть 1:	Физические характеристики ISO/IEC DIS 7816-2:1998
	Часть 2:	Размеры и положение контактов
ISO/IEC 7816-3:1989	Часть 3:	Электрические сигналы и протоколы передачи
ISO/IEC 7816-3:1992	Часть 3:	Протокол типа T=1, асинхронный полудуплексный протокол блочной передачи
ISO/IEC 7816-3:1994	Часть 3:	Выбор типа протокола
ISO/IEC 7816-4:1995	Часть 4:	Команды обмена
ISO/IEC 7816-5:1994	Часть 5:	Процедура для выработки прикладных идентификаторов
ISO/IEC 7816-6:1996	Часть 6:	Информационные элементы
ISO 8731-1:1987	Часть 1:	Алгоритмы аутентификации сообщений (DEA)
ISO 8372:1987	Обработка информации. Режимы работы для 64-битовых блочных алгоритмов шифрования/дешифрования
ISO/IEC 8825:1990	Информационная технология. Соединение открытых систем. Спецификация базовых правил кодирования для синтаксической нотации ASN.1
ISO 8583:1987	Сообщения банковских карт - Спецификации сообщений - Содержимое финансовых транзакций
ISO 8583:1993	Сообщения транзакций банковских карт - Спецификации сообщений
ISO 8859:1987	Обработка сообщений - 8-битовые графические символьные наборы
ISO/IEC 9796-2: 1997	Информационная технология - Методы безопасности - Схема восстановления сообщений с цифровой подписью. Часть 2: Механизм использования хэш-функций
ISO/IEC 9797:1994	Информационная технология - Методы безопасности - Механизм информационной целостности, использующий функцию криптографической проверки на базе алгоритма блочного шифра
ISO/IEC 10116: 1997	Информационная технология - режимы работы алгоритмов n-битовых блочных шифров
ISO/IEC 10118-3: 1998	Информационная технология - Методы безопасности - хэш-функции

Рис. 4.6.4.1. Расположение контактов на лицевой стороне карты

Рис. 4.6.4.2. Положение контактов (все контакты имеют размер 1,7х2,0 мм) Всего на карте 8 контактов. На рис. 4.6.4.1 обязательные контакты представлены закрашенными прямоугольниками. Контакты C4 и С8 не используются и могут отсутствовать, контакт же С6 используется для программирования на фазе изготовления. Сопротивление для этого контакта по отношению к любым другим контактом должно превышать 10 Мом при напряжении 5 В. Таблица 4.6.4.1.

Контакт	Назначение	Контакт	Назначение
С1	VCC - напряжение питания	С5	GND - земля
С2	RST - сброс	С6	Не используется
С3	CLK - тактовые импульсы	С7	Вход/Выход (I/O)

VCC - напряжение питания 5 ± 0,5В при токе 50 мА при любых частотах работы микросхемы. В таблице 4.6.4.2 представлены параметры входных информационных сигналов VIH- Высокий уровень входного сигнала
VIL- Низкий уровень входного сигнала
VOH- Высокий уровень выходного сигнала
VOL- Низкий уровень выходного сигнала
tR- Время нарастания сигнала
tF- Время спада сигнала Таблица 4.6.4.2

	Минимум	Максимум
VIH	0,7xVcc	Vcc
VIL	0	0,8 В
tR и tF	-	1,0 мксек

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

	Условия	Минимум	Максимум
VOH	-20мкА<IOH<0, Vcc= min	0,7xVcc	Vcc
VOL	0< IOL < 1мА, Vcc = min	0	0,4 В
tR и tF	C IN(терминала) =30пФ макс	-	1,0 мксек

В таблице 4.6.4.4 перечислены требования на параметры тактовых импульсов. ICC может работать корректно при скважности тактовых импульсов в диапазоне (44-56)% и значении тактовой частоты от 1 до 5 МГц. Таблица 4.6.4.4

	Минимум	Максимум
VIH	Vcc-0,7В	Vcc
VIL	0	0,5 В
tR и tF	-	9% тактового периода

В таблице 5 представлены характеристики сигнала сброса (RST). Таблица 4.6.4.5

	Минимум	Максимум
VIH	Vcc-0,7В	Vcc
VIL	0	0,6 В
tR и tF	-	1,0 мксек

ICC выдерживает уровни сигнала на шине RST от -0,3В до Vcc+0,3В. ICC откликается на сигнал сброса асинхронно.

Микросхема может также противостоять импульсам тока через цепь питания до 100 мА длительностью 400 нсек и с интегральным зарядом 40 нАсек. Любая транзакция для карты начинается с ее вставления в интерфейсное устройство IFD (Interface Device) и активации контактов карты. Далее следует сброс микросхемы ICC в исходное состояние и установление связи между ICC и IFD. Только после этого начинает реализовываться конкретная транзакция. Любая транзакция завершается дезактивацией контактов и удалением ICC из интерфейсного устройства. После вставления карты в IFD терминал проверяет, что все сигнальные контакты находятся в состоянии L (низкий логический уровень - VOL). IFD контролирует корректность положения ICC с точностью ±0,5мм. Если карта позиционирована правильно, производится активация контактов в соответствии с порядком, представленном на рис. 4.6.4.3.

Рис. 4.6.4.3. Последовательность активации контактов ICC Через некоторое время после подачи на ICC напряжения питания Vcc начинают поступать тактовые импульсы. В исходный момент времени (сразу после вставления карты уровень сигналов на шине I/O является низким (L). Далее уровень этой шины может быть неопределенным (обозначено на рисунке серым прямоугольником), но после прихода 200 тактов этот уровень становится высоким (H). При этом уровень на шине RST остается низким (L). Терминал IFD устанавливает свой драйвер I/O в режим приема не позднее поступления 200-го такта. После этого выполняется процедура сброса (Reset). ICC откликается на команду RESET асинхронно. Время, когда на ICC начинают поступать тактовые импульсы, называется T0. Терминал поддерживает в это время уровень шины RST в низком состоянии.

Рис. 4.6.4.4. Диаграмма реализации "холодного" сброса После прихода 40000-45000 тактов после Т0 шина RST переходит в состояние H. Этот момент времени называется T1. Начало отклика на Reset со стороны ICC наступает спустя 400-40000 тактов после T1 (время t1). Если за это время отклик со стороны ICC не поступает, терминал в пределах 50 мсек деактивирует контакты микросхемы на карте.

Диаграмма холодного сброса ICC показана на рис. 4.6.4.4. Команда сброса может поступать и в процессе обычной работы - так называемый "теплый" сброс. Временная диаграмма такого сброса показана на рис. 4.6.4.5.

Рис. 4.6.4.5. Временная диаграмма "теплого" сброса Следует учитывать, что при теплом сбросе напряжение питание Vcc имеет рабочий уровень, шина RST имеет уровень H, состояние шины I/O может быть любым. После перехода шины RST в состояние L (момент времени T0') на шине I/O не позднее чем через 200 тактов должен установиться уровень H. В момент Т1' шина RST переходит в состояние H, после чего завершается процедура сброса аналогично "холодному" варианту. Процедура деактивации контактов ICC показана на рис. 4.6.4.6. В момент начала этой процедуры напряжение питание Vcc имеет рабочий уровень, шина RST имеет уровень H, состояние шины I/O может быть любым. Сигналом к началу процесса является переход шины RST в низкое состояние. Через некоторое время состояние шины I/O должно стать низким, прекращается подача тактовых импульсов, после чего с небольшой задержкой напряжение питания Vcc становится равным нулю и процедура в пределах 100 мсек завершается. При гальваническом отключении контактов Vcc должно быть не более 0,4 В. По завершении процедуры карта может быть извлечена из интерфейсного устройства.

Рис. 4.6.4.6. Временная диаграмма дезактивации контактов ICC Исходная длительность такта на шине I/O определяется как: t = 372/f секунд, где f частота в Гц. В общем случае t определяется как: t = F/(Df), где f частота в Гц, F и D параметры, которые могут варьироваться, но обычно F=372, а D=1. f лежит в пределах (1-5) МГц.

Рис. 4.6.4.7. Диаграмма передачи символов по шине I/O Перед началом передачи символа шина I/O должна находиться в состоянии H. Для передачи любого символа требуется 10 бит (смотри рисунок 4.6.4.7). Стартовый бит должен иметь уровень L и номер 1. Последний бит представляет собой бит четности (нечет). Стартовый бит детектируется путем стробирования шины I/O.

Время стробирования составляет 0, 2 t. Время между началами передачи последовательных символов составляет t(10±0,2) плюс время выдержки. Во время выдержки ICC и терминал должны находиться в режиме приема. (H). Определены два протокола: символьный (Т=0) и блочный (Т=1). ICC поддерживает один из этих протоколов, терминалы поддерживают оба. Тип протокола определяется значением символа TD1. При отсутствии в ATR TD1 рабочим считается протокол Т=0. Физический уровень обмена должен согласовываться с обоими протоколами. Минимальный интервал между лидирующими битами двух последовательных символов, посылаемых ICC, равно 12t. Максимальный интервал между стартовыми битами двух последовательных символов (Work Waiting Time) не должно превышать (960хDxWI) t (параметры D и WI пересылаются с помощью символов TA1 и TC2, соответственно). Если это время будет превышено, терминал не позднее, чем спустя 960t должен начать процесс дезактивации. В режиме T=0, если ICC или терминал детектировали при передаче/приеме символа ошибку четности, шина I/O переводится в состояние L, чтобы передающая сторона узнала об ошибке. На транспортном уровне терминала TTL (Terminal Transport Layer) данные всегда передаются через шину I/O так, что старший байт следует первым. Будет ли первым старший бит, определяется символом TS, возвращаемым в ответ на команду сброс ATR. Такой отклик может содержать строку символов. При отклике на сброс минимальное время между стартовыми битами последовательных символов составляет 9600t. ICC передает все символы отклика в пределах 19200 t. Это время измеряется между стартовым битом первого символа TS и после 12 t от начала последнего символа. Число символов в отклике зависит от транспортного протокола и поддерживаемых управляющих параметров. ICC может опционно поддерживать более одного транспортного протокола, но одним из таких протоколов должен быть Т=0 или Т1. Символы, присылаемые в рамках ATR, представлены в таблице 4.6.4.6. Таблица 4.6.4.6. Базовый ATR для T=0

Символ	Значение	Примечания
TS	3B или 3F	Указывает на прямую или инверсную схему передачи бит
T0	6x	Присутствуют TB1 и TC1; х обозначает число исторических байтов
TB1	00	VPP не требуется
TC1	00 - FF	Указывает на необходимость дополнительного времени выдержки. FF имеет специальное назначение.

Если поддерживается только протокол типа T=1 (блочный асинхронный транспортный протокол), то используемые символы отклика ATR содержатся в таблице 4.6.4.7. Следует иметь в виду, что ICC может поддерживать более одного транспортного протокола. Таблица 4.6.4.7. Базовый ATR для T=1

Символ	Значение	Примечания
TS	3B или 3F	Указывает на прямую или инверсную схему
T0	Ex	Присутствуют TB1 - TD1; х обозначает число исторических байтов
TB1	00	VPP не требуется
TC1	00 - FF	Указывает на необходимость дополнительного времени выдержки. FF имеет специальное назначение.
TD1	81	TA2 - TC2 отсутствуют; TD2 присутствует; должен работать протокол T=1
TD2	31	TA3 и TB2 присутствуют; TC3 и TD3 отсутствуют; должен работать протокол T=1
TA3	10 - FE	Возвращает IFSI, что указывает на начальное значение размера информационного поля для ICC и IFSC равное 16-254 байтам
TB3	Старший полубайт =0-4 Младший полубайт =0-5	BWI = 0-4 CWI = 0-5
TCK		Контрольный символ

Интерфейсы могут поддерживать отклики, не описанные в данной спецификации. Максимальное число символов в отклике, включая TS, не должно превышать 32. TS служит для синхронизации терминала и для определения логической схемы интерпретации последующих символов. Инверсная логическая схема предполагает, что логической единице на шине I/O соответствует уровень L, а старший бит данных передается первым. Прямая схема предполагает, что логической единице на шине I/O соответствует уровень H, а первым передается младший бит. Первые четыре бита LHHL используются для синхронизации. ICC может прислать ATR, содержащий TS, который имеет одно из следующих значений:
(H)LHHLLLLLLH - инверсная схема, значение 3F.
(H)LHHLHHHLLH - прямая схема, значение 3B
Последний бит этих кодов Н является битом четности (смотри рис. 4.6.4.7). T0 - символ формата. Старший полубайт (b5-b8) используется для определения того, присутствуют ли последующие символы TA1-TD1. Если биты b5-b8 установлены в состояние логической единицы, TA1-TD1 присутствуют. Младший полубайт (b1-b4) содержит число опционных исторических байтов (0-15).

Смотри таблицу 4.6.4.8. Таблица 4.6.4.8

	b8	b7	b6	b5	b4	b3	b2	b1
Только Т=0	0	1	1	0	X	X	X	X
Только Т=1	1	1	1	0	X	X	X	X

Символы интерфейса TA1- TC3 передают информацию, которая используется при обмене между терминалом и ICC. Они определяют значения параметров F, D, I, P и N, а также IFSC, BWI (Block Waiting time Integer) и CWI (Character Waiting time Integer). Информация, содержащаяся в TA1, TB1, TC1, TA2 и TB2 будут применяться для всех последующих обменов вне зависимости от используемого протокола. TA1 служит для передачи значений FI и DI, где FI используется для задания значения F (параметр, определяющий тактовую частоту). DI служит для задания значения D, используемого для настройки частоты следования бит. По умолчанию FI=1 и DI=1, что означает F=372, а D=1. Если ТА1 присутствует в ATR (b5 в T0 равен 1) и TA2 прислан с b5=0, то терминал воспринимает ATR, если TA1=11, и немедленно реализует указанные F и D. ТВ1 несет в себе значения PI1 и II, где PI1 специфицировано в битах b1-b5 и используется для программирования значения напряжения P, необходимого ICC. PI0=0 означает, что VPP не подключено к ICC. II специфицируется в битах b6 и b7 и служит для определения максимального тока, потребляемого ICC. Этот параметр не используется, если PI1 = 0. TC1 несет в себе величину N, которая используется для задания дополнительной выдержки (guardtime) между символами. Это время будет добавлено к минимальной выдержке. N может принимать значения 0-255 t. TD1 указывает, должны ли быть переданы еще интерфейсные байты, и содержит информацию о типе протокола. Старший полубайт используется для индикации наличия символов TA2 - TD2. Биты b5-b8 принимают значение логической единицы, если указанные выше символы присутствуют. Младший полубайт указывает протокол, который будет использован для последующих обменов. ATR не содержит TD1, если используется только Т=0. Для T=1 TD1=81 указывает на наличие TD2. Наличие или отсутствие TA2 говорит о работе ICC в специфическом или согласованном режиме, соответственно.

Базовый отклик ATR не содержит ТА2. ТВ2 передает PI2, который используется для определения величины программируемого напряжения Р, необходимого ICC. Если этот символ присутствует, значение, указанное в PI1 (ТВ1), заменяется на новое. По умолчанию ТВ2 отсутствует. ТС2 специфичен для протокола типа Т=0 и несет в себе значение WI (Waiting time Integer), которое используется для определения максимального интервала между началом передачи любого символа, посланного ICC, и началом предыдущего символа, поступившего от ICC или терминала. Время выдержки вычисляется по формуле 960xDxWI. По умолчанию ТС2 отсутствует, а WI=10. Терминал воспринимает ATR, содержащий ТС2=0А. Он отвергает ATR, несущий в себе ТС2=00 или ТС2>0А. TD2 указывает, будут ли еще переданы какие-либо интерфейсные байты, а также определяет тип протокола, используемого далее. Старший полубайт используется для указания наличия символов ТА3 - TD3. Биты b5-b8 устанавливаются в единичное состояние при наличии ТА3 - TD3. Младший полубайт указывает тип протокола, применяемый в последующих обменах. При Т=1 он равняется 1. По умолчанию при Т=0 ATR не содержит TD2, в противном случае ATR содержит TD2=31 (T=1). ТА3 несет в себе информацию о размере поля данных для ICC (IFSI) и специфицирует длину информационного поля INF блоков, которые могут быть получены картой. Этот символ характеризует длину IFSC в байтах и может содержать коды в интервале 0х01-0хFE. Значения 0х00 и 0хFF зарезервированы на будущее. По умолчанию ATR содержит ТА3 со значение в диапазоне 0х10-0хFE, если Т=1, IFSC лежит в интервале 16-254 байта. Если ТА3 содержит недопустимый код, ATR терминалом отвергается. ТВ3 характеризует значения CWI и BWI, используемые для вычисления CWT и BWT, соответственно. ТВ3 имеет две части. Младший полубайт (b1-b4) используется для определения значения CWI, а старший полубайт (b5-b8) - BWI. По умолчанию ATR несет в себе ТВ3, при этом младший полубайт содержит код 0-5, а старший - 0-4, если Т=1, указывая, что CWI=0-5, а BWI=0-4.

Формат ТВ3 показан в таблице 4.6.4.9. Таблица 4.6.4.9

	b8	b7	b6	b5	b4	b3	b2	b1
Только Т=1	0	X	X	X	0	Y	Y	Y

XXX лежит в интервале 000-100, а YYY - 000- 101 Терминал отвергает ATR, не содержащий ТВ3 или указывающий на значения BWI больше 4 и/или CWI больше 5, или 2CWI<(N+1). TC3 индицирует тип блока кода детектирования ошибки. Тип кода определяется битом b1 (b2-b8 - не используются). По умолчанию ATR не содержит ТС3. Терминал воспринимает ATR с ТС3=00, и отбрасывает любые-другие ATR, содержащие другие значения ТС3. ТСК (контрольный символ) имеет значение, которое позволяет проверить целостность данных, пересылаемых в ATR. Значение TCK таково, что исключающее ИЛИ всех байтов от Т0 до ТСК включительно должно давать код 0. По умолчанию ATR не содержит ТСК, если используется только Т=0, во всех других случаях ТСК должен присутствовать. Терминал воспринимает ATR ICC без TCK, если только Т=0. Во всех остальных случаях терминал отвергнет ATR без, или с некорректным ТСК. Если ТСК некорректно, терминал инициирует последовательность дезактивации не позднее 480 t после начала ТСК. Если терминал отверг холодный АТR, он не отвергает карту немедленно, а инициирует "теплый" сброс в пределах 4800t. Если терминал отверг теплый ATR, он в пределах 4800 t запускает процедуру дезактивации. Если во время отклика на холодный или теплый сброс интервал между двумя последовательными символами превысит 9600t, терминал прерывает сессию путем инициализации дезактивации спустя 14400t после стартового бита последнего полученного символа. Если отклик на холодный или теплый сброс не завершился в пределах 19200t, терминал спустя 24000t (от начала TS) запускает процедуру дезактивации карты. Если терминал обнаруживает ошибку по четности при передаче символа ATR, он прерывает сессию карты и спустя 4800t инициирует процедуру дезактивации.

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

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

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

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

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

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

Система CyberCash для работы с кредитными картами версии 0.8 предоставляет достаточную защиту платежных сообщений, как это описано в разделах 1.2, 2.2.4 и 2.2.5. Система не обеспечивает достаточной защиты от нечестного продавца (здесь вне конкуренции протокол SET). Следует не выпускать из внимания ЭВМ, на которых работают различные части системы, в противном случае нельзя добиться приемлемого уровня безопасности.

Ссылки

[ISO 4217]	Codes for the representation of currencies and funds
[ISO 8583]	Financial transaction card originated messages - Interchange message specifications, 1993-12-15.
[RFC-822]	Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC- 822, UDEL, August 1982.
[RFC-1521]	Borenstein, N., and N. Freed, "MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC- 1521, Bellcore, Innosoft, September 1993.
[RFC-1766]	Alvestrand, H., "Tags for the Identification of Languages", UNINETT, March 1995.

Назад:
Оглавление:
Вперёд:

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

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

Сообщение CM- post-auth-capture

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

#####################################################################
Отправитель: MerchantApp
Получатель: CyberServer
#####################################################################
Пример сообщения:

$$-CyberCash-0.8-$$
merchant-ccid: ACME-012

merchant-transaction: 123123
merchant-date: 19950121100705.nnn
merchant-cyberkey: CC1001
cyberkey: CC1001
opaque:

EDD+b9wAfje5f7vscnNTJPkn1Wdi7uG3mHi8MrzLyFC0dj7e0JRjZ2PmjDHuR81kbhqb
nX/w4uvsoPgwM5UJEW0Rb9pbB39mUFBDLPVgsNwALySeQGso0KyOjMxNs1mSukHdOmDV
4uZR4HLRRfEhMdX4WmG/2+sbewTYaCMx4tn/+MNDZlJ89Letbz5kupr0ZekQlPix+pJs
rHzP5YqaMnk5iRBHvwKb5MaxKXGOOef5ms8M5W8lI2d0XPecH4xNBn8BMAJ6iSkZmszo
QfDeWgga48g2tqlA6ifZGp7daDR81lumtGMCvg==
merchant-opaque:

6BVEfSlgVCoGh1/0R+g1C143MaA6QLvKpEgde86WWGJWx45bMUZvaAu4LVeqWoYCqSGf
aWKUF7awol0h1i1jtgieyAcXB8ikvRJIsupSAwsRMyoNlekR6tucvfv/622JY7+n7nGO
dGbMzP0GJImh2DmdPaceAxyOB/xOftf6ko0nndnvB+/y2mFjdUGLtFQP/+3bTpZttZXj
j7RO1khe1UrAIk2TGQJmNw+ltsu0f42MgsxB8Q31vjPtoiPi5LEmD0Y4jlpJ7Jg2Ub84
F9vJhYpmzNkdiJUe83Hvo/xfJRbhafJpXFEsUZwQK0jU1ksU6CQd2+CPBB+6MxtsHoxJ
mjD6ickhd+SQZhbRCNerlTiQGhuL4wUAxzGh8aHk2oXjoMpVzWw2EImPu5QaPEc36xgr
mNz8vCovDiuy3tZ42IGArxBweasLPLCbm0Y=
$$-CyberCash-End-7Tm/djB05pLIw3JAyy5E7A==-$$

#####################################################################
Содержимое скрытой секции продавца:

type: post-auth-capture
authorization-code: a12323
order-id: 1231-3424-234242
merchant-amount: usd 10.00
pr-hash: 7Tm/djB05pLIw3JAyy5E7A==
pr-signed-hash:

a/0meaMHRinNVd8nq/fKsYg5AfTZZUCX0S3gkjAhZTmcrkp6RZvppmDd/P7lboFLFDBh
Ec0oIyxWeHfArb3OtkgXxJ7qe0Gmm/87jG5ClGnpBnw0dY7qcJ6XoGB6WGnD
id: myCyberCashID
transaction: 78784567
date: 19950121100505.nnn
merchant-signature:

vxyEF1ZHn5Rgmtms3H3t/+UB6RAvZQA1AdddjvlS0H75N1x83FyJuh8V9Ok6t4EUQQZ6
Mnptzc6phJi3Ar0s0oumELsdc8upJdXpNpJV021PGJXfDKfHP0heJIWLodXr
#####################################################################

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

Сообщение IOTP

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

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

<!ELEMENT IotpMessage
( TransRefBlk,

	SigBlk?,
	ErrorBlk?,
	( AuthReqBlk \|
		AuthRespBlk \|
		AuthStatusBlk \|
		CancelBlk \|
		DeliveryReqBlk \|
		DeliveryRespBlk \|
		InquiryReqBlk \|
		InquiryRespBlk \|
		OfferRespBlk \|
		PayExchBlk \|
		PayReqBlk \|
		PayRespBlk \|
		PingReqBlk \|
		PingRespBlk \|
		TpoBlk \|
		TpoSelectionBlk
	)*

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

Содержимое:

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

AuthReqBlk, AuthRespBlk,	Торговые блоки.
DeliveryReqBlk	Торговые блоки присутствуют в сообщениях IOTP, а само содержимое
DeliveryRespBlk	торгового блока зависит от типа выполняемой операции IOTP
ErrorBlk	смотри определение каждой операции в разделе 9.
InquiryReqBlk,
InquiryRespBlk,
OfferRespBlk, PayExchBlk,
PayReqBlk	Полные определения каждого торгового блока описаны в разделе 8.
PayRespBlk, PingReqBlk, PingRespBlk, SigBlk, TpoBlk, TpoSelectionBlk

Атрибуты:

Xmlns

Определение [XML Namespace] для сообщений IOTP.

Сообщение IOTP выбора TPO

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

Блок выбора TPO (смотри раздел 8.2) содержит:

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

Аннулирует возврат денег, если сообщение

Аннулирует возврат денег, если сообщение получено до окончательного расчета. Сообщение аналогично сообщению CM1 за исключением того, что оно имеет другой код типа и снабжено полем номера ссылки возврата (retrieval-reference-number field) (которое включается в подпись). #####################################################################
Отправитель: MerchantApp
Получатель: CyberServer
#####################################################################
Пример сообщения: $$-CyberCash-0.8-$$
merchant-ccid: ACME-012
merchant-transaction: 123123
merchant-date: 19950121100705.nnn
merchant-cyberkey: CC1001
cyberkey: CC1001
opaque: EDD+b9wAfje5f7vscnNTJPkn1Wdi7uG3mHi8MrzLyFC0dj7e0JRjZ2PmjDHuR81kbhqb
nX/w4uvsoPgwM5UJEW0Rb9pbB39mUFBDLPVgsNwALySeQGso0KyOjMxNs1mSukHdOmDV
4uZR4HLRRfEhMdX4WmG/2+sbewTYaCMx4tn/+MNDZlJ89Letbz5kupr0ZekQlPix+pJs
rHzP5YqaMnk5iRBHvwKb5MaxKXGOOef5ms8M5W8lI2d0XPecH4xNBn8BMAJ6iSkZmszo
QfDeWgga48g2tqlA6ifZGp7daDR81lumtGMCvg==
merchant-opaque:
6BVEfSlgVCoGh1/0R+g1C143MaA6QLvKpEgde86WWGJWx45bMUZvaAu4LVeqWoYCqSGf
aWKUF7awol0h1i1jtgieyAcXB8ikvRJIsupSAwsRMyoNlekR6tucvfv/622JY7+n7nGO
dGbMzP0GJImh2DmdPaceAxyOB/xOftf6ko0nndnvB+/y2mFjdUGLtFQP/+3bTpZttZXj
j7RO1khe1UrAIk2TGQJmNw+ltsu0f42MgsxB8Q31vjPtoiPi5LEmD0Y4jlpJ7Jg2Ub84
F9vJhYpmzNkdiJUe83Hvo/xfJRbhafJpXFEsUZwQK0jU1ksU6CQd2+CPBB+6MxtsHoxJ
mjD6ickhd+SQZhbRCNerlTiQGhuL4wUAxzGh8aHk2oXjoMpVzWw2EImPu5QaPEc36xgr
mNz8vCovDiuy3tZ42IGArxBweasLPLCbm0Y=
$$-CyberCash-End-7Tm/djB05pLIw3JAyy5E7A==-$$
#####################################################################
Содержимое скрытой секции продавца: type: void
retrieval-reference-number: 432112344321
order-id: 1231-3424-234242
merchant-amount: usd 10.00
pr-hash: WATCQuH2q17lRuoxD78YBg==
pr-signed-hash: 8zqw0ipqtLtte0tBz5/5VPNJPPonfTwkfZPbtuk5lqMykKDvThhO0ycrfT7eXrn/hLUC
kXoSctahEVdw1KBJbp0EVr1zVzcN9Aa7m2fJgxNfiisTgIRW+PMaa78rn+Ov
id: myCyberCashID
transaction: 78784567
date: 19950121100505.nnn
Подпись продавца: lkjladjslkjflsakjflkjsdljflsakjflkjsdljflsakjflkj flsakjflkjsdljflsakjflkjsdljflsajflksdjflksdjflsdjssf=

#####################################################################
Ключ закрытой секции продавца генерируется из общедоступного ключа шифрования CyberCash, идентифицируемого в Merchant-CyberKey.
Закрытая секция сообщения покупателя (Opaque) - смотри CH1.
#####################################################################
Содержимое закрытой секции и подпись: (в точности как в CH1) swversion: 0.8win
amount: usd 10.00
card*: [из успешного bc4 (содержит card-salt, номер карты и срок ее действия)]
Подпись: 48SBKUfojyC9FDKCwdCYNvucgiDxYO9erZW4QndIXZRyheTHXH8OeIhwUkyLmgQSD/UK
+IX9035/jUkdNPOxUQq9y/beHS1HU9Fe0wlzfXYRtnjlqvQX+yUfQ4T7eNEs
#####################################################################
Подпись продавца покрывает следующие поля: merchant-ccid, merchant-transaction, merchant-date, merchant-cyberkey, type, retrieval-reference-number, order-id, merchant-amount, pr-hash, pr-signed-hash, id, transaction, date, cyberkey
#####################################################################<> Подпись продавца гарантирует целостность большей части сообщения. Проверка корректности подписи покупателя гарантирует, что невидимая часть сообщения клиента не была изменена или замещена.

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

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

блок отклика Authentication (смотри раздел 8.5) и

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

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

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

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

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

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

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

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

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

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

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

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

Сообщение-отклик доставки

Сообщение-отклик доставки содержит блок отклика доставки и опционно блок подписи.

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

один компонент накладной (Delivery Note) (смотри раздел 7.15), который содержит инструкции по доставке товаров или услуг.

Блок подписи (отклик доставки)

Блок подписи должен содержать один компонент подписи, который содержит элементы дайджеста, которые относятся к:

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

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

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

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

компонент Status;

компонент накладной (Delivery Note)

Сообщение отклик на предложение IOTP

Сообщение отклика Offer используется только в документальном обмене предложения, зависящего от вида платежа. Помимо блока ссылок транзакции (смотри раздел 3.3), это сообщение состоит из:

блока отклика Offer (смотри раздел 8.1) aиnd

опционного блока подписи (смотри раздел 8.16).

Блок отклика предложения (блок отклика OFFER)

Блок отклика Offer (смотри раздел 8.3) содержит следующие компоненты:

один компонент Status (смотри раздел 7.16), который индицирует состояние отклика Offer. Атрибут ProcessState должен быть равен CompletedOk;

один компонент Order (смотри раздел 7.5), который содержит детали о товарах и услугах, которые покупаются, или о финансовых операциях, которые имеют место;

один или более компонентов (смотри раздел 7.9) для каждого платежа, которы надлежит произвести;

нуль или один компонент Delivery (смотри раздел 7.13), содержащий детали доставки, которую надлежит осуществить, если транзакция предполагает доставку;

нуль или более компонентов данных о торговой роли (смотри раздел 7.17), если это затребовано Продавцом.

Блок подписи (отклик предложения)

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

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

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

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

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

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

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

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

Сообщение платежного обмена IOTP

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

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

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

Содержимое этого сообщения то же, что и для платежного документального обмена (смотри раздел 9.1.3.3).

Сообщение платежного отклика и отклика доставки

Содержимое этого сообщения включает в себя:

блок платежного отклика,

опционный блок подписи (платежный отклик) и

блок отклика доставки.

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

Блок SIGNATURE (отклик PAYMENT)

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

Содержимое блока отклика доставки то же, что и в блоке отклика доставки при платежном документальном обменее (смотри раздел 9.1.4.3).

Сообщение платежного запроса

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

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

опционный блок подписи

Блок платежного запроса (смотри раздел 8.7) состоит из:

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

	- компонент Status
	- компонент Payment для выполняемого платежа

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

	- компоненты Organisation с ролями Продавец и Кассир, которые были пересланы в блоке платежного запроса;
	- компонент списка видов платежа, т.e. список видов платежа, указанный в атрибуте BrandListRef компонента Payment;

одного компонента выбора вида платежа, т.e. компонента выбора вида платежа, где атрибут BrandListRef указывает на список видов платежа. Этот компонент может быть:

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

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

нуль или более компонентов данных о торговой роли (смотри раздел 7.17).

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

если в блоке отклика Offer имеется более одного компонента Payment, тогда вторым платежем являет тот, что записан в блоке отклика Offer и который содержит атрибут StartAfter (смотри раздел 7.9), указывающий на компонент Payment предыдущего платежа;

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

компонент списка видов платежей определяется атрибутом BrandListRef компонента o Payment;

компонент выбора вида платежа берется из блока отклика Offer, где имеется атрибут BrandListRef (смотри раздел 3.5), который идентифицирует компонент списка видов платежей.

Блок подписи (запрос платежа)

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

Сообщение платежного запроса IOTP

Содержимое этого сообщения то же, что и для запроса при платежном документальном обмене (смотри раздел 9.1.3.2).

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

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

блок состояния аутентификации (смотри раздел 8.5) и

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

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

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

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

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

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

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

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

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

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

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

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

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

Сообщение TPO

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

Блок TPO (TRADING PROTOCOL OPTIONS)

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

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

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

Компоненты Organisation (смотри раздел 7.6), со следующими ролями:

	- Продавец, который сделал предложение
	- Покупатель, который осуществляет транзакцию
	- Кассир. "ID" компонента организщации-кассира содержится в атрибуте PhOrgRef компонента платежа (Payment).

Если транзакция IOTP включает доставку, тогда блок TPO должен содержать:

Компоненты Organisation со следующими ролями:

	- Агент доставки (DeliveryHandler), который осуществляет доставку товаров или услуг;
	- DelivTo т.e. лицо или организация, куда нужно выполнить доставку.

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

Если за документальным обменом Offer следует обмен аутентификации, тогда сообщение TPO может также содержать:

блок состояния аутентификации (смотри раздел 8.6) и

опционный блок Signature (состояния аутентификации).

Для получения подробностей смотри раздел 9.1.1.4 (сообщение о состоянии аутентификации).

Сообщение TPO и отклика Offer

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

блок опций торгового протокола (TPO) (смотри раздел 8.1);

блок отклика Offer (смотри раздел 8.1) и

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

Блок TPO (TRADING PROTOCOL OPTIONS)

Это тот же самый блок опций торгового протокола, что описан в IOTP-сообщении TPO (смотри раздел 9.1.2.3).

Блок отклика OFFER

Это тот же самый блок отклика Offer, что и в сообщении отклика Offer (смотри раздел 9.1.2.5).

Если до документального обмена Offer имел место обмен аутентификации, тогда сообщение TPO и отклика Offer может содержать (смотри раздел 8.6).

Блок подписи тот же самый блок Signature, что и в сообщении отклика Offer (смотри раздел 9.1.2.5), со следующими добавлениями:

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

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

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

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

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

блок запроса Authentication (смотри раздел 8.4) и

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сообщение запроса доставки IOTP

Сообщение запроса доставки IOTP состоит из:

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

опционный блок подписи

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

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

	- компонент Status (смотри раздел 7.16)
	- компонент Order (смотри раздел 7.5)
	- компонент Organisation (смотри раздел 7.6) с ролями: Продавец, Агент доставки и DeliverTo
	-компонент Delivery (смотри раздел 7.13)

следующий компонент из блока платежного отклика:

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

нуль или более компонентовданных о торговых ролях (смотри раздел 7.17).

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

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

Сообщения покупателя о покупке, содержащие данные о кредитной карте

Вообще, подключение CyberCash к покупке с помощью кредитной карты происходит после того как пользователь определит, что же он, в конце концов, покупает. Когда клиент нажимает клавишу CyberCash "payment", продавец посылает покупателю сообщение PR1 в виде тела типа MIME риложение/cybercash.

Если покупатель желает продолжить процедуру, он отвечает продавцу сообщением CH1. Продавец реагирует, послав отклик CH2. В паузе между посылкой CH1 и получением CH2, продавец обычно контактирует с сервером CyberCash посредством сообщений CM*.

Сообщения продавца о покупке, связанные с кредитной картой

Продавец представляет покупки через кредитную карту, делает корректировки и выражает предпочтения через последовательность CM*. Вообще, цикл, сопряженный с кредитной картой включает авторизацию для покупки, включение покупки в перечень на оплату и собственно осуществление оплаты. Имеется возможность удалить определенную позицию из перечня или аннулировать всю сделку (смотри раздел 5.1.). Авторизации всегда осуществляется клиентом через отклики-сообщения CM1 или CM2. Если приобретение выполняется получателем (acquirer) или каким-то другим объектом между сервером CyberCash и получателем, это делается посредством сообщений CM3 или CM2 в зависимости от соглашения между продавцом и объектом, осуществляющим приобретение. Возвраты обрабатываются с помощью сообщений CM5. Сообщение CM4 служит для возврата покупки или возврата до оплаты сделки. CM6 является форматом сообщения, используемого для откликов на все другие CM*-сообщения.

Последовательности MM* были также применены для оплат, осуществляемых продавцом, как описано в разделе 3.4.7

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

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

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

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

два обычных вида платежа через кредитную карту и два льготных вида платежа.

два платежных протокола:

	- SET (Secure Electronic Transactions) смотри [SET] и
	- SCCD (Secure Channel Credit Debit) смотри [SCCD].

<BrandList ID='M1.2' XML:Lang='us-en' ShortDesc='Purchase ladies coat' PayDirection='Debit'>
<Brand ID ='M1.3' BrandId='MasterCard' BrandName='MasterCard Credit'
BrandLogoNetLocn='ftp://otplogos.mastercard.com' ProtocolAmountRefs='M1.7 M1.8'>
<ProtocolBrand ProtocolId='SET1.0' ProtocolBrandId='MasterCard:'>
</ProtocolBrand>
</Brand>
<Brand ID ='M1.4' BrandId='Visa' BrandName='Visa Credit'
BrandLogoNetLocn='ftp://otplogos.visa.com' ProtocolAmountRefs='M1.7 M1.8'>
<ProtocolBrand ProtocolId='SET1.0' ProtocolBrandId='Visa:'>
</ProtocolBrand>
</Brand>
<Brand ID ='M1.5' BrandId='BritishAirwaysMC' BrandName='British Airways MasterCard'
BrandLogoNetLocn='ftp://otplogos.britishairways.co.uk'
BrandNarrative='Double air miles with British Airways MasterCard'
ProtocolAmountRefs ='M1.7 M1.8' >
<ProtocolBrand ProtocolId='SET1.0' ProtocolBrandId='MasterCard:BA'>
</ProtocolBrand>
</Brand >
<Brand ID ='M1.6' BrandId='Walmart' BrandName='Walmart Store Card'
BrandLogoNetLocn='ftp://otplogos.walmart.com'
BrandNarrative='5% off with your Walmart Card on purchases over $150'
ProtocolAmountRefs='M1.8'>
</Brand>
<ProtocolAmount ID ='M1.7' PayProtocolRef='M1.10' CurrencyAmountRefs='M1.9' >
<PackagedContent Transform="BASE64">
238djqw1298erh18dhoire
</PackagedContent>
</ProtocolAmount>
<ProtocolAmount ID ='M1.8' PayProtocolRef='M1.11' CurrencyAmountRefs='M1.9' >
<PackagedContent Transform="BASE64">
238djqw1298erh18dhoire
</PackagedContent>
</ProtocolAmount>
<CurrencyAmount ID ='M1.9' Amount='157.53' CurrCode='USD'/>
<PayProtocol ID ='M1.10' ProtocolId='SET1.0'
ProtocolName='Secure Electronic Transaction Version 1.0'
PayReqNetLocn='http://www.example.com/etill/set1' >
<PackagedContent Transform="BASE64">
8ueu26e482hd82he82
</PackagedContent>
</PayProtocol>
<PayProtocol ID ='M1.11' ProtocolId='SCCD1.0'
ProtocolName='Secure Channel Credit/Debit'
PayReqNetLocn='http://www.example.com/etill/sccd1' >
<PackagedContent Transform="BASE64">
82hd82he8226e48ueu
</PackagedContent>
</PayProtocol>
</BrandList>

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

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

платежи, использующие Mondex, GeldKarte, CyberCash или DigiCash;

в валютах, в список которых входят доллары США, британские фунты, итальянские лиры, немецкие марки и канадские доллары;

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

более одного Кассира для случаев использования Mondex или CyberCash;

поддержка более чем одной версии CyberCash для платежного протокола CyberCoin.

Ссылки

[Base64]	Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[DOM-HASH]	Maruyama, H., Tamura, K. and N. Uramoto, "Digest Values for DOM (DOMHASH)", RFC 2803, April 2000.
[DNS]	Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[DNS]	Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[DSA]	The Digital Signature Algorithm (DSA) published by the National Institute of Standards and Technology (NIST) in the Digital Signature Standard (DSS), which is a part of the US government's Capstone project.
[ECCDSA]	Elliptic Curve Cryptosystems Digital Signature Algorithm (ECCDSA). Elliptic curve cryptosystems are analogues of public-key cryptosystems such as RSA in which modular multiplication is replaced by the elliptic curve addition operation. See: V. S. Miller. Use of elliptic curves in cryptography. In Advances in Cryptology - Crypto '85, pages 417-426, Springer-Verlag, 1986.
[HMAC]	Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[HTML]	Berners-Lee, T. and D. Connolly, "Hypertext Markup Language - 2.0", RFC 1866, November 1995.
[HTML]	Hyper Text Mark Up Language. The Hypertext Mark-up Language (HTML) is a simple mark-up language used to create hypertext documents that are platform independent. See the World Wide Web (W3C) consortium web site at: http://www.w3.org/MarkUp/
[HTTP]	Berners-Lee, T., Fielding, R. and H. Frystyk, "Hypertext Transfer Protocol -- HTTP/1.0", RFC-1945, May 1996.
[HTTP]	Fielding, R., Gettys, J., Mogul, J., Frystyk, T. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1.", RFC-2616, June 1999.
[IANA]	The Internet Assigned Numbers Authority. The organisation responsible for co-ordinating the names and numbers associated with the Internet. See http://www.iana.org/
[ISO4217]	ISO 4217: Codes for the Representation of Currencies. Available from ANSI or ISO.
[IOTPDSIG]	Davidson, K. and Y. Kawatsura, "Digital Signatures for the v1.0 Internet Open Trading Protocol (IOTP)", RFC-2802, April 2000.
[MD5]	Rivest, R., "The MD5 Message-Digest Algorithm", RFC-1321, April 1992.
[MIME]	Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, August 1982.
[MIME]	Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC-2045, November 1996.
[MIME]	Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC-2046, November 1996.
[MIME]	Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text" RFC-2047, November 1996.
[MIME]	Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", RFC-2048, November 1996.
[MIME]	Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples" RFC-2049, November 1996.
[OPS]	Open Profiling Standard. A proposed standard which provides a framework with built-in privacy safeguards for the trusted exchange of profile information between individuals and web sites. Being developed by Netscape and Microsoft amongst others.
[RFC1738]	Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource Locators (URL)", RFC-1738, December 1994.
[RFC2434]	Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC-2434, October 1998.
[RSA]	RSA is a public-key cryptosystem for both encryption and authentication supported by RSA Data Security Inc. See: R. L. Rivest, A. Shamir, and L.M. Adleman. A method for obtaining digital signatures and public-key cryptosystems. Communications of the ACM, 21(2): 120-126, February 1978.
[SCCD]	Secure Channel Credit Debit. A method of conducting a credit or debit card payment where unauthorised access to account information is prevented through use of secure channel transport mechanisms such as SSL/TLS. An IOTP supplement describing how SCCD works is under development.
[SET]	Secure Electronic Transaction Specification, Version 1.0, May 31, 1997. Supports credit and debit card payments using certificates at the Consumer and Merchant to help ensure authenticity. Download from: <http://www.setco.org>.
[SSL/TLS]	Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC-2246, January 1999.
[SHA1]	[FIPS-180-1]"Secure Hash Standard", National Institute of Standards and Technology, US Department Of Commerce, April 1995. Also known as: 59 Fed Reg. 35317 (1994). See http://www.itl.nist.gov/div897/pubs/fip180-1.htm
[UTC]	Universal Time Co-ordinated. A method of defining time absolutely relative to Greenwich Mean Time (GMT). Typically of the form: "CCYY-MM-DDTHH:MM:SS.sssZ+n" where the "+n" defines the number of hours from GMT. See ISO DIS8601.
[UTF16]	The Unicode Standard, Version 2.0. The Unicode Consortium, Reading, Massachusetts. See ISO/IEC 10646 1 Proposed Draft Amendment 1
[X.509]	ITU Recommendation X.509 1993 \| ISO/IEC 9594-8: 1995, Including Draft Amendment 1: Certificate Extensions (Version 3 Certificate)
[XML	Recommendation for Namespaces in XML, World Wide Web Namespace] Consortium, 14 January 1999, "http://www.w3.org/TR/REC-xml-names"
[XML]	Extensible Mark Up Language. A W3C recommendation. See http://www.w3.org/TR/1998/REC-xml-19980210 for the 10 February 1998 version.

Назад:
Оглавление:
Вперёд:

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

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

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

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

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

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

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

XML-определения сообщений IOTP, включая операционный блок ссылки (Transaction Reference Block), - XML-элемент, который идентифицирует IOTP-операцию и IOTP-сообщение Message, сопряженное с ним.

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

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

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

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

Как IOTP работает с безопасными и опасными сетевыми позициями (Net Locations), при посылке сообщений.

Как могут аннулироваться операции IOTP.

Таблица описанных сообщений

C = Приложение Покупателя, M = Приложение Продавца, S = Сервер CyberCash

FLOW	Раздел	Имя
C->S	4.2.1	BC.1 bind-credit-card
S->C	4.2.2	BC.4 bind-credit-card-response
C->M	4.3.2	CH.1 credit-card-payment
M->C	4.3.3	CH.2 credit-card-response
M->S	4.4.8	CD.1 запрос данных о кредитной карте
S->M	4.4.9	CD.2 отклик на запрос о кредитной карте
M->S	4.4.1	CM.1 только аутентификация
M->S	4.4.2	CM.2 auth-capture
M->S	4.4.3	CM.3 post-auth-capture
M->S	4.4.4	CM.4 void
M->S	4.4.5	CM.5 возврат
S->M	4.4.6	CM.6 отклик на платеж
C->S	4.5.7	DL.1 диагностическая запись
M->S	4.5.7	DL.2 диагностическая запись продавца
C->S	4.1.3	GA.1 получение приложения
S->C	4.1.4	GA.2 получение отклика приложения
M->S	4.4.7	MM.1 только аутентификация продавца
M->S	4.4.7	MM.2 merchant-auth-capture
M->S	4.4.7	MM.3 merchant-post-auth-capture
M->S	4.4.7	MM.4 merchant-void
M->S	4.4.7	MM.5 merchant-return
S->M	4.4.7	MM.6 отклик продавца на процедуру оплаты
C->S	4.5.1	P.1 ping
S->C	4.5.2	P.2 отклик на ping
M->C	4.3.1	PR.1 запрос платежа
C->S	4.1.1	R.1 регистрация
S->C	4.1.2	R.2 отклик на регистрацию
C->S	4.5.3	TQ.1 запрос о состоянии транзакции
C->S	4.5.4	TQ.2 аннулирование транзакции
S->C	4.5.5	TQ.3 отклик на транзакцию
S->C, S->M, M->C	4.5.6	UNK.1 неизвестная ошибка

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

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

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

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

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

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

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

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

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

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

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

<!ELEMENT IotpMessage

	( TransRefBlk,
	SigBlk?,
	ErrorBlk?,
	( AuthReqBlk \|
		AuthRespBlk \|
		AuthStatusBlk \|
		CancelBlk \|
		DeliveryReqBlk \|
		DeliveryRespBlk \|
		InquiryReqBlk \|
		InquiryRespBlk \|
		OfferRespBlk \|
		PayExchBlk \|
		PayReqBlk \|
		PayRespBlk \|
		PingReqBlk \|
		PingRespBlk \|
		TpoBlk \|
		TpoSelectionBlk
	)*

) >

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

Блок запроса аутентификации (Authentication Request Block)

Блок отклика аутентификации (Authentication Response Block)

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

Блок Cancel

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

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

Блок Error

Блок информационного запроса

Блок информационного отклика

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

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

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

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

Блок подписи

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

Блок выьора TPO

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

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

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

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

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

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

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

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

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

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

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

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

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

Компонент платежа

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

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

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

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

Компонент накладной

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

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

Компонент ошибки

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

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

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

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

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

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

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

Покупатель. Человек (или организация), который получает товар или услугу и платит за это.

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

Оператор платежей. Субъект, который получает платеж от потребителя в пользу торговой фирмы или физического лица.

Оператор доставки. Субъект, который доставляет товар или предоставляет услугу потребителю от торговой фирмы или лица.

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

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

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

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

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

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

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

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

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

Атрибуты:

ID	Идентификатор, который однозначно определяет торговый блок информационного отклика транзакции.
LastReceivedIotpMsgRef	Содержит ссылку элемента (смотри раздел 3.5) на Id-компонент (смотри раздел 3.3.2) последнего сообщения, которое получил данный сервер от покупателя. Если до этого не получено от покупателя ни одного сообщения, этот атрибут должен содержать значение (Null). Данный атрибут предназначен для отладочных целей.
LastSentIotpMsgRef	Содержит ссылку элемента (смотри раздел 3.5) на Id-компонент (смотри раздел 3.3.2) последнего сообщения, которое послал данный сервер покупателю. Если до этого не послано ни одного сообщения покупателю, данный атрибут должен содержать значение (Null). Этот атрибут предназначен для отладочных целей.

Cодержимое:

Status	Содержит статусную информацию об успехе или неудаче (смотри раздел 4.2) определенного торгового обмена (т.e., предложения, платежа или доставки).
PaySchemeData	Компонент Payment Scheme (смотри раздел 7.10), который содержит специфические информационные запросы по поводу платежной схемы. Он присутствует, когда атрибут Type атрибута StatusType компонента Status равен Payment.

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

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

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

Атрибуты:

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

Cодержимое:

InquiryType	Компонент тип информационного запроса (смотри раздел 7.18), который содержит код типа запроса.
PaySchemeData	Компонент платежная схема (Payment Scheme) (смотри раздел 7.10), который содержит специфические данные конкретных информационных запросов о платежной схеме. Он присутствует, когда атрибут Type компонента типа запроса равен Payment.

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

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

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

Оплата. Платежный обмен (Payment Exchange) предполагает осуществление какого-то платежа между потребителем и кассиром. Направление платежа может быть любым.

Доставка. Процедура доставки (Delivery Exchange) сопряжена с передачей товаров или доставкой информации о товарах агентом доставки Потребителю.

Аутентификация. Аутентификационный обмен (Authentication Exchange) может использоваться любой из тоговых ролей для аутентификации другой торговой роли и выяснения является ли субъект тем, за кого он себя выдает.

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

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

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

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

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

1.	Покупатель (С) решает сделать покупку и шлет информацию о заказе продавцу (М), например в формате HTML.
C а M	Данные: информация о том, что покупается (запрос Предложения) - формат запроса не определен в рамках IOTP
2.	Продавец проверяет информацию, выданную Покупателем, формирует предложение, опционно его подписывает и посылает Покупателю.
C Я M	Отклик на Предложение. Компоненты: Статус; Организации (покупатель, DelivTo, продавец, кассир, Агент обслуживания покупателя); Заказ; Платеж; Доставка; TradingRoleData подпись отклика-предложения (опционно)
3.	Покупатель проверяет информацию от продавца и решает, стоит ли осуществлять покупку.

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

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

o	Компонент Заказа (Order Component) содержит описания товаров или услуг, предмет сделки, если покупателя устроит соглашение. Эта информация посылается Продавцом покупателю.
o	Компонент оплаты (Payment Component), генерируемый продавцом, содержит детали того сколько надо платить, в какой валюте и кто должен платить кому, например покупатель может попросить вернуть деньги. Заметим, что число платежей в сделке может быть больше одного.
o	Компонент Доставки (Delivery Component), также генерируемый продавцом, используется, если товары или услуги требуют доставки. Он содержит информацию о том, как будет осуществляться доставка, например с помощью обычной или электронной почты.
o	Компонент данных о торговых ролях содержит информацию, которую продавец хочет довести до сведения другой торговой роли, такой как Кассир или Агент доставки.
o	Компонент подпись "отклика на предложение", если присутствует, подписывает все выше перечисленные компоненты с целью гарантии их целостности.

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

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

Запрос клиента серверу в связи с аннулированием транзакции.

#####################################################################
Отправитель: CyberApp
Получатель: CyberServer
#####################################################################
Пример сообщения:

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

VFaztHuj757Jrv+JxZFsHORy/zgkrxhBCu9cPdE04c1NnXzVlGOHygpSl+UGbUvnhkYl
21QQaHkaE3geccRk03cqFYoLNRCclImcsyeIZCgVt+2dJTj1V+E7R7ePQtCj+0gY42+V
L5BWhVtmDQFyg1DdJ6n3S/er6ZuObAjpcAogG+T1Na5dJmrTA1wRMiYVkqhXi2KMYdur
3U47P8ZGUza7W0MST3DgvviN0kVhtmHEnm515mo6NTQdfdxw9WZpy6vMqrBGk2nTgi2c
bnf+muO0+kiNPXVvEzRrO8o=
$$-CyberCash-End-kchfiZ5WAUlpk1/v1ogwuQ==-$$
#####################################################################
Скрытый ключ: полученный из ключа шифрования CyberCash, заданного CyberKey
#####################################################################
Содержимое скрытой секции:
type: transaction-cancel
swversion: 0.8win
begin-transaction: 1234
end-transaction: 4321
Подпись:

kD7DEav2uLQIYMtP9gbhYaBUpB2a5whNwnK2eXbbyTCf56F6dl3DIVf7D8Z4WxbY2YZn
ByRIKeqlhmss7fbdnBiDYmKfOuc+I4bi/Oslml5riaciQhTd2JdHG+PCcHwZ
#####################################################################
Подпись защищает следующие поля: id, date, transaction, cyberkey, type, swversion, begin-transaction, end-transaction
#####################################################################
Объяснение:<> Это попытка клиента аннулировать предыдущую транзакцию или транзакции.<> begin-transaction и end-transaction могут совпадать.

Запрос аннулирования транзакции (TQ.2) определен для взаимодействия клиента с сервером. Этот запрос позволяет клиенту запросить состояние операции и предотвратить операцию, если она еще не осуществлена.

TQ- отклик транзакции (transaction-response)

Отклики, генерируемые TQ1 или TQ2

#####################################################################
Отправитель: CyberServer
Получатель: CyberApp
#####################################################################
Пример сообщения:

$$-CyberCash-0.8-$$
id: mycybercashid
date: 19950121100505.nnn
transaction: 12312314
server-date: 19950121100505.nnn
opaque:

eFXRL+H0J5q318M21wRdtcbhu9WCyLysQkeF9oIcjtbstymx343bbt0EAtU1gcJaUKJZ
3skgvwrhcxU4bFcE68OPlUXAvLq10I3MczPYPsiGrsU0K4bZtQvDZmn727QQAfONBm5s
s1yjIha+Fj481BJQs0CTYc3ju90lAjCYgirXtnnR6yJXoDO75b7UjthvHSnrTWVZvktX
PvTuUCYzbXSFoYvwFM3Y+yHqSHlmWutYKQpYze8zbUSDQfmwTCJyw3aY2JasZ+xMP/CD
JWbCA+gCLBYCnvzM/ExKTZTFD3xr5JBfNbV4p6CiK6lsfRFD7maAK6TSVnWjwCEJNpOv
fyllfWD04fT7LINQcjJiQK1Pk/912Tk6Q35eRaQZorwv2hnY/7By2OkPyFdAqFL+D0H6
TqzxmdEjEFKxi/PPT1+Cs/Nszy8wZzaGg8iWATfARY6stl+02dDhwOoFXSBNvchlVrcI
IlvhumSIQs29Pntj3DbkYo4IEmmN/qi1vnzld22q7lA1q/CQakyc7jlQUFISx76buqwy
35XiC9Yn8flE4Va14UxMf2RCR1B/XoV6AEd64KwPeCYyOYvwbRcYpRMBXFLyYgWM+ME1
+yp7c66SrCBhW4Q8AJYQ+5j5uyO7uKyyq7OhrV0IMpRDPjiQXZMooLZOifJPmpvJ66hC
VZuWMuA6LR+TJzWUm4sUP9Zb6zMQShedUyOPrtw1vkJXU1vZ5aI8OJAgUcLEitcD+dsY
Df4CzA00fC10POkJ58HZB/pSBfUrHAa+IqMHyZkV/HBi9TjTwmktJi+8T9orXS0jSvor
dMTGWn0ifETy2VXt
$$-CyberCash-End-0QXqLlNxrn4GNQPPk9AO1Q==-$$
#####################################################################
Скрытый ключ. Ключ сессии из TQ1/TQ2 для текущих значений транзакции и ID.
#####################################################################
Содержимое скрытой секции:

type: transaction-response
response-code: success/failure/etc.
message; текстовое сообщение, посылаемое сервером покупателю.
swseverity: fatal/warning
swmessage; Сообщение, указывающее, что программа CyberApp является устаревшей. Может содержать несколько строк.
report-fee: usd 0.15 [если не равно нулю]

transaction-1: old-transaction-number
transaction-status-1: success/failure/pending/cancelled/etc.
server-date-1: 19951212125959.nnn
date-1: 19950121100505.nnn
type-1: auth-only/etc.

Оплата отчета (Report-fee) представляет собой уведомление о том, что данный отчет имеет цену и его предоставление зависит от оплаты.
Транзакции с заданным номером может соответствовать несколько транзакций (аутентификация, оплата и т.д.). Термины

"исходная транзакция"			относится к платежу или другой транзакции, которая была запрошена или аннулирована. Заметим, что эта транзакция в действительности не является резидентной для сервера.
"request"			относится к запрашивающим сообщениям TQ.2 или TQ.1.
id:			идентификатор сообщения-запроса
date:			дата сообщения-запроса
transaction:			транзакция сообщения-запроса
server-date:			текущая дата/время
type:			Отклик транзакции
response-code:			код отклика для сообщения-запроса, может быть одним из:
	"success"		означает, сообщение прошло успешно. Не подразумевает требования присылки состояния запроса.
	"failure-hard"		означает, что сообщение-запрос не прошло из-за некорректного формата или по какой-то другой причине.
	"failure-swversion"		означает, что запрос не был обработан из-за проблем ревизии программного обеспечения.
message:			сообщение используется только для транзакции TQ, а не к состоянию транзакций, статус или аннулирование которых были запрошены. Сообщение формируется на основании кода отклика:
	"success"		сообщение проигнорировано.
	"failure-hard"		используется стандартное сообщение уведомление о неудаче.
	"failure-swversion"		в случае фатальной ошибки используется стандартное сообщение типа swversion
swseverity:			относится к сообщению-запросу
swmessage:			относится к сообщению-запросу - для полей запрос/отмена ('N' берется из ряда от 1 до N)
transaction-N:			номер исходной транзакции, или, если исходной транзакции на сервере нет, то номер транзакции запроса состояния транзакции с заданным номером. Состояние исходной транзакции может быть одним из:
		"success"	исходная транзакция была успешно проведена. Если запросом было сообщение TQ.2, аннулирование не производится.
		"failure"	исходная транзакция не была реализована. Если запросом было сообщение TQ.2, аннулирование не производится.
		"pending"	исходная транзакция все еще обрабатывается и окончательный результат пока не известен.
		"canceled"	исходная транзакция была аннулирована сервером. Последующий приход исходной транзакции не будет обрабатываться, но будет послан отклик "failure-canceled".
server-date-1:			поле server-date из исходной транзакции. Опускается, если исходная транзакция на сервере отсутствует.
date-1:			поле даты исходной транзакции. Опускается, если исходная транзакция на сервере отсутствует.
type-1:			поле типа исходной транзакции. Опускается, если исходная транзакция на сервере отсутствует.

TQ- запрос транзакции

Запрос клиента серверу о состоянии транзакции.

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

VFaztHuj757Jrv+JxZFsHORy/zgkrxhBCu9cPdE04c1NnXzVlGOHygpSl+UGbUvnhkYl
>21QQaHkaE3geccRk03cqFYoLNRCclImcsyeIZCgVt+2dJTj1V+E7R7ePQtCj+0gY42+V
L5BWhVtmDQFyg1DdJ6n3S/er6ZuObAjpcAogG+T1Na5dJmrTA1wRMiYVkqhXi2KMYdur
3U47P8ZGUza7W0MST3DgvviN0kVhtmHEnm515mo6NTQdfdxw9WZpy6vMqrBGk2nTgi2c
bnf+muO0+kiNPXVvEzRrO8o=
$$-CyberCash-End-kchfiZ5WAUlpk1/v1ogwuQ==-$$

#####################################################################
Скрытый ключ. Генерируется ключом шифрования CyberCash, идентифицированным CyberKey
#####################################################################
Содержимое скрытой секции:

type: transaction-query
swversion: 0.8win
begin-transaction: 1234
end-transaction: 4321
Подпись:

jJfFsKvOxLaV87gxu7lIPet3wIDwh1H2F61reYC9jmUrS6WAtUVFG9aCNuTEBoMixF0X
vD5oPfyheJRIlnL6i0c4o/bfyO3edKAacmWjTmKt6/4y9p3qgvKkSX8r9aym
#####################################################################
Подпись содержит в себе поля: id, date, transaction, cyberkey, type, swversion, begin-transaction, end-transaction
#####################################################################
Объяснение:
Это запрос клиента сообщить ему о состоянии предшествующей транзакции или транзакций.

begin-transaction и end-transaction могут совпадать.

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

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

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

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

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

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

Транзакции IOTP

Базовая версия протокола IOTP поддерживает три типа транзакций. Среди них:

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

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

- Депозит
- Покупка
- Возврат денег
- Отзыв сделки
- Обмен ценностями

Транзакции IOTP предназначенные для проверки корректности функционирования инфраструктуры. В частности:

- Транзакция запроса состояния и
- Ping

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

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

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

Транзакция аутентификации и платежа

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

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

Эти шесть документальных обменов включают в себя:

Аутентификация. Это прямая реализация аутентификации торгового обмена;

Предложение (Offer), зависимое от вида платежа. Это торговый обмен предложения, объединенный с платежным обменом выбора вида платежа. Его целью является обеспечение Продавца информацией о выборе вида платежа;

Предложение, не зависимое от вида платежа. Это также торговый обмен предложения (Offer). Однако в этом случае содержимое отклика Offer не зависит от выбора вида платежа;

Платеж. Это непосредственная реализация платежной части торгового обмена;

Доставка. Это прямая реализация обмена доставки;

Доставка с платежом. Это реализация совмещеных торговых обменов платежа и доставки.

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

Рис. .17. Блок-диаграмма обмена сообщениями платежа и аутентификации

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

Далее рассматриваются методы обработки рабочих ошибок (Business Errors) в процессе документального обмена (смотри раздел 4.2).

UNK- неизвестная ошибка

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

#####################################################################
Отправитель: MerchantApp или CyberServer
Получатель: CyberApp или MerchantApp
#####################################################################
Пример сообщения:

$$-CyberCash-0.8-$$
type: unknown-error
unknown-error-message:
Текст сообщения о причинах ошибки, которое следует представить пользователю. (Не найден CyberCash-обработчик, проверка целостности обработчика не прошла, специфицирована неизвестная версия протокола, специфицирован неизвестный тип и т.д.)
{
server-date: 19950121100506.nnn [если послано сервером]
}
или
{
merchant-date: 19950121100506.nnn [если послано продавцом]
}
x-id: mycybercashID
x-transaction: 123123213
x-date: 19950121100505.nnn
x-cyberkey: CC1001
x-opaque:

2DqiOQfGRZjzddWpEZwGsJnoTsp9Yiri8DE9cPUMPsJ7lTFuE4XHi4QfN2cAipDB2G/G
9hr7Hj4u4xfMky7nPvJurClZejkI8eNp8iXLtrfS4DhR4yCFQjCiKk0dh83p+DDsFVV7
TI3Du2B15sQS+SdaoPwkfVDnJv4Y+b7vu2cN7bG7exCkBapBcJZbReNaWX5sf+U8ypfw
5V6QdMOzNXpef3z+cTTWfGOtmn9T1Pwo1Yi9ObyIf/wiK+IPb+bBZ9UwLZSB+qVMfJmX
GnHXO3AnA/PD+jKYCtsm2Gxv2WB3CuezOyzPtORuqLp5ubgnLBF9aBBjxwLdbn+cp5sm
lw51IHbmo1Jj7H6wyNnRpEjy4tM73jcosBfGeQDHxgyH1uaiFNr2D+WvmuYo7eun2dsy
Wve2O/FwicWHvkg5aDPsgOjzetsn1JCNZzbW
$$-CyberCash-End-7Tm/djB05pLIw3JAyy5E7A==-$$

Это сообщение посылается в качестве отклика, когда не удается найти или понять тип сообщения. Оно всегда имеет в начале поля типа и unknown-error-message. Любые поля запроса, которые удается распознать, копируются с префиксами "x-" в сообщение UNK1, посылаемое в качестве отклика. Таким образом, если появляется x-opaque, это означает, что в исходном запросе было поле opaque и т.д.

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

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

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

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

рабочими ошибками

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

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

Связанные с проверкой согласованности блоков и компонентов.

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

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

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

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

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

XML not well formed. Документ имеет не верный формат XML (смотри [XML])

XML not valid. Документ не вполне отвечает требованиям XML (смотри [XML])

Технические ошибки блочного уровня (смотри раздел 4.3.3) в блоке ссылок транзакции (смотри раздел 3.3) и блоке подписи. Следует проверить только эти блоки, если с XML все в порядке.

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

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

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

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

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

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

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

предложение ограничено по времени;

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

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

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

Выбор Покупателем льготных видов платежа

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

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

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

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

Покупатель непосредственно вводит этот код. Это располагает к ошибкам и неудобно для клиента, кроме того покупателю надо как-то передать этот код. Этот подход не рекомендуется,

Используется один из идентификаторов вида платежа, определенных в IOTP и предварительно загруженных в приложение покупателя,

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

	- сертификат SET для видов платежа, которые используют этот протокол оплаты;
	- код предоставляется платежной программой, которая работает с конкретным методом оплаты, это может быть приложимо к, например, GeldKarte, Mondex, CyberCash и DigiCash,

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

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

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

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

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

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

XML Document Prolog

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

<?XML Version='1.0'?>
<!DOCTYPE IotpMessage >
<IotpMessage>
...[ZEBR_TAG_br </iotpmessage>

	SigBlk?,
	ErrorBlk?,
	( AuthReqBlk \|
		AuthRespBlk \|
		AuthStatusBlk \|
		CancelBlk \|
		DeliveryReqBlk \|
		DeliveryRespBlk \|
		InquiryReqBlk \|
		InquiryRespBlk \|
		OfferRespBlk \|
		PayExchBlk \|
		PayReqBlk \|
		PayRespBlk \|
		PingReqBlk \|
		PingRespBlk \|
		TpoBlk \|
		TpoSelectionBlk
	)*

	( TransRefBlk,
	SigBlk?,
	ErrorBlk?,
	( AuthReqBlk \|
		AuthRespBlk \|
		AuthStatusBlk \|
		CancelBlk \|
		DeliveryReqBlk \|
		DeliveryRespBlk \|
		InquiryReqBlk \|
		InquiryRespBlk \|
		OfferRespBlk \|
		PayExchBlk \|
		PayReqBlk \|
		PayRespBlk \|
		PingReqBlk \|
		PingRespBlk \|
		TpoBlk \|
		TpoSelectionBlk
	)*

Размер Logo

Регистрация персоны и нахождение приложения

Рекомендации для Id видов платежа в программе покупателя

SET и другие системы осуществления платежей

Severity = Hard Error

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

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

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

Скрытая часть

Словарь

Смарт-карты EMV

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

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

Сообщение CM- post-auth-capture

Сообщение IOTP

Сообщение IOTP выбора TPO

Аннулирует возврат денег, если сообщение

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

Сообщение-отклик доставки

Сообщение отклик на предложение IOTP

Сообщение платежного обмена IOTP

Сообщение платежного отклика и отклика доставки

Сообщение платежного запроса

Сообщение платежного запроса IOTP

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

Сообщение TPO

Сообщение TPO и отклика Offer

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

Сообщение запроса доставки IOTP

Сообщения покупателя о покупке, содержащие данные о кредитной карте

Сообщения продавца о покупке, связанные с кредитной картой

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

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

Ссылки

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

Таблица описанных сообщений

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

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

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

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

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

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

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

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

TQ- отклик транзакции (transaction-response)

TQ- запрос транзакции

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

Транзакции IOTP

Транзакция аутентификации и платежа

UNK- неизвестная ошибка

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

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

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

Выбор Покупателем льготных видов платежа

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

XML Document Prolog