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

         

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


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

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

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

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

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

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

За исключением алгоритмов, которые начинаются с "pay:", новые значения выделяются после просмотра торгового почтового списка IETF и с привлечением “специального эксперта”.

Элемент Algorithm обычно определяется в пределах пространства имен [DSIG]. Со временем эта процедура может измениться.

Тип элемента/Имя атрибутаЗначения атрибутов
Вид платежа/BrandId

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

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

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

Если CurrCodeType = "ISO4217-A", тогда код валюты является буквенным, определенным в [ISO4217].

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

Код типа валюты IOTP, сконструирован так, чтобы позволять поддержку "новых" псевдовалют, таких как loyalty или frequent flyer points.
На момент написания этого документа ни один из таких кодов не был лпределен.

Тип элемента/Имя атрибутаЗначения атрибута
Валютная сумма/CurrCodeType"ISO4217A"
"IOTP"
Новые значения атрибута CurrCodeType выделяются после публикования через подписной лист IETF и рассмотрения экспертами.
DeliveryData/DelivMethod"Post"
"Web"
"Email"
Новые значения атрибута Delivery Method выделяются после публикования через подписной лист IETF и рассмотрения экспертами. Это может потребовать публикации дополнительной документации, описывающей как используется данный метод доставки.
PackagedContent/Content"PCDATA"
"MIME"
"MIME:mimetype" (где mimetype должен быть тем же, что и в content-type, как это определено в [MIME])
"XML"
Если атрибут Content имеет форму "MIME:mimetype", тогда управление новыми значениями для "mimetype" определено в [MIME]. В противном случае, новые значения атрибута Content выделяются после публикования через подписной лист IETF и рассмотрения экспертами. Это может потребовать публикации дополнительной документации, описывающей как используется новый атрибут в элементе Packaged Content.
RelatedTo/RelationshipType"IotpTransaction"
"Reference"
Новые значения атрибута RelationshipType выделяются после публикования через подписной лист табочей группы IETF и рассмотрения экспертами. Это может потребовать публикации дополнительной документации, описывающей как осуществляется метод доставки.
Тип элемента/Имя атрибута Значения атрибута
Значения Status/StatusTypeЗначения Предложение
Платеж
Доставка
Аутентификация
Не идентифицировано
Новые значения атрибута Status Type выделяются после:oпубликации в Торговой Рабочей Группе IETF, документа RFC, описывающего торговый обмен, торговые роли и соответствующие компоненты, которые относятся к Status и
oрассмотрения документа в торговом почтовом листе IETF и экспертами.
Документ, описывающий новые значения атрибута Status Type, может быть объединен с документами,описывающими новые торговые роли и типы подписей (смотри ниже).
TradingRole/TradingRole"Consumer"
"Merchant"
"PaymentHandler"
"DeliveryHandler"
"DelivTo"
oпубликации в Торговой Рабочей Группе IETF, документа RFC, описывающего торговый обмен, торговые роли и соответствующие компоненты, которые относятся к Trading Role и
oрассмотрения документа в торговом почтовом листе IETF и экспертами.



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

Содержание раздела