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

         

Определение ID-атрибутов сообщений IOTP


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

IotpMsgId_value ::= IotpMsgIdPrefix IotpMsgIdSuffix
IotpMsgIdPrefix ::= NameChar (NameChar)*IotpMsgIdPrefixКроме того сообщения, которые содержат: торговый блок информационного запроса, информационного отклика, запроса или отклика Ping, используют один и тот же префикс для всех сообщений, посланных Продавцом или Покупателем:<
table>о"M" - Продавец (Merchant)о"C" - Покупатель (Consumer)


Для сообщений, которые содержат торговый блок информационного запроса или блок запроса Ping, префикс делается равным "I" (Inquiry). Для сообщений, которые содержат торговый блок отклика на информационный запрос или блок отклика Ping, префикс равен "Q". Префикс для других торговых ролей в сделке содержится в компоненте Organisation (организации) и прописывается обычно Продавцом. Ниже представлены рекомендуемые значения:

о"P" - Первый Кассир
o"R" - Второй Кассир
o"D" - Агент доставки
o"C" - Доставка (Deliver To)
Префиксы должны содержать один символ. NameChar имеет то же значение, что и определение NameChar в [XML].
IotpMsgIdSuffixСуффикс состоит из одной или более цифр. Суффикс должен быть уникальным для данной торговой роли транзакции IOTP. Рекомендации сводятся к следующему:
oПервому сообщению IOTP, посланному торговой ролью, присваивается суффикс "1".
oДля второго и последующих IOTP-сообщений, посланных той же торговой ролью, суффикс увеличивается на 1 для каждого последующего сообщения.
oСуффикс не может содержать начальных нулей.
Короче Id-компонент первого сообщения IOTP, посланного Покупателем будет иметь ID-атрибут "C1", второе - "C2", третье - "C3" и т.д. Цифра имеет то же определение что и в [XML].

Определение платежного инструмента


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

кредитная карта, такая как MasterCard или Visa;

дебитная карта типа MasterCard Maestro;

смарт карта, базирующаяся на системе электронных платежей, такой как Mondex, GeldKarte или Visa Cash;

программа, базирующаяся на системе платежей типа CyberCash или DigiCash.

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

Определение стимулирующего вида оплаты


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

во время покупки. Например, если покупатель платит с помощью "Walmart MasterCard" через сервер Walmart, то он может получить скидку в 5%, это означает, что покупатель в действительности платит меньше,

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

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

первый пример (получение выгоды в момент покупки), требует чтобы:

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


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

каждый поощрительный вид оплаты в списке, предлагаемом продавцом, должен быть идентифицирован как отдельный вид платежа. Например: "Walmart", "Sears", "Marks and Spencer" и "American Advantage Visa", будут рассматриваться как отдельные виды оплаты.

Определение вида платежа


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

платежные ассоциации и платежные системы частных фирм, например MasterCard, Visa, American Express, Diners Club, Mondex, GeldKarte, CyberCash, и т.д..

поощрительные виды платежа (смотри ниже). Сюда входят:

 

- store brands, где платежный инструмент предоставляется покупателю конкретным продавцом, например Walmart, Sears или Marks and Spencer (UK)

 

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



Определения и выбор вида платежа


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

определения платежных инструментов и видов платежа в контексте IOTP. Вводятся опционные категории видов оплаты "Dual Brand" или "поощрительный вид платежа",

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

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


ID-атрибут блоков и компонентов в пределах транзакции IOTP также должен быть уникальным. Ниже представлено его определение:

BlkOrCompId_value ::= IotpMsgId_value "." IdSuffix
IdSuffix ::= Digit (Digit)*

IotpMsgId_value

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

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

IdSuffixСуффикс состоит из одной или более цифр. Суффикс должен быть уникальным для ID-атрибута ID-компонента сообщения, используемого для генерации ID-атрибута. Рекомендуется здесь следующее:
o

Первому блоку или компоненту, посылаемому торговой ролью присваивается суффикс "1"

o

Для второго и далее блоков или компонентов ID-атрибуты увеличивается на 1 для каждого последующего сообщения.

oСуффикс не может содержать начальных нулей.

Короче, первый новый блок или компонент добавляется ко второму посылаемому сообщению IOTP, например, первый ID-атрибут - "C2.1", второй - "C2.2", третий - "C2.3" и т.д. Цифра имеет то же определение, что и в [XML].

Определения типов данных протокола IOTP


Этот раздел содержит XML DTD для IOTP.

<!--
******************************************************
* *
* INTERNET OPEN TRADING PROTOCOL VERSION 1.0 DTD *
* Имя файла: ietf.org/rfc/rfc2801.dtd *
* *
* Отличие от версии 07 (iotp-v1.0-protocol-07.dtd) *
* - никаких изменений *
* *
* Copyright Internet Engineering Task Force 1998-2000*
* *
******************************************************
******************************
* Определение сообщения IOTP *
******************************
-->
<!ELEMENT IotpMessage ( TransRefBlk, IotpSignatures?, 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' >

<!--
***************************************
* Определение блока ссылок транзакции *
*************************************** -->
<!ELEMENT TransRefBlk (TransId, MsgId, RelatedTo*)>
<!ATTLIST TransRefBlk ID ID #REQUIRED>
<!ELEMENT TransId EMPTY>
<!ATTLIST TransId ID ID #REQUIRED
Version NMTOKEN #FIXED '1.0'IotpTransId CDATA #REQUIRED
IotpTransType CDATA #REQUIREDTransTimeStamp CDATA #REQUIRED>

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

RespIotpMsg NMTOKEN #IMPLIEDxml:lang NMTOKEN #REQUIRED
LangPrefList NMTOKENS #IMPLIEDCharSetPrefList NMTOKENS #IMPLIED

SenderTradingRoleRef NMTOKEN #IMPLIED

SoftwareId CDATA #REQUIREDTimeStamp CDATA #IMPLIED>

<!ELEMENT RelatedTo (PackagedContent) >

<!ATTLIST RelatedTo ID ID #REQUIRED

xml:lang NMTOKEN #REQUIREDRelationshipType NMTOKEN #REQUIRED
Relation CDATA #REQUIREDRelnKeyWords NMTOKENS #IMPLIED>

<!--
**********************************
* Общий элемент Packaged Content *
********************************** -->
<!ELEMENT PackagedContent (#PCDATA)>
<!ATTLIST PackagedContent Name CDATA #IMPLIED

Content NMTOKEN "PCDATA"Transform (NONE|BASE64) "NONE">

<!--
***********************
* Торговые компоненты *
*********************** -->
<!-- PROTOCOL OPTIONS COMPONENT -->
<!ELEMENT ProtocolOptions EMPTY >
<!ATTLIST ProtocolOptions ID ID #REQUIRED
xml:lang NMTOKEN #REQUIREDShortDesc CDATA #REQUIRED
SenderNetLocn CDATA #IMPLIEDSecureSenderNetLocn CDATA #IMPLIED
SuccessNetLocn CDATA #REQUIRED> <!-- AUTHENTICATION DATA COMPONENT -->
<!ELEMENT AuthReq (Algorithm, PackagedContent*)>
<!ATTLIST AuthReq ID ID #REQUIRED
AuthenticationId CDATA #REQUIREDContentSoftwareId CDATA #IMPLIED>
<!-- AUTHENTICATION RESPONSE COMPONENT -->
<!ELEMENT AuthResp (PackagedContent*) >
<!ATTLIST AuthResp ID ID #REQUIRED
AuthenticationId CDATA #REQUIREDSelectedAlgorithmRef NMTOKEN #REQUIRED
ContentSoftwareId CDATA #IMPLIED>
<!-- TRADING ROLE INFO REQUEST COMPONENT -->
<!ELEMENT TradingRoleInfoReq EMPTY>
<!ATTLIST TradingRoleInfoReq ID ID #REQUIRED
TradingRoleList NMTOKENS #REQUIRED>
<!-- ORDER COMPONENT -->
<!ELEMENT Order (PackagedContent*)>
><!ATTLIST Order ID ID #REQUIRED
xml:lang NMTOKEN #REQUIREDOrderIdentifier CDATA #REQUIRED
ShortDesc CDATA #REQUIREDOkFrom CDATA #REQUIRED
OkTo CDATA #REQUIREDApplicableLaw CDATA #REQUIRED
ContentSoftwareId CDATA #IMPLIED>
<!-- ORGANISATION COMPONENT -->
<!ELEMENT Org (TradingRole+, ContactInfo?, PersonName?, PostalAddress?)>
<!ATTLIST Org ID ID #REQUIRED
xml:lang NMTOKEN #REQUIREDOrgId CDATA #REQUIRED
LegalName CDATA #IMPLIEDShortDesc CDATA #IMPLIED
LogoNetLocn CDATA #IMPLIED>
<!ELEMENT TradingRole EMPTY>
><!ATTLIST TradingRole ID ID#REQUIRED
TradingRole NMTOKEN #REQUIREDIotpMsgIdPrefix NMTOKEN #REQUIRED
CancelNetLocn CDATA #IMPLIEDErrorNetLocn CDATA #IMPLIED
ErrorLogNetLocn CDATA #IMPLIED>
<!ELEMENT ContactInfo EMPTY>
<!ATTLIST ContactInfo xml:lang NMTOKEN #IMPLIED
Tel CDATA #IMPLIEDFax CDATA #IMPLIED
Email CDATA #IMPLIEDNetLocn CDATA #IMPLIED>
<!ELEMENT PersonName EMPTY >


<!ATTLIST PersonName xml:lang NMTOKEN #IMPLIED
Title CDATA #IMPLIEDGivenName CDATA #IMPLIED
Initials CDATA #IMPLIEDFamilyName CDATA #IMPLIED>
<!ELEMENT PostalAddress EMPTY>
<!ATTLIST PostalAddress xml:lang NMTOKEN #IMPLIED
AddressLine1 CDATA #IMPLIEDAddressLine2 CDATA #IMPLIED
CityOrTown CDATA #IMPLIEDStateOrRegion CDATA #IMPLIED
PostalCode CDATA #IMPLIEDCountry CDATA #IMPLIED
LegalLocation (True | False) 'False' >
<!-- BRAND LIST COMPONENT -->
<!ELEMENT BrandList (Brand+, ProtocolAmount+, CurrencyAmount+, PayProtocol+)>
<!ATTLIST BrandList IDID #REQUIRED
xml:lang NMTOKEN #REQUIREDShortDesc CDATA #REQUIRED PayDirection
(Debit | Credit) #REQUIRE>
<!ELEMENT Brand (ProtocolBrand*, PackagedContent*)>
<! ATTLIST Brand ID ID #REQUIRED
xml:lang NMTOKEN #IMPLIEDBrandId CDATA #REQUIRED
BrandName CDATA #REQUIREDBrandLogoNetLocn CDATA #REQUIRED
BrandNarrative CDATA #IMPLIEDProtocolAmountRefs IDREFS #REQUIRED
ContentSoftwareId CDATA #IMPLIED>
<!ELEMENT ProtocolBrand (PackagedContent*) >
<!ATTLIST ProtocolBrand ProtocolId CDATA #REQUIRED
ProtocolBrandId CDATA #REQUIRED>
<!ELEMENT ProtocolAmount (PackagedContent*) >
<!ATTLIST ProtocolAmount IDID #REQUIRED
PayProtocolRef IDREF #REQUIREDCurrencyAmountRefs IDREFS #REQUIRED
ContentSoftwareId CDATA #IMPLIED>
<!ELEMENT CurrencyAmount EMPTY >
<!ATTLIST CurrencyAmount IDID #REQUIRED
Amount CDATA #REQUIREDCurrCodeType NMTOKEN 'ISO4217-A'
CurrCode CDATA #REQUIRED>
<!ELEMENT PayProtocol (PackagedContent*) >
<!ATTLIST PayProtocol ID ID #REQUIRED
xml:lang NMTOKEN #IMPLIEDProtocolId NMTOKEN #REQUIRED
ProtocolName CDATA #REQUIREDActionOrgRef NMTOKEN #REQUIRED
PayReqNetLocn CDATA #IMPLIEDSecPayReqNetLocn CDATA #IMPLIED
ContentSoftwareId CDATA #IMPLIED >
<!-- BRAND SELECTION COMPONENT -->
<!ELEMENT BrandSelection (BrandSelBrandInfo?,
BrandSelProtocolAmountInfo?,BrandSelCurrencyAmountInfo?)>
<!ATTLIST BrandSelection IDID #REQUIRED
BrandListRef NMTOKEN #REQUIREDBrandRef NMTOKEN #REQUIRED
ProtocolAmountRef NMTOKEN #REQUIRED


CurrencyAmountRef NMTOKEN #REQUIRED>
<!ELEMENT BrandSelBrandInfo (PackagedContent+)>
<! ATTLIST BrandSelBrandInfo ID ID #REQUIRED
ContentSoftwareId CDATA #IMPLIED>
<!ELEMENT BrandSelProtocolAmountInfo (PackagedContent+)>
<!ATTLIST BrandSelProtocolAmountInfo ID ID #REQUIRED
ContentSoftwareId CDATA #IMPLIED>
<!ELEMENT BrandSelCurrencyAmountInfo (PackagedContent+)>
<!ATTLIST BrandSelCurrencyAmountInfo ID ID #REQUIRED
ContentSoftwareId CDATA #IMPLIED >
<!-- PAYMENT COMPONENT -->
<!ELEMENT Payment EMPTY>
<!ATTLIST Payment IDID #REQUIRED
OkFrom CDATA #REQUIREDOkTo CDATA #REQUIRED
BrandListRef NMTOKEN #REQUIREDSignedPayReceipt (True | False) #REQUIRED
StartAfterRefs NMTOKENS #IMPLIED>
<!-- PAYMENT SCHEME COMPONENT -->
<!ELEMENT PaySchemeData (PackagedContent+) >
<!ATTLIST PaySchemeData IDID #REQUIRED
PaymentRef NMTOKEN #IMPLIEDConsumerPaymentId CDATA #IMPLIED
PaymentHandlerPayId CDATA #IMPLIEDContentSoftwareId CDATA #IMPLIED>
<!-- PAYMENT RECEIPT COMPONENT -->
<!ELEMENT PayReceipt (PackagedContent*) >
<!ATTLIST PayReceipt ID ID #REQUIREDPaymentRef NMTOKEN #REQUIRED
PayReceiptNameRefs NMTOKENS #IMPLIEDContentSoftwareId CDATA #IMPLIED>
<!-- PAYMENT NOTE COMPONENT -->
<!ELEMENT PaymentNote (PackagedContent+)>
<!ATTLIST PaymentNote ID ID #REQUIREDContentSoftwareId CDATA #IMPLIED>
<!ELEMENT Delivery (DeliveryData?, PackagedContent*) >
<!ATTLIST Delivery IDID #REQUIRED
xml:lang NMTOKEN #REQUIREDDelivExch (True | False) #REQUIRED
DelivAndPayResp (True | False) #REQUIREDActionOrgRef NMTOKEN #IMPLIED>
<!ELEMENT DeliveryData (PackagedContent*) >
<!ATTLIST DeliveryData xml:langNMTOKEN #IMPLIED
OkFrom CDATA #REQUIREDOkTo CDATA #REQUIRED
DelivMethod NMTOKEN #REQUIREDDelivToRef NMTOKEN #REQUIRED
DelivReqNetLocn CDATA #IMPLIEDSecDelivReqNetLocn CDATA #IMPLIED
ContentSoftwareId CDATA #IMPLIED>
<!-- CONSUMER DELIVERY DATA COMPONENT -->


<!ELEMENT ConsumerDeliveryData EMPTY>
<! ATTLIST ConsumerDeliveryData ID ID #REQUIRED
ConsumerDeliveryId CDATA #REQUIRED>
<!-- DELIVERY NOTE COMPONENT -->
<!ELEMENT DeliveryNote (PackagedContent+)>
<!ATTLIST DeliveryNote IDID #REQUIRED
xml:lang NMTOKEN #REQUIREDDelivHandlerDelivId CDATA #IMPLIED
ContentSoftwareId CDATA #IMPLIED >
<!-- STATUS COMPONENT -->
<!ELEMENT Status EMPTY>
<!ATTLIST Status IDID #REQUIRED
xml:lang NMTOKEN #REQUIREDStatusType NMTOKEN #REQUIRED
ElRef NMTOKEN #IMPLIEDProcessState (NotYetStarted | InProgress |
CompletedOk | Failed | ProcessError) #REQUIRED
CompletionCode NMTOKEN #IMPLIED
ProcessReference CDATA #IMPLIEDStatusDesc CDATA #IMPLIED >
<!-- TRADING ROLE DATA COMPONENT -->
<!ELEMENT TradingRoleData (PackagedContent+)>
<!ATTLIST TradingRoleData ID ID #REQUIRED
<!ELEMENT InquiryType EMPTY>
<!ATTLIST InquiryType IDID #REQUIRED
Type NMTOKEN #REQUIREDElRef NMTOKEN #IMPLIED
ProcessReference CDATA #IMPLIED >
<!-- ERROR COMPONENT -->
<!ELEMENT ErrorComp (ErrorLocation+, PackagedContent*)>
<!ATTLIST ErrorComp IDNMTOKEN #REQUIRED
xml:lang NMTOKEN #REQUIREDErrorCode NMTOKEN #REQUIRED
ErrorDesc CDATA #REQUIREDSeverity (Warning|TransientError|HardError) #REQUIRED
MinRetrySecs CDATA #IMPLIEDSwVendorErrorRef CDATA #IMPLIED>
<!ELEMENT ErrorLocation EMPTY >
<!ATTLIST ErrorLocation ElementTypeNMTOKEN #REQUIRED
IotpMsgRef NMTOKEN #IMPLIEDBlkRef NMTOKEN #IMPLIED
CompRef NMTOKEN #IMPLIEDElementRef NMTOKEN #IMPLIED
AttName NMTOKEN #IMPLIED>
<!--
**********************
* ТОРГОВЫЕ БЛОКИ *
********************** --> <!-- TRADING PROTOCOL OPTIONS BLOCK -->
<!ELEMENT TpoBlk ( ProtocolOptions, BrandList*, Org* )>
<!ATTLIST TpoBlk ID ID #REQUIRED >
<!-- TPO SELECTION BLOCK -->
<!ELEMENT TpoSelectionBlk (BrandSelection+)>
<!ATTLIST TpoSelectionBlk ID ID #REQUIRED>
<!-- OFFER RESPONSE BLOCK -->
<!ELEMENT OfferRespBlk (Status, Order?, Payment*, Delivery?, TradingRoleData*)>


<! ATTLIST OfferRespBlk ID ID #REQUIRED > <!-- AUTHENTICATION REQUEST BLOCK -->
<!ELEMENT AuthReqBlk (AuthReq*, TradingRoleInfoReq?)>
<!ATTLIST AuthReqBlk ID ID #REQUIRED> <!-- AUTHENTICATION RESPONSE BLOCK -->
<!ELEMENT AuthRespBlk (AuthResp?, Org*)>
<!ATTLIST AuthRespBlk ID ID #REQUIRED> <!-- AUTHENTICATION STATUS BLOCK -->
<!ELEMENT AuthStatusBlk (Status) >
<!ATTLIST AuthStatusBlk ID ID #REQUIRED> <!-- PAYMENT REQUEST BLOCK -->
<!ELEMENT PayReqBlk (Status+, BrandList, BrandSelection,
Payment, PaySchemeData?, Org*, TradingRoleData*)>
<!ATTLIST PayReqBlk ID ID #REQUIRED> <!-- PAYMENT EXCHANGE BLOCK -->
<!ELEMENT PayExchBlk (PaySchemeData)>
<!ATTLIST PayExchBlk ID ID #REQUIRED> <!-- PAYMENT RESPONSE BLOCK -->
<!ELEMENT PayRespBlk (Status, PayReceipt?, PaySchemeData?,
PaymentNote?, TradingRoleData*) >
<!ATTLIST PayRespBlk ID ID #REQUIRED>
<!-- DELIVERY REQUEST BLOCK -->
<!ELEMENT DeliveryReqBlk (Status+, Order, Org*, Delivery,
ConsumerDeliveryData?, TradingRoleData*) >
<!ATTLIST DeliveryReqBlk ID ID #REQUIRED> <!-- DELIVERY RESPONSE BLOCK -->
<!ELEMENT DeliveryRespBlk (Status, DeliveryNote)>
<!ATTLIST DeliveryRespBlk ID ID #REQUIRED> <!-- INQUIRY REQUEST BLOCK -->
<!ELEMENT InquiryReqBlk ( InquiryType, PaySchemeData? )>
<!ATTLIST InquiryReqBlk ID ID #REQUIRED > <!-- INQUIRY RESPONSE BLOCK -->
<!ELEMENT InquiryRespBlk (Status, PaySchemeData?)>
<!ATTLIST InquiryRespBlk ID ID #REQUIRED
LastReceivedIotpMsgRef NMTOKEN #IMPLIED
LastSentIotpMsgRef NMTOKEN #IMPLIED> <!-- PING REQUEST BLOCK -->
<!ELEMENT PingReqBlk (Org*)>
<!ATTLIST PingReqBlk ID ID #REQUIRED> <!-- PING RESPONSE BLOCK -->
<!ELEMENT PingRespBlk (Org+)>
<!ATTLIST PingRespBlk ID ID #REQUIRED
PingStatusCode (Ok | Busy | Down) #REQUIRED
BR/P> xml:lang NMTOKEN #IMPLIEDPingStatusDesc CDATA #IMPLIED> <!-- ERROR BLOCK -->


><!ELEMENT ErrorBlk (ErrorComp+, PaySchemeData*)>
<! ATTLIST ErrorBlk ID ID #REQUIRED> <!-- CANCEL BLOCK -->
<!ELEMENT CancelBlk (Status)>
<!ATTLIST CancelBlk ID ID #REQUIRED>
<!--
*****************************
* Определение блока подписи *
***************************** -->
<!ELEMENT IotpSignatures (Signature+ ,Certificate*)>
<!ATTLIST IotpSignatures ID ID #IMPLIED> <!--
*******************************************
* Определение компонента подписи IOTP *
******************************************* --> <!ELEMENT Signature (Manifest, Value+) >
<!ATTLIST Signature ID ID #IMPLIED> <!ELEMENT Manifest ( Algorithm+,
Digest+,
Attribute*,
OriginatorInfo,
RecipientInfo+ )> <!ATTLIST Manifest LocatorHRefBase CDATA #IMPLIED> <!ELEMENT Algorithm (Parameter*)>
<!ATTLIST Algorithm ID ID #REQUIRED
>type (digest|signature) #IMPLIEDname NMTOKEN #REQUIRED> <!ELEMENT Digest (Locator, Value)>
<!ATTLIST Digest DigestAlgorithmRef IDREF #REQUIRED> <!ELEMENT Attribute ( ANY ) >
<!ATTLIST Attribute type NMTOKEN #REQUIRED
>critical ( true | false ) #REQUIRED> <!ELEMENT OriginatorInfo ANY >
<!ATTLIST OriginatorInfo OriginatorRef NMTOKEN #IMPLIED> <!ELEMENT RecipientInfo ANY >
<!ATTLIST RecipientInfo SignatureAlgorithmRef IDREF #REQUIRED
SignatureValueRef IDREF #IMPLIEDSignatureCertRef IDREF #IMPLIED
RecipientRefs NMTOKENS #IMPLIED> <!ELEMENT KeyIdentifier EMPTY>
<!ATTLIST KeyIdentifier value CDATA #REQUIRED> <!ELEMENT Parameter ANY >
<!ATTLIST Parameter type CDATA #REQUIRED>
<!--
*******************************************
* Определение компонента сертификата IOTP *
******************************************* -->
<!ELEMENT Certificate ( IssuerAndSerialNumber, ( Value | Locator ) )> <!ATTLIST Certificate ID ID #IMPLIEDtype NMTOKEN #REQUIRED> <!ELEMENT IssuerAndSerialNumber EMPTY >
<!ATTLIST IssuerAndSerialNumber issuer CDATA #REQUIRED number CDATA
#REQUIRED>
<!--
**************************************
* Определение компонента SHARED IOTP *
************************************** -->
<!ELEMENT Value ( #PCDATA )>
<!ATTLIST Value ID ID #IMPLIED encoding (base64|none) 'base64'> <!ELEMENT Locator EMPTY>
<!ATTLIST Locator xml:link CDATA #FIXED 'simple' href CDATA #REQUIRED>

Открытый торговый протокол Интернет определяет


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

Оттиски (Thumbprints)


Оттиски определяются путем вычисления хэш функции SHA-1, следуя кодировке DER ASN.1 структур:

UnsignedCertificate

UnsignedCertificateRevocationList

UnsignedBrandCRLIdentifier

Оттиск является тем же самым хэшем, который используется для подписи, верификации, CRL или BCI. Оттиски посылаются в сообщениях-запросах SET и могут игнорироваться получателем. Отправитель не обязан посылать все оттиски для всех сертификатов, CRL и BCI, имеющимся в его кэше, а только те, которые имеют отношение к конкретной паре сообщений запрос/отклик. Например, программа продавца не обязана посылать оттиски для всех держателей карт или всем платежным системам. Процедура отправки оттиска представлена в таблице 4.6.2.7.

Таблица 4.6.2.7. Посылка оттиска

ШагДействие
1Инициализировать буфер для запоминания оттисков
2

Добавить оттиск (хэш):

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

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

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

3Присылается результат работы шага 2.

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

Таблица 4.6.2.8. Обработка оттисков получателем

ШагДействие
1Инициализировать буфер для запоминания оттисков
2

Для каждого из них:

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

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

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

3

Присылается результат работы шага 2 со списком сертификатов, CRL и BCI, которые следует послать в отклике.


Простая инкапсуляция с оператором подписи Enc(s,r,t) представляет данные, которые были сначала подписаны, а затем зашифрованы. Этот случай соответствует варианту PKCS#7 SignedData, инкапсулированных в EnvelopedData. Процедура выполняется следующим образом.
ШагДействие
1Используя оператор подписи и секретный ключ объекта s, подписать содержимое группы t
2Добавить результат шага 1 в группу t
3Используя оператор асимметричного шифрования и общедоступный ключ получателя r, зашифровать результат шага 2
4Послать результат работы шага 3
Другие варианты инкапсуляции осуществляются сходным образом. Асимметричный оператор шифрования E(r,t) соответствует EnvelopedData PKCS#7 для группы t, зашифрованной для объекта r. Этот оператор включает в себя быстрое симметричное шифрование основного объема данных, а также асимметричное шифрование секретного ключа предшествующего шифрования с привлечением общедоступного ключа получателя. Протоколом шифрования по умолчанию для SET является DES, а для асимметричного шифрования - RSA. Последовательность операций при асимметричном шифровании представлена в таблице 4.6.2.9. Таблица 4.6.2.9. Процедура асимметричного шифрования
ШагДействие
1Инициализировать и загрузить информационные поля, зависимые от типа сообщения
2Преобразовать информационные поля, подлежащие шифрованию, в формат DER
3Сформировать новый ключ DES
4Зашифровать результат работы шага 2, используя ключ DES из шага 3. Используется режим DES-CBC.
5Инициализировать буфер зашифрованных данных с помощью кода типа данных, идентификатора алгоритма и добавить эту информацию к результату шага 4.
6Инициализировать буфер цифрового конверта, в зависимости от получателя (128 байт)
7Инициализировать буфер дополнительного шифрования OAEP с использование ключа из шага 3.
8Применить OAEP для буфера цифрового конверта
9Зашифровать результат шага 8, используя асимметричный общедоступный ключ объекта r
10Инициализировать информационный буфер получателя посредством идентификатора алгоритма RSA и добавить туда результат работы шага 9
11Инициализировать буфер EnvelopedData PKCS#7 и положить туда результат шага 10 и 5
12Прислать результат шага 11
Оператор шифрования с гарантией целостности EH(r,t) подобен Е за исключением того, что цифровой конверт PKCS#7 включает в себя хэш группы t.


Он предполагает быстрое симметричное шифрование открытого текста сообщения и последующее шифрование секретного ключа с использование общедоступного ключа получателя. Процедура такого шифрования представлена в таблице 4.6.2.10. Таблица 4.6.2.10. Асимметричное шифрование с гарантией целостности
ШагДействие
1Инициализировать и загрузить информационные поля, зависимые от типа сообщения
2Преобразовать информационные поля, подлежащие шифрованию, в формат DER
3Вычислить хэш SHA-1 результата шага 2
4Сформировать новый ключ DES
5Зашифровать результат работы шага 2, используя ключ DES из шага 4. Используется режим DES-CBC.
6Инициализировать буфер зашифрованных данных с помощью кода типа данных, идентификатора алгоритма DES и добавить эту информацию к результату шага 5.
7Инициализировать буфер цифрового конверта, в зависимости от получателя (128 байт)
8Инициализировать буфер дополнительного шифрования OAEP с использование ключа из шага 4 и хэша, вычисленного на шаге 5.
9Применить OAEP для буфера цифрового конверта
10Зашифровать результат шага 9, используя асимметричный общедоступный ключ объекта r
11Инициализировать информационный буфер получателя посредством идентификатора алгоритма RSA и добавить туда результат работы шага 10
12Инициализировать буфер PKCS#7 и положить туда результат шага 11 и 6
13Прислать результат шага 12
Оператор симметричного шифрования EK(k,t) шифрует открытый текст группы t с привлечением ключа k. Для целей шифрования здесь могут использоваться алгоритмы DES или CDMF. Процедура симметричного шифрования представлена в таблице 4.6.2.11. Таблица 4.6.2.11. Процедура симметричного шифрования
ШагДействие
1Инициализировать и загрузить информационные поля, зависимые от типа сообщения
2Преобразовать информационные поля, подлежащие шифрованию, в формат DER
3Зашифровать результат работы шага 2, используя ключ k. Применяется алгоритм DES или CDMF в зависимости от того, какой из этих алгоритмов поддерживается получателем сообщения. Для DES используется режим DES-CBC.
4Инициализировать буфер зашифрованных данных с помощью кода типа данных, идентификатора алгоритма (DES или CDMF) и добавить к этой информации результат шага 3.
5Прислать результат шага 4
Оператор цифровой подписи S(s,t) соответствует PKCS#7 SignedData для группы t, подписанной объектом s.


Для SET алгоритмом подписи по умолчанию является RSA с хэшем SHA-1. Обычно для SET подпись делается до шифрования. Операция цифровой подписи для SignedData всегда производится над данными, представленными в формате DER (ASN.1). Операции подпись SignedData никогда не производятся для произвольных строк октетов (например, для ASCII-строк). По этой причине тип содержимого data не используется никогда. PKCS#7 требует включения в подписываемый текст двух аутентифицированных атрибутов. Такими атрибутами являются contentType и messageDigest, оба они включаются в содержимое, которое подписывается в рамках SET. SignedData имеет формат DER, и содержат октеты тэга и длины атрибутов. Исходные данные для расчета дайджеста сообщения берутся из компонента content последовательности ContentInfo. ContentInfo связывает идентификатор компонента contentType с типом компонента >content. В SET каждый тип содержимого однозначно именуется объектным идентификатором. Так как это значение не защищено от атак подмены, он также включается в authenticateAttributes. Атрибут contentType специфицирует идентификатор объекта, который соответствует значению компонента contentType последовательности ContentInfo. Атрибут messageDigest содержит значение хэшированного компонента content ContentInfo. Определение последовательности SignerInfos в PKCS#7 допускает любое число подписантов (по одному SignerInfo на каждого). SET PKCS#7 SignedData требует наличия одного подписанта для всех сообщений кроме CertReq и CertInqReq, которые требуют две подписи, когда используются для обновления сертификата. Таким образом, требования SET несколько мягче, чем PKCS#7. В компоненте SignerInfo из SignerInfos как authenticateAttributes, так и unauthenticateAttributes компоненты специфицируются опционно. В SET компонент unauthenticateAttributes последовательности SignerInfo всегда отсутствует и никогда не появляется при кодировании SignedData. Компонент же authenticateAttributes всегда присутствует и включается в процесс вычисления дайджеста.


Процедура цифровой подписи представлена в таблице 4.6.2.12. Таблица 4.6.2.12. Процедура формирования цифровой подписи
ШагДействие
1 Инициализировать тип SignedData, введя код версии, идентификатор алгоритма и тип содержимого, подлежащего подписанию
2Преобразовать информацию, подлежащую подписанию в формат DER
3Использовать результат шага 2 для инициализации компонента content из ContentInfo.
4Инициализировать тип SignerInfo, введя код версии, идентификаторы алгоритмов вычисления и шифрования дайджеста
5Вычислить дайджест сообщения, используя SHA-1 для результата шага 3
6Инициализировать структуру authenticatedAttributes и занести в структуру атрибуты contentType и messageDigest. Установить компоненты type атрибутов равными идентификаторам этих атрибутов
7Инициализировать компонент values первого атрибута типа кодом содержимого, подлежащего подписанию, а второго атрибута - значением дайджеста, вычисленного на этапе 5
8Закодировать аутентифицированные атрибуты и зашифровать результат, используя секретный ключ отправителя. Поместить результат в SignedData
9Выбрать соответствующие сертификаты Х.509 и CRL, необходимые для верификации подписи, и включить их в SignedData
10Если тип сообщения требует двух подписей, повторить шаги с 4 по 9
Оператор ключевого хэширования HMAC(t,k) соответствует 160-битовому хэшу HMAC-SHA-1 для группы t при использовании секретного ключа k. Эта функция нужна для сокрытия номера счета в сертификате владельца карты. Секретный ключ известен только владельцу карты и эмитенту. Процедура ключевого хэширования представлена в таблице 4.6.2.13. Таблица 4.6.2.13. Процедура ключевого хэширования
ШагДействие
1Установить ipad соответствующим буферу, который содержит 64 байта с кодами 0х36
2Установить opad равным буферу, содержащему 64 байта с кодами 0х5С
3Добавить нули в конец k, чтобы размер строки стал равным 64 байтам. Например, если длина k равна 20 байт, то следует добавить 44 нуля.
4Осуществить операцию побитового исключающего ИЛИ для результата шага 3 и ipad
5Добавить данные группы t в 64-байтовый буфер, сформированный на этапе 4
6Вычислить хэш SHA-1 для результата шага 5 с привлечением Hash-оператора
7Осуществить операцию побитового исключающего ИЛИ для результата шага 3 и opad
8Добавить результат SHA-1 шага 6 к 64-байтовому буферу, заполненному в результате шага 7
9Вычислить хэш SHA-1 для результата шага 8 с привлечением Hash-оператора
10Прислать результат работы шага 9
Оператор хэширования H(t) соответствует 160-битовому хэшу SHA-1 для группы t.


Этот оператор соответствует параметризованному типу ASN.1 H{}. Он используется только в обработке OAEP. Оператор DigestedData DD(T) соответствует 160-битовому хэшу SHA-1 группы, вложенной в последовательность PKCS DigestedData. Протокол SET использует параметризованный тип DD{} (detached digests). Каждый тип содержимого типа дайджест в SET имеет имя, уникальный идентификатор объекта. Компонент contentType из ContentInfo делается равным значению этого идентификатора. Компонент digest из DigestedData является результатом вычисления дайджеста сообщения. Он содержит дайджест сообщения типа SET, идентифицируемый компонентом contentType из contentInfo. Дайджест вычисляется с помощью алгоритма из перечня DigestAlgorithm. Вычисление производится для полного DER-представления, включая тэг, длину в октетах и типа ASN.1. Компонент digestAlgorithm из DigestedData устанавливается равным одному из значений кодов алгоритма. Код digestAlgorithm используется получателем для проверки дайджеста сообщения. Верификация осуществляется путем независимого вычисления дайджеста сообщения и сравнения его значения с компонентом digest из DigestedData. Последовательность действий показана в таблице 4.6.2.14. Таблица 4.6.2.14. Процедура вычисления дайджеста сообщения.
ШагДействие
1Установить B равным адресу группы t, для которой вычисляется дайджест
2Установить L равным длине группы t
3Инициализировать 160-битный буфер для хранения хэша SHA-1
4Вычислить хэш SHA-1 для буфера, используя B и L
5Положить результат шага 4 в поле digest DigestedData
6Положить идентификатор хэш-алгоритма SHA-1 в digestAlgorithm
7Установить значение версии равным нулю
Оператор связи L(t1,t2) соответствует последовательности t1 и DigestedData. Компонент связи DigestedData содержит дайджест сообщения для группы t2 и может быть представлен посредством DD(t2). Оператор связи не является симметричным и не может связать t2 с t1. Целью OAEP является обеспечение гарантии того, что отдельные фрагменты сообщения не будут извлечены из блока PKCS#7.


Существуют криптографические методы, которые позволяют определить одни биты сообщения легче, чем другие. OAEP случайным образом перераспределяет биты блока PKCS#7 так, что все биты становятся с этой точки зрения эквивалентными. Примитивы шифрования E, EH, EX и EXH объединяют RSA-шифрование и алгоритм OAEP (Bellare-Rogaway Optimal Asymmetric Encryption Padding). SET использует OAEP для получения дополнительной защиты информации о счете клиента (владельца карты, продавца или получателя) с помощью цифрового конверта. Реализация алгоритма OAEP продемонстрирована в таблице 4.6.2.15. Таблица 4.6.2.15. Описание алгоритма OAEP
ШагДействие
1Подготовить дополнительные данные, как это описано в формате сообщения
2Если используется оператор шифрования EH или EXH, вычислить хэш SHA-1 для данных подлежащих DES-шифрованию
3Сформировать новый случайный ключ для DES-шифрования регулярной части данных
4Объединить DES-ключ, хэш SHA-1 данных (HD) перед DES-шифрованием (если оно применяется) и любые дополнительные данные, чтобы сформировать действительный блок данных ADB (Actual Data Block).
5Взять байт, содержащий код 0х03 (тип блока - BT), семь байтов нулей (байты верификации - V) и байт блока содержимого (BC) и положить в ADB, тем самым формируя блок данных (DB). DB= BT|BC|V|ADB
6Сгенерировать случайную 16-битовую строку E-Salt и вычислить H1(E-Salt). H1 выдает лидирующие байты хэша SHA-1
7Вычислить А=DB Е H1(E-Salt)
8Осуществить присвоение B= E-Salt Е H2(A). Сформировать PDB, объединив А и В. Н2 предоставляет завершающие байты хэша SHA-1
9Присвоить I случайное значение, не равное 0х00 или 0х80
10Зашифровать полученный блок R с помощью RSA
Алгоритм работа OAEP показан на рисунке 4.6.2.9. В DB присутствуют только информационные элементы типа атомик (в нотации ASN.1). Каждый элемент DB кодируется согласно требованиям DER, но без тэгов и октетов длины. При преобразовании из DER-формата в DB к концу блока данных могут добавляться нули (0х00). При обратном преобразовании такие заполнители удаляются.
Рис. 4.6.2.9.


Диаграмма работы OAEP Обработка ошибок Каждому сообщению-запросу должно соответствовать сообщение-отклик. Сообщения об ошибках могут соответствовать как запросам, так и откликам. Сообщение об ошибке указывает, что приславший его не смог разобрать формат полученного запроса или отклика, или при обработке потерпели неудачу верификационные тесты. Не следует путать отрицательный отклик с сообщением об ошибке. Сообщение об ошибке посылается при невозможности обработать входное сообщение. Сообщение Error не посылается, например, при непрохождении аутентификации. Причиной сигнала ошибки может быть искажение пакета при транспортировке по локальной сети или через Интернет, нелегальные значения полей сообщения или протокольные искажения. Для выявления сообщений-дубликатов достаточно использовать открытый текст, содержащийся в цифровом конверте сообщения. Реакция получателя на сообщение-дубликат зависит от свойств идемпотентности конкретного типа сообщения, от числа дубликатов, частоты их поступления и от того, кто является их отправителем. Поврежденным сообщением считается такое, которое не может быть обработано. В норме такие сообщения не должны приходить, так как имеется контроль корректности пакетов на транспортном уровне и при обнаружении любых повреждений сообщение должно быть переслано повторно. Но если такое “невозможное событие” все-таки произойдет, будет послано сообщение Error, содержащие код типа ошибки и идентификатор сообщения, ее вызвавшего. Приложение никогда не посылает сообщение Error в ответ на другое сообщение Error. Сообщения, которые не являются протокольными для SET, просто игнорируются. Если тэг типа сообщения равен 999 (указывая, что это сообщение об ошибке), приложение SET не должно ни при каких обстоятельствах посылать на него отклик. Когда приложение сталкивается с ошибкой, оно формирует Error-сообщение в следующей последовательности.
ШагДействие
1Сформировать ErrorTBC следующим образом:Установить ErrorCode равным значению, указывающему на причину (см. табл. 4.6.2.16)Сформировать новый ErrorNonceЕсли ошибка случилась из-за того, что приложение не знает, как обрабатывать расширение сертификата или сообщения, занести в ErrorOID объектный идентификатор расширения.Если ошибка произошла из-за проблем с сертификатом, занести в ErrorThamb ThumbPrint сертификатаЕсли ошибка является результатом неудачной верификации подписи, занести в ErrorThamb хэш сертификатаErrorMsg формируется следующим образом: заносится MessageHandler или все сообщение (но не более 20 килобайт). Выбор того, следует ли заносить все сообщение или только заголовок, оставляется на усмотрение разработчика.
2Подписать сообщение Error, если имеется сертификат подписи
3Вызвать формирование цифрового конверта и отправить сообщение



Для сообщения Error определены следующие поля
Имя поляОписание
Error<Signed Error, UnsignedError >
SignedErrorS(EE, ErrorTBS)
UnsignedErrorErrorTBSНеподписанная версия Error будет использоваться, если объект не имеет сертификата подписи
ErrorTBS{ ErrorCode, ErrorNonce, [ErrorOID], [ErrorThumb], ErrorMsg}
ErrorCodeЦифровой код, определяющий условия ошибки (см. табл. 4.6.2.16)
ErrorNonceРазовый код, который гарантирует, что подпись генерируется для трудно предсказуемых данных
ErrorOIDОбъектный идентификатор неподдерживаемых критических расширений, вызвавших ошибку
ErrorThumbОттиск сертификата, который вызвал ошибку или хэш сертификата, если произошла ошибка верификации подписи
ErrorMsg<MessageHeader, BadWrapper>
MessageHeaderЗаголовок сообщения, которое вызвало ошибку
BadWrapperЦифровой конверт сообщения, которое вызвало ошибку (не более 20 килобайт)
Таблица 4.6.2.16. ErrorCode
ОшибкаОписание
unspecifiedFailureПричина неудачи не фигурирует в списке стандартных ошибок
messageNotSupportedЭтот вполне корректный тип сообщения не поддерживается получателем
decodingFailureПроизошла ошибка в процессе DER-кодирования сообщения
invalideCertificateСертификат, необходимый для обработки сообщения, некорректен. Поле ErrorThumb идентифицирует этот сертификат.
expiredCertificateВремя действия сертификата, необходимого для обработки сообщения, иссякло. Поле ErrorThumb идентифицирует этот сертификат.
revokedCertificateСертификат, необходимый для обработки сообщения, отозван. Поле ErrorThumb идентифицирует этот сертификат.
missingCertificateСертификат, необходимый для обработки этого сообщения, отсутствует в кэше сертификатов получателя.
signatureFailureЦифровая подпись сообщения не может быть верифицирована
badMessageHeaderЗаголовок сообщения не может быть обработан
wrapperMsgMismatchСодержимое цифрового конверта сообщения не согласуется с внутренним содержимым сообщения.
versionTooOldНомер версии сообщения слишком стар для получателя
versionTooNewНомер версии сообщения слишком нов для получателя
unrecognizedExtensionСообщение или сертификат содержит критическое расширение, которое получатель не может обработать. Поле ErrorOID идентифицирует расширение. Если расширение присутствует в сертификате, поле ErrorThumb идентифицирует сертификат
messageTooBigСообщение слишком длинно для получателя
signatureRequiredНеподписанная версия сообщения неприемлема
messageTooOldДата сообщения слишком далеко в прошлом для получателя
messageTooNewДата сообщения слишком близка для получателя
thumbsMismatchОттиск, посланный в неподписанном запросе, не согласуется с тем, что прислано запрашивающей стороне
unknownXIDПолучен неизвестный RRPID
challengeMismatchВызов, посланный в запросе, не согласуется с вызовом в отклике



Так как сообщения Error могут посылаться, в том числе и в ответ на отклик, возникает проблема при работе с протоколами, базирующимися на алгоритмах запрос-отклик (например, HTTP). В этом случае сообщение об ошибке может посылаться в качестве запроса, на который необязательна посылка отклика. На нижележащем протокольном уровне при этом может происходить таймаут. Работа с сертификатами В работе с сертификатами участвуют девять субъектов. Иерархия этих субъектов представлена на рис. 4.6.2.10. Верхнюю позицию в иерархии занимает корневой центр сертификации. Корневой сертификат следует требованиям документа X.509 (версия 3) с некоторыми расширениями, вводимыми протоколом SET. Прежде чем система будет развернута, должны быть проделаны следующие операции: Нужно сформировать пару #1 корневых ключей R1Сгенерировать сертификат для корневого ключа #1 (C1)Сформировать пару #2 корневых ключей R2Вычислить оттиск (хэш - H2) общедоступной составляющей R2 С1 рассылается при развертывании системы и является самоподписываемым. Корневой сертификат SET доставляется приложению с помощью протокола запроса сертификата и платежного протокола. Начальное значение корневого сертификата, его общедоступный ключ или хэш общедоступного ключа могут быть доставлены и программой приложения SET. Как только приложением получен новый корневой сертификат, оно проверяет через расширение HashedRootKey связь с предыдущим корневым сертификатом. Когда приходит время заменить корневой сертификат R1, производятся следующие операции: Вычисляется общедоступная часть корневого ключа #3 (R3)Определяется оттиск R3 (хэш H3)Формируется сертификат корневого ключа #2 (C2 - содержит H3) Новый корневой сертификат рассылается с использованием SET-сообщений или методик HTTP, FTP или SMTP. Приложение SET проверяет подпись, используя R2, вычисляет хэш R2 и сравнивает его с H2, полученным из расширения в С1.
Рис. 4.6.2.10. Иерархия субъектов сертификации Из списка этих субъектов один является опционным, это GCA (Геополитический центр сертификации - Geo-Political Certificate Authority).


Проверка сертификатов производится строго в соответствии с данной иерархической схемой. Доступ к корневому центру сертификации производится крайне редко, только в случае получения нового сертификата платежной системы или при обновлении корневого сертификата. При взаимодействии с ним привлекается в максимально возможной мере аппаратный контроль. Если произойдет раскрытие секретного ключа платежной системы, то RCA сформирует и разошлет новый список отмененных сертификатов CRL (Certificate Revocation List). BCA являются независимыми для каждой платежной системы и реализуются практически теми же мерами безопасности, как и RCA. Эти центры служат для формирования и рассылки геополитических и/или сертификатов владельцев карты, продавцов или платежных центров, размещенных ниже по иерархии. Они также ответственны за обновление и рассылку списков CRL и BCI, содержащие все CRL платежной системы. Геополитические центры сертификации (являются опционными) позволяют платежным системам перераспределять ответственность между отдельными географическими и политическими регионами. Эти центры ответственны за формирование и рассылку соответствующих региональных CRL. Центры сертификации владельцев карт (ССА) формируют по запросу и отсылают сертификаты владельцам платежных карт. Запрос сертификата может быть послан через WEB или по электронной почте. ССА поддерживают взаимоотношения с эмитентами карт для сертификации счетов владельцев карт. ССА также занимаются рассылкой CRL, сформированных RCA, BCA, GCA и центров сертификации платежных центров. Функции CCA может выполнять центр платежной системы, эмитента карты или какой-то иной субъект, который отвечает требованиям конкретной платежной системы. Центр МСА ответственен за рассылку сертификатов продавцам. Получатели (Acquirers) проверяют и одобряют запросы сертификатов продавца до их выдачи центром MCA. Центр PCA служит для выдачи сертификатов для платежных центров. Их функции, также как и в случае CCA, могут выполняться центрами платежной системы, получателя и т.д. Любой центр сертификации выполняет следующие функции: Формирование и выдача сертификатаОбновление сертификатовКонтроль работоспособности сертификатов и удаление непригодных Формирование сертификатов осуществляется различными методами, зависящими от типа объекта.


Для владельцев карты формируются только сертификаты подписи, для продавцов и платежных центров формируются сертификаты подписи и шифрования. Сертификаты для владельцев карт формируются центрами CCA. Выпуск сертификата держателя карты включает в себя следующие обмены между держателем карты и CCA (см. также рис. 4.6.2.2). Владелец карты посылает запрос сертификатаССА производит шифрование сертификата для защиты передачи номера платежной карты в ССАВладелец шифрует номер своей карты, используя сертификат ССА, и посылает результат в ССАССА откликается посылкой формы для регистрации сертификата картыВладелец карты заполняет форму, которая включает в себя его общедоступный ключ, и посылает форму в ССА для регистрацииССА верифицирует полученную регистрационную информацию с привлечением эмитента карты и генерирует сертификат, подписывает его и посылает владельцу карты. Для продавцов сертификаты формируются в центрах MCA. Перед выпуском сертификата продавца запрос верифицируется банком продавца (получатель - acquirer) или центром управления платежной системы. Сертификат получается продавцом в результате последовательности следующих операций. Продавец посылает запрос сертификата в МСА.МСА откликается посылкой регистрационной формы.Продавец заполняет форму и посылает ее и свой общедоступный ключ в МСА для обработки.Банк продавца или центр управления платежной системы проверяет запрос продавца и МСА генерирует, подписывает и посылает сертификат продавцу. Сертификаты платежного центра формируются и присылаются центром PCA. Процедура генерации сертификата сходна с вариантом продавца. Банк продавца верифицирует запрос сертификата платежного центра и авторизует генерацию сертификата в РСА. Сертификаты центров сертификации формируются вышестоящими по иерархии узлами. Обновление любых сертификатов производится периодически и следует тем же алгоритмам, что и формирование совершенно нового сертификата. Регистрационная форма при обновлении сертификата может содержать существенно меньше информации. Аннулирование сертификата может производиться по разным причинам, например, из-за реального или кажущегося раскрытия секретного ключа, из-за изменения регистрационной информации или по причине истечения срока пригодности.


При аннулировании идентификатор и некоторые другие характеристики сертификата заносятся немедленно в список CRL. Последний сразу подлежит рассылке всем субъектам, которые могут использовать этот сертификат. При выполнении любой операции в рамках протокола SET производится проверка всех сертификатов, образующих иерархическую цепочку (см. рис. 4.6.2.11), начиная от конечного объекта (ЕЕ) до корневого (Root). Стрелки означают, чей сертификат использовался для подписи. Таким образом, каждый сертификат связан с сертификатом подписи субъекта его сформировавшего.
Рис. 4.6.2.11. Иерархия проверок Основной протокол Далее рассматривается протокол и обработка откликов владельца карты, продавца или платежного центра (конечный объект - EE), а также получение подписей и/или сертификатов Х.509 шифрования данных от СА (Certificate Authority). Протокол определяет процедуры получения первого сертификата или обновления предшествующего. Прежде чем запросить сертификат владелец карты должен выполнить следующее: Получить счет в одной из платежных систем, например, в VISA или MasterCard.Иметь возможность формировать общедоступный и секретные ключи. Обеспечить безопасное хранение секретного ключа. Понятно, что местом его хранения не может быть оперативная память, да и дисковые накопители вряд ли можно считать приемлемым местом записи, если хотя бы теоретически к ним может быть получен доступ.Программа владельца карты должна иметь определенную информацию, которая может быть использована для идентификации и аутентификации владельца карты. Это должно быть сделано в соответствии с требованиями эмитента карты.Иметь URL или электронный почтовый адрес для связи с ССА.Обзавестись прикладной программой (например, броузером), поддерживающей протокол SET. Продавец должен иметь следующее, прежде чем посылать запрос сертификата: Идентификатор, присланный получателем (Acquirer - банк продавца)Иметь возможность формировать общедоступный и секретные ключи. Обеспечить безопасное хранение секретного ключа.Программа продавца должна иметь определенную информацию, объем и характер которой согласуется с банком продавца.URL или электронный почтовый адрес для связи с MCA.Обзавестись прикладной программой (например, броузером), поддерживающей протокол SET. Расчетный центр должен обзавестись следующим, прежде чем посылать запрос сертификата: Возможностью формировать пары ключей (секретый/общедоступный) и местом их надежного храниения.Получить банковский идентификационный номер BIN (Bank ID)Программа владельца карты должна иметь определенную информацию, которая может быть использована для идентификации и аутентификации платежного центра.


Объем и характер этой информации согласуется с банком продавца.Иметь URL или электронный почтовый адрес для связи с PCAОбзавестись прикладной программой (например, броузером), поддерживающей протокол SET. После того как приложение запущено, стартуют сертификационные обмены между владельцем карты и CCA, между продавцом и MCA, а также между платежным центром и PCA. В результате участники получают необходимые сертификаты подписи и шифрования. Так взаимодействие владельца карты и ССА предполагает следующие обмены: Приложение владельца карты посылает CardCInitReq CCA. При этом используется идентификатор платежной системы или идентификатор, полученный из стартового сообщения.ССА посылает приложению SET сообщение CardCInitRes.Приложение владельца карты посылает ССА сообщение RegFormReq.ССА отправляет сообщение RegFormRes, содержащее регистрационную форму и формулировку общих требований.Приложение владельца карты заполняет регистрационную форму, заносит свой общедоступный ключ и сертификат, подлежащий обновлению (если имеется) в CertReq и посылает его ССА.ССА формирует сертификат, включает его в CertRes и посылает владельцу карты. Функционирование приложения продавца и платежного центра имеет свою специфику: Приложение SET посылает сертификационному центру СА сообщение Me-AqCInitReq, при этом используется BIN и идентификатор продавца, полученные от системного администратора продавца или платежного центра.СА посылает приложению SET сообщение Me-AqCInitRes, содержащее регистрационную форму и формулировку общих требований.Приложение SET отображает эту форму и требования. Пользователь должен заполнить регистрационную форму и согласиться с предлагаемыми требованиями.Приложение SET включает в CertReq заполненную форму, новый общедоступный ключ и сертификат, подлежащий обновлению (если он имеется) и посылает это все СА.СА формирует сертификат, включает его в CertRes и посылает продавцу или платежному центру. Схемы таких обменов для получения нового или обновления старого сертификатов представлены на рис. 4.6.2.12 и 4.6.2.13.


Логика обменов для получения сертификата владельцем карты при начальной регистрации была показана на рис 4.6.2.12.
Рис. 4.6.2.12. Схема обмена сообщениями при получении сертификата между владельцем карты и ССА Если ЕЕ уже имеет регистрационную информацию, обмены CardCInitReq/Res и RegFormReq/Res могут быть опущены. При работе через WWW используется во всех случаях полный перечень обменов. После того как приложение SET инициализировано, владелец карты посылает ССА сообщение CardCInitReq, указывающее через оттиски на сертификаты, CRL и BrandCRLIdentifier, которые содержаться в его кэше сертификатов. ССА реагирует посылкой сообщения CardCInitRes, содержащего любые сертификаты, CRL и BrandCRLIdentifier, которые потребуются владельцу карты для верификации подписи, а также сертификат шифрования, используемый для последующих сообщений. Приложение SET формирует сообщение CardCInitReq следующим образом.
ШагДействие
1Генерируется RRPID
2Генерируется LID-EE
3Формируется новый случайный Chall-EE
4Копируется BrandID, который запомнен или получен в инициализирующем сообщении
5Опционно заполняется поле Thumbs, которое содержит оттиски для каждого CRL, сертификатов SET, BrandCRLIdentifier и корневой сертификат, резидентный в кэше владельца карты
6Формируется цифровой конверт сообщения, чтобы послать CardCInitReq центру ССА
Структура сообщения CardCInitReq охарактеризована в таблице 4.6.2.17. Таблица 4.6.2.17. Структура сообщения CardCInitReq
CardCInitReq{RRPID, LID-EE, Chall-EE, BrandID, [Thumbs]}
RRPIDИдентификатор пары запрос/отклик
LID-EEЛокальный ID, сформированный для системы владельца карты
Chall-EEВызов владельца карты по поводу пригодности подписи, адресованный ССА
BrandIDИдентификатор платежной системы для запрошенного сертификата
ThumbsСписок оттисков сертификатов (включая корневой), CRL и BrandCRLIdentifier, которые хранятся в данный момент владельцем карты
ССА, получив CardCInitReq, выполнит следующие операции:
ШагДействие
1Получить CardCInitReq из сообщения Receive
2Проверить, что RRPID в CardCInitReq соответствует RRPID в цифровом конверте сообщения. Если проверка не прошла, присылается сообщение об ошибке с кодом ErrorCode= unknownRRPID
3Запомнить список откликов, LID-EE, Chall-EE и RRPID, которые должны быть использованы в CardCInitRes



После того как ССА обработает CardCInitReq, он выполнит следующие шаги, для того чтобы сформировать CardCInitRes. Как и в случае SignedData, сертификаты и CRL, нужные для верификации подписи, включаются в CardCInitRes вне данных, которые должны быть подписаны. Последовательность действий представлена ниже в таблице.
ШагДействие
1Сформировать структуру данных CardCInitResTBS, для этого:Скопировать RRPID, LID-EE и Chall-EE, полученные из сообщения CardCInitReqСформировать опционно LID-CAЗаполнить CAEThumb оттиском сертификата шифрования данных CCAЕсли BrandCRLIdentifier не специфицирован в списке оттисков, полученном в CardCInitReq, занести BrandCRLIdentifierСкопировать список оттисков из CardCInitReq
2Подписать DER-кодированный массив кодов CardCInitResTBS, установить тип содержимого SigneadData равным id-set-content- CardCInitResTBS.Включить в SigneadData любые сертификаты, CRL или BrandCRLIdentifier, которые отсутствуют в списке оттисков.
3Сформировать цифровой конверт сообщения и послать сообщение CardCInitRes владельцу карты
Формат отклика CardCInitRes представлен в таблице ниже.
CardCInitResS(CA, CardCInitResTBS)
CardCInitResTBS{RRPID, LID-EE, Chall -EE, [LID-CA], CAEThumb, [BrandCRLIdentifier], [Thumbs]}
RRPIDИдентификатор пары запрос/отклик
LID-EEКопируется из CardCInitReq
Chall-EEКопируется из CardCInitReq
LID-CAЛокальный ID. Генерируется системойCCA или для нее
CAEThumbОттиск сертификата ключевого обмена CCA, котоый владелец карты должен использовать для шифрованияRegFormReq
BrandCRLIdentifierСмотри секцию описания BrandCRLIdentifier
ThumbsКопируется из CardCInitR
Приложение владельца карты обрабатывает сообщение CardCInitRes в следующей последовательности:
ШагДействие
1Получить CardCInitRes из входного сообщения (Receive)
2Проверить, что RRPID соответствует тому, что был послан в CardCInitReq и тому, который получен в цифровом конверте сообщения CardCInitRes. Если соответствия нет, посылается сообщение об ошибке с кодом ErrorCode равным unknownRRPID
3Проверить, что полученный список оттисков соответствует тому, что был послан в сообщении CardCInitReq. Если соответствия нет, посылается сообщение об ошибке с кодом ErrorCode равным thumbsMismatch
4Проверить, что полученный Chall-EE равен посланному в CardCInitReq. Если равенство отсутствует, посылается сообщение об ошибке с кодом ErrorCode равным challengeMismatch.
5Запомнить LID-CA (если этот элемент был включен) для последующей записи в RegFormReq. Проверить, что полученный Chall-EE равен посланному в CardCInitReq.
6Проверить, что приложение владельца карты поддерживает один из алгоритмов, перечисленных в туннельном расширении сертификата шифрования CA. Если приложение владельца карты не поддерживает ни одного общего с СА алгоритма, следует уведомить об этом пользователя и прервать дальнейшую обработку сообщения СА.



Если приложение владельца карты успешно обработало отклик CardCInitRes, оно может сформировать и послать сообщение RegFormReq. Это сообщение шифруется приложением владельца карты с использованием сертификата, полученного от ССА в CardCInitRes. Последовательность формирования и посылки RegFormReq представлена ниже в таблице.
ШагДействие
1Сформировать RegFormReqData согласно следующему формату:Сформировать новый RRPIDСкопировать LID-EE, посланный в CardCInitReqСформировать новый Chall-EE2Если такой элемент был включен в CardCInitRes, скопировать LID-CAЗаполнить RequestType согласно таблице 4.6.2.19, где представлены коды поля RequestType регистрационной формы владельца картыЗаполнить поле языка (Language)Опционно ввести список оттисков для каждого CRL, сертификата SET, BrandCRLIdentifier и корневого сертификата, резидентных для кэша оттисков владельца карты (если таковой имеется).
2Сформировать структуру RegFormReqTBE:Ввести ReqFormReqDataЗаполнить поле PANOnly, используя PAN и ExNonce. В PAN не используется заполнитель.Сформировать хэш SHA-1 для DER-кодированного PANOnly. Установить код типа содержимого digestedData равным id-set-content-PANOnly
3Оформить поле данных, подлежащих дополнительному шифрованию:Заполнить PAN. Если PAN имеет длину менее 19 байт, дополнить его до 19 байтДля маскирования PAN сгенерировать новый EXNonce
4Зашифровать данные, используя оператор EXH со следующими параметрами:RegFormReqTBE в качестве данных, подлежащих шифрованию, и типом contentType данных Envelopeddata равным id-set-content-RegFormReqTBE иРезультатом шага 3 в качестве данных, подлежащих шифрованиюДля шифрования используется сертификат идентифицированный CAEThumb в CardCInitRes
5Вложить результат в цифровой конверт комбинированного сообщения и послать RegFormReq в центр СА
Структура сообщения RegFormReq представлена в таблице 4.6.2.18. Таблица 4.6.2.18. Структура RegFormReq
RegFormReqEXH(CA, RegFormReqData, PANOnly)
RegFormReqData{RRPID, LID-EE, Chall-EE2,[LID-CA], RequestType, Language, [Thumbs]}
PANOnlyСтруктуру смотри в табл. ниже
RRPIDID пары запрос/отклик
LID-EEКопируется из CardCInitRes
Chall-EE2Вызов ЕЕ, имеющий целью обновление подписи СА
LID-CAКопируется из CardCInitRes
RequestTypeСмотри табл. 4.6.2.19
LanguageПредпочтительный язык последующего текста
ThumbsСписки сертификатов (включая корневой), CRL и BrandCRLIdentifier, хранимых в данный момент владельцем карты



Поля данных PANOnly
Имя поляОписание
PANНомер платежной карты владельца
EXNonce Случайное число, используемое для маскирования PAN
Таблица 4.6.2.19. Значения кодов RequestType
Тип запросаТолько сертификат подписиТолько сертификат шифрованияОба сертификата
Начальный запрос владельца карты12*3*
Запрос обновления владельца карты1011*12*
* указывает на значения, зарезервированные для будущего использования Когда центр ССА получает ReqFormReq, он выполняет следующие шаги для проверки корректности сообщения.
ШагДействие
1Извлечь RegFormReq из входного сообщения
2Заполнить PAN из данных, которые подлежат шифрованию. Это делается после удаления заполнителя.
3Из данных RegFormReqData запомнить RequestType, RRPID, LID-EE, Chall-EE2, LID-CA, список оттисков (Thumbs) и код языка.
4Проверить, что RRPID, полученный из цифрового конверта сообщения соответствует одному коду из RegFormReqTBE. Если соответствия нет, возвращается сообщение об ошибке с ErrorCode равным unknownRRPID
После верификации RegFormReq CCA генерирует RegFormRes следующим образом. Если верификация запроса прошла успешно, присылается регистрационная форма, уведомление о политике, URL платежной системы и логотип карты. В случае неудачи сообщается причина и опционно URL и адрес e-mail, откуда может быть получена более детальная информация. Процедура формирования RegFormRes описана ниже.
ШагДействие
1Сформировать RegFormTBS в соответствии со следующей процедурой:Скопировать RRPID, RequestType, LID-EE, список оттисков и Chall-EE2 из RegFormReqDataЕсли в CardCInitRes имеется LID-CA, скопировать его, в противном случае сформировать LID-CA для данного запроса.Сгенерировать новый Chall-CAЕсли BrandCRLIdentifier не специфицирован в списке оттисков, полученном в CardCInitReq, заполнить поле randCRLIdentifier.Если регистрационная форма владельца карты доступна для PAN, Language, RequestType, сформировать RegFormData в виде:Заполнить шаблон RegTemplate и PolicyText, соответствующие RequestType, PAN и LanguageВключить RegFormID и RegFieldSeq. В случае обновления поле RegFieldSeq может быть опущено.Опционно добавляется URL для отображения логотипа платежной системы или карты.CertReq должно быть зашифровано с помощью ключа, отличного от того, который использовался в случае RegFormReq. Внести CAEThumb с оттиском, отличным от посланного в CardCInitRes.Если подходящей регистрационной формы для владельца карты нет, сформировать структуру ReferralData:Заполнить поле причины информацией об отказе обслуживания, которая будет отображена владельцу карты.Опционно записать в поле ReferralLoc почтовый адрес и/или URL, где пользователь может получить дополнительную информацию о причине отказа обслуживания.
2Подписать результат шага 1 (то есть данные RegFormTBS), установить contentType для SignedData равным id-set-content-RegFormTBS.
3Сформировать цифровой конверт сообщения и послать владельцу карты RegFormRes



Структура сообщения RegFormRes представлена в таблице 4.6.2.20. Таблица 4.6.2.20. Структура RegFormRes
RegFormResS(CA, RegFormResTBS)
RegFormResTBS{RRPID, LID-EE, Chall-EE2,[LID-CA], Chall-CA, [CAEThumb], RequestType, RegFormOrReferral, [BrandCRLIdentifier], [Thumbs]}
RRPIDID пары запрос/отклик
LID-EEКопируется из RegFormReq
Chall-EE2Копируется из RegFormReq
LID-CA Локальный ID. Формируется для системы СА.
Chall-CAСА обращение по поводу пригодности сертификата запрашивающей стороны
CAEThumbОттиск сертификата ключевого обмена, который должен использоваться для шифрования CertReq. Если это поле отсутствует, используется сертификат, идентифицированный в CardCIntRes.
RequestTypeСмотри табл. 4.6.2.19
RegFormOrReferralСмотри табл. 4.6.2.21
BrandCRLIdentifierСмотри описание в разделе о BrandCRLIdentifier ниже.
ThumbsКопируется из RegFormReq
Таблица 4.6.2.21. Структура поля RegFormOrReferral
RegFormOrReferral<RegFormData, ReferralData>
RegFormData{[RegTemplate], PolicyText}
ReferralData{RegFormID, [BrandLogoURL], [CardLogoURL], RegFieldSeq}
RegTemplate{RegFormID, [BrandLogoURL], [CardLogoURL], RegFieldSeq}
PolicyTextЗаявление, которое должно быть отображено в системе отправителя запроса вместе с RegTemplate
ReasonЗаявление, связанное с запросом и отображаемое в системе отправителя запроса
ReferralURLSeq{ReferralURL +}Опционные URL ссылок, перечисленные в порядке важности
RegFormIDИдентификатор, присвоенный СА
BrandLogoURLURL базовой страницы расчетной системы
CardLogoURLURL базовой страницы финансовой организации
RegFieldSeq{RegField +}
ReferralURLURL альтернативного СА для обработки запросов сертификатов для данного объекта
RegField{[FieldId], FieldName, [FieldDesc], [FieldLen], FieldRequired, FieldInvisible}
FieldIDИдентификаторы объекта для полей регистрационной формы
FieldNameОдно или более имен полей, которые должны быть отображены в качестве меток для заполнения формы; текст записывается на языке, определенном в RegFormReq или Me-AqCInitReq
FieldDescОписание содержимого поля на языке, заданном в RegFormReq или Me-AqCInitReq; содержит дополнительную информацию для использования в случае, когда владелец карты запросит помощи при заполнении формы
FieldLenМаксимальная длина поля
FieldRequiredБулево значение, указывающее на необходимость ввода (должен ли поле заполнить владелец карты или оно будет заполнено приложением) (невидимое поле)
FieldInvisibleБулево значение, указывающее на то, что поле не должно отображаться пользователю; приложение должно заполнить FieldValue, основываясь на FieldID, или оставить его пустым
Приложение владельца карты обрабатывает сообщение RegFormRes следующим образом:
ШагДействие
1Получить RegFormRes из входного сообщения
2Проверить подпись. Если подпись некорректна, отправить сообщение об ошибке с ErrorCode равным signatureFailure.
3Получить RRPID, RequestType, LID-EE, Chall-EE2, CAEThumb из RegFormTBS
4Проверить, что RRPID является тем же самым, что и идентификатор, записанный в цифровом конверте сообщения, и совпадет с кодом, присланным в RegFormReq. Если совпадения нет, отправить сообщение об ошибке с ErrorCode равным unknownRRPID.
5Проверить, что RequestType, LID-EE и Chall-EE2 идентичны присланным в RegFormReq. Если совпадения нет, отправить сообщение об ошибке с ErrorCode равным challengeMismatch.
6Если был включен CAEThumb, запомнить соответствующий сертификат шифрования, использованный для шифрования CertReq.
7Проверить, что полученные оттиски, соответствуют посланным в сообщении CardCInitReq. Если соответствия нет, отправить сообщение об ошибке с ErrorCode равным thumbsMismatch.
8Если в RegFormTBS включены данные RegFormData то:Запоминается LID-CAПрежде чем приложение SET сформирует CertReq, отображается текст общих требований и необходимый отклик пользователяОтображаются видимые поля регистрационной формы и приглашение для заполнения их пользователем.Если RegFormRes содержит URL, отображаются логотипы платежной системы или эмитента карты.Заполняются видимые поля регистрационной формы. Если поле является необходимым, а приложение не может его заполнить, оно остается пустым, а остальная часть формы заполняется и посылается обычным порядком.После того как пользователь завершил ввод, формируется сообщение CertReq.
9Если в RegFormResTBS включено поле ReferralData то:Отображается причина (Reason)Если включено ReferralLoc, отображаются URL или электронный адрес из ReferralLocCertReq не формируется. Протокол переходит к формированию CardCInitReq



Пары сообщений Me-AqCInitReq/ Res используются продавцом или расчетным центром для получения регистрационной формы сертификата. Продавец или расчетный центр запускают сертификатный протокол путем посылки запроса Me-AqCInitReq. Это сообщение содержит банковскую информацию продавца или расчетного центра, тип запрашиваемого сертификата, а также сертификаты, CRL и BrandCRLIdentifier, которые хранятся в надежном сертификатном кэше. Если MCА или РСА имеют регистрационные формы на подходящем языке для указанного банка, она присылается в сообщении Me-AqCInitRes вместе с любыми сертификатами, CRL и BrandCRLIdentifier, которые могут потребоваться продавцу или расчетному центру для проверки цифровой подписи. Если MCА или РСА не имеют подходящей регистрационной формы и/или имеют дополнительную информацию относительно отклонения поступившего запроса, эти данные также заносятся в Me-AqCInitRes. Схема работы протокола сертификатов для данного случая показана на рис. 4.6.2.13.
Рис. 4.6.2.13. Схема обмена сообщениями при получении сертификата между продавцом и MCA или между платежным центром и PCA При получении Me-AqCInitRes программа конечного пользователя (ЕЕ) может послать сообщение CertReq, содержащее заполненную форму. Процедура формирования Me-AqCInitReq включает в себя следующие операции:
ШагДействие
1Сформировать новый RRPID
2Сформировать новый LID-EE
3Сформировать новый случайный код Chall-EE
4Занести BrandID, который хранится в приложении или получен в стартовом сообщении
5Заполнить поле RequestType
6Заполнить поле Language (язык)
7Опционно создать оттиски для каждого CRL, сертификата, BrandCRLIdentifier и корневого сертификата, резидентно размещенных в кэше (если имеются)
8Если ЕЕ (конечным пользователем) является продавец, заполнить поля BIN и ID продавца. В противном случае BIN получателя и его рабочий ID.
9Сформировать цифровой конверт и послать сообщение Me-AqCInitReq СА.
Формат сообщения Me-AqCInitReq представлен в таблице 4.6.2.22. Таблица 4.6.2.22. Формат Me-AqCInitReq
Me-AqCInitReq{RRPID, LID-EE, Chall-EE, RequestType, IDData, BrandID, Language, [Thumbs]}
RRPIDID пары запрос/отклик
LID-EEЛокальный ID; формируется ЕЕ-системой или для нее
Chall-EEОбращение EE к СА по поводу пригодности подписи
RequestTypeСмотри табл. 4.6.2.24
IDDataСм. табл. 4.6.2.23
BrandIDBrandID запрошенного сертификата
LangauageЖелательный язык последующих текстов
ThumbsСписок оттисков сертификатов, CRL и BrandCRLIdentifier, хранимых ЕЕ



Формат поля IDData описан в таблице 4.6.2.23. Таблица 4.6.2.23. Формат IDData
IDData<MerchantAcquirerID, AcquirerID> (только для продавца и получателя)
MerchantAcquirerID{MerchantBIN, MerchantBIN}
AcquirerID{AcquirerBIN, [AcquirerBusinessID]}
MerchantBIN Идентификационный номер банка для обработки транзакции продавца в его банке (Acquirer)
MerchantIDИдентификатор продавца, присвоенный ему его банком (Acquirer)
AcquirerBINИдентификационный номер банка для Acquirer (BIN получателя)
AcquirerBusinessIDРабочий идентификационный номер банка продавца
Таблица 4.6.2.24. Значения RequestType для продавца и платежного центра
Тип запросаТолько сертификат подписиТолько сертификат шифрованияОба
сертификата
Начальный для продавца456
Начальный для расчетного центра789
Обновление для продавца131415
Обновление для расчетного центра161718
Получив Me-AqCInitReq, СА производит его обработку следующим образом:
ШагДействие
1Выделяеть Me-AqCInitReq из входного сообщения
2Проверяеть, что RRPID из цифрового конверта сообщения совпадает с полученным в Me-AqCInitReq. Если это не так, формируется сообщение об ошибке с errorCode unknownRRPID.
3Запоминается RRPID, LID-EE, Chall-EE, BrandID, Language, Thumbs и IDData
Проверив корректность Me-AqCInitReq, CA формирует Me-AqCInitRes. Эта операция включает в себя следующие шаги:
ШагДействие
1Сформировать сообщение Me-AqCInitResTBS:Скопировать RRPID, LID-EE и Chall-EE из Me-AqCInitReqОпционно сгенерировать LID-CA для данного вида запроса обслуживанияСгенерировать новый Chall-CAЕсли регистрационная форма продавца или платежного центра доступна для BIN, языка и RequestType, то:Заполнить поле RegFormData, используя RegTemplate и PolicyText, соответствующие Requesttype, BIN и LanguageОпционно включить URL для отображения логотипа платежной системы и/или картыВключить RegFormID и RegFieldSeq. При обновлении RegFieldSeq может быть опущено.Если СА посредством AcctData аутентифицирует продавца или расчетный центр, заполнить поле AcctDataField, указывая наименование данных, подлежащих вводу, описание, их длину и будут ли данные вводиться ЕЕ (конечным пользователем).Если соответствующая форма для продавца или расчетного центра не доступна, заполняется поле ReferralData:Включить причину отказа обслуживания, которая будет отображена для продавца или расчетного центраОпционно включить в ReferralLoc электронный адрес и/или URL, где пользователь может получить дополнительную информацию, об отказе обслуживания.Включить оттиск сертификата шифрования CA, CAEThumb.Если BrandCRLIdentifier в полученном Me-AqCInitReq не специфицирован, ввести BrandCRLIdentifier.Скопировать список оттисков (Thumbs) из Me-AqCInitReqСкопировать RequestType, полученный в Me-AqCInitReq.
2Подписать Me-AqCInitResTBS, установить тип содержимого SignedData равным id-set-content-Me-AqCInitResTBS.
3Сформировать цифровой конверт и послать сообщение Me-AqCInitRes продавцу или расчетному центру.
MCA и PCA используют один и тот же шаблон регистрационной формы, идентичный ССА (см.


табл. 4.6.2.25) Таблица 4.6.2.25. Шаблон регистрационной формы MCA и PCA
Me-AqCInitResS(CA, Me-AqCInitResTBS)
Me-AqCInitResTBS{RRPID, LID-EE, Chall-EE, [LID-CA], Chall-CA, RequestType, RegFormOrReferral, [AcctDataField], [Thumbs]}
RRPIDID пары запрос/отклик
LID-EEКопируется из Me-AqCInitReq
Chall-EEКопируется из Me-AqCInitReq
LID-CA Локальный ID; генерируется СА системой или для нее
Chall-CAСА обращение по поводу пригодности сертификата запрашивающей стороны
RequestTypeСмотри табл. 4.6.2.24
RegFormOrReferralСмотри табл. 4.6.2.21
AcctDataFieldRegField; дополнительное поле регистрационной формы, которое следует отобразить, для того чтобы получить значение AcctData в CertReq
CAEThumbОттиск сертификата ключевого обмена СА, который должен использоваться для шифрования CertReq
BrandCRLIdentifierСмотри раздел описания BrandCRLIdentifier ниже.
ThumbsКопируется из Me-AqCInitReq
Приложение SET (продавца или расчетного центра) обрабатывает Me-AqCInitRes следующим образом:
ШагДействие
1Получить Me-AqCInitRes из входного сообщения.
2Верифицировать подпись. Если она некорректна, послать сообщение об ошибке с ErrorCode равным signatureFailure.
3Из Me-AqCInitResTBS извлекаются и запоминаются RRPID, LID-EE, Chall-EE, CAEThumb, BrandCRLIdentifier, оттиски и TequestType
4Проверяется, что RRPID совпадает со значением, извлеченным из цифрового конверта сообщения и кодом, посланным в Me-AqCInitReq. Если равенства нет, посылается сообщение об ошибке с ErrorCode равным unknownRRPID.
5Проверяется, что полученный Chall-EE соответствует посланному в Me-AqCInitReq. Если соответствие отсутствует, посылается сообщение об ошибке с ErrorCode равным challengeMisMatch.
6Проверяется, что полученный список оттисков соответствует посланному в сообщении Me-AqCInitReq. Если соответствие отсутствует, посылается сообщение об ошибке с ErrorCode равным thumbsMisMatch.
7Если в Me-AqCInitResTBS включено поле RegFormData то:Запомнить LID-CA и Chall-CAОтобразить текст общих требований и ввод пользователя, прежде чем приложение SET сформирует CertReqОтобразить видимые поля регистрационной формы и приглашение пользователю для заполнения этих полейЕсли Me-AqCInitResTBS содержит URL, отобразить логотипы расчетной системы и/или картыЕсли присутствует поле AcctDataField, отобразить имя и описание, а также приглашение пользователю для заполнения этого поляЗаполнить невидимые поля регистрационной формы. Если приложение не может заполнить поле, оно будет оставлено пустым, остальные поля будут заполнены обычным порядком и пересланы в CertReq.
8После того как продавец или расчетный центр заполнили регистрационную форму и ввели AcctData, (если это требуется) генерируется CertReq.
9Если в Me-AqCInitResTBS включено поле ReferrelData, то:Отображается причинаЕсли включено поле ReferralLoc, отображается URL или электронный адрес из ReferralLocCertReq не генерируется. Протокол продолжит работу с посылки Me-AqCInitReq



Владелец карты, системный администратор продавца или расчетного центра вводит информацию, необходимую для RegForm, а приложение SET (EE) посылает сообщение CertReq центру СА. После успешной верификации CertReq формируются сертификаты, которые посылаются ЕЕ в сообщениях CertRes. Если в регистрационной форме обнаружены ошибки, СА оповещает об этом в CertRes. Приложение SET может повторно представить исправленную регистрационную форму в новом CertReq. Владелец карты вводит ее номер, дату пригодности и другие данные, запрошенные ССА в регистрационной форме. Системный администратор продавца вводит аутентификационные данные расчетного центра и другую информацию, запрошенную МСА в регистрационной форме. Системный администратор расчетного центра вводит аутентификационные данные продавца (если таковые имеются) и другую информацию, запрошенную РСА в регистрационной форме. Запрос сертификата (CertReq) содержит в себе: Новые общедоступные ключи.Обновляемые сертификаты (если таковые есть).Заполненную регистрационную форму.Информацию об аккоунте ЕЕСекретные ключи, которые должен использовать СА для шифрования отклика CertRes,Другие контрольные коды Поле данных сообщения и опционно хэш аккоунт-данных ЕЕ подписываются секретным ключом, соответствующим сертификату подписи, подлежащему обновлению (если таковой имеется) и новым секретным ключом. Симметричный ключ, используемый для этого шифрования, берется из OAEP (Bellare-Rogaway Optimal Asymmetric Encryption Padding). Все перечисленные данные шифруются с использованием общедоступного ключа. Если СА обнаружит ошибку в представленной регистрационной форме, информация о ней будет передана в сообщении CertRes и будет послан новый запрос CertReq. ЕЕ-приложение генерирует CertReq следующим образом. Это делается с использованием EncX или Enc техники в зависимости от присутствия AcctInfo. Если ЕЕ является владельцем карты, AcctInfo всегда содержит аутентификационные данные, которые могут быть, а могут и не быть затребованы СА. Me-AqCInitRes указывает, нужно ли AcctInfo в AcctInfoField.


EncX используется лишь при наличии AcctInfo. Если ЕЕ является владельцем карты, продавцом или расчетным центром и намерен послать AcctInfo, то CertReq формируется с привлечением методики EncX следующим образом.
ШагДействие
1Если RequestType соответствует новому сертификату подписи или его обновлению, формируется пара ключей (общедоступный/секретный), необходимых для подписи сертификата
2Если запрашивающим субъектом не является владелец карты и, если RequestType соответствует новому сертификату шифрования, формируется пара ключей (общедоступный/секретный), необходимых для сертификата шифрования.
3Если ЕЕ является владельцем карты, генерируется 160-битовый случайный код - CardSecret.
4Генерируется 160-битовый случайный код - EXNonce
5Формируется CertReqTBS:Генерируется RRPIDЕсли ЕЕ получил RegFormRes или Me-AqCInitRes, копируется RequestType из этого сообщения, в противном случае вводится требуемый RequestType.Заполняется поле RequestDataКопируется LID-EE (если присутствует) и Chall-CA из предыдущего сообщения. Если его нет, генерируется новый.Генерируется новый Chall-EE3Копируется LID-CA, (если присутствует) и Chall-CA из предыдущего сообщения.Если ЕЕ является продавец карты или расчетный центр, то:заполняется поле IDData и,если в Me-AqCInitRes включено поле AcctDataField, записывается AccData, введенная ЕЕЕсли ЕЕ является продавец, занести PAN, CardExpiry и CardSecret.Сформировать EXNonceСкопировать RegForm ID, который был послан в RegFormRes или Me-AqCInitResЕсли RegFieldSeq присутствовал в Me-AqCInitRes или RegFormRes, включить новую или исправленную форму.
6Если приложение владельца карты выберет алгоритм шифрования CertRes, производится заполнение ID алгоритма и ключа в CaBackKeyData. Если общего алгоритма не найдено, процесс прерывается, о чем уведомляется пользователь.Заносится вновь сформированный общедоступный ключ, PublicKeyS и/или PublicKeyE, предназначенный для сертификации СА.Если ЕЕ является продавец или расчетный центр, а тип запроса соответствует обновлению сертификата шифрования, заполняется EEThumb с оттиском сертификата, подлежащего обновлению. Если тип запроса соответствует обновлению сертификата подписи, оттиск сертификата подписи не требуется, так как CertReq подписан им.Опционно включается список, который содержит оттиски для каждого CRL, сертификата SET, BrandCRLIdentifier и корневого сертификата, резидентно размещенных в кэше.
7Данные, подлежащие дополнительному шифрованию, имеют следующий формат. Если ЕЕ является продавец карты, заполняется PAN, CardExpiry, CardSecretCardNonce и EXNonce в PANData0.
Если ЕЕ является продавец или расчетный центр, опционно заполняется AccTData и EXNonce.
8Данные укладываются в конверт с использованием техники EncX:
Включить:
Обработка
а. В качестве подписанных данных CertReqTBS То, как данные подписываются зависит от RequestType. Имеется как минимум одна и допускаются две подписи, т.е. SignerInfo для CertReq.
Если тип запроса относится к новому сертификату подписи, подписать данные, используя секретный ключ, соответствующий общедоступному ключу, содержащемуcя в PublicKeyS.
Если тип запроса относится к обновлению сертификата подписи, подписать данные, используя секретный ключ, соответствующий общедоступному ключу, содержащемуся в PublicKeyS и, используя секретный ключ, соответствующий обновляемому сертификату.
Если тип запроса относится к сертификату шифрования, подписать данные, используя секретный ключ, соответствующий существующему сертификату подписи.
Если данные подписаны секретным ключом, который не соответствует сертификату, установить SignerInfo.SerialNumber равным нулю, а SignerInfo.IssuerName=”Null-DN”, т.е. RDNSequence равна кодированному NULL.
Тип содержимого SignedData устанавливается равным id-set-content-CertReqTBS.
b. Результат шага 6 в качестве данных, подлежащих дополнительному шифрованию
Провести дополнительное шифрование, используя СА-сертификат, указанный CAEThumb в CardCInitRes или RegFormRes, если один из них был включен, или Me-AqCInitRes
c. CertReqTBEX в качестве данных, подлежащих шифрованию
Зашифровать CertReqTBEX и установить тип содержимого EnvelopedData равным id-set-content-CertReqTBEX
 
9Сформировать цифровой конверт и послать сообщение CertReq центру СА



Если приложением ЕЕ является продавец или расчетный цент, который не имеет данных AcctData (в AcctInfo), чтобы их послать, тогда генерируется CertReq с привлечением техники Enc:
ШагДействие
1Если RequestType соответствует обновлению сертификата подписи, формируется пара ключей (секретный/общедоступный) для сертификата подписи
2Если RequestType соответствует новому или обновляемому сертификату шифрования, формируется пара ключей (секретный/общедоступный) для сертификата шифрования
3Сгенерируется 160-битное случайное число - EXNonce
4Данные CertReqData формируются следующим образом:Генерируется RRPIDЕсли продавец или расчетный центр получают Me-AqCInitRes, RequestType копируется из этого сообщения, в противном случае это поле заполняется обычным путем.Заполняется поле ReqestDateКопируется LID-EE из предыдущего сообщения. Если такового нет, генерируется новое.Генерируется новое Chall-EE3Копируется LID-CA (если имеется) и Chall-CA из предыдущего сообщения, если таковое имеется.Заполнить поле IDDataЗанести RegFormID, полученный из Me-AqCInitResЗанести новую или скорректированную форму RegFormЗанести вновь сформированные общедоступные ключи, PublicKeyS и/или PublicKeyE, предназначенные для сертификации СА.Если RequestType соответствует обновлению сертификата шифрования, заполняется EEThumb оттиском сертификата, подлежащего обновлению.Опционно включается список, который содержит оттиски каждого CRL, сертификата SET, BrandCRLIdentifier и корневого сертификата, резидентные в кэше владельца карты.
5Поместить данные в цифровой конверт, используя инкапсуляцию Enc:
Включить:
Обработка
CertReqData в качестве информации, подлежащей подписыванию.То, как подписываются данные, зависит от RequestType. Имеется как минимум одна и допускаются две подписи, т.е. SignerInfo для CertReq.
Если тип запроса соответствует новому сертификату подписи, данные подписываются с применением секретного ключа, составляющего пару с общедоступным ключом, который содержится в PublicKeyS.
Если тип запроса соответствует обновлению сертификата подписи, данные подписываются с применением секретного ключа, составляющего пару с общедоступным ключом, который содержится в PublicKeyS, а затем посредством секретного ключа, соответствующего обновляемому сертификату.
Если тип запроса соответствует сертификату шифрования, данные подписываются с применением секретного ключа, составляющего пару с общедоступным ключом, который соответствует существующему сертификату подписи.
Если данные подписаны ключом, который еще не соответствует сертификату, следует установить Signer.Info.SerialNumber равным “Null-DN”. Тип содержимого SignedData делается равным id-set-content-CertReqData.
Производится DER-кодирование полученной информации SignedData с целью получения CertReqTBE.Ключ DES в качестве данных, подлежащих дополнительному шифрованиюДля Enc-обработки единственной информацией, которая должна быть зашифрована, является симметричный ключ, используемый для шифрования “обычных данных”. Шифруется ключ с применением сертификата, указанного посредством CAEThumb в Mt-AqCInitRes.
CertReqTBE в качестве обычных данных, подлежащих шифрованиюШифруется CertReqTBE и устанавливается ContentType равным id-set-Content-CertReqTBE.  
6Подготовить цифровой конверт и послать CertReq центру СА



Формат сообщения CertReq, генерируемого EE (End Entity) представлен ниже в таблице 4.6.2.26: Таблица 4.6.2.26. Формат CertReq
CertReq<EncX(EE, CA, CertReqData, AcctInfo), Enc(EE, CA, CertReqData)>
Допускается инкапсуляция с двумя подписями. CertReqTBE и AcctInfo могут быть подписаны любым или всеми секретными ключами, соответствующими следующим сертификатам ЕЕ:секретный ключ нового сертификата подписисуществующий сертификат подписи для запроса сертификата шифрования илисуществующий сертификат подписи для запроса обновленияЭти подписи без соответствующего сертификата являются лишь проформой; они доказывают лишь то, что ЕЕ владеет секретным ключом.
CertReqData{RRPID, LID-EE, Chall-EE3, [LID-CA], [Chall-CA], RequestType, RequestDate, [IDData], RegFormID, [RegForm], [CABackKeyData], publicKeySorE, [EEThumb], [Thumbs]}
AcctInfo<PANData0, AcctData>
Если отправитель запроса - владелец карты, вводится PANData0.
Если отправитель запроса - продавец или получатель, вводится AcctData
RRPIDID пары запрос/отклик
LID-EEКопируется из RegFormRes или Me-AqCInitRes
Chall-EE3Обращение ЕЕ по поводу обновления подписи СА
LID-CAКопируется из RegFormRes или из Me-AqCInitRes
Chall-CAКопируется из RegFormRes или из Me-AqCInitRes
RequestTypeСмотри таблицу 4.6.2.24
RequestDateДата запроса сертификата
IDDataСм. табл. 4.6.2.23. Опускается, если ЕЕ является владельцем карты.
RegFormIDИдентификатор, присвоенный СА
RegForm{RegFormItems +}
Имена полей копируются из RegFormRes или из Me-AqCInitRes вместе со значениями, внесенными ЕЕ
CABackKeyData{CAAIgId, CAKey}
publicKeySorE{[ PublicKeyS], [PublicKeyE]}
Общедоступный ключ объекта. Должен быть специфицирован, по крайней мере, один ключ. Пользователь может запросить сертификат подписи, сертификат шифрования или оба эти сертификата.
EEThumbОттиск сертификата ключа шифрования, который обновляется
ThumbsСписки сертификатов, включая корневой, CRL и BrandCRLIdentifier, используемые в данный момент ЕЕ.
PANData0См. табл. 4.6.2.27
AcctDataСм. табл. 4.6.2.28
RegFormItems{FieldName, FieldValue}
CAAlgIdИдентификатор симметричного алгоритма шифрования
CAKeyСекретный ключ, соответствующий идентификатору алгоритма
PublicKeySПредлагаемый для сертификации общедоступный ключ подписи
PublicKeyEПредлагаемый для сертификации общедоступный ключ шифрования
FieldNameОдно или более имен полей, которые надо отобразить в качестве заполняемой формы в системе отправителя запроса. Это текстовые поля с текстом на языке, специфицированном в RegFormReq или Me-AqCInitReq
FieldValueВеличина, введенная ЕЕ



Таблица 4.6.2.27. Формат PANData0
PANData0{PAN, CardExpiry, CardSecret, EXNonce}
PANПервичный номер счета ( Primary Account Number) для данной карты
CardExpiryДата пригодности карты
CardSecretПредложенная владельцем карты часть секретного ключа PANSecret. Эта величина используется для генерации TransStain.
EXNonceНовый код (Nonce) для предотвращения атак на PANData0
Таблица 4.6.2.28. Формат AcctData
AcctData{AcctIdentification, EXNonce}
AcctIdentificationДля продавца это поле уникально и определяется платежной системой карты (Brand) и получателем (банк продавца)
EXNonceНовый код Nonce для предотвращения атак на PANData0
СА проверяет CertReq (EncX) следующим образом.
ШагДействие
1Получить CertReq из входного сообщенияЕсли RequestType соответствует новому сертификату подписи или сертификатам подписи и шифрования, то используется одна подпись CertReq. Верифицировать ее, используя новый общедоступный ключ, содержащийся в PublicKeyS. Если верификация не прошла, возвращается CertRes с CertStatusCode равным sigValidationFail.Если RequestType соответствует обновлению сертификата подписи или одновременному обновлению сертификатов подписи и шифрования, то используются две подписи (SignerInfos) для CertReq.Для SingerInfo с нулевым DN эмитента верифицируется подпись с использованием нового общедоступного ключа подписи, содержащегося в PublicKeyS. Если верификация не прошла, возвращается CertRes с CertStatusCode равным ValidationFail.Для SingerInfo c DN эмитента и серийным номером равными значениям из обновляемого сертификата подписи верификация подписи осущетствляется с использованием общедоступного ключа этого сертификата. Если верификация не прошла, возвращается сообщение Error с ErrorCode равным signstureFailure.Если RequestType соответствует новому или обновляемому сертификату шифрования, то для CertReq используется одна подпись. Верифицировать ее, используя общедоступный ключ сертификата подписи ЕЕ. Если верификация не прошла, возвращается сообщение Error с ErrorCode равным signatureFailure.
2Из данных CertReqTBS запомнить RRPID, LID-EE, Chall-EE3, RequestType, LID-CA, Chall-CA, IDData, RegForm, CaBackKeyData, список оттисков и новые сертификаты подписи и/или шифрования
3Проверить то, что RRPID и RequestDate соответствуют значениям, полученным из цифрового конверта сообщения. Если соответствия нет, выдается сообщение Error с ErrorCode равным unknownRRPID.
4Проверить то, что полученный Chall-CA соответствует посланному в Me-AqCInitRes или RegFormRes. Если соответствия нет, выдается сообщение Error с ErrorCode равным challengeMismatch.
5Проверить PAN (если он включен) в соответствии с политикой платежной системы (Brand), в противном случае проверить AcctData. Если соответствия нет, возвращается CertRes c кодом CertStatusCode равным rejectByIssuer.
6Если RequestType соответствует обновлению, проверить, что сертификаты, подлежащие обновлению, не были до этого обновлены. Если проверка не прошла, возвращается CertRes c кодом CertStatusCode равным rejectedByCA.
7Проверить то, что RegFormID корректен с точки зрения языка, RequestType и BIN или PAN. Если проверка не прошла, возвращается CertRes c кодом CertStatusCode равным rejectByCA.
8Если отправителем CertReq является владелец карты, запомнить алгоритм и ключ, включенные в CABackKeyData, для шифрования CertRes, посылаемого владельцу карты.
9Проверить невидимые пункты формы регистрации. Если некоторые пункты необходимы, но заполнены некорректно, вернуть CertRes с CertStatusCode равным rejectedByIssuer.
10Если все предшествующие проверки прошли успешно, проверить все позиции регистрационной формы, проверить также, что длина, формат и типы символов правильны. Проверить, что все необходимые поля имеются. Если обнаружены какие-то ошибки, вернуть номер позиции и текст сообщений, где обнаружены ошибки в последовательности FailedItems в CertRes с CertStatusCode равным regFormAnswerMalformed.



Если верификация не прошла, СА подготавливает и отсылает сообщение CertRes c соответствующим статусом. Если обнаружены ошибки в CertReq, СА отметит эти ошибки в CertRes и приложение ЕЕ должно будет послать повторно CertReq. При полном успехе система перейдет к аутентификации в финансовом учреждении. Здесь, прежде чем формировать сертификат, проверяется запрос CertReq. Методика этой проверки зависит от типа платежной системы (Brand) и находится за пределами спецификации SET. В зависимости от результатов проверки CertReq, CertRes будет содержать сертификат или статусный код (при неуспехе). Сообщение CertRes будет подписано и в зависимости от характера данных, уложенных в него, зашифровано. Если CertRes уведомляет владельца карты об успехе, то сообщение шифруется с использованием обычного симметричного алгоритма, поддерживаемого приложениями СА и владельца карты. Если сообщение CertRes предназначено для продавца или расчетного центра или возвращает владельцу карты статусные данные, то оно подписывается, но не шифруется. Если CertReq аутентичен и корректен, а СА сформировал сертификат, используя представленный ключ, то будет возвращен CertRes с завершенным статусом. Если CertRes предназначен для владельца карты и содержит ключ (в CaBackKeyData) для шифрования CertRes, СA сформирует CertRes как SignedData. Осуществляется это следующим образом.
ШагДействие
1CertResData формируется как:Копируется RRPID, LID-EE, список оттисков и Chall-EE3 из CertReqГенерируется или копируется из CertReq (если имеется) LID-CA Опционно заполняется CardLogo, URL, BrandLogo, URL, CardCurrency и/или CardholderMessage (CaMsg)CertStatusCode устанавливается равным “Request Complete”Формируется Nonce-CCAВычисляются и заносятся оттиски EE-сертификатов, CertThumbs.Если BrandCRLIdentifier не специфицирован в списке оттисков CertReq, заполняется поле BrandCRLIdentifier.
2Подписать и вложить данные в цифровой конверт, используя технику EncK-инкапсуляции, для CertResData в качестве данных, подлежащих подписке.Подписать данные посредством сертификата подписи САУстановить тип данных SignedData равным id-set-content-CertResData.Вставить новые сертификаты подписи и/или шифрования ЕЕ в сертифицированной части SignedData.Зашифровать подписанные данные, используя сгенерированный вектор инициализации, а также алгоритм и ключ, представленные CABackKeyData в CertReq.Установить тип содержимого EncriptedData равным id-set-content-CertResTBE
3Сформировать цифровой конверт и послать EE CertRes.
Если СА возвращает статус в CertRes, в него для передачи данных продавцу, владельцу карты или расчетному центру включается сообщение EEMessage.


Подписанное сообщение CertRes формируется следующим образом:
ШагДействие
1Если СА сгенерировал сертификат, который будет включен в CertRes, выполняется формирование CertResTBS.
2Если СА не сгенерировал сертификат, т.е. имеет статус, отличный от “Request Complete”, создается CertResData:Копируется LID-EE и Chall-EE3 из CertReqОпционно заносится EEMessageИз табл. 4.6.2.30 заносится значение CertStatusCodeЕсли CertStatusCode установлен равным regFormAnswerMalformed, занести номера позиций (ItemNumbers) и причины (ItemReasons) для каждой ошибочной позиции (FailedItem) в регистрационной форме.
3Сформировать цифровой конверт и послать конечному пользователю (ЕЕ) CertRes
Формат CertRes в этом случае имеет вид представленный в таблице 4.6.2.29. Таблица 4.6.2.29. Формат CertRes
CertRes<S(CA, CertResData), EncK(CABackKeyData, CA, CertResData)>
EncK-версия этого сообщения необходима только в случае, когда в CertRes включен опционный компонент CAMsg. Эта версия используется, если в CertReq включено поле CABackKeyData
CertResData{RRPID, LID-EE, Chall-EE3, LID-CA, CertStatus, [CertThumbs], [BrandCRLIdentifier], [Thumbs]}
CABackKeyDataКопируется из CertReq
RRPIDID пары запрос/отклик
LID-EEКопируется из CertReq
Chall-EE3Копируется из CertReq. Источник запроса проверяет соответствие со значением, хранящимся в памяти.
LID-CAКопируется из CertReq. Если в CertReq его нет, то присваивается новое значение.
CertStatus{CertStatusCode, [Nonce-CCA], EEMessage], {CaMsg], [FailedItemSeq]}
CertThumbsЕсли запрос обслужен, то это список оттисков вложенных сертификатов подписей и/или шифрования
BrandCRLIdentifierСмотри раздел об идентификаторах списков отмененных сертификатов платежной системы.
ThumbsКопируется из CertReq.
CertStatusCodeНумерованный код, указывающий на статус запроса сертификата
Nonce-CCAПрисутствует, если в качестве ЕЕ выступает владелец карты. Этот код представляет собой дополнительный секретный ключ, используемый совместно владельцем карты и ССА.
EEMessageСообщение на естественном языке, предназначенное для отображения в системе ЕЕ
CAMsg{[CardLogoURL], [BrandLogoURL], [CardCurrency], [CardholderMsg]}
FailedItemSeq{FailedItem+}
CardLogoURLURL - указатель на логотип эмитента карты
BrandLogoURLURL - указатель на логотип платежной системы
CardCurrancyВид валюта, хранящейся на счете владельца карты
CardholderMsgСообщение на естественном языке владельца карты, которое должно быть отображенопрограммой
FailedItem{ItemNumber, ItemReason}
ItemNumberУказывает на позицию в списке полей регистрационной формы, интерпретация которой невозможна. Значение нуль указывает на поле AcctData
ItemReasonПричина неудачи. Текстовое поле на естественном языке.



Таблица 4.6.2.30. Статусные коды для запросов сертификата
КодЗначениеИсточник
requestCompleteЗапрос сертификата одобренCA
invalidLanguageВ запросе указан неверный языкCA
invalidBINЗапрос сертификата отклонен из-за некорректного BINЭмитент или получатель
sigValidationFailЗапрос сертификата отклонен по причине некорректной подписиCA
decryptionErrorЗапрос сертификата отклонен из-за ошибки дешифрованияCA
requestInProgressЗапрос сертификата обрабатываетсяСА, эмитент или получатель
rejectedByIssuerЗапрос сертификата отклонен эмитентом картыЭмитент
requestPendedЗапрос сертификата ждет обработкиСА, эмитент или получатель
rejectedByAquirerЗапрос сертификата отклонен банком продавца (получателем)Получатель
regFormAnswerMalformedЗапрос сертификата отклонен из-за неверной позиции в регистрационной форме.CA
rejectedByCAЗапрос сертификата отклонен центром сертификацииCA
unableToEncryptCertResЦентр сертификации не получил ключа и по этой причине не может зашифровать отклик для владельца картыCA
Конечный пользователь ЕЕ проверяет новый сертификат следующим образом:
ШагДействие
1Выделить CertRes из входного сообщения. Если CertRes содержит подписанные данные, дешифровать их и проверить подпись CertRes (см. описание методики EncK). Процедура осуществляется для полученных сертификатов CRL и BrandCRLIdentifier.
2Проверить, что полученные оттиски соответствуют посланным в сообщении CardCInitReq. Если проверка не прошла, возвращается сообщение Error с ErrorCode равным thumbsMismatch.
3Проверить, что LID-EE и Chall-EE соответствуют значениям, посланным в CertReq. Если проверка не прошла, возвращается сообщение Error с ErrorCode равным challengeMismatch.
4Если CertStatusCode указывает “Certificate request complete” (с запросом сертификата все в порядке), то:Извлекаются новые сертификаты из сертификатной секции SignedData и проверяются подписи.Проверяется, что полученные CertThumbs соответствуют посланным в CertReq. Если проверка не прошла, возвращается сообщение Error с ErrorCode равным thumbsMismatch.В случае владельца карты извлекается CaMsg, отображается логотип и CardholderMsg из CaMsg и запоминается CardCurrency.Проверяется, что общедоступные ключи в сертификате соответствуют секретным ключам. Если проверка не прошла, возвращается сообщение Error с ErrorCode равным invalidCertificate.В случае владельца карты выполняются следующие дополнительные действия:Для того чтобы получить PANSecret, вычисляется (Nonce-CCAЕ CardSecret)Вычисляется уникальный идентификатор владельца карты, HMAC-SHA-1{{PAN, cardExpiry}, PANSecret}, т.е. Salted Hash, и проводится верификация того, что полученный результат соответствует значению сертификата.
5Если CertStatusCode равен “MalFormed Registration Form Items”, это означает, что некоторые позиции регистрационной формы заполнены неверно. Для каждой ошибочной позиции приложение ЕЕ занесет в CertRes номер этой позиции и соответствующее сообщение об ошибке. ЕЕ разрешается повторить ввод для полей с ошибкой и повторно послать CertReq с новым запросом сертификата.
6Если CertStatusCode установлен равным requestinProgress или requestPended, сертификат может быть доставлен позднее с помощью процедуры CertInqReq
7Если CertStatusCode указывает какой-либо иной статус, отображается EEMessage.



Информационные сертификатные запросы и обработка статуса Если сертификат не возвращен немедленно в CertRes, EE может попросить прислать ему информацию о состоянии его запроса путем присылки CertReq в центр СА. Запрос CertInqRes возвращает сертификат, если он готов, или предоставляет информацию о том, когда сертификат будет прислан. Такие запросы могут посылать владелец карты, продавец или расчетный центр. Адресуются эти запросы CA, CCA, MCA или PCA (источникам сертификатов). Если CertStatusCode из CertRes равен “Certificate Request in Progress” или “Certificate Request Pending”. EE формирует CertInqReq для получения сертификата следующим образом:
ШагДействие
1Копируется LID-CA3 из CertRes в поле данных “CertInqReqTBS”
2Генерируется новый RRPID
3Генерируется новый LID-EE
4Генерируется новый Chall-EE3
5Копируется LID-CA из предыдущего CertRes
6Подписывается CertInqReqTBS. Устанавливается тип содержимого равным id-set-content-CertInqReqTBS. CertInqReq подписывается также как и CertReq.
7Формируется цифровой конверт и посылается CertInqReq в центр СА.
Формат сообщения представлен в таблице ниже. Таблица 4.6.2.31. Формат CertInqReq
CertInqReqS(EE, CertInqReqTBS)
CertInqReqTBS{RRPID, LID-EE, Chall-EE3, LID-CA}
RRPIDИдентификатор пары запрос/отклик
LID-EEКопируется из CertRes
Chall-EE3Требование ЕЕ по поводу обновления подписи СА
LID-CAКопируется из CertRes
Центр СА обрабатывает CertInqReq следующим образом:
ШагДействие
1Из входного сообщения извлекается CertInqReq. Подпись CertInqReqTBS верифицируется также как и для CertReq. Если проверка не прошла отклик будет таким как при CertReq(EncX)
2Проверить, что RRPID соответствует посланному в цифровом конверте. Если соответствия нет, возвращается сообщение об ошибке с ErrorCode равным unknownRRPID.
3Используя LID-CA в качестве индекса, определяется статус CertReq.
4Если сертификат сформирован, он посылается ЕЕ в отклике CertInqRes, в противном случае в CertInqRes возвращается актуализованный код CertStatusCode
После обработки CertInqReq СА формирует CertInqRes.


Этот отклик имеет ту же структуру и формат, что и CertRes. Обработка CertInqRes происходит аналогично. Реальный формат сертификатов определяется документом Х.509. Характеристики различных полей такого сертификата представлены в таблице 4.6.2.32. Таблица 4.6.2.32. Поля формата сертификата Х.509
ИмяОграничения на формат и значенияОписание
Version (Версия)ЦелоеУказывает на версию сертификата
SerialNumberЦелоеУникальный порядковый номер, приписываемый СА, сформировавшим сертификат
Signature.AlgorithmIdentifierOID и типОпределяет алгоритм, используемый для генерации подписи сертификата
Issuer (эмитент)ИмяСодержит уникальное имя (Distinguished Name) CA, выдавшего сертификат
Validity.notBeforeВремя UTCСпецифицирует время, когда сертификат становится активным
Validity.notAfterВремя UTCСпецифицирует время, когда сертификат перестает действовать. Если это относится к сертификату владельца карты, то его время действия не может быть дольше пригодности карты.
SubjectИмяСодержит уникальное имя объекта владельца ключа
SubjectPublicKeyInfo.algorithm. AlgorithmIdentifierOID и типСпецифицирует алгоритм, который может использоваться с этим ключом.
SubjectPublicKeyInfo. subjectPublicKeyСтрока битовСодержит общедоступный ключ, представленный в запросе сертификата
IssuerUniqueID В SET не используется
SubjectUniqueID В SET не используется
Extensions.extnIdФормат OIDСодержит расширение OID, как это определено Х.509 или SET
Extensions.criticalБулево: 0=ложно
1=истинно
Каждое описание расширения определяет то, какое значение должно принимать это поле
Extensions.extnValue Информация расширения
Для определения позиций необходимы следующие идентификаторы объектов OID (указаны в скобках) в сертификатах SET: countryName [2 5 4 6]organizationName [2 5 4 10]organizationUnitName [2 5 4 11]commonName [2 5 4 3] Ниже представлены формальные определения атрибутов (at), которые заключают в себе уникальные имена (Subject Distinguished Name) для каждого объекта SET, указанного в расширении типа сертификата (CertificateType). OID имен (ASN.1) id-at-countryNameOBJECT IDENTIFIER ::= { id-at 6 }


id-at-organizationNameOBJECT IDENTIFIER ::= { id-at 10 }
id-at-organizationalUnitNameOBJECT IDENTIFIER ::= { id-at 11 }
id-at- commonNameOBJECT IDENTIFIER ::= { id-at 3 } Владелец карты
countryName=<Страна, где размещается финансовое учреждение, выпустившее карту>
organizationName=<BrandID> (идентификатор платежной системы)
organizationalUnitName=<Название финансового учреждения, выпустившее карту>
organizationalUnitName=<Опционно - название карты>
commonName=<Уникальный идентификатор владельца карты>
Если в перечне появляется два атрибута organizationalUnitName, первый из них представляет название финансового учреждения, выпустившее карту. Продавец
countryName=< Страна, где размещается банк продавца - Acquirer>
organizationName=<BrandID>
organizationalUnitName=<Название банка продавца>
commonName=<Имя продавца, как написано в заявлении владельца карты>
Расчетный центр
countryName=<Страна, где размещается банк продавца - Acquirer>
organizationName=<BrandID>
organizationalUnitName=<Название банка продавца>
commonName=<Уникальный идентификатор расчетного центра>
Центр сертификации владельца карты
countryName=<Страна, где размещается финансовое учреждение, выпустившее карту>
organizationName=<BrandID>
organizationalUnitName=<Описательное имя>
commonName=<Опционный уникальный идентификатор>
Центр сертификации продавца
countryName=<Страна, где размещается банк продавца - Acquirer >
organizationName=<BrandID>
organizationalUnitName=<Описательное имя>
commonName=<Опционный уникальный идентификатор>
Центр сертификации расчетного центра
countryName=<Страна, где размещается банк продавца - Acquirer >
organizationName=<BrandID>
organizationalUnitName=<Описательное имя>
commonName=<Опционный уникальный идентификатор>
Геополитический центр сертификации
countryName=<Страна геополитической организации>
organizationName=<BrandID>


organizationalUnitName=<Описательное имя>
commonName=<Опционный уникальный идентификатор>
Центр сертификации платежной системы (Brand)
countryName=<Страна, где размещен центр сертификации платежной системы>
organizationName=<BrandID>
organizationalUnitName=<Описательное имя>
commonName=<Опционный уникальный идентификатор>
Корневой центр сертификации
countryName=<Страна, где размещен корневой центр сертификации - СА>
organizationName=<Корневой центр SET>
commonName=<Опционный - уникальный ID>
Поля имен в имени субъекта сертификата определены в таблице ниже:
Country2 символа кода страны (ISO 3166)
BrandID<Brand Name>:<Product>, где название продукта является опционным.
Brand NameПлатежная система карты, которая определяется разработчиками платежной системы.
Product TypeОпционное поле, которое определяет тип продукта в рамках заданной платежной системы.
Описательное имяЭто описательное имя объекта, ответственного за выпуск сертификата в рамках данного СА. Например:Название финансовой организацииНазвание организации, выполняющей функцию САНазвание платежной системыИмя объекта, ответственного за одобрение сертификатов
Официальное название картыЭто опционное поле содержит официальное название карты. Примерами могут служить, например: Frequent Flayer Program, Affinity Program и т.д.
Название финансовой организацииИмя финансовой организации, выпускающей расчетные карты
Уникальный идентификатор владельца картыУникальным идентификатором владельца карты в сертификате владельца является хэшированный номер его счета.
Уникальный идентификатор расчетного центраПоле содержит BIN, за которым следует серийные номера банка продавца или расчетной системы. Поле форматировано как <BIN:SerialNumber>. Серийный номер позволяет однозначно идентифицировать каждый расчетный центр, ассоциированный с одним и тем же банком продавца (Acquirer). В пределах расчетной системы (Brand) может быть несколько сертификатов для одного BIN.
Уникальный ID владельца карты в сертификате представляет собой хэшированный номер его счета.


PAN маскируется с использованием общего секретного ключа (PANSecret), который состоит из комбинации CardSecret владельца карты и Nonce-CCA сертификационного центра. Вычисление хэша производится с привлечением алгоритма HMAC-SHA1 (RFC-2105). Функция HMAC-SHA1 определяется в терминах ключа K и текста, который кэшируется следующим образом: Hash(KЕ opad|hash((KЕipad)|text)), где Е - оператор исключающее ИЛИ, а оператор | - обозначает объединение кодов. K, text, ipad и opad определяются в SET следующим образом:
KРавно PANSecret и представляет собой 20-байтовую строку, полученную в результате операции исключающее ИЛИ, выполненной над DER-кодированными значениями CardSecret и Nonce-CCA.
TextПредставляет собой DER-кодированную копию исходного текста, содержащего PAN и CardExpiry.Text ::= SEQUENCE {pan PAN
cardExpiry CardExpiry
}
PAN ::= NumberString (SIZE(1..19))
CardExpiry ::= NumericString (SIZE(6)) --YYYMM
Время истечения действия карты
ipad64 байта, содержащих код 0x36
opad64 байта, содержащих код 0x5C
K дополняется нулями до 64 байт. Результат вычисления HMAC кодируется в представлении base64, после чего производится в поле сертификата commonName. Профайлы сертификатов В таблице 4.6.2.33 представлен полный список сертификатов необходимых SET. Таблица 4.6.2.33. Типы сертификатов
ОбъектЦифровая подписьШифрование_ключей/
шифрование_данных
ПодписьkeyCertПодписьCRL
Владелец картыХ   
ПродавецХХ  
Расчетный центрХХ  
Центр сертификации владельца картыХХХ 
Центр сертификации продавцаХХХ 
Центр сертификации расчетного центраХХХХ
Геополитический центр сертификацииХ ХХ
Центр сертификации платежной системы  ХХ
Корневой центр сертификации  ХХ
ССА, MCA и PCA при совмещении функций не обязательно требуют наличия трех отдельных сертификатов. Сертификат подписи может содержать два или три различных типов сертификата. Разные СА не обязательно требуют различных сертификатов для подписи сертификатов и CRL. Поле KeyUsage может содержать: привилегии keyCertSign и offLineCRLSign илиkeyEncipherment и dataEncipherment В таблице 4.6.2.34 представлены обязательные расширения сертификата конечного пользователя (ЕЕ). Таблица 4.6.2.34.


Обязательные расширения сертификата ЕЕ.
 Сертификат владельца картыСертификат продавцаСертификат расчетного центра
Расширение Х.509 ПодписьПодписьШифрова-ние ключаПодписьШифрова-ние ключа
AuthorityKeyIdentifierХХХХХ
KeyUsageХХХХХ
PrivateKeyUsagePeriodХХ Х 
CertificatePoliciesХХХХХ
SubjectAltNameOOOOO
BasicConstraintsХХХХХ
IssuerAltNameOOOOO
Частное расширение
HashedRootKey     
CertificateTypeХХХХХ
MerchantData ХХ  
CardCertRequired    Х
Tunneling    Х
SETExtensions    Х
Х - обязательный
O - опционный Таблица 4.6.2.35. Обязательные расширения сертификатов СА
 САКорневой центр сертификации
Расширение Х.509Цифровая
подпись
Подпись
серти-фиката
Шифрова-ние ключаПодпись
CRL
Подпись сертификата & CRL
AuthorityKeyIdentifierХХХХХ
KeyUsageХХХХХ
PrivateKeyUsagePeriodХХ Х 
CertificatePoliciesХХХХХ
SubjectAltNameOOOOO
BasicConstraintsХХХХХ
IssuerAltNameOOOOO
Частное расширение
HashedRootKey    Х
CertificateTypeХХХХХ
MerchantData     
CardCertRequired     
Tunneling  Х  
SETExtensions     
Каждый центр сертификации (за исключением MCA и CCA) поддерживает CRL и производит их рассылку. BCI (BrandCRLIdentifier), определенный SET, содержит список всех CRL в пределах данной платежной системы (Brand). Как только СА выпустит новый список CRL, соответствующий BCI актуализируется. Получение конечным пользователем BCI гарантирует, что устаревшие или скомпрометированные сертификаты не будут использованы. В CRL записываются серийные номера устаревших сертификатов. СА идентифицируется в CRL по своему уникальному имени, CRL подписывается рассылающим СА. Длина списка CRL со временем растет. Каждый СА CRL содержит в себе следующую информацию: Номер CRL. Номера монотонно возрастают.Список серийных номеров устаревших сертификатов.Даты, когда конкретные сертификаты были признаны устаревшими.Даты, когда был сформирован CRL и когда завершается срок его действия (замещается новым CRL).Уникальное имя СА, который поддерживает данный CRL.Эмитент и серийный номер сертификата СА, который используется для подписи данного CRL. В таблице 4.6.2.36 определен формат полей CRL и ограничения для их значений (X.509). Таблица 4.6.2.36.


Формат полей CRL и ограничения для их значений
Имя поляФормат и ограничения на значениеОписание
CRL.version (версия)Целое; V2Определяет версию CRL. В настоящее время =2.
CRL.signature
.algorithmIdentifier
OID и типОпределяет алгоритм, использованный для подписи CRL
CRL.IssuerИмяСодержит DN субъекта для СА, который выпустил устаревший сертификат. Должен совпадать с именем субъекта в сертификате СА
CRL.thisUpdateВремя UTCОпределяет время, когда был сформирован CRL
CRL.nextUpdateВремя UTCОпределяет время, когда CRL устареет
CRL.revokedCertificate
.certSerialNumber
ЦелоеНомер по порядку устаревшего сертификата
CRL. RevokedCertificate
.revocationDate
Время UTCДата признания сертификата устаревшим
CRL. RevokedCertificate
.extensions
РасширенияНе используется в SET
CRL.extensionsРасширенияВ этом поле используются два расширения: CRLNumber и AuthorityKeyIdentifier
Следующие СA должны поддерживать CRL в рамках SET: корневой СА - для поддержки незапланированной замены корневых сертификатов или сертификатов СА платежных систем.СА платежных систем - для поддержки незапланированной замены или прекращения действия сертификата, выданного центром сертификации платежной системы.геополитические СА - для поддержки незапланированной замены сертификатов CCA, MCA или PCA.CA расчетного центра - для поддержки незапланированной замены сертификатов ключевого обмена расчетного центра. Расширение CRLNumber содержит одно целое число. Центр СА, подписывающий CRL, должен инкрементировать это число каждый раз при выпуске нового CRL. При получении нового CRL должны проводиться следующие проверки: 1. Сначала проверяется подпись: Используется AuthorityKeyIdentifier расширения CRL для контроля корректности сертификата подписи.Расширение KeyUsage в сертификате подписи указывает на CRLsign(6) 2. IssuerDN рассматриваемого сертификата должен соответствовать полю IssuerDN в CRL.
3. IssuerDN и устаревший certSerialNumber сравниваются с проверяемым сертификатом Следующие проверки производятся для того, чтобы выяснить, не входит ли данный сертификат в список CRL: IssuerDN рассматриваемого сертификата должен соответствовать содержимому поля IssuerDN CRLcertSerialNumber должно соответствовать значению поля revokedCertificates.certSerialNumber списка CRL. Существующие CRL от одного и того же IssuerDN могут быть удалены, когда успешно прошел проверку CRL с более высоким значением CRLNumber. BrandCRLIdentifier BrandCRLIdentifier (BCI) представляет собой структуру, определенную SET и используемую для идентификации всех рабочих CRL заданной области ответственности сертификационного центра платежной системы.


BrandCRLIdentifier содержит в себе следующую информацию: Номер BCI (увеличивается для каждого нового BCI)Название платежной системыВремя пригодности BCIСписок номеров CRL (из расширения номера CRL)Эмитент и серийный номер сертификата СА платежной системы, который используется для подписи BCI (включается в расширение) Подпись BCI производится с привлечением секретного ключа, соответствующего сертификату CRLSign. BCI пересылаются владельцам карт и продавцам в виде сообщений-откликов. Запросы и отклики сертификатов Запрос сертификата посылается клиентом вышестоящему центру сертификации (СА). Последний формирует сертификат и отсылает его отправителю запроса в подписанном сообщении отклике. Различные объекты ответственны за подпись разных сертификатов, как это показано ниже.
Сертификат для:Формируется и подписывается:
СА платежной системыКорневой СА
Геополитический САСА платежной системы
ССА, МСА или РСАГеополитический СА, если таковой имеется, в противном случае СА платежной системы
Сообщения запросы от СA форматируются согласно CertificationRequest, специфицированному в PKCS#4 версии 1.0. CertificationRequest содержит общедоступный ключ, DN субъекта и атрибуты, которые должен сертифицировать подписывающий СА. Сообщение-запрос сертификата включает в себя информацию, которая должна присутствовать в расширениях сертификата. Эта информация содержится в атрибутах запроса PKCS#10. В таблице 4.6.2.37 показаны атрибуты, которые необходимы или опционны в CertificationRequest. Таблица 4.6.2.37. Атрибуты CertificationRequest
 ССА, МСА или РСАГеополитический центр сертификации или СА платежной системы
Атрибут SETСертификат подписиПодпись CRLСертификат и подпись CRL
KeyUsageXXXXX
PrivateKeyUsagePeriodXX XX
AdditionalPolicyOOOOO
SubjectAltNameOOOOO
CertificateTypeXXXXX
Tunneling  X  
Х - обязательный
O - опционный При получении CertificationRequest СА должен проверить запрос и сформировать отклик в соответствии со следующей процедурой:
ШагДействие
1Используя процедуру, определенную платежной системой, проверить аутентичность CertificationRequest
2Используя общедоступный ключ, присланный в запросе, проверить подпись
3Проверить, что уникальное имя субъекта (Distinguished Name) согласуется с форматом Certificate Subject Name
4Используя тип сертификата и атрибуты использования ключа, проверить, что имеются необходимые атрибуты (см. таблицу 4.6.2.37)
5Для сертификатов подписи проверить, что запрошенный PrivateKeyUsagePeriod находится в пределах допустимого диапазона пригодности по времени для подписывающего СА, и что дата notBefore в запрошенном PrivateKeyUsagePeriod находится в пределах допустимого для подписывающего СА.
6Если какая-либо из вышеперечисленных проверок не прошла, сертификат не будет сформирован.
7Если верификация прошла успешно, сертификат формируется с применением атрибутов, включенных в запрос. Сформированный сертификат помещается в соответствующую секцию SignedData.
8SignedData помещается в цифровой конверт и посылается отправителю запроса. Транспортные механизмы находятся вне зоны ответственности SET.



Рассылка CRL CRL представляет собой механизм, определенный Х.509, и предназначенный для публикации и рассылки списков выведенных из употребления сертификатов, срок действия которых еще не истек. Когда корневой СА актуализует свой CRL, он посылает его каждому центру сертификации платежной системы. Когда нижерасположенный центр сертификации актуализует свой CRL, он рассылает его своим СА платежных систем. CRL рассылаются в секции SignedData сообщений CRLNotification согласно следующему алгоритму.
ШагДействие
1Сформировать CRLNotificationTBS:Занести в поле данные текущую датуЗанести в CRLThumbprint оттиск, несущий в себе CRL
2Подписать содержимое, используя сертификат подписи СА. Установить тип содержимого равным id-set-content-CRLNotificationTBS
3Внести новый CRL в CRL-секцию SignedData. Вложить CRL в сертификационную секцию сообщения.
4Закодировать и вложить в цифровой конверт подписанное сообщение CRLNotification. Следует заметить, что это не SET-сообщение. SignedData подвергается DER-кодированию и вкладывается в цифровой конверт MIME.
CRL-Notification-сообщение содержит следующие поля:
Название поля Описание
CRL-NotificationS(CA, CRLNotificationTBS)
CRL-NotificationTBS{Date, CRLThumbprint}
ДатаДата, когда сформировано сообщение
CRLThumbprintОттиск CRL, заключенный в CRL-секцию SignedData
При получении сообщения CRL Notification СА платежной системы проверяет и анализирует его следующим образом:
ШагДействие
1Если дата раньше, чем для любого предыдущего CRL, полученного от этого СА, сообщение проигнорировать и откликнуться отправившему СА сообщением Error c кодом ошибки badDate.
2Если CRL-оттиск не согласуется с тем, который записан в CRL-секции SignedData, сообщение проигнорировать и откликнуться отправившему СА сообщением Error c кодом thumbMismatch.
3Запомнить модифицированный CRL и послать СА платежной системы для добавления в последующее сообщение рассылки BCI.
CA платежной системы формирует отклик CRL Notification согласно следующему алгоритму:
ШагДействие
1Заполнить NotificationResTBS:Вставить дату из сообщения CRLNotificationВставить оттиск полученного CRL
2Подписать содержимое, используя сертификат подписи центра сертификации платежной системы. Установить contenttype равным id-set-content-CRLNotificationResTBS
3Закодировать и вложить в цифровой конверт подписанное сообщение CRLNotificationRes в форме согласованной с транспортным механизмом. Послать сообщение отклика CRLNotification запросившему СА.



Сообщение- отклик CRLNotification содержит следующие поля.
Название поля Описание
CRL-NotificationResS(CA, CRLNotificationTBS)
CRL-NotificationResTBS{Date, CRLThumbprint}
ДатаКопируется из сообщения CRLNotification
CRLThumbprintОттиск CRL, копируется из сообщения CRLNotification
При получении отклика CRLNotification СА проверяет то, что дата и оттиск соответствуют значениям из запроса. Если соответствия нет, посылается сообщение об ошибке, а запрос CRLNotification посылается повторно. Получение BCI BrandCRLIdentifier (BCI) является списком текущих CRL, соответствующим всем СА из зоны ответственности платежной системы (Brand). Центр сертификации платежной системы отвечает за поддержку, корректность и актуальность BCI. Каждый CA из зоны ответственности платежной системы отвечает за обновление и осуществление доступа к BCI и соответствующим спискам CRL. Эту информацию они выдают в виде откликов на запросы ЕЕ или нижестоящих СА. Центр сертификации каждой платежной системы формирует и поддерживает свой BCI и реализует механизм для рассылки этой информации. СА, например, расчетного центра должен организовать ежедневное обновление этих данных. Центр сертификации платежной системы рассылает информацию о новых CRL в виде сообщений BCI Distribution. Это сообщение является подписанным, содержащим текущую дату, BCI, соответствующие сертификаты и CRL. Сообщение BCI Distribution не формируется ежедневно, а лишь по мере необходимости. Алгоритм формирования этого сообщения представлен ниже.
ШагДействие
1Заполнить BCIDistributionTBS:Ввести текущую датуВключить последнюю версию BCI
2Подписать содержимое, используя сертификат подписи центра сертификации платежной системы. Установить contenttype равным id-set-content-BCIDistributionTBS. В CRL секцию SignedData ввести все CRL, перечисленные в BCI. В сертификатную часть вставить все сертификаты, необходимые для верификации всех CRL.
3Закодировать и вложить в цифровой конверт подписанное сообщение BCIDistribution в форме, согласованной с транспортным механизмом.
Сообщение BCI Distribution содержит в себе следующие поля:
Название поля Описание
BCIDistributionS(CA, BCIDistributionTBS)
BCIDistributionResTBS{Date, BCIDistribution}
ДатаДата формирования сообщения
BrandCRLIdentifierСписок текущих CRL для всех СА в зоне ответственности центра сертификации платежной системы и корневого СА. Сообщение подписывается сертификационным центром платежной системы.



Обработка пришедшего сообщения BCIDistribution соответствующим СА производится согласно алгоритму, приведенному ниже:
ШагДействие
1Извлечь BCIDistribution из транспортного сообщения. Проверить подпись сообщения, используя сертификат подписи СА платежной системы.
2Если дата относится к моменту времени раньше, чем та, что в предыдущем сообщении BCIDistribution, сообщение следует выбросить.
3Если BrandCRLIdentifier отличается от текущего, проверить подпись каждого CRL из BCI. Если подпись некорректна или список CRL из перечня BCI не включен в сообщение, оно отбрасывается.
4Запомнить все CRL и BrandCRLIdentifier для последующей рассылки
Структуры данных Сообщения SET включают в себя несколько структур данных, которые содержат информационные элементы, переносимые из одного сообщения в другое. Информационные поля сообщения с протокольной точки зрения непрозрачны. TransID TransID предоставляет всю информацию для уникально определенной транзакции и характеристики транзакции, частью которой является данное сообщение. В частности TransID позволяет участнику процесса связать каждое сообщение с определенной транзакцией. Структура данных в TransID представлена ниже в таблице.
TransID{LID-C, [LID-M], XID, PReqData, [PaySysID], Language}
LID-CЛокальный ID. Метка, генерируемая системой владельца карты или для нее.
LID-MЛокальный ID. Метка, генерируемая системой продавца или для нее.
XIDГлобально уникальный идентификатор
PReqDataДата запроса покупки. Генерируется продавцом в PInitRes или владельцем карты в PReq.
PaySysIDИспользуется некоторыми платежными системами для пометки транзакций
LanguageЕстественный язык владельца карты
TransID предоставляет несколько идентификаторов для транзакций. LID-C, LID-M и PaySysID являются идентификаторами, которые присваиваются владельцем карты, продавцом и/или платежной системой. LID-M часто используется для хранения номера заказа продавца для данной транзакции. PreqData предоставляет дату запуска транзакции. XID представляет собой идентификатор транзакции, который обычно формируется системой продавца, если только нет PInitRes, в последнем случае он формируется системой владельца карты.


XID представляет собой псевдослучайный 20 байтовый код, который должен быть уникальным. В таблице 4.6.2.38 рассмотрено, когда формируется и используется поле TransID в сообщениях SET. Таблица 4.6.2.38. Условия формирования и использование поля TransID
СообщениеLID-CLID-MXIDPaySysID
PInitReqRC1N/PN/P
PInitResЯЯ (C2)RN/P
PReqЯЯЯ (R3)N/P
PResЯЯ (C2)ЯC4
InqReqЯЯЯC5
InqResЯЯЯC4
AuthReqЯЯЯN/P
AuthResЯЯЯC6
AuthRevReqЯЯЯC
AuthRevResЯЯЯЯ
CapReqIIII
CapResIIII
CapRevReqIIII
CapRevResIIII
CredReqIIII
CredResIIII
CredRevReqIIII
CredRevResIIII
PCertReqN/PCN/PN/P
PCertResN/PЯN/PN/P
BatchAdminReqIIII
BatchAdminResIIII
CardCInitReqRN/PN/PN/P
CardCInitResЯN/PN/PN/P
Me-AdCInitReqN/PCN/PN/P
Me-AdCInitResN/PЯN/PN/P
RegFormReqЯЯN/PN/P
RegFormResЯЯN/PN/P
CertReqЯЯN/PN/P
CertResЯЯN/PN/P
CertInqReqЯЯN/PN/P
CertInqResЯЯN/PN/P
RПоле является обязательным, генерируется отправителем сообщения и копируется в цифровой конверт.
CНаличие поля является условным. Оно может быть сформировано для этого сообщения и задублировано в цифровом конверте. В противном случае поле копируется из предыдущего сообщения.
N/P(Not Present) Отсутствует как в сообщении так и в цифровом конверте.
ЯКопируется из запроса или предыдущего сообщения, дублируется в цифровом конверте
IМожет присутствовать в элементе информационной структуры сообщения, отсутствует в цифровом конверте.
Примечания: Копируется из процесса инициализации SET (если имеется)Если для данной транзакции нет предшествующего LID-M, продавец может сформировать его для данного сообщения.Если пара PinitReq/PinitRes отсутствует, то генерируется владельцем карты.Если послано после получения AuthRes с PaySysIDЕсли послано после получения PRes с PaySysIDМожет быть сформировано расчетным центром для данного сообщения. Алгоритм формирования TransID представлен ниже:
ШагДействие
1Если сообщение для данной транзакции получено раньше, следует запомнить все его поля.
2Если это новая транзакция, сформировать все необходимые поля (см таблицу выше)
3Заполнить любые опционные поля, которые могут быть сформированы данным объектом.
Обработка TransID зависит от типа сообщения. Платежная инструкция Платежная инструкция (PI) является одной из важнейших информационных структур SET.


Она используется для передачи информации, необходимой для авторизации операции платежа владельца карты расчетному центру. Данная операция служит для инициализации транзакции с привлечением традиционной платежной карты. Данные шифруются владельцем карты и посылаются через продавца получателю (банку продавца - Acquirer). Эта информация не может быть прочитана продавцом. Имеется три разновидности PI. Первые два формируются владельцем карты, третье - расчетным центром.
PIUnsignedФормируется владельцем карты без использования сертификата подписи. Используется в сообщениях PReqUnsigned.Целостность данных обеспечивается за счет добавления хэша PI-данных, которые защищены в блоке OAEP. В данном механизме аутентификация отправителя не производится.
PIDualSignedФормируется владельцем карты, который владеет сертификатом подписи. Используется в сообщениях PreqDualSigned. Подпись владельца карты аутентифицирует отправителя и гарантирует целостность данных.
AuthTokenФормируется расчетным центром. Продавец извлекает PI для дальнейшего вложения в AuthReq.
Этот вариант используется для поддержки доставки по частям и передается назад из расчетного центра после первичной авторизации с тем, чтобы использоваться для запросов последующих авторизаций.
Платежная инструкция имеет структуру представленную в таблице 4.6.2.39. Таблица 4.6.2.39. Структура PI
PI<PIUnsigned, PIDualSigned, AuthToken>
Владелец карты создает PIUnsigned или PIDualSigned инструкцию.
Расчетный центр формирует AuthToken для поддержки поставки по частям и последовательных платежей. Продавец запишет PI для последующего вложения в AuthReq.
PIUnsignedEXH(P, PI-OILink, PANToken)} (См. табл. 4.6.2.46)
PIDualSigned{PISignature, EX(P, PI-OILink, PANData)} (См. табл. 4.6.2.45)
AuthTokenСм. табл. 4.6.2.42
PI-OILinkL(PIHead, OIData) (см. табл. 4.6.2.40)
PISignatureSO(C, PI-TBS)
PI-TBS{HPIData, HOIData}
HPIDataDD(PIData)
HOIDataDD(OIData)
PIData{PIHead, PANData} (см. табл. 4.6.2.40 и 4.6.2.45)
Таблица 4.6.2.40.


Структура PIHead
PIHead{TransIDs, Inputs, MerchantID, [InstallRecurData], TransStain, SWIdent, [AcqBackKeyData], [PIExtensions]}
TransIDsСм. выше описание TransIDs
Inputs{HOD, PurchAmt}
MerchantIDКопируется из сертификата подписи продавца
InstallRecurDataСм. табл. 4.6.2.41
TransStainHMAC(XID, CardSecret)
SWIdentСтрока, идентифицирующая программное обеспечение (разработчик и версия), инициирующее запрос. Оно специфицируется в PI, чтобы расчетный центр знал программное обеспечение владельца карты.
AcqBackKeyData{AcqBackAlg, AcqBackKey}
PIExtensionsДанные из расширения платежных инструкций должны быть финансовыми и важными для обработки авторизации расчетного центра, эмитента или финансовой сети
Прикладные данные в этом сообщении состоят из PIData, от которых PANData отличается более сильной криптографической обработкой. PANData - это информация платежной карты. PIData включает в себя все прочие данные о покупке, идентификацию транзакции и переменные криптографической поддержки. Таблица 4.6.2.41. Структура InstallRecurData
InstallRecurData{InstallRecurDInd, [IRExtensions]}
InstallRecurDInd< InstallTotalTrans, Recurring >
IRExtensionsДанные в расширении или рекурсивные данные. Они должны носить финансовый характер и должны иметь отношение к последующим процедурам авторизации продавца и расчетного центра
InstallTotalTransВладелец карты специфицирует максимально допустимое число авторизаций для последовательных платежей
Recurring{RecurringFrequency, RecurringExpiry}
RecurringFrequencyМинимальное число дней между авторизациями (ежемесячная авторизация обозначается 28 днями)
RecurringExpiryОкончательная дата, после которой никакие авторизации не разрешены
Рекуррентные данные являются компонентом платежной инструкции, которая копируется в авторизационный маркер (token). Эта информация не пересылается эмитенту. AuthToken представляет данные, необходимые расчетному центру для авторизации последующих транзакций. Расчетный центр, если необходимо, актуализует AuthToken.


Данные, содержащиеся там должны быть доступны только расчетному центру. Структура данных AuthToken представлена в таблице 4.6.2.42. Таблица 4.6.2.42. Структура AuthToken
AuthTokenData{TransIDs, PurchAmt, MerchantID, [AcqBackKeyData], [InstallRecurData], [RecurringCount], PrevAuthDataTime, TotalAuthAmount, AuthTokenOpaque}
PANTokenПоля копируются из поля PI-Head, сформированного владельцем карты (см. табл. 4.6.2.40)
TransIDs
PurchAmt
MerchantID
AcqBackKeyData
InstallRecurData
RecurringCountЧисло реализованных рекуррентных авторизаций
PrevAuthDateTimeДата и время последней авторизации продавца в последовательности рекуррентных авторизаций
TotalAuthAmountПолное число авторизованных в результате всех авторизаций для данного XID
AuthTokenOpaqueНевидимые данные, генерируемые расчетным центром
AuthToken формируется следующим образом:
ШагДействие
1Генерируется AuthTokenTBE как:
Если это первая авторизация (выполнена согласно PI)
а. Заполняется из PI поля PANToken, TransIDs, PurchAmt, MerchantID и, если имеется в PI, AcqBackInfo и InstallRecurData
б. RecurringCount делается равным 1
в. В PrevAuthDateTime записывается текущая дата
г. В TotalAuthAmount заносится AuthAmt из авторизационного отклика, который содержит данный AuthTokenЕсли это очередная аутентификация (сгенерирована из предыдущего AuthToken)
а. Заполняется из предыдущего AuthToken поля PANToken, TransIDs, PurchAmt, MerchantID и, если имеется, AcqBackInfo и InstallRecurData
б. Инкрементируется на 1 RecurringCount
в. В PrevAuthDateTime записывается текущая дата
г. TotalAuthAmount увеличивается на AuthAmt, взятое из авторизационного отклика, который содержит данный AuthTokenЕсли это полная (reversal) аутентификация (сгенерирована из предыдущего AuthToken)
а. Из предыдущего AuthToken заполняются поля PANToken, TransIDs, PurchAmt, MerchantID, PrevAuthDateTime и, если имеется, AcqBackInfo и InstallRecurData
б. Если это повторное выполнение всех авторизаций (т.е. AuthNewAmt в AuthRevReq равно нулю), уменьшить RecurringCount на 1
в. Уменьшить TotalAuthAmount на AuthNewAmt из авторизацилнного отклика, который будет содержать маркер AuthToken.
2Сформировать PANToken (см. табл. 4.6.2.46)
3С привлечением инкапсуляции EncX уложить данные в цифровой конверт, используя P1=P2=Cert-PE в качестве s и r параметров, AuthTokenTBE (из шага 1) - в качестве параметра t и PANToken - в качестве параметра p.



Обработка AuthToken выполняется в следующем порядке:
ШагДействие
1Извлечь AuthToken из EncX-конверта, используя секретный ключ расчетного центра.
2Если это автризационный запрос и AuthToken уже использовался при авторизации, установить AuthCode равным piPreviouslyUsed
3Если это запрос повторной авторизации (reversal request) и AuthToken не использовался при авторизации, установить AuthCode=piAuthMismatch.
4Если это авторизационный запрос и InstallRecurData специфицирована рекурентной информацией:Проверить, что текущая дата относится ко времени раньше даты RecurringExpiry. Если проверка не прошла, установить AuthCode равным recurringExpired.Проверить, что текущая дата позднее, чем PrevAuthDate плюс число дней, специфицированное в RecurringFrequency. Если проверка не прошла, установить AuthCode равным recurringTooSoon.
5Если это автризационный запрос и InstallRecurData специфицирована информацией Installment, реализовать специфические требования платежной системы карты.
6Если на предыдущих шагах AuthCode не был установлен, переадресовать данные от AuthToken авторизационному процессу.
AcqCardMsg является полем, которое предоставляет механизм для посылки банком продавца сообщения владельцу карты, не информируя об этом продавца (туннелирование). Это поле может быть использовано после того, как расчетный центр получит сообщение AuthReq от продавца. Структура данных AcqCardMsg представлена в таблице 4.6.2.43. Таблица 4.6.2.43. Структура AcqCardMsg
AcqCardMsgEncK(AcqBackKeyData, P, AcqCardCodeMsg)
AcqBackKeyData предоставляется владельцем карты в PI.
Зашифрованное сообщение адресуется владельцу карты.
AcqBackKeyDataКопируется из PIHead.AcqBackKeyData (см. табл. 4.6.2.40)
AcqCardCodeMsg{AcqCardCode, AcqCardMsgData}
AcqCardCodeЧисловой код
AcqCardMsgData{[AcqCardText], [AcqCardURL], [AcqCardPhone]}
AcqCardTextТекстовое сообщение, отображаемое владельцу карты
AcqCardURLURL HTML-сообщения, отображаемого владельцу карты
AcqCardPhoneТелефонный номер, предоставляемый владельцу карты
Для AcqCardCode определены следующие значения:
messageOfDayБанк продавца хочет, чтобы это сообщение было передано всем
accountInfoИнформация о счете должна быть передана назад пользователю
сallCustomerServiceПредлагает приложению отобразить сообщение, рекомендующее пользователю обратиться в службу обслуживания клиентов
CapToken предоставляет данные, необходимые расчетному центру для платежной транзакции на фазе авторизации.


Структура данных CapToken представлена в таблице 4.6.2.44. Таблица 4.6.2.44. Структура CapToken
CapToken<Enc(P1, P2, CapTokenData), EncX(P1, P2, CapTokenData, PANToken), {}>
P1 и P2 обозначают платежные центры:P1 - отправителяP2 - получателя В данной версии SET P1 и P2 означают один и тот же расчетный центр (т.е. P1=P2)
CapTokenData{AuthRRPID, AuthAmt, TokenOpaque}
PANTokenСмотри табл. 4.6.2.46
AuthRRPIDRRPID, который появляется в соответствующем AuthReq или AuthRevReq
AuthAmtДействительное число авторизованных, которое может отличаться от PurchAmt владельца карты
TokenOpaqueНевидимые данные, определенные расчетным центром
Алгоритм формирования CapToken показан ниже:
ШагДействие
1Если формируется в ходе авторизации, установить AuthAmt в CapTokenData равным AuthAmt в AuthRes. В противном случае, если генерируется во время повторного авторизационного процесса, занести AuthAmt в CapTokenData равным AuthNewAmt для последующей посылки в AuthRevRes
2Занести в TokenOpaque из CapTokenData частные данные, необходимые для расчетов
3Если продавец получает PANToken из своего банка, тогда:Занести PANToken из PIИспользовать EncX инкапсуляцию с CapTokenData в нормально зашифрованной части и PANToken в дополнительно зашифрованной секцииВ противном случае:Использовать Enc инкапсуляцию с CapTokenData
Обработка CapToken производится следующим образом:
ШагДействие
1Используя секретный ключ расчетного центра, извлечь CapTokenData из упаковки ЕncX или Enc.
2Если это платежный запрос (capture request) и CapToken уже использовался в таком запросе, установить CapCode в CapResPayload равным dublicateRequest.
3Если это аннулирование (reversal) платежного запроса, запрос кредита или отзыв кредита и CapToken ранее не использовался в платежных запросах, установить CapRevOrCredCode в поле CapRevOrCredResPayload равным originalNotFound
4Если это аннулирование платежного запроса, а CapToken уже использовался в подобном запросе, установить CapRevOrCredCode в CapRevOrCredResPayload равным dublicateRequest.
5Если CapCode или CapRevOrCredCode не были установлены при выполнении предыдущих шагов, переадресовать данные из CapToken процессу платежного запроса.
PANData содержит информацию, идентифицирующую определенный счет платежной карты.


Структура данных PANData представлена в таблице 4.6.2.45. Таблица 4.6.2.45. Структура PANData
PANData {PAN, CardExpiry, PANSecret, EXNonce}
PAN Первичный номер счета, обычно номер счета карты
CardExpiryДата действительности карты
PANSecritСекретный код, используемый совместно владельцем карты, расчетным центром и сертификационным центром владельца карты. Предотвращает атаки на PAN в сертификате владельца карты.
EXNonceНовый код (Nonce), который препятствует атаке на PANData
Формирование PANData осуществляется согласно алгоритму, рассмотренному ниже.
ШагДействие
1Занести в PAN номер счета владельца карты
2Записать в CardExpiry дату действительности карты
3Занести PANSecret, который был получен от СА вместе с сертификатом владельца карты. Для владельца карты без сертификата все октеты этого поля устанавливаются равными нулю.
4Сформировать новое значение EXNonce
PANToken подобно PANData содержит информацию, идентифицирующую определенную платежную карту. PANToken используется, когда для сокрытия данных PANSecret не нужен. Структура PANToken показана в таблице 4.6.2.46. Таблица 4.6.2.46. Структура PANToken
PANToken {PAN, CardExpiry, EXNonce}
PANПервичный номер счета, обычно номер счета карты
CardExpiryДата действительности карты
EXNonceНовый код (Nonce), который препятствует атаке на PANData
Формирование PANToken осуществляется достаточно просто:
ШагДействие
1Занести в PAN номер счета владельца карты
2Записать в CardExpiry дату действительности карты
3Сформировать новое значение EXNonce.
Структура SaleDetail SaleDetail соединяет в себе данные, относящиеся к текущей транзакции. Эта структура формируется как часть установления процесса между продавцом и расчетным центром. Для AuthReq, CredReq и CapReq формирование продавцом SaleDetail является опционным. Структура данных в SaleDetail показана в таблице 4.6.2.47. Таблица 4.6.2.47. Структура SaleDetail
SaleDetail{[BatchID],[BatchSequenceNum], [PayRecurInd], [MerOrderNum], [AuthCharInd], [MarketSpecSaleData], [CommercialCardData], [OrderSummery], [CustomerReferenceNumber], [CustomerServicePhone], OktoPrintPhoneInd, [SaleExtensions]}
Это поле может появляться в AuthReq с флагом CaptureNow установленным равным TRUE или в сообщениях, связанных с платежным запросом.
BatchIDИдентификация последовательности операций в системе продавец и его банк
BatchSequenceNumПорядковый номер позиции в данной последовательности расчетных операций.
PayRecurIndНомер типа транзакции
MerOrderNumНомер заказа продавца
AuthCharIndКопируется из AuthResPayload
MarketSpecSaleData{[MarketSpecDataID], [MarketSpecCapData]}
CommercialCardDataОписание позиции в платежном запросе (см. табл. 4.6.2.48)
OrderSummaryКраткое описание заказа
CustomerReferenceNumberНомер ссылки, присвоенный заказу владельца карты
CustomerServicePhoneНомер телефона службы обслуживания клиентов данного продавца
OKtoPrintPhoneIndБулево число, указывающее, может ли эмитент выдавать телефон службы сервиса в ответ на запрос владельца карты.
SaleExtensionsДанные этого расширения должны быть финансовыми и важными для обработки платежного запроса расчетного центра или эмитента
MarketSpecDataIDКопируется из AuthResPayload
MarketSpecCapData<MarketAutoCap, MarketHotelCap, MarketTransportCap>
MarketAutoCapОписание оплаты проката автомобиля (см. табл. 4.6.2.49)
MarketHotelCapОписание оплаты гостиницы (см. табл. 4.6.2.50)
MarketTransportCapДанные о пассажире (см. табл. 4.6.2.51)



PayRecurInd может принимать следующие значения:
unknownТип транзакции неизвестен
singleTransactionТранзакция состоит из одной авторизации и платежного запроса
recurringTransactionТранзакция состоит из нескольких авторизаций и платежных запросов, которые повторяются регулярно
installmentPaymentТранзакция состоит из нескольких авторизаций и заказов-резервирований, которые выполняются фиксированное число раз
otherMailOrderПрочие транзакции заказов по почте
Структура коммерческих данных карты представлена в таблице 4.6.2.48. Таблица 4.6.2.48. Структура коммерческих данных карты
CommercialCardData{[ChargeInfo], [MerchantLocation], [ShipFrom], [ShipTo], [ItemSeq]}
ChargeInfo{[TotalFreightShippingAmount], [TotalDutyTariffAmount], [DutyTariffReference], [TotalNationalTaxAmount], [TotalLocalTaxAmount], [TotalOtherTaxAmount], [TotalTaxAmount], [MerchantTaxID], [MerchantDutyTariffRef], [CustomerDutyTariffRef], [SummaryCommodityCode], [MerchantType]}
MerchantLocationМестоположение продавца
ShipFromАдрес отправки
ShipToАдрес получателя
ItemSeq{Item +}
Номера от 1 до 999
TotalFreightShippingAmountОбщее количество позиций, подлежащих обработке и доставке
TotalDutyTariffAmountПолная сумма налога или тариф для заказа
DutyTariffReferenceКод ссылки, приписанный налогу или тарифу для данного заказа
TotalNationalTaxAmountПолная величина национального налога (с продаж или на добавленную стоимость), распространяющегося на данный заказ
TotalLocalTaxAmountРазмер местного налога, распространяющегося на данный заказ
TotalOtherTaxAmountПрочие налоги, действующие для данного заказа
TotalTaxAmountПолный размер налога для данного заказа
MerchantTaxIDИндивидуальный идентификационный номер продавца
MerchantDutyTariffRefКод налога или тарифа, приписанный продавцу
CustomerDutyTariffRefКод налога или тарифа, приписанный владельцу карты
SummaryCommodityCodeКод товара, приложимый ко всему заказу
MerchantTypeТип продавца
Item{Quantity, [UnitOfMeasureCode], Descriptor, [CommodityCode], [ProductCode], [UnitCost], [NetCost], DiscountInd, [DiscountInd], [NationalTaxAmount], [NationalTaxAmount], [NationalTaxRate], [NationalTaxType], [LocalTaxAmount], [LocalTaxAmount], ItemTotalCost}
QuantityКоличество предметов или услуг данного типа
UnitOfMeasureCodeЕдиницы измерения для данной позиции в заказе
DescriptorОписание позиции в заказе
CommodityCodeКод вида товара для данной позиции заказа
ProductCodeКод продукта для данной позиции заказа
UnitCostЦена единицы товара
NetCostЧистая цена единицы товара
DiscountIndУказывает, распространяется ли скидка на данную позицию в заказе
DiscountAmountВеличина скидки для данной позиции заказа
NationalTaxAmountВеличина национального налога, применимого к данной позиции заказа
NationalTaxRateНациональный налог (с продаж или на добавленную стоимость), применимый к данной позиции заказа
NationalTaxTypeСтавка национального налога, действующая для данной позиции заказа
LocalTaxAmountВеличина местного налога, действующая для данной позиции заказа
OtherTaxAmountВеличина прочих налогов
ItemTotalCostПолная цена данной строки заказа
Структура данных MarketAutoCap представлена в таблице 4.6.2.49. Таблица 4.6.2.49.


Структура MarketAutoCap
MarketAutoCap{[RenterName], [RentalLocation], RentalDateTime, [AutoNoShow], [RentalAgreementNumber], [ReferenceNumber], [InsuranceType], [InsuranceType], [ReturnLocation], ReturnDateTime, AutoCharges}
RenterNameИмя лица, сдающего авто в аренду
RentalLocationАдрес фирмы сдающей авто в аренду
RentalDateTimeДата (опционно время), когда авто было взято в аренду
AutoNoShow Числовой код, указывающий, что клиент не предъявил во время арендованную машину
RentalAgreementNumberНомер арендного соглашения
ReferenceNumberКод аренды
InsuranceTypeТип страховки, выбранный арендатором
AutoRateInfo{AutoApplicableRate, [LateReturnHourlyRate], [LateReturnHourlyRate], [FreeDistance], [VehicleClassCode], [CirporateID]}
ReturnLocationАдрес фирмы, куда следует вернуть авто (см. табл. 4.6.2.51)
ReturnDateTimeДата (опционно время) возвращения автомобиля
AutoCharges{RegularDistanceCharges, [LateReturnCharges], [TotalDistance], [ExtraDistanceCharges], [InsuranceCharges], [FuelCharges], [AutoTowingCharges], [OneWayDropOffCharges], [TelephoneCharges], [ViolationsCharges], [DelivaryCharges], [ParkingCharges], [OtherCharges], [TotalTaxAmount], [AuditAdjustment]}
AutoApplicableRate<DailyRentalRate, WeeklyRentalRate>
LateReturnHourlyRateПочасовая плата за опоздание возврата
DistanceRateПомильная оплата за превышение допустимого пробега
FreeDistanceРасстояние, которое может пройти машина в день, без увеличения арендной платы.
VehicleClassCodeКласс арендуемого автомобиля
CorporateIDКорпоративный идентификационный номер, который применяется для определения арендной платы
RegularDistanceChargesСумма расходов за аренду (исключая расходы, перечисленные ниже)
LateReturnChargesСумма выплаты за возвращения автомобиля после оговоренного срока.
TotalDistanceПолный пробег автомобиля.
ExtraDistanceChargesСумма оплаты избыточного пробега (сверх оговоренного в договоре)
InsuranceChargesСумма страховки
FuelChargesОплата горючего
AutoTowingChargesОплата буксировки
OneWayDropOffChargesОплата одностороннего разрыва арендного договора
TelephoneChargesРасходы использования телефона в арендованной машине
ViolationsChargesСумма штрафов за нарушения за время аренды автомобиля
DelivaryChargesОплата доставки арендованного автомобиля
ParkingChargesОплата парковки арендованного автомобиля
OtherChargesОплата расходов, не определенных в других позициях
TotalTaxAmountСумма налогов, связанная с арендой автомобиля
AuditAdjustmentСумма изменения объема транзакции в результате аудита в компании, предоставляющей автомобили в аренду.
DailyRentalRateДневная арендная плата
WeeklyRentalRateАрендная плата за неделю
Структура данных MarketHotelCap представлена в таблице 4.6.2.50. Таблица 4.6.2.50.


Структура MarketHotelCap
MarketHotelCap{[ArriveDate], [RentalLocation], DepartureDate, [DurationOfStay], [FolioNumber], [PropertyPhone], [CustomerServicePhone], [ProgramCode], [HotelRateInfo], HotelCharges}
ArriveDateДата регистрации владельца карты в отеле
HotelNoShow Цифровой код, указывающий, что клиент не был зарегистрирован в этом отеле своевременно
DepartureDateДата отбытия владельца карты из отеля
DurationOfStayЧисло дней пребывания владельца карты в отеле
FolioNumberНомер книги
PropertyPhoneНомер телефона отеля
CustomerServicePhoneНомер телефона системы обслуживания клиентов отеля или сети отелей
ProgramCodeКод, указывающий тип специальной программы пребывания клиента
HotelRateInfo{DailyRoomRate, [DailyTaxRate]}
HotelCharges{RoomCharges, [RoomTax], [PrepaidExpenses], [FoodBeverageCharges], [RoomServiceCharges], [MiniBarCharges], [LaundryCharges], [TelephoneCharges], [BusinessCenterCharges], [ParkingCharges], [MovieCharges], [HealthClubCharges], [GiftShopCharges], [FolioCashAdvances], [OtherCharges], [TotalTaxAmount ], [AuditAdjustment]}
DailyRoomRateСтоимость проживания в день. В эту сумму входят налоги, если не специфицирована переменная DailyTaxRate.
DailyTaxRateРазмер налога за проживание одного дня в гостинице
RoomChargesПолная стоимость проживания в номере с учетом дополнительных расходов, перечисленных ниже
RoomTaxНалог, взымаемый с суммы RoomCharges
PrepaidExpensesПолный размер предоплаты
FoodBeverageChargesОплата еды и напитков
RoomServiceChargesОплата обслуживания номера
MiniBarChargesОплата пользования минибаром
LaundryChargesОплата услуг прачечной
TelephoneChargesПлата за пользование телефоном
BusinessCenterChargesОплата за услуги бизнес-центра
ParkingChargesОплата парковки
MovieChargesОплата за просмотр фильмов в номере
HealthClubChargesОплата услуг оздоровительного клуба
GiftShopChargesОплата покупок в сувенирном магазине
FolioCashAdvancesСумма, предварительно внесенная за номер
OtherChargesДругие расходы
TotalTaxAmountСумма налогов, включенная в счет
AuditAdjustmentИзменение платежа в результате перепроверки расчетов в отеле
Структура данных MarketTransportCap представлена в таблице 4.6.2.51. Таблица 4.6.2.51.


Структура MarketTransportCap
MarketTransportCap{PassangerName, DepartureDate, OrigCityAirport, [TripLegSeq], [TicketNumber], [TravelAgencyCode], [TravelAgencyName], [Restrictions]}
PassangerNameИмя пассажира, кому выдается билет
DepartureDateДата отбытия
OrigCityAirportГород начала путешествия
TripLegSeq{TripLeg +}
от одной до 10 TripLeg-записей
TicketNumberНомер билета
TravelAgencyCodeКод турагенства
TravelAgencyNameНазвание турагенства
Restrictions Численный код, указывающий на ограничения выплат и расходов
TripLeg{DateOfTravel, CarrierCode, ServiceClass, StopOverCode, DestCityAirport, [FareBasisCode], [DepartureTax]}
DateOfTravelДата путешествия
CarrierCodeКод перевозчика данного тура
ServiceClassКласс услуг тура
StopOverCodeЧисловой код, указывающий на допустимость остановок в пути при совершении тура
DestCityAirportАэропорт места назначения тура
FareBasisCodeКод базовой цены тура
DepartureTaxНалог при отбытии для данного тура
Структура данных, указывающих место (Location), представлена в таблице ниже.
Location{CountryCode, [City], [StateProvince], [PostalCode], [LocationID]}
CountryCodeКод страны ISO 3166
CityНазвание города
StateProvinceНазвание или аббревиатура штата или провинции
PostalCodeПочтовый код
LocationIDИдентификатор, который использует продавец, чтобы специфицировать один из своих адресов
Структура данных RRTags представлена в таблице 4.6.2.52. Таблица 4.6.2.52. Структура RRTags
RRTags{ RRPID, MerTermIDs, Date}
RRPIDНовый идентификатор пары запрос/отклик
MerTermIDs{MerTermIDs, [TerminalID], [AgentNum], [ChainNum], [StoreNum]}
DateТекущая дата для устаревающих записей
MerchantIDВладелец карты заносит эти данные в PIHead. Этот код копируется из MerID в сертификат подписи продавца.
TerminalIDПродавец вводит эти данные в AuthReq.
AgentNumПродавец вводит эти данные в AuthReq.
ChainNumПродавец вводит эти данные в AuthReq.
StoreNumПродавец вводит эти данные в AuthReq.
Формирование RRTags производится следующим образом
ШагДействие
1Формируется новый RRPID и запоминается в базе данных транзакции.
2Заносятся MerTermIDs из записанных данных продавца, описывающих место продажи.
3Записывается текущая дата в поле Date.
Целью BatchStatus является предоставление данных о состоянии платежной линии между расчетным центром и продавцом или для согласования объемов платежей продавца в расчетный центр.


Структура данных BatchStatus представлена в таблице 4.6.2.53. Таблица 4.6.2.53. Структура BatchStatus
BatchStatus{OpenDateTime, [ClosedWhen], BatchDetails, [BatchExtensions]}
OpenDateTimeДата и время открытия платежной линии
ClosedWhen{CloseStatus, CloseDateTime}
BatchDetails{CloseDateTime, [BrandBatchDetailsSeq]}
BatchExtensionsДанные в расширении для сообщения управления платежами должны носить финансовый характер и быть существенными для обработки административного запроса
CloseStatusЦифровой код, указывающий статус закрытия платежной линии
CloseDateTimeДата и время закрытия платежной линии
BatchTotals{TransactionCountCredit, TransactionTotalAmtCredit, TransactionCountDebit, TransactionTotalAmtDebit, [BatchTotalExtensions]}
BrandBatchDetailsSeq{BrandBatchDetails +}
TransactionCountCreditЧисло транзакций, которые внесли вклад в кредит продавца.
TransactionTotalAmtCreditПолная сумма, внесенная на счет продавца
TransactionCountDebitЧисло транзакций, которые внесли вклад в дебет продавца
TransactionTotalAmtDebitПолная сумма, снятая со счета продавца
BatchTotalExtensionsДанные расширения отклика управления платежами должны носить финансовый характер и быть существенными для обработки административного запроса.Информация, относящаяся к обработке запроса, должна появляться в расширении BatchAdminResData. Информация, имеющая отношение к состоянию платежной линии, должна лежать в расширении BatchStatus. Информация, относящаяся к деталям по конкретной позиции заказа, присутствует в расширении TransactionDetail.
BrandBatchDetails{BrandID, BatchTotals}
BrandIDТип платежной системы карты без типа продукта
Структура TransactionDetail служит для предоставления детальной информации о платежной линии между расчетным центром и продавцом. Формат этой структуры описан в таблице 4.6.2.54. Таблица 4.6.2.54. Структура TransactionDetail
TransactionDetail{TransIDs, AuthRRPID, BrandID, BatchSequenceNum, [ReimbursementID], TransactionAmt, TransactionAmtType, [TransactionStatus], [TransExtensions]}
TransIDsИдентификаторы транзакций обработки авторизации/оплаты для заданной позиции
AuthRRPIDRRPID, который присутствует в соответствующих AuthReq или AuthRevReq
BrandIDПлатежная система карты (без типа продукта)
BatchSequenceNumПорядковый номер позиции в пакете платежей
ReimbursmentIDЦифровой код, указывающий на тип оплаты для заданной позиции
TransactionAmtСумма для позиции, тип которой указан в TransactionAmtType. Сумма всегда обозначается положительным числом.
TransactionAmtTypeЦифровой код, указывающий тип суммы (кредит или дебет)
TransactionStatusЦифровой код, индицирующий результат прохождения транзакции для вышестоящей системы
TransExtensionsДанные в расширении для административного отклика последовательности платежей (batch) должны иметь финансовый характер и использоваться при обработке административного запроса для заданной последовательности платежей.
Информация, имеющая отношение к обработке запроса должна размещаться в расширении BatchAdminResData.



Суммы в платежных сообщениях SET характеризуются тремя полями: валюта, сумма и amtExp10. Эти поля содержат ASCII-строки, формат которых охарактеризован в таблице ниже.
ПолеОпределение
currency (валюта)Значение представляется в виде строки ASCII-символов, характеризующей три цифры кода валюты (ISO 4217) Например, платеж в долларах США будет обозначен кодом 840. Возможные значения лежат в диапазоне 1-999 включительно.
amount (cумма)Значение представляется в виде строки ASCII-символов, характеризующей сумму платежа в указанной валюте. Значение должно соответствовать положительному числу.
amtExp10Значение представляется в виде строки ASCII-символов, характеризующей десятичный показатель степени:cумма * (10amtExp10). Значение может быть как положительным, так и отрицательным.
Для того чтобы представить сумму US $2.87 в поле PurchAmt, в поля currency, amount и amtExp10 заносятся коды 840, 250 и -2. Поля Date Даты в SET обычно указываются в форме строк, характеризующих календарную дату и время UTC в формате: YYYYMMDDHHMM[SS[.f]f]f]]]Z где Z литерал буквы Z в верхнем регистре. Таким образом, строка должна состоять из четырех цифр, характеризующих год, по две цифры, определяющие месяц, день, час (24-часовое представление) и минуту. После минут опционно могут присутствовать две цифры секунд. Если поле секунд присутствует, далее могут опционно быть прописаны доли секунды. Запись может иметь, например, форму: 20011003102853.33Z, что означает 2001 год, 03 октября, 10 часов 28 минут 53,33 секунды. Полночь отмечается датой, следующего дня. Поток платежных сообщений Основу потока платежных сообщений SET составляют пары запрос/отклик, следующие между владельцем карты и продавцом, а также между продавцом и расчетным центром. Основу обмена между владельцем карты и продавцом составляют сообщения PReq/PRes. Сообщение PRes может быть прислано немедленно или спустя некоторое время. Присылаемая информация зависит от фазы реализации протокола, в которой находится система. Авторизация продавца в расчетном центре выполняется с помощью сообщений AuthReq/AuthRes. На рис. 4.6.2.14 показан типичный пример обмена сообщениями при реализации протокола покупки.
Рис. 4.6.2.14.


Диаграмма обмена для протокола покупки На рис. 4.6.2.15 показаны все возможные сообщения, которые могут иметь место при обработке транзакции (опционные сообщения отмечены курсивом). Следует заметить, что приведенный порядок обмена является рекомендуемым, и допускается его изменение.
Рис. 4.6.2.15. Опции обмена сообщениями при покупке
Рис. 4.6.2.15а. (продолжение) Пары сообщений InqReq/InqRes позволяют владельцу карты получать информацию о состоянии транзакции. Запрос InqReq может быть послан в любое время после посылке продавцу PReq. В паре сообщений PReq/PRes владелец карты уведомляет продавца о том, что же он хочет купить. Сообщения AuthRevReq и AuthRevRes используются тогда, когда необходимо возобновить авторизацию. Сообщения CapRevReq и CAPRevRes организуют процесс отмены оплаты покупки, прежде чем сделка будет завершена. Пара CredReq и CredRes сходна с предыдущей парой, но используется после завершения сделки. Сообщения PCertReq/PCertRes обеспечивают для продавца механизм получения сертификата шифрования, который необходим для шифрования сообщения расчетному центру. BatchAdminReq и BatchAdminRes служат продавцу для открытия, закрытия и выяснения статуса транзакции его платежной линии с расчетным центром. Сообщения Error служат для уведомления об ошибках в протоколе или при обработке. Обработка запросов/откликов инициализации платежа Процедура инициализации платежа включает в себя обмен двумя сообщениями. Первоначальный запрос PInitReq посылает владелец карты, отклик PInitRes ему присылает продавец. Задачей этого обмена является получение владельцем карты сертификатов и CRL. Без такого обмена данная информация может быть получена и каким-то другим образом, например с CD-ROM. Эти сообщения посылаются после инициализации процесса SET. Сообщение-запрос PInitReq идентифицирует платежную систему карты (Brand), предоставляет локальный идентификатор владельца карты для данной транзакции, посылает переменную вызова для определения пригодности (свежести) сообщения-отклика.


В этом сообщении передается также набор оттисков, который идентифицирует соответствующие сертификаты и CRL, уже имеющиеся у владельца карты, чтобы их не нужно было посылать еще раз. Сообщение-отклик PInitRes содержит запрошенные данные, включая сертификаты и CRL. Присылается продавцом также дата, XID и вызов владельца карты, добавляется, кроме того, и вызов продавца. Алгоритм формирования владельцем карты сообщения PInitReq приведен в таблице ниже.
ШагДействие
1Сформировать RRPID для идентификации сообщения и установления соответствия между запросом и откликом
2Занести в поле Language, значение которое выбрал владелец карты для данной транзакции
3Сформировать идентификатор LID-C, который является идентификатором пары сообщений, так как XID еще не присвоен. Этому полю могут присваиваться числа натурального ряда или случайные коды.
4Если продавец при инициации SET-процесса предоставил код LID-M, скопировать его в сообщение.
5Сформировать новый код Chall-C
6На основе выбранной формы платежа заполнить BrandID (из программы-магазина или из программы инициализации SET).
7Заполнить поле BIN (первые 6 цифр номера счета владельца карты)
8Опционно. Заполнить оттиски для сертификатов, CRL и BrandCRLIdentifier, имеющиеся у владельца карты. Сюда должен входить корневой сертификат.
9Записать в базу данных транзакций RRPID, LID-C, LID-M (если имеется), Chall-C и оттиски (если имеются).
10Опционно. Заполнить любые расширения PInitReq.
11Занести все это в цифровой конверт и послать продавцу
Сообщение PInitReq, задавая естественный язык владельца карты, определяет ID и контекст транзакции, а также спецификацию платежной системы. Кроме того, предоставляются оттиски, где записаны сертификаты и криптографические вызовы, гарантирующие новизну отклика. Структура PInitReq представлена в таблице 4.6.2.55. Таблица 4.6.2.55. Структура PInitReq
PInitReq{ RRPID, Language, LID-C, [LID-M], Chall-C, BrandID, BIN, [Thumbs], [PIRqExtensions]}
RRPIDИдентификатор пары запрос/отклик
LanguageЕстественный язык владельца карты
LID-CЛокальный ID. Метка, формируемая системой владельца карты или для нее.
LID-MКопируется из сообщения инициации SET (если имеется)
Chall-CВызов владельца карты, служащий для гарантии новизны подписи продавца
BrandIDВыбранная владельцем карты платежная система
BINНомер идентификации банка из номера счета владельца карты (первые 6 цифр)
ThumbsОттиски списка сертификатов, CRL и BrandCRLIdentifier из кэша владельца карты
PIRqExtensionsЗапрос инициализации покупки незашифрован, по этой причине эти расширения не должны содержать конфиденциальных данных.



Алгоритм обработки PInitReq продавцом представлен ниже.
ШагДействие
1Извлечь запрос из входного сообщения
2Если LID-M присутствует, найти запись транзакции, базирующуюся на LID-M. Если запись не найдена:Прислать сообщение Error c ErrorCode равным unknownLIDПрервать обработку PInitReq
3Если LID-M отсутствует, найти запись транзакции, на основе критериев, выходящим за пределы регламентаций SET. Если продавец не сформировал LID-M для этой транзакции, опционно сгенерировать LID-M и занести его в запись транзакции.
4Сформировать новый XID
5Занести XID, RRPID, Language, LID-C, Chall-C, BrandID и BIN в запись транзакции
6Если оттиски присутствуют, произвести спасение записи транзакции
7Если имеется какое-либо расширение PInitReq, произвести его обработку. Если расширение не распознано и флаг критичности равен TRUE, сформировать сообщение Error, в противном случае игнорировать расширение. Если расширение распознано, его следует обработать.
Формирование продавцом отклика PInitRes осуществляется следующим образом.
ШагДействие
1Сформировать структуру данных PInitRes следующим образом:Сгенерировать TransID согласно следующей процедуре:Скопировать LID-C, XID и Language из записи транзакцииЕсли запись транзакции содержит LID-M, скопировать егоЗанести текущую дату в TransIDs.PReqDateСкопировать RRPID из записи транзакцииСкопировать Chall-C из записи транзакцииСформировать новый Chall-MЕсли оттиск для текущего BrandCRLIdentifier не получен или устарел, занести новый BrandCRLIdentifierНа основе информации из PInitReq (BrandID, BIN и сертификат владельца карты) выбрать расчетный центр. Записать в PEThumb оттиск сертификата выбранного расчетного центра.Скопировать оттиски из PInitReq, если он имеется. Это позволяет владельцу карты проверить, что продавцу корректно доставлены ве посланные оттиски.Опционно: добавить любые PIRqExtensions
2Ввести Compose SignedData. Если оттиск для Cert-PE не получен в PInitReq, включить в подпись Cert-PE.
3Вставить все эти данные в цифровой конверт и послать владельцу карты
Информационная структура PInitRes представлена ниже в таблице 4.6.2.56. Таблица 4.6.2.56.


Структура PInitRes
PInitResS(M, PInitResData)
PInitResData{TransIDs, RRPID, Chall-C, Chall-M, [BrandCRLIdentifier], PEThumb, [Thumbs], [PIRsExtensions]}
TransIDsСмотри описание структуры TransID выше
RRPIDИдентификатор пары запрос/отклик
Chall-CКопируется из сообщения PInitReq
Chall-M Вызов продавца, служащий для проверки новизны подписи владельца карты
BrandCRLIdentifierСписок текущих CRL для всех СА в рамках заданной платежной системы.
PEThumbОттиск сертификата ключевого обмена расчетного центра.
ThumbsКопируется из PInitReq
PIRsExtensionsЗапрос инициализации покупки незашифрован, по этой причине эти расширения не должны содержать конфиденциальных данных.
При получении владельцем карты сообщения PInitRes он обрабатывает его следующим образом.
ШагДействие
1Извлечь PInitRes из входного сообщения
2Вызвать Receive SignedData
3Проверить TransID следующим образом:Осуществить поиск транзакции с использованием LID-C. Если поиск безуспешен:Послать сообщения Error с ErrorCode равным unknownLIDОстановить обработку PInitResЕсли LID-M был послан во время инициализационного процесса SET, сравнить LID-M с LID-M в записи транзакции. Если они неэквивалентны, то:Послать сообщение Error с ErrorCode равным unknownLIDОстановить обработку PInitResс) Если LID-M не был послан и имеется LID-M, то:Послать сообщение Error с ErrorCode равным unknownLIDОстановить обработку PInitRes
4Сравнить RRPID со значением из записи транзакции. Если они отличаются, то:Послать сообщение Error с ErrorCode равным unknownRRPIDОстановить обработку PInitRes
5Сравнить Сhall-C со значением из записи транзакции. Если они отличаются, то:Послать сообщение Error с ErrorCode равным challengeMismatch.Остановить обработку PInitRes
6В опционном варианте управления со стороны владельца карты из сертификата продавца извлекается его имя и отображается для пользователя. Если владелец карты одобряет кандидатуру, процесс продолжается, в противном случае обработка PInitRes прерывается.
7Занести данные, включая TransID и Chall-M, в запись транзакции
8Обработать BrandCRLIdentifier, если он присутствует.
9Использовать PEThumb для идентификации сертификата шифрования (Cert-PE), чтобы использовать в PReq при шифровании данных для расчетного центра.
10Проверить, что сертификат платежной системы продавца и сертификат расчетного центра (Cert-PE) согласуются с платежной системой владельца карты, указанной в PInitReq. Если согласия нет, владелец карты оповещается об этом, а обработка PInitReq прерывается.
11Если поле Thubs присутствует, сравнить его значение с тем, что прислано в PInitReq. Если значения совпадают, перейти к исполнению пункта 14, в противном случае:Послать сообщение Error с ErrorCode равным thumbsMismatchОстановить обработку PInitRes
12Если поле Thumbs отсутствует, проверить, что Thumbs не было послано в PInitReq. Если Thumbs было послано в PInitReq, о:Послать сообщение Error с ErrorCode равным thumbsMismatchОстановить обработку PInitRes
13Если PIRsExtensions существуют, их необходимо обработать. Если они не распознаны, а флаг критичности (criticality) равен TRUE, сформировать сообщение Error, в противном случае расширения следует игнорировать.
14Проверить Cert-PE (идентифицированный в PEThumb) для неподписанных транзакций. Если индикатор в Cert-PE не допускает неподписанных транзакций, а владелец карты не имеет сертификата, информировать его о том, что транзакция не может быть продолжена и прервать обработку.
15Владелец карты может теперь продолжить процедуру посылкой запроса покупки.



Запросы инициализации покупки (PInitReq) несут в себе достаточно информации о владельце карты для программы продавца, чтобы выбрать сертификат платежного центра. Следует имеь в виду, что эти запросы не шифруются и соответствующие расширения не должны нести в себе конфиденциальной информации. Отклик на запрос инициализации (PInitRes) содержит копии данных из запроса PInitReq, а также сертификаты продавца и расчетного центра. Отклик подписывается продавцом, что позволяет владельцу карты быть уверенным в том, что посланная им в запросе информация дошла до продавца неискаженной (за счет просмотра копий). Отклик PInitRes также не шифруется. Обработка заказа-покупки Обмен запрос-отклик (PReq/PRes) представляет собой реализацию покупки, выполняемой владельцем карты у продавца. Данные сообщения составляют ядро протокола купли-продажи. На долю владельца карты выпадает функция платежа. Реализация запроса покупки проходит через 5 этапов (см. рис. 4.6.2.16).
Рис. 4.6.2.16. Обработка запроса покупки Прежде чем послать запрос покупки покупатель (владелец карты) должен заполнить форму заказа, одобрить условия сделки и выбрать платежную карту. Для того чтобы послать запрос продавцу, владелец карты должен иметь копию ключей расчетного центра. Обработка заказа начинается, когда программа владельца карты запрашивает копию сертификата расчетного центра. В этом сообщении содержится информация о выборе платежной системы. Когда продавец получает запрос, он присваивает транзакции уникальный идентификатор. После этого продавец пересылает свой сертификат и сертификат расчетного центра вместе с этим идентификатором владельцу карты. Программа владельца карты верифицирует полученные сертификаты и запоминает их для использования в последующей обработке заказов. Приложение владельца карты формирует данные заказа OI (Order Information) и платежные инструкции PI. OI и PI снабжаются идентификатором транзакции, для того чтобы расчетный центр мог связать их вместе при авторизации запроса продавца.


Заметим, что OI не содержит таких данных как описание товара или условий поставки. Эта информация получается на фазе сделки, предшествующей операциям SET (например, в рамках протокола IOTP). Программное обеспечение владельца карты генерирует двойную цифровую подпись для OI и PI путем вычисления дайджеста для обоих модулей данных, объединения этих дайджестов, вычисления дайджеста результата и осуществления подписи этого сообщения с привнием секретного ключа владельца карты. Дайджесты OI и PI посылаются вместе с этим сообщением. Далее программа формирует симметричный ключ и использует его для шифрования дважды подписанных PI. Затем программа шифрует номер счета владельца карты и симметричный ключ с привлечением общедоступного ключа расчетного центра. Результат составляет цифровой конверт сообщения, которое передается продавцу. Когда программа продавца получает заказ, она верифицирует сертификат подписи владельца карты, используя общедоступный ключ владельца карты и дайджест PI (заключенный в OI), проверяет цифровую подпись, чтобы убедиться в не искаженности заказа и в том, что сообщение подписано секретным ключом владельца карты. Заметим, что продавцу не обязательно выполнять авторизацию до посылки отклика владельцу карты. Последний может позднее определить, была ли выполнена авторизация, послав информационный статусный запрос. После обработки OI продавец генерирует отклик и снабжает его цифровой подписью. Этот отклик содержит в себе сертификат подписи продавца и указывает на факт получения заказа от владельца карты. Если отклик авторизации указывает на одобрение транзакции, продавец поставляет товар или услугу, указанные в заказе. Когда приложение владельца карты получает отклик на запрос покупки от продавца, сначала верифицируется сертификат подписи. Далее проверяется цифровая подпись продавца. При благоприятном исходе этих проверок выдается соответствующее сообщение и производится запись в базу данных. Состояние выполнения заказа владелец карты может выяснить путем посылки информационных статусных запросов. Сообщение PReq не обязательно следует за сообщениями PInitReq/PInitRes.


Сообщение же PRes может быть прислано до выполнения авторизации и оплаты. Если владелец карты обладает сертификатом, то для обеспечения целосности и аутентичности сообщения выполняется двойная подпись. PReq представляет собой наиболее сложное сообщение в протоколе. Оно состоит из двух частей: инструкции-заказа OI (Order Instruction) для продавца и платежной инструкции PI (Payment Instruction), которая проходит транзитом через продавца в расчетный центр. Эти две части принципиально должны подписываться независимо. Продавец получает описание заказа OD (Order Description) и PurchAmt. В PI включаются хэши OD и PurchAmt (HODINput). Расчетный центр проверяет, что хэш передан покупателем (владельцем карты) через продавца и равен хэшу, выданному продавцом в AuthReq. Некоторые владельцы карт могут не иметь сертификатов. Сообщения от таких владельцев не будут подписаны, вместо этого PIHead связывается с OIData. Целостность таких сообщений обеспечивается следующими мерами: C PI используется OAEPВ блок OAEP включается H(PIHead) (вместе с PANData)С PIHead используется H(OIData)Расчетным центром производится сравнение H(OIData), присланного продавцом, с H(OIData) из PIHead. Владелец карты формирует сообщение PReq следующим образом (эти действия предпринимаются как для PReqUnsigned так и для PreqDualSigned).
ШагДействие
1Извлечь PurchAmt и OD
2Сформировать OIData следующим образом:
a)Если имел место обмен PInitReq/ PInitRes:Скопировать TransIDs из PInitRes
В противном случае:Для формирования TransIDs владелец карты сгенерирует PreqDate (текущие дата/время), LID-C и XID
b)Сформировать новый RRPID, запомнить его значение для сверки с откликом продавца
Если имел место обмен PInitReq/PInitRes:Скопировать Chall-c из PInitRes
В противном случае:Сформировать новый Chall-C
c)Сформировать новый ODSalt
d)Сформировать HODInput посредством следующей процедуры: Скопировать OD из данных процесса инициализации SETЗаписать PurchAmt cо значением, одобренным владельцем карты на фазе инициации SET.Скопировать ODSalt из пункта 2 с)Если владелец карты намерен выполнить инсталляцию или последовательные платежи, то записать InstallRecurDataОпционно: добавить любые ODExtensions
e)Сформировать HOD с HODInput из пункта 2 d
f)Если имел место обмен PInitReq/ PInitRes:Скопировать Chall-M из PInitRes и не заполнять BrandID
В противном случае:Не заполнять Chall-M
Записать BrandID, указав предпочтительный тип карты
g)Произвести записьв поле BIN с HODInput из пункта 2d
h)Если HODInput из шага 2.d имеет какие-то расширения OIExtensions, внести ODExtOIDs со всеми OID в ODExtensions. ODExtOIDs будут перечислены в том же порядке, что и расширения ODExtensions, таким образом продавец сможет вычислить тот же самый хэш
i)Опционно: добавить любые расширения OIExtensions.
3Сформировать PIHead следующим образом:
a)Скопировать TransIDs, вычисленные в пункте 2.а
b)Сгенерировать Inputs согласно процедуре:
Скопировать HOD из пункта 2.еСкопировать PurchAmt из шага 2.d.2
c)Скопировать MerchandID из сертификата продавца в PInitRes, или из CD-ROM-каталога
d)Скопировать InstallRecurData из пункта 2.d.4 (если имеется)
e)Сформировать TransStain, как HMAC, используя XID в качестве данных и CardSecret - в качестве ключа. Если владелец карты не имеет сертификата, использовать CardSecret, заполненный нулями.
f)Записать SWIdent, который получен из локальных данных. Это значение будет соответствовать коду в цифровом конверте сообщения
g)Если присутствует туннельное расширение Cert_PE, сформировать AcqBackInfo следующим образом:
Найти туннельное расширение для алгоритма шифрования, приемлемое для владельца карты. Если такое найдено, заполнить AcqBackAlg, в противном случае, не формировать AcqBackInfo и перейти к пункту f.Сформировать новый AcqBackKey (приемлемый для AcqBackAlg)
h)Опционно добавить любые PIExtensions
4Сформировать PANData
5Сгенерировать PU-OIData c L-оператором, используя PIHead из пункта 3 (параметр t1) и OIData из пункта 2 (параметр t2)
6Используя результат пунктов 2, 3 и 4, сгенерировать PreqDualSigned, если владелец карты имеет сертификат или PreqUnsigned, если сертификата нет.



Когда расчетный центр готов шифровать данные для конечного пользователя (ЕЕ), его сертификат содержит список симметричных алгоритмов шифрования, которые он поддерживает, в порядке их предпочтения. Конечный пользователь, который хочет иметь шифрованные данные, выбирает первый алгоритм из списка, который он способен использовать. Ключ для этого алгоритма передается расчетному центру в сообщении PReq. Реализация PReqDualSigned рассмотрена ниже.
ШагДействие
1Сформировать PISignature:Сформировать PI-TBS:Сгенерировать HPIData в виде дайджеста PIDataСгенерировать HOIData в виде дайджеста OIDataВыполнить PISinature c оператором S0, используя сертификат владельца карты (параметр s) и PI-TBS (параметр t).
2Применить оператор EX, используя общедоступный ключ расчетного центра (параметр r), PI-OILink от владельца карты создает PReq шаг 5 (параметр t), а PANData от владельца карты создает PReq шаг 4 (параметр p)
3Образовать PIDualSigned как объединение подписи PISignature, вычисленной в пункте 1, и шифрованных данных, полученных на шаге 2.
4Генерируем PIData как объединение HIHead из PReq владельца карты, (см. пункт 3 предшествующей таблицы), и PANData владельца карты, которая создается в пункте 4 при формировании PReq (см. предшеств. табл.).
5Генерируем OIDualSigned, посредством оператора L, используя OIData от владельца карты, создаем PReq - пункт 2 (параметр t1) и данные PIData, полученные в пункте 4 (параметр t2)
6Генерируем PReqDualSigned как объединение PIDualSigned из пункта 3 и OIDualSigned из пункта 5.
Сообщение запроса покупки PReq содержит инструкцию заказа OI для продавца и платежную инструкцию для передачи транзитом в зашифрованном виде через продавца в расчетный центр. Аутентичность и целостность сообщений достигается за счет использования двойной подписи, если владелец карты имеет сертификат (PReqDualSigned). Если владелец карты не имеет сертификата, для тех же целей применяются хэши в ОАЕР-конверте (PReqUnsigned). Структура данных в случае PreqDualSigned показана в таблице 4.6.2.57. Таблица 4.6.2.57. Структура PReqDualSigned
PReqDualSigned{PIDualSigned, OIDualSigned}
PIDualSignedСмотри описание PI (выше)
OIDualSignedL(OIDualSigned, PIData)
OIDataСмотри табл. 4.6.2.59
PIData{PIHead, PANData}
Структура данных в случае PReqUnsigned показана в таблице 4.6.2.58. Таблица 4.6.2.58.


Структура PReqUnsigned
PReqUnsigned{PIUnsigned, OIUnsigned}
PIUnsignedСмотри описание PI (выше)
OIUnsignedL(OIData, PIDataUnsigned)
OIDataСмотри табл. 4.6.2.59
PIDataUnsigned{PIHead, PANToken} (см. табл. 4.6.2.40 и 4.6.2.45)
Структура данных сообщения PReq для PReqDualSigned и PreqUnsigned показана в таблице 4.6.2.59. Таблица 4.6.2.59. Структура PReq для PReqDualSigned и PreqUnsigned
OIData{TransIDs, RRPID, Chall-C, HOD, ODSalt, [Chall-M], BrandID, BIN, [ODExtOIDs], [OIExtensions]}
TransIDsКопируется из PInitRes, если имеется
RRPIDID пары запрос/отклик
Chall-CКопируется из соответствующего PInitReq (см. табл. 4.6.2.55)
HODDD(HODInput)Связывает OIData с PurchAmt без копирования PurchAmt в OIData, что может привести к проблемам с конфиденциальностью
ODSaltКопируется из HODInput
Chall-MВызов продавца владельцу карты относительно свежести подписи
BrandIDВыбранная владельцем карты платежная система
BINИдентификационный номер банка из номера счета владельца карты (первые 6 цифр)
ODExtOIDsСписок объектных идентификаторов из ODExtensions
OIExtensionsДанные в расширении к OI должны относиться к обработке заказа продавцом. Информация заказа незашифрованна, по этой причине здесь не должно быть конфиденциальной информации.
HODInput{OD, PurchAmt, PurchAmt, [InstallRecurData], [ODExtensions]}
ODОписание заказа (Order Description). Обмен этой информацией происходит между владельцем карты и продавцом (не регламентируется SET). Здесь могут содержаться данные о качестве товара, размере, цене, адресе поставки и т.д.
PurchAmtЧисло транзакций, как это определено владельцем карты. Значение должно соответствовать PIHead (табл. 4.6.2.40).
ODSaltНовое значение Nonce, сгенерированное владельцем карты, чтобы препятствовать атакам на HOD.
InstallRecurDataСм. табл. 4.6.2.41
ODExtensionsДанные в этом расширении OD должны относиться к обработке заказа продавцом. Эта информация должна быть известна независимо владельцу карты и продавцу.
При получении PReq продавец производит следующие действия.
ШагДействие
1Извлекает PReq из входного сообщения
2Если получено PReqDualSigned, производит проверку подписи;Извлекает OIData и HPData из OIDualsignedФормирует HOIData в виде дайджеста OIDataФормирует PI-TBS в виде объединения HPOData из пункта А и HOIData из пункта В.Генерирует подпись с помощью оператора SO, используя сертификат владельца карты (параметр s) и PI-TBS из пункта С (параметр t).Сравнивает подпись из пункта D с PISignature. Если они не тождественны, послает сообщение Error c ErrorCode равным signatureFailure и останавливает обработку PReq.Переходит к выполнению пункта 4.
3Если получено PReqUnsigned, проверяет, что сертификат платежной системы (Cert-PE) допускает PReqUnsigned. Если нет, то:Возвращает сообщение PRes c CompletionCode=signatureDequired (необходима подпись)Останавливает обработку PReq
4Производит обработку TransIDs:
Проводит поиск транзакций, базирующихся на XID.
Если запись такой транзакции найдена
Сравнивает LID-C и LID-M с записью. Если соответствия нет:Возвращает сообщение Error c ErrorCode = unknownLIDОстанавливает обработку PReqВ противном случае сверяет Chall-M с записью. Если соответствия нет, то:Присылает сообщение Error c ErrorCode = challengeMismatchОстанавливает обработку PReqВ противном случаеФормирует новую запись транзакцииСпасает LID-C, PReqDate и LanguageОпционно формирует LID-M 
5Проверяет, что BrandID в сертификате владельца карты соответствует BrandID в PInitReq и/или OIData. Если соответствия нет, то:Присылает сообщение PRes c completionCode = orderRejected (заказ отклонен)Останавливает обработку PReq
6Запоминает Chall-C, чтобы вернуть его в последующем PRes
7Запоминает оставшиеся переменные из сообщения в базе данных
8Сверяет HOD c сформированным хэшем OD, PurchAmt, ODSalt, InstallRecurData (если имеется) и ODExtensions (если имеется)
9Начиная с этого момента, продавец может, если захочет, послать PRes владельцу карты, или ждать пока от расчетного центра не будет получено сообщение AuthRes



После обработки PReq продавец формирует отклик PRes согласно следующему алгоритму:
ШагДействие
1Сформировать PResData:Заполнить поле TransIDs. Включить сюда все поля TransIDs, полученные от владельца карты или расчетного центраСкопировать RRPID из PReq (или из InqReq)Скопировать Chall-C из PReq (или из InqReq)Если для текущего BrandCRLIdentifier не получены оттиски (или они устарели), заполнить поле текущим значением BrandCRLIdentifierСформировать PresPayloadSeq:Если запрос покупки включает в себя PurchAmt = 0, сформировать единичный PresPayload c CompletionCode = meaninglessRatio и с пустыми остальными полями. Перейти к пункту 2.Если расчетный центр отклонил заказ, сформировать PresPayload:Установить CompletionCode = orderRejectСкопировать AcqCardMsg из AuthRes, если имеется.Перейти к пункту 2Если расчетный центр еще не посылал отклик на запрос авторизации продавца, сгенерировать PresPayload c CompletionCode = orderReceived и пустыми прочими полями. Перейти к пункту 2.Если это отклик на запрос InqReq, где транзакция не была найдена, сформировать PresPayload c CompletionCode = orderNotReceived и пустыми прочими полями. Перейти к пункту 2.Если расчетный центр откликнулся на запрос авторизации продавца, сформировать PresPayloadSeq, как это описано ниже
2Ввести Compose SignedData
3Вставить сообщение в цифровой конверт и послать владельцу карты
Для каждой авторизации, которую провел продавец и которая не отменена, формируется PresPayload:
ШагДействие
1Если выполнена только авторизация:Установить CompletionCode = authorizationPerformedСформировать Results, как это описано ниже, опуская CapStatus и CredStatusSeq.
2Если оплата (capture) выполнена:Установить CompletionCode = capturePerformedСформировать Results, как это описано ниже, опуская CredStatusSeq
3Если кредитование осуществлено;Установить CompletionCode = creditPerformedСформировать Results, как это описано ниже
4Опционно добавить любые PRsExtensions
Формирование поля Results производится согласно следующему алгоритму:
ШагДействие
1Скопировать AcqCardMsg из AuthRes, если этот отклик имеется
2Если позиция авторизована, сформировать AuthStatus:Скопировать AuthDate из записи транзакцииСкопировать AuthCode из записи транзакцииВычислить AuthRatio, как AuthReqAmt ч PurchAmtЕсли в AuthRes присутствуют данные о конвертации валюты, скопировать их
3Если позиция оплачена, сформировать CapStatus:Скопировать CapDate из записи транзакцииСкопировать CapCode из записи транзакцииВычислить CapRatio, как CapReqAmt ч PurchAmt
4Сформировать CredStatusSeq как последовательность CredStatus для каждой выполненной и не отмененной кредитной операции. Сформировать CredStatus:Скопировать CreditDate из записи транзакцииСкопировать CreditCode из записи транзакцииВычислить CreditRatio, как CapRevOrCredReqAmt ё PurchAmt



Структура данных сообщения PRes, формируемого продавцом, представлена в таблице 4.6.2.60. Таблица 4.6.2.60. Структура PRes, формируемая продавцом
PResS(M, PresData)
PResData{TransIDs, RRPID, Chall-C, [BrandCRLIdentifier], PresPayloadSeq}
TransIDsКопируется из PReq
RRPIDИдентификатор пары запрос/отклик
Chall-CКопируется из соответствующего PInitReq
BrandCRLIdentifierСписок текущих CRL для всех СА в зоне ответственности СА платежной системы
PResPayloadSeq{PresPayload +}
Одна запись для каждой выполненной авторизации. Отмена авторизации удаляет запись из PResPayload. Если не было авторизаций, появляется одна позиция с соответствующей статусной записью
PResPayloadСм. табл. 4.6.2.61
Структура данных PResPayload представлена в таблице 4.6.2.61 Таблица 4.6.2.61. Структура PResPayload
PResPayload{CompletionCode, [Results], [PrsExtensions]}
CompletionCodeЦифровой код, указывающий на состояние завершения транзакции
Results{[AcqCardMsg], [AuthStatus], [AuthStatus], [CredStatusSeq]}
PRsExtensionsОтклик на запрос покупки не зашифрован и по этой причине не должен содержать конфиденциальную информацию
AcqCardMsgКопируется из AuthRes (см. табл. 4.6.2.43)
AuthStatus{AuthDate, AuthCode, AuthRatio, [CurrConv]}
CapStatus{CapData, CapCode, CapRatio}
Данные присутствуют здесь, только если CapReq соответствует выполненной авторизации. Сообщение CredRevReq удаляет эти данные.
CredStatusSeq{CredStatus +}
Данные присутствуют, только если CredReq соответствует выполненной авторизации. Сообщение CredRevReq удаляет эти данные.
AuthDateДанные авторизации. Копируются из AuthRRTags.Date (см. табл. 4.6.2.64)
AuthCodeЦифровой код, указывающий на состояние авторизационного процесса. Копируется из AuthResPayload.
AuthRatioAuthReqAmt ч PurchAmt
CurrConv{CurrConvRate, CardCurr}
Информация о конвертировании валюты, копируется из AuthResPayload
CapDataДата оплаты, копируется из CapPayload
CapCodeЦифровой код, указывающий на состояние оплаты, копируется из CapResPayload
CapRatioCapReqAmt ч PurchAmt
CreditStatus{CreditDate, CreditCode, CreditRatio}
Данные присутствуют, только если реализован запрос CreditReq. Эта информация удаляется CredRevReq
CreditDateДата кредита. Копируется из CapRevOrCredCode.
CreditCodeЦифровой код, указывающий на состояние кредита. Копируется из CapRevOrCredResPayload.CapRevOrCredCode. (см. табл. 4.6.2.74)
CreditRatioCapRevOrCredReqAmt ч PurchAmt



Коды завершения (completionCode) могут принимать следующие значения (см. табл. 4.6.2.62). Таблица 4.6.2.62. Коды завершения операции
meanonglessRatioPurchAmt=0; отношение не может быть вычислено
orderRejectedПродавец не может обработать заказ
orderReceivedПроцессы авторизации отсутствуют
orderNotReceivedИнформационный запрос получен до заказа
authorizationPerformedСм. AuthStatus
capturePerformedСм. CapStatus
creditPerformedСм. CreditStatus
Владелец карты обрабатывает полученный отклик PRes следующим образом.
ШагДействие
1Извлекается отклик из входного сообщения
2Чтобы проверить подпись продавца, производится обращение к Received Signed Data,
3На основе Trans.LID-C ищется запись транзакции. Если запись не найдена:Посылается сообщение Error c ErrorCode равным unknownLIDПрерывается обработка PRes
4Сравнить значения TransIDs.XID с XID из записи транзакции. Если равенства нет:Посылается сообщение Error c ErrorCode равным unknownXIDПрерывается обработка PRes
5Сравнить значения RRPID из сообщения и записи транзакции. Если совпадения нет:Посылается сообщение Error c ErrorCode равным unknownRRPIDПрерывается обработка PRes
6Сравнить значения Chall-C из сообщения и записи транзакции. Если совпадения нет:Посылается сообщение Error c ErrorCode равным challengeMismatchПрерывается обработка PRes
7Запомнить BrandCRLIdentifier и проверить, что перечисленные CRL содержаться в кэше. Если это не так, и перечисленные CRL относятся к элементам, чьи сертификаты использовались для верификации подписи, сообщение игнорируется, так как подпись может быть некорректной.
8Для каждого PResPayload из PresPayloadSeq выполняются следующие действия:Если CompletionCode указывает на реализацию кредита, для каждой информационной структуры в CreditSeq представить пользователю CreditAmount (PurchAmount*CredRatio) и дату кредита вместе с полученным объемом платежа (PurchAmount*CapRatio).В противном случае, если CompletionCode указывает на завершение процесса платежа, представить пользователю CapCode вместе с вычисленным Capture Amount (PurchaseAmount*CapRatio).В противном случае, если CompletionCode указывает на завершение процесса авторизации, представить пользователю AuthCode вместе с вычисленным Authorization Amount (PurchaseAmount*AuthRatio).В противном случае сообщить результат транзакции на основе CompletionCode.Если присутствует AcqCardMsg, дешифровать и представить владельцу карты. Если там имеется URL, программа может выдать содержимое соответствующей WEB-страницы. Здесь может потребоваться обработка, зависящая от вида платежной системы.



Обработка информационных запросов Пара сообщений InqReq/ InqRes позволяет владельцу карты получать информацию о состоянии транзакции. Информационный запрос может быть послан в любое время после запроса PReq, адресованного продавцу. Запросы InqReq могут посылаться многократно. Отклик InqRes имеет тот же формат, что и PRes. Продавец должен проверять, что сертификат, сопровождающий InqRes, соответствует сертификату, использованному с PRes. Это препятствует запросам одного владельца карты о состоянии транзакций других покупок. Владелец карты без сертификатов не подписывает информационные запросы, что означает возможность нарушения целостности сообщения. Владелец карты формирует запрос InqReq следующим образом.
ШагДействие
1Копируется InqReqData из предыдущего запросаФормируется новый RRPIDГенерируется новый Chall-СОпционно добавляются любые InqReqExtensions
2Если владелец карты послал подписанный PReq, вставить Compose SignedData c InqReqData
3Вставить сообщение в цифровой конверт и послать продавцу
Структура данных запроса InqReq представлена в таблице 4.6.2.63. Таблица 4.6.2.63. Структура InqReq
InqReq<InqReqSigned, InqReqData>
InqReqSignedS(C, InqReqData)
InqReqData{TransIDs, RRPID, Chall-C2, [InqRqExtensions]}
TransIDsКопируется из самого последнего: PReq, PRes, InqReq
RRPIDИдентификатор пары запрос/отклик
Chall-C2Новый вызов владельца карты по поводу подписи продавца.
InqRqExtensionsИнформационный запрос не шифруется, по этой причине расширения не должны содержать конфиденциальной информации.
Когда продавец получает InqReq, он обрабатывает это сообщение следующим образом:
ШагДействие
1Извлекается запрос из входного сообщения
2Если получены данные InqReqData (в противоположность InqReqSigned), проверить, позволяет ли сертификат расчетного центра неподписанные транзакции. Если он этого не допускает, тогда:Прислать сообщение InqRes c CompletionCode = signatureRequired.Прервать обработку InqReqВ противном случае перейти к пункту 4.
3Если получен InqReqSigned, проверить подпись. Если проверка подписи не прошла:Прислать сообщение Error с ErrorCode = signatureFailureПрервать обработку InqReq
4Сравнить TransIDs со значениями из цифрового конверта сообщения. Если равенства нет:Прислать сообщение Error c ErrorCode = wrapperMsgMismatchПрервать обработку InqReq
5Искать транзакцию в базе данных, основанную на TransIDs.XID. Если поиск неудачен:Прислать InqRes c CompletionCode = orderNotReceived.Прервать обработку InqReq
6Если PReq был подписан, проверить, что PReq и InqReq подписаны одним и тем же владельцем карты. Если соответствия нет, то:Прислать сообщение Error c ErrorCode = unknownXID.Прервать обработку InqReq
7Сформировать PResPayloadSeq



Авторизация платежей продавца осуществляется согласно схеме, показанной на рис. 4.6.2.17.
Рис. 4.6.2.17. Авторизация платежей Процесс авторизации проходит через три состояния. Во время обработки заказа от владельца карты продавец авторизует транзакцию. Программа продавца формирует и цифровым образом подписывает авторизационный запрос, который включает в себя сумму платежа, подлежащую авторизации, идентификатор транзакции из OI и некоторые другие данные. Запрос затем шифруется с использованием нового случайного симметричного ключа, который в свою очередь шифруется общедоступным ключом расчетного центра. Это тот самый ключ, который использовал владелец карты для шифрования цифрового конверта с платежными инструкциями. Запрос авторизации и платежные инструкции владельца карты передаются в расчетный центр. Когда расчетный центр получает авторизационный запрос, он дешифрует цифровой конверт запроса и извлекает из него симметричный ключ. Этот ключ используется для дешифрования текста запроса. Далее верифицируется сертификат подписи продавца срок его действия, а также цифровая подпись. После этого расчетный центр дешифрует цифровой конверт платежных инструкций (PI), откуда извлекается симметричный ключ и информация о счете клиента. Ключ используется для дешифрования PI. Используя общедоступный ключ владельца карты и дайджест OI (включенный в PI), проверяется цифровую подпись, чтобы убедиться, что PI не модифицированы и что они подписаны с использованием секретного ключа владельца карты. Расчетный центр проверяет, что идентификатор транзакции, полученный от продавца, соответствует идентификатору, присланному в PI. При успешном завершении этих проверок расчетный центр формирует и отсылает через финансовую сеть авторизационный запрос эмитенту карты. При получении отклика авторизации от эмитента расчетный центр генерирует и подписывает цифровым образом авторизационный отклик, который содержит отклик эмитента и копию сертификата подписи расчетного центра. Этот отклик может также включать в себя платежный маркер (capture token) с данными, которые будут нужны расчетному центру для обработки платежного запроса.


Платежный маркер вставляется в отклик только в случае, если этого требует банк продавца (Получатель). Отклик шифруется с помощью вновь сформированного секретного симметричного ключа, который в свою очередь шифруется общедоступным ключом продавца. После шифрования отклик посылается продавцу. Когда программа продавца получает авторизационный отклик из расчетного центра (РЦ), она дешифрует цифровой конверт и извлекает оттуда симметричный ключ, посредством которого дешифруется текст отклика. Продавец верифицирует сертификат подписи расчетного центра, а посредством общедоступного ключа РЦ и его цифровую подпись. Продавец запоминает авторизационный отклик и платежный маркер для последующего использования при обработке платежных запросов. Далее продавец может осуществлять доставку товаров или услуг, оговоренных в заказе. Обмен AuthReq/AuthRes возможен как для исключительно авторизованных транзакций, так и транзакций оплаты. Пара запрос/отклик автортизации предоставляет механизм авторизации сделки. В запросе авторизации продавец посылает подписанные и зашифрованные данные о покупке, а также инструкцию PI, полученную от владельца карты. Так как каждая из секций содержит хэш OD и количества (Amount), расчетный центр может проверить то, что владелец карты и продавец договорились о заказе и сумме, которые следует авторизовать. Так как PI включает данные платежной карты, необходимые для авторизации, расчетный центр может выполнить авторизацию, используя существующую финансовую сеть платежной карты. Когда продавец заранее знает, что заказ будет выполняться по частям (несколько поставок), он осуществит несколько шагов AuthReq (по одному для каждой части). Продавец устанавливает в первом AuthReq значение SubsequentAuthInd равным TRUE, что представляет собой указание на авторизацию выполнения первой части заказа. Расчетный центр пришлет в отклике AuthRes значение AuthToken. Продавец будет вынужден выполнить дополнительные запросы AuthReq для реализации последующих этапов выполнения заказа.


В каждое последующее сообщение AuthReq продавец должен включать значение AuthToken из предшествующего отклика расчетного центра. В последнем AuthReq продавец установит значение SubsequentAuthInd равным FALSE. Когда продавец обнаруживает, что заказ будет выполняться поэтапно после отправки AuthReq, он должен послать AuthRevReq, чтобы согласовать число дополнительных авторизаций, и установить SubsequentAuthInd = TRUE, для получения AuthToken в последующих откликах AuthRes. Алгоритм формирования AuthReq представлен ниже.
ШагДействие
1Сгенерировать AuthTags (см. табл. ниже)
2Сгенерировать HOD2 путем хэширования OD, PurchAmt, ODSalt, ODExtensions и, если имеется, InstallRecurData. Расчетный центр сравнит его значение с полученным в PI.
3Сгенерировать AuthReqPayload (см. табл. ниже)
4Опционно для одновременной авторизации и резервирования заказа:Установить CaptureNow = TRUEСгенерировать SaleDetail (см. табл. 4.6.2.47)Опционно занести в поле BatchID значение открытой в настоящее время платежной линии (серия платежей для данного клиента) для BrandAndBIN. Это значение должно быть ассоциировано с текущей транзакцией и BatchSequenceNumber (номер платежа).Может так случиться, что банк продавца не может выполнить одновременно авторизацию и платеж для данного заказа даже при CaptureNow=TRUE. В этом случае AuthCode=captureNotSupported укажет на то, что производится только авторизация. Продавец может послать позднее запрос CapReq, чтобы выполнить платеж для данного заказа.
5Включить CheckDigest с вычисленными продавцом H(OIData) и HOD2. H(PIData) копируется продавцом из PReq. Это поле опускается, если запрос AuthReq представляет последовательную авторизацию, базирующуюся на присланном из расчетного центра коде AuthToken.
6Рекомендуется заполнить MThumbs путем вычисления оттисков сертификатов и CRL, хранимых продавцом. Продавец должен внести в сообщение оттиски, которые могут потребоваться позднее для верификации подписи и сертификатов расчетного центра.
7Осуществить EncB-инкапсуляцию
8Включить сертификаты подписи и шифрования отправителя и всей цепи сертификации вплоть до сертификата платежной системы.
9Поместить сообщение в цифровой конверт и отправить адресату
Процедура формирования AuthTags показана в таблице ниже.
ШагДействие
1Заполнить поле AuthRRTags (см. табл. 4.6.2.52)
2Заполнить поле TransIDs. Если это последовательная авторизация и определено PaySysID, занести его значение в поле PaySysID.
3Если это многоэтапный платеж и банк продавца задал для авторизации значение AuthRetNum, скопировать AuthRetNum из предыдущего AuthRes



Схема формирования поля данных AuthReq показана ниже.
ШагДействие
1Если планируется обработка последовательных авторизаций для покупки и это не последняя авторизация, установить SubsequentAuthInd равным TRUE, в противном случае FALSE.
2Если продавец и владелец карты договорились о рекуррентных или поэтапных платежах, заполнить поле InstallRecurData
3Установить AuthReqAmt равным числу авторизаций
4Опционно присвоить CardSuspect соответствущее значение, если продавец имеет какие-то подозрения относительно владельца карты.
5Если при некотором платеже необходимы данные MerchData, добавить их в сообщение.
6Сформировать MarketSpecAuthData, если это диктуется платежной системой карты или типом покупки.
7Если политика платежной системы карты требует наличия AVSData, записать в это поле информацию, предоставленную владельцем карты.
8Если политика платежной системы карты требует наличия SpecialProcessing, сгенерировать его значение.
9Если продавец требует информацию о типе платежной карты, установить RequestCardTypeInd = TRUE.
Структура данных сообщения AuthReq представлена в таблице 4.6.2.64. Таблица 4.6.2.64. Структура AuthReq
AuthReqEncB(M, P, AuthReqData, PI)
AuthReqData{AuthReqItem, [Mthumbs], CaptureNow, [SaleDetail]}
PIСм. табл. 4.6.2.39.
AuthReqItem{AuthTags, [CheckDigests], AuthReqPayload}
MThumbsОттиски сертификатов, CRL и BrandCRLIdentifiers, хранимые в данный момент в кэше продавца.
CaptureNowБулева переменная, указывающая, что резервирование должно проводиться, если проведена авторизация.
SaleDetailСм. табл. 4.6.2.47
AuthTags{AuthRRTags, TransIDs, [AuthRetNum]}
CheckDigests{HOIData, HOD2}используется расчетным центром для аутентификации PI. Опускается, если PI = AuthToken
AuthReqPayloadСм. табл. 4.6.2.65
AuthRRTagsRRTags
Необходим RRPID, так как для одного PReq может потребоваться более одного цикла авторизации.
TransIDsКопируется из соответствующего поля OIData (см. табл. 4.6.2.59)
AuthRetNumИдентификация запроса авторизации, используемого в пределах финансовой сети.
HOIDataDD(OIData) (См. табл. 4.6.2.59) Независимый хэш, вычисляемый продавцом. Расчетный центр сравнивает это значение с копией, сформированной владельцем карты в PI.
HOD2DD(HODInput) (См. табл. 4.6.2.59) Вычисляется независимо продавцом. Расчетный центр сравнивает это значение с копией, сформированной владельцем карты в PI.



Структура данных AuthReqPayload представлена в таблице 4.6.2.65. Таблица 4.6.2.65. Структура AuthReqPayload
AuthReqPayload{SubsequentAuthInd, AuthReqAmt, [AVSData],
[SpecialProcessing], [CardSuspect],
RequestCardTypeInd, [InstallRecurData],
[MarketSpecAuthData], MerchData, [ARqExtensions]}
SubsequentAuthInd Булева переменная, указывающая на запросы со стороны продавца дополнительной авторизации из-за раздельной поставки
AuthReqAmtМожет отличаться от PurchAmt; политика банка продавца может наложить ограничение на допустимое отличие
AVSData{[StreetAddress], Location}
Адрес счета владельца карты: содержимое получается от владельца карты посредством механизмов, выходящих за пределы SET.
SpecialProcessingЧисловое поле, указывающее тип запрошенной обработки
CardSuspectЧисловое поле, указывающее, что продавец подозревает владельца карты, и на причину подозрения
RequestCardTypeIndУказывает, что тип карты должен быть прислан в поле CardType отклика. Если информация недоступна, присылается значение unavailable(0).
InstallRecurDataСм. табл. 4.6.2.41.
MarketSpecAuthData< MarketAutoAuth, MarketHotelAuth, MarketTransportAuth >
Специфические авторизационные данные рынка
MerchData{[MerchCatCode], [MerchGroup]}
ARqExtensionsДанные в расширении авторизационного запроса должны иметь финансовый характер и относиться к процессу авторизации (или последующей оплаты заказа) расчетного центра, финансовой сети или эмитента карты.
StreetAddressАдрес улицы владельца карты
MarketAutoAuth{Duration}
MarketHotelAuth{Duration, [Prestige]}
MarketTransportAuth{}
В настоящее время нет авторизационных данных для этого сегмента рынка
MerchCatCode4-байтовый код (определен в ANSI X9.10), описывающий тип бизнеса, продукта или услуги продавца.
MerchGroupЧисловой код, идентифицирующий общую категорию продавца
DurationОжидаемая длительность транзакции (в днях). Эта информация помогает понять, какое время пройдет со времени авторизации до оплаты заказа (capture).
PrestigeЧисловой тип приоритета, определяется платежной системы карты.
Схема обработки запроса AuthReq платежным центром представлена в таблице ниже.
ШагДействие
1Извлечь запрос из транспортного сообщения
2Дешифровать PI
3Сравнить TransIDs из AuthTags и PIHead или AuthToken:Проверить что коды XID идентичныПроверить что коды LID-C идентичныЕсли LID-M присутствуют в AuthTags и PIHead, сравнить их значенияЕсли хотя бы одна из проверок не прошла, сообщение отбрасывается и возвращается AuthCode = piAuthMismatch
4Если PI является AuthToken:Обработать AuthTokenВ противном случае, если PI подписаны:Проверить, что платежная система в подписи владельца карты согласуется с платежной системой сертификата шифрования расчетного центра. Если согласия нет, то авторизация отвергается путем отправки AuthCode = CardMerchBrandMismatch.Проверить PANDataЗапомнить данные из PANDataВ противном случае, если PI не подписаны:Проверить, что расчетный центр не требует подписи (путем проверки сертификата платежного центра). Если подпись требуется, отвергнуть авторизацию, послав AuthCode = signatureRequiredВерифицировать хэш в EXHЗапомнить данные из PANToken
5Проверить состояние авторизации PI. Если PI была обработана и не отвергнута или отозвана, отвергнуть авторизацию, послав AuthCode = piPreviouslyUsed
6Обработать PIHead:Проверить, что PiHeadMerchantID соответствует содержимому поля merID в расширении merchantData сертификата подписи, используемом при верификации подписи продавца для сообщения AuthReq. Если соответствия нет, авторизация отвергается и посылается отклик с AuthCode = piAuthMismatch. Это предотвращает атаки подстановки, когда PI разных продавцов меняются местами.Передать TransStain эмитенту через финансовую сеть для верификации или запоминания с последующей верификацией.Проверить хэши OIData, полученные от владельца карты и продавца. Если они не совпадают, прислать AuthCode = piAuthMismatch.Проверить, что HOD от HIHead соответствует HOD2 от AuthReqPayload, при несовпадении прислать сообщение Error c ErrorCode = HODMismatchОбработать PIExtensions. Если обнаружены неподдерживаемые расширения, сообщение отвергается путем посылки сообщения Error c кодом unrecognizedExtensionЗапомнить данные от PIHead
7Если в AuthReq имеется InstallRecurData, проверить, что InstallRecurData в AuthReqPayload и в PIHead совпадают. Если это не так, отклонить авторизацию с AuthCode = InstallRecurMismatch.
8Запомнить AcqBackInfo в безопасной локальной памяти, если таковая имеется.
9Если captureNow=TRUE и платежная система не поддерживает этот режим, послать AuthCode = captureNotSupported
10Выполнить авторизацию через финансовую сеть платежной карты
11Если captureNow=TRUE, выполнить платеж через существующую финансовую сеть платежной карты
12Продолжить формирование сообщения AuthRes



Отклик AuthRes генерируется после завершения авторизации через финансовую сеть платежной карты. AuthCode и AuthAmt извлекаются из данных, полученных через финансовую сеть платежной карты. Формирование отклика AuthRes производится по схеме, изложенной в нижеприведенной таблице.
ШагДействие
1Получить необходимые данные от авторизационного процесса
2Заполнить поле AuthTags из AuthReq. Если это необходимо, занести в поле AuthRetNum, значение, полученное из авторизационного процесса.
3Заполнить текущее значение BrandCRLIdentifier, хранимое расчетным центром, если для текущего BrandCRLIdentifier не получен оттиск или он устарел.
4Если Mthumbs из AuthReq указывает, что продавцу нужен новый Cert-PE шифрования информации для расчетного центра:Вставить Cert-PE в цифровой конверт PKCS#4Вставить GKThumb в AuthResData, так как сам Cert-PE не защищен подписью
5Заполнить поле PaySysID в TransIDs, если они получены из авторизационного процесса
6Заполнить поле PANToken, если это необходимо для сертификата продавца,
7Заполнить AuthResBaggage (опционно):Опционно заполнить CapTokenОпционно заполнить AcqCardMsg, если соответствующие правила платежной системы требуют посылки запроса и получения ключа от владельца карты.Занести в AuthToken значения, полученные в InstallRecurData продавца, если осуществлена дополнительная авторизация (в предыдущем AuthReq SubsequentAuthInd=TRUE).Если ни одна из этих величин не присутствует, AuthResBaggage характеризуется пустой последовательностью.
8Опционно заполнить BatchStatus, как этого требует политика платежной системы карты.
9Если PANToken имеется, реализовать EncBX-инкапсуляцию
10Вставить сообщение в цифровой конверт и отправить владельцу карты
Расчетный центр формирует AuthResPayload следующим образом.
ШагДействие
1Сгенерировать CapResPayload
Заполнить AuthCode и AuthAmt c привлечением результатов авторизационного процессаЕсли авторизация отвергнута, вернуть AuthAmt, специфицированный в предыдущем AuthReq.Если флаг CaptureNow был указан в AuthReq, но не был реализован, вернуть в случае успешной авторизации AuthCode = captureNotSupported
3Заполнить поле CurrConv в соответствии с запрошенным владельцем карты типом валюты и с учетом текущего курса, если специфицирована валюта, отличная от используемой владельцем карты.
4Заполнить ResponseData:Заполнить поле AuthValCodes следующим образом: записать ApprovalCode, RespReason, AuthCharInd, ValidationCode и LogRefID, если получены из авторизационного процесса.Если RequestCardTypeInd в AuthReq был установлен равным TRUE, занести в поле CardType значение, полученное из авторизационного процесса.Занести в AuthCharInd значение, присланное авторизационным процессом
Структура полей AuthRes представлена в таблице 4.6.2.66. Таблица 4.6.2.66. Структура полей AuthRes
AuthRes<EncB(P, M, AuthResData, AuthResBaggage), EncBX(P, M, AuthResData, AuthResBaggage, PANToken)>
AuthResData{AuthTags, [BrandCRLIdentifier], [PEThumb], AuthResPayload}
AuthResBaggage{[CapToken], [AcqCardMsg], [AuthToken]}
PANTokenСм. табл. 4.6.2.46. Посылается, если сертификат продавца указывает на то, что информация предназначена продавцу.
AuthTagsКопируется из соответствующего AuthReq; TransIDs и AuthRetNum могут быть актуализованы с привлечением текущей информации
BrandCRLIdentifierСписок текущих CRL для всех СА в зоне ответственности СА платежной системы.
PEThumbОттиск сертификата расчетного центра предоставляется, если AuthReq.Mthumbs указывает то, что он нужен продавцу
AuthResPayloadСм. табл. 4.6.2.67.
CapTokenСм. табл. 4.6.2.44.
AcqCardMsgЕсли владелец карты включил AcqBackKeyData в PIHead, расчетный центр может послать это поле продавцу в шифрованном сообщении для владельца карты. Продавец должен скопировать AcqCardMsg в любой последующий отклик PRes или InqRes, посылаемый владельцу карты.
AuthTokenПродавец использует это поле в качестве PI в последующих запросах AuthReq. См. табл. 4.6.2.42.



Структура AuthResPayload представлена ниже в таблице 4.6.2.67. Таблица 4.6.2.67. Структура AuthResPayload
AuthResPayload{AuthHeader, [CapResPayload], [ARsExtensions]}
AuthHeader{AuthAmt, AuthCode, ResponseData, [BatchStatus], [CurrConv]}
CapResPayloadПрисылается, если CaptureNow имеет значение TRUE в AuthReq. См. табл. 4.6.2.71.
ARsExtensionsДанные в расширении к авторизационному отклику должны быть финансовыми и существенными для обработки авторизационного отклика.
AuthAmtКопируется из AuthReqPayload.AuthReqAmt
AuthCodeЧисловой код, индицирующий результат процесса авторизации
ResponseData{[AuthValCodes], [RespReason], [CardType], [AVSResult], [LogRefID]}
BatchStatusСм. табл. 4.6.2.53.
CurrConv{CurrConvRate, CardCurr}
AuthValCodes{[ApprovalCode], [AuthCharInd], [ValidationCode], [MarketSpecDataID]}
RespReasonЧисловой код, который указывает на объект сервиса авторизации и причину отказа (если таковая имеется)
CardTypeЧисловой код, который указывает на тип карты, использованной для транзакции.
AVSResultЧисловой код отклика адресной верификационной службы
LogRefIDАлфавитно-цифровые данные, ассоциируемые с авторизационной транзакцией (используется для распознавания при отзыве предшествующего запроса)
CurrConvRateКурс обмена валюты. Значение, на которое нужно умножить AuthReqAmt, чтобы получить сумму в валюте владельца карты.
AuthReqAmtКод валюты владельца карты в стандарте ISO 4217
ApprovalCodeКод одобрения, присваиваемый транзакции эмитентом
AuthCharIndЧисловое значение, которое указывает условия, при которых выполнена авторизация.
ValidationCode4-байтовый алфавитно-цифровой код, вычисленный, чтобы гарантировать, что необходимые поля авторизационных сообщений присутствуют в соответствующих клиринговых сообщениях.
MarketSpecDataIDЧисловой код, который указывает тип данных, специфических для рынка, представляемых при авторизации (как это определено финансовой сетью)
Список возможных значений кода AuthCode приведен ниже
approvedЗапрос авторизации удовлетворен
unspecifiedFailureЗапрос авторизации не может быть обработан по причине, которая отсутствует в приведенном здесь списке.
declinedЗапрос авторизации отклонен
noReplyЭмитент не откликнулся на запрос авторизации. Это значение часто указывает на временное отсутствие доступа к системе обработки данных эмитента.
callIssuerЭмитент запрашивает телефонный вызов от продавца
amountErrorТакое число транзакций не может быть обработано системой (банком продавца, финансовой сетью, эмитентом и т.д.)
expiredCardСрок действия карты истек
invalidTransactionЗапрос не может быть обработан последующей системой (банком продавца, финансовой сетью, эмитентом и т.д.), так как тип транзакции является недопустимым.
systemErrorЗапрос не может быть обработан последующей системой (банком продавца, финансовой сетью, эмитентом и т.д.), так как запрос содержит в себе некорректные данные.
piPreviouslyUsedПлатежная инструкция (PI) в запросе авторизации использовалась для первичной авторизации (отклик, сформированный расчетным центром).
recurringTooSoonМинимальное время между авторизациями для рекуррентной транзакции еще не истекло (отклик, сформированный расчетным центром).
recurringExpiredДата истечения действия для рекуррентной транзакции наступила (отклик, сформированный расчетным центром)
piAuthMismatchДата в PI от владельца карты не согласуется с данными в OD от продавца.
installRecurMismatchInstallRecurData в PI от владельца карты не согласуется с InstallRecurData в OD от продавца.
captureNotSupportedРасчетный центр не поддерживает платеж (capture).
signatureRequiredОпция неподписанной PI не поддерживается расчетным центром для данной платежной системы.
cardMerchBrandMismatchПлатежная система в сертификате подписи владельца карты не согласуется с платежной системой сертификата шифрования расчетного центра.



Обработка продавцом отклика AuthRes производится следующим образом.
ШагДействие
1Получить отклик из входного сообщения
2Извлечь запись транзакции и сравнить с AuthTags:Проверить, что XID соответствует транзакции. Если соответствия нет, сообщение отвергается с Error = unknownXIDПроверить, что LID-M и, если имеется в записи транзакции, LID-C согласуются с содержимым записи транзакции. Если соответствия нет, сообщение отвергается, а в журнал операций расчетного центра записывается Error = unknownLID.
3Если в сообщение включен BrandCRLIdentifier, запомнить CRL.
4Обработать AuthResPayload
5Проверить, что GKThumb соответствует существующему сертификату шифрования расчетного центра, если GKThumb имеется. Если соответствия нет, актуализовать кэш сертификата с использованием текущего сертификата
6Если BatchStatus присутствует, обработать и запомнить данные.
7Обработать AuthResBaggage:Запомнить CapToken, если это поле присутствуетЕсли имеется AcqCardMsg, запомнить его для отправки владельцу картыЗапомнить AuthToken, если имеется, для последующей авторизации.Если в AuthReq SubsequentAuthInd = TRUE, будет возвращено AuthToken
8Если присутствует PANToken, записать его в безопасную локальную память
9Продолжить обработку оплаты заказа и/или отклика на покупку, в зависимости от результатов авторизации и временных рамок продавца для возвращения отклика на покупку.
Алгоритм обработки AuthResPayload представлен ниже.
ШагДействие
1Обработать ARsExtensions, если они имеются. Если неподдерживаемое расширение помечено как критическое, расчетный центр производит запись в журнал Error = unrecognizedExtension, а сообщение игнорируется.
2Обрабатать CapResPayload:Обработать CRsPayExtensions. Если имеется нераспознанное расширение, помеченное как критическое, отвергнуть AuthRes, а расчетный центр делает запись в журнал Error = unrecognizedExtensionОбработать CapCode с целью определения результатаОбработать SaleDetail в соответствии с политикой платежной системы картыДля успешной оплаты заказа, записать CapCode и CapAmt.Если делался запрос оплаты (capture), будет возвращен CapResPayload
3Если имеется CurrConv, запомнить его для переадресации владельцу карты
4Обработать AuthCode, AuthAmt и ResponseData:Для определения результата обрабатывается AuthCode.Запомнить AuthCode и AuthAmt для получения успешного результата.Запомнить ValidationCode для успешного исхода, если это поле имеется.Запомнить AuthValCode, если имеется.Запомнить AVSResult, если имеется.Запомнить LogRefID, если имеется.
Когда эмитент обрабатывает авторизационный запрос, возможно получение трех результатов: одобрение, отклонение, условное отклонение.


Последний вариант называется referral (откладывание) и индицируется значением callissuer(4) в AuthCode. При получении отклика referral продавец может обратиться в свой банк по телефону (вне пределов протокола SET). После идентификации транзакции банк свяжет продавца с эмитентом. В результате этого телефонного вызова эмитент может преобразовать авторизацию в одобрение путем посылки продавцу кода ApprovalCode. Программное обеспечение продавца позволяет оператору сервера продавца вводить код одобрения. Последующая обработка транзакции будет производиться так, как если бы кодом отклика был approved(0). При этом код отклика не переписывается. Программа расчетного центра обрабатывает отложенные авторизации как одобрение за исключением случаев, когда AuthCode = callIssuer и когда оплата (capture) не осуществляется, до тех пор пока продавец не получит от эмитента кода ApprovalCode. Программа расчетного центра обрабатывает все последующие сообщения для транзакций, как если бы транзакция была одобрена, при условии посылки продавцом корректного кода ApprovalCode. Запрос авторизации несет в себе необходимую информацию от продавца к расчетному центру для формирования сообщения-запроса авторизации, которое может быть обработано банком продавца. Отклик на запрос авторизации несет в себе информацию от расчетного центра, относящуюся к обработке запроса авторизации. Пары сообщений AuthRevReq/AuthRevRes (Autorization Reversal Request/Response) используются только для сокращения или аннулирования полученной ранее авторизации. Эта пара опционных сообщений не может применяться для ликвидации разделения авторизации, выполненной ранее. Необходимость разделения авторизации возникает тогда, когда поставка в рамках сделки должна быть выполнена поэтапно. Данные сообщения могут посылаться когда угодно после авторизации и до осуществления платежа (capture). Для реализации разделения или ликвидации авторизации продавец посылает запрос AuthRevReq, который уменьшает значение AuthAmt и устанавливает переменную SubsequentAuthInd = TRUE.


Расчетный центр возвращает AuthToken в отклике AuthRevRes. Маркер AuthToken будет использоваться для авторизации покупок при последующих частичных поставках. Запрос/отклик платежа (CapReq/CapRes) Пара сообщений CapReq/CapRes предоставляет механизм выполнения платежа. Обмен этими сообщениями происходит между продавцом и расчетным центром. Транзакция обработки платежных запросов проходит через три состояния (см. рис. 4.6.2.18).
Рис. 4.6.2.18. Обработка платежных запросов После завершения обработки заказа владельца карты продавец осуществляет запрос платежа. Между запросами авторизации и запросом платежа может быть достаточно большая задержка. Программа продавца генерирует платежный запрос, снабженный цифровой подписью. Этот запрос содержит итоговую сумму транзакции, ее идентификатор из OI и другую информацию о транзакции. Запрос шифруется с использованием вновь сформированного симметричного ключа, который в свою очередь шифруется с привлечением общедоступного ключа расчетного центра. Запрос платежа и опционно платежный маркер (capture token), если таковой был включен в авторизационный отклик, пересылаются в расчетный центр. В общем случае в одном сообщении может быть заключено несколько платежных запросов. Когда расчетный центр получает запрос платежа, он дешифрует цифровой конверт, извлекает из него симметричный ключ и дешифрует с его помощью текст платежного запроса. Далее посредством общедоступного ключа продавца верифицируется его цифровая подпись. Расчетный центр дешифрует платежный маркер (если таковой имеется) и использует платежный запрос и маркер для формирования клирингового запроса, который направляется эмитенту карты через платежную систему кредитной карты. После этого расчетный центр генерирует платежный отклик, снабженный цифровой подписью. Этот отклик содержит в себе копию сертификата подписи расчетного центра. Отклик шифруется с использованием нового симметричного ключа и переправляется продавцу. Когда продавец получает платежный отклик из расчетного центра (РЦ), он дешифрует цифровой конверт, извлекает из него симметричный ключ и с его помощью дешифрует полученный текст отклика.


Далее верифицируется сертификат подписи расчетного центра и цифровая подпись РЦ. Продавец запоминает платежный отклик для последующего использования при контроле платежей, поступающих из его банка. Пары запросов CapReq/CapRes предоставляют механизм завершения ранее авторизованного денежного платежа. Размер платежа определяется на фазе обмена авторизационными сообщениями. Продавец не должен посылать запрос CapReq для ранее успешно прошедших платежей. Возможно осуществление платежей с помощью пар сообщений, выходящих за пределы протокола SET. Формирование запроса CapReq продавцом осуществляется следующим образом.
ШагДействие
1Заполнить поле CapRRTags
2Опционно заполнить поля AuthReqData и AuthResPayload. Процедура опускается, если информация содержится в CapToken
3Рекомендуется заполнить MThumbs всех сертификатов для расчетного центра, куда посылается это сообщение, для CRL и для BrandCRLIdentifier
4Заполнить один или более CapItem в CapSeq следующим образом. Для каждого CapItem:Заполнить TransIDs и AuthRRPID платежной позиций предшествующих сообщений в каждой транзакции.Заполнить CapPayloadЗаполнить SaleDetail, как это требует политика платежной системы карты.Если CapToken нет, или отсутствует авторизация в расчетном центре, копировать CapTokenItem из соответствующего AuthReqItem запроса AuthReq и из AuthResPayload отклика AuthRes
5Заполнить CapTokSeq с помощью CapToken из соответствующих сообщений AuthRes, полностью тождественных с CapItem в CapSeq. Если CapToken для транзакции отсутствует, заносится нуль.
6В дополнительные позиции инкапсуляции EncBX заносятся PANToken, если продавец получил PANToken
7Опционно заполняется CRqExtensions
8Если включено PANToken, использовать EncBХ-инкапсуляцию
9Если PANToken не включено, использовать EncB-инкапсуляцию
10Вложить сообщение в цифровой конверт и послать владельцу карты
Генерация CapPayload осуществляется согласно алгоритму.
ШагДействие
1Занести в поле CapDate текущее значение даты
2Занести в CapReqAmt сумму выплаты
3Скопировать AuthResPayload из соответствующего AuthRes
4Опционно заполнить CPayExtensions
Формат сообщения CapReq представлен в таблице 4.6.2.68 Таблица 4.6.2.68.


Формат CapReq
CapReq<EncB(M, P, CapReqData, CapTokenSeq), EncBX(M, P, CapReqData, CapTokenSeq, PANToken)>
CapTokenSeq является внешним “багажом”.
Если имеется маркер PANToken, он должен соответствовать одному CapItem и одному CapToken в CapTokenSeq.
CapReqData{CapRRTags, [MThumbs], CapItemSeq, [CRqExtensions]}
CapTokenSeq{[CapToken] +}
Один или более CapTokens, соответствующие один-в-один CapItems в CapItemSeq. Любой CapToken может быть опущен, т.е. может равняться нулю.
PANTokenСм. табл. 4.6.2.46.
CapRRTagsRRTags.
Новый RRPID и Date
MThumbsОттиски сертификатов, CRL и BrandCRLIdentifier, хранящиеся в кэше продавца.
CapItemSeq{CapItem +}
Один или более CapItem в упорядоченном массиве
CRqExtensionsДанные в расширении запроса платежа (capture) должны иметь финансовый характер и быть существенными для сообщения capture, посланного расчетному центру, финансовой сети или эмитенту.
Данные в этом расширении относятся ко всем позициям запроса оплаты capture. Данные, относящиеся к специфическим позициям, должны помещаться в CapPayload
CapTokenКопируется из соответствующего AuthRes или AuthRevRes
CapItem{TransIDs, AuthRRPID, CapPayload}
TransIDsКопируется из соответствующего AuthRes или AuthRevRes
AuthRRPIDRRPID, который появляется в соответствующем AuthReq или AuthRev
CapPayloadСм. табл. 4.6.2.69.
Структура данных CapPayload представлена в таблице 4.6.2.69. Таблица 4.6.2.69. Структура CapPayload
CapPayload{CapDate, CapReqAmt, [AuthReqItem], [AuthResPayload], [SaleDetail], [CPayExtensions]}
CapDateДата платежа - это дата транзакции, которая появится в уведомлении владельца карты.
CapReqAmtСумма платежа, затребованная продавцом, может отличаться от AuthAmt. Это сумма транзакции (до конвертации валюты), которая появится в уведомлении владельца карты.
AuthReqItemСм. табл. 4.6.2.64. Поле необходимо, если соответствующий маркер CapToken отсутствует или система расчетного центра/банка продавца не содержит подходящих данных для авторизационного запроса.
AuthResPayloadСм. табл. 4.6.2.67. Поле необходимо, если соответствующий маркер CapToken отсутствует или система расчетного центра/банка продавца не содержит подходящих данных для авторизационного отклика.
SaleDetailСм. табл. 4.6.2.47.
CPayExtensionsДанные в расширении запроса платежа (capture) должны иметь финансовый характер и быть существенными для сообщения capture, посланного расчетному центру, финансовой сети или эмитенту.
Данные этого расширения приложимы к индивидуальным позициям платежного запроса. Данные, относящиеся ко всему запросу, помещаются в расширение CapReqData.



Расчетный центр, получив запрос CapReq, обрабатывает его следующим образом.
ШагДействие
1Извлечь запрос из входного сообщения
2Обработать CRqExtensions. Если какое-либо неподдерживаемое расширение имеет критический флаг, отбросить сообщение, послав сообщение Error = unrecognizedExtension
3Для каждого CapItem обработать платеж и сформировать CapResItem с суммой из обрабатываемого платежа и кодом CapCode, соответствующим успеху или неудаче:Обработать CapPayloadЕсли CapToken присутствует:Проверить CapToken. Если CapToken некорректен, отклонить платеж, возвратив для данной позиции CapCode = invalidCapToken Проверить, что CapToken не был еще обработан. Если проверка не прошла, отклонить платеж, прислав CapCode = invalidCapTokenОбработать TokenOpaqueВ противном случае, если допустимы платежи без CapToken:Если AuthReqItem и AuthResPayload отсутствуют, отклонить платеж, послав CapCode = authDataMissingСверить AuthReqItem и AuthResPayload с записями транзакции. Если соответствия нет, платеж отвергается путем посылки CapCode = invalidAuthData.В противном случае, если платежи без CapToken не поддерживаются, платеж отклоняется посылкой CapCode = missingCapTokenПроверить TransIDsИзвлечь запись транзакцииПроверить, что XID согласуется с записью транзакции. Если согласия нет, то платеж отклоняется посылкой CapCode = unknownXIDСверить LID-C и, если имеется, LID-M со значениями из записи транзакции. Если совпадения нет, то транзакция терпит неудачу, посылается CapCode = unknownLIDf) Обработать платеж для заданной позиции через существующую финансовую сеть карты и записать результат.
Расчетный центр обрабатывает CapPayLoad следующим образом.
ШагДействие
1Обработать CPayExtensions. Если неизвестное расширение помечено как критическое, сообщение отвергается и возвращается сообщение Error unrecognizedExtension
2Запомнить SaleDetail
3Проверить, что BatchID является открытой платежной линией для BrandAndBIN.Если платежная линия неизвестна, отклонить платеж с посылкой CapCode = batchUnknown.Если линия не открыта, отклонить платеж с CapCode = batchClosed
4Проверить, что идентификатор BatchSequenceNum является уникальным в рамках платежной линии. Если идентификатор не уникален, отклонить платеж путем возвращения CapCode = batchUnknown.



Расчетный центр формирует отклик CapRes согласно следующему алгоритму.
ШагДействие
1Получить данные о платеже от платежного процесса
2Скопировать CapRRTags из CapReq
3 Заполнить текущее значение BrandCRLIdentifier, имеющееся в расчетном центре, если оттиск для текущего BrandCRLIdentifier не получен или устарел.
4Если MThumbs указывают, что продавцу для шифрования информации нужен новый Cert-PE:Вложить Cert-PE в цифровой конверт PKCS#7Вложить GKThumb в AuthResData, так как сам Cert-PE не защищен подписью
5Опционно занести в поле BatchSequenceNum состояние текущих платежных линий
6Скопировать BatchID и BatchSequenceNum из SaleDetail в CapResPayload
7Заполнить CapResSeq. Для каждого CapItem в соответствующем CapReq заполнить CapResItem следующим образом:Скопировать TransIDs из соответствующего CapReqItemСкопировать AuthRRPID из соответствующего CapReqItem, если он имеетсяЗаполнить CapResPayload
8Опционно заполнить CRsExtensions
9Вставить сообщение в цифровой конверт и послать продавцу
Генерация CapResPayload осуществляется следующим образом.
ШагДействие
1Заполнить CapCode и CapAmt результатами обработки соответствующего CapReqItem
2Скопировать BatchID и BatchSequenceNum из соответствующего CapReqItem
3Опционно заполнить CRsPayExtensions
Структура сообщения-отклика CapRes показана в таблице 4.6.2.70. Таблица 4.6.2.70. Структура CapRes
CapResEnc(P, M, CapResData)
CapResData{CapRRTags, [BrandCRLIdentifier], [PEThumb], [BatchStatusSeq], CapResItemSeq, [CRsExtensions]}
CapRRTagsRRTag>s; копируется из CapReq
BrandCRLIdentifierСписок текущих CRL для всех СА в области ответственности платежной системы СА.
PEThumbОттиск сертификата расчетного центра, предоставляемый, если CapReqData.Mthumbs указывает на то, что продавец в нем нуждается.
BatchStatusSeq {BatchStatus +}
CapResItemSeq{CapResItem +}
Заказ соответствует CapReq
CRsExtensionsДанные в расширении платежного отклика должны иметь финансовый характер и быть важными для осуществления платежа или последующего возврата денег.
BatchStatusСм. табл. 4.6.2.53.
CapResItem {TransIDs, AuthRRPID, CapResPayload}
TransIDsКопируется из соответствующего CapReq
AuthRRPIDRRPID, который появился в соответствующем AuthReq или AuthRevReq, копируется из соответствующего CapReq
CapResPayloadСм. табл. 4.6.2.71.



Структура данных CapResPayload представлена в таблице 4.6.2.71. Таблица 4.6.2.71. Структура CapResPayload
CapResPayload{CapCode, CapAmt, [BatchID], [BatchSequenceNum],
[CRsPayExtensions]}
CapCode Цифровой код, указывающий на состояние платежа
CapAmtКопируется из соответствующего CapReq
BatchIDИдентификатор для установления платежной линии между продавцом и его банком. Копируется из соответствующего CapReq
BatchSequenceNumПорядковый номер позиции в текущей последовательности платежей; копируется из соответствующего CapReq
CRsPayExtensionsДанные в расширении поля данных платежного отклика должны иметь финансовый характер и быть важными для осуществления платежа ли последующего возврата денег.
Продавец обрабатывает отклик CapRes следующим образом.
ШагДействие
1Извлекается отклик из входного сообщения
2Обрабатывается CRsExtensions, если таковые имеются. Если не узнанное расширение помечено как критическое, в рабочий журнал заносится запись Error = unrecognizedExtension, а сообщение CapRes отбрасывается
3Извлекается запись транзакции и производится сравнение CapRRTags:Проверяется, что XID соответствует транзакции. Если это не так, сообщение отвергается и посылается отклик Error = unknownXIDПроверяется, что LID-M и, если присутствует в записи транзакции, LID-C согласуются с записью транзакции. Если согласия нет, сообщение отвергается и посылается отклик Error = unknownLID
4Если в сообщение включен BrandCRLIdentifier, запомнить все CRL.
5Проверить, что GKThumb согласуется с сертификатом шифрования платежного центра (если GKThumb имеется). Если это не так, актуализовать кэш сертификата с использованием текущего сертификата.
6Для каждого CapResItem в CapResSeq:Обрабатывается CRsPayExtensions. Если неузнанное расширение помечено как критическое, в рабочий журнал заносится запись Error = unrecognizedExtension, а сообщение CapRes отбрасывается.Обработать CapCode для получения результата операцииДля успешного платежа запомнить CapCode и CapAmt, ассоциированные с AuthRRPID.
7Если BatchStatusSeq присутствует, обработать и запомнить каждое значение BatchStatus
В таблице ниже представлены допустимые значения CapCode.
successПлатежная позиция обработана расчетным центром успешно
unspecifiedFailureПричина неудачи неизвестна
duplicateRequestПлатежный запрос для данной транзакции уже был обработан (для XID и AuthRRPID)
authExpiredАвторизационный запрос был обработан слишком давно в прошлом. Это время определяется политикой платежной системы карты.
authDataMissingВ платежном запросе отсутствует авторизационная информация
invalidAuthDataАвторизационная информация для данной транзакции некорректна
capTokenMissingДля обработки данной позиции необходимо поле CapToken, а его нет
invalidCapTokenПоле CapToken некорректно для данной транзакции
batchUnknownРасчетный центр не знает о существовании платежной линии для данной позиции
batchClosedПлатежная линия для данной позиции закрыта
unknownXIDНе распознан идентификатор XID
unknownLIDНе распознан идентификатор LID



Сообщения отзыва платежа и кредита синтактически идентичны и выполняют сходную функцию. Алгоритм формирования информационной структуры CapRevOrCredReqData продавцом представлен ниже.
ШагДействие
1Сформировать CapRevOrCredRRTags с новым RRPID и текущей датой.
2Рекомендуется заполнить MThumbs путем вычисления оттисков сертификатов и CRL, имеющихся у продавца. Продавец должен заполнить оттиски в сообщении, которые могут быть затем нужны для верификации подписей и сертификатов, присылаемых расчетным центром.
3Заполнить одну или более позиций в CredRevOrCredReqItems:Скопировать TransIDs из соответствующего CapRes.Скопировать AuthRRPID из самого последнего запроса (settlement), если имеется.Скопировать CapPayload из самого последнего запроса (settlement), (т.е. CapReq, CapRevReq, CredReq или CredRevReq).Заполнить NewBatchID, если кредитная линия транзакции закрыта.Заполнить CapRevOrCredReqData с текущей датой и временемОпционно заполнить CapRevOrReqAmt с новой суммой, которая может отличаться от значений, содержащихся в AuthAmt из CapToken и CapReqAmt из CapPayload.Опционно установить новое значение NewAccountInd, если сделка состоится для нового счета владельца карты, как это специфицировано в PANToken.Опционно заполнить CRvRqItemExtensions
4Опционно заполнить CRvRqExtensions
Структура данных CapRevOrCredReqData описана в таблице 4.6.2.72. Таблица 4.6.2.72. Структура CapRevOrCredReqData
CapRevOrCredReqData{CapRevOrCredRRTags, [MThumbs], CapRevOrCredReqItemSeq, [CRvRqExtensions]}
CapRevOrCredRRTagsRRTags.Новый идентификатор RRPID и Date для данной пары.
MThumbsОттиски сертификатов, CRL и BrandCRLIdentifier, хранящиеся в кэше продавца
CapRevOrCredReqItemSeq{CapRevOrCredReqItem +}Один или более CapRevOrCredReqItem в виде упорядоченного массива
CRvRqExtensionsДанные расширения отзыва платежа или запроса кредита должны иметь финансовый характер и играть важную роль для обработки этих сообщений расчетным центром или эмитентом.
CapRevOrCredReqItem{TransIDs, AuthRRPID, CapPayload, [NewBatchID], CapRevOrCredReqDate, [CapRevOrCredReqAmt], NewAccountInd, [CRvRqItemExtensions]}
TransIDsКопируется из соответствующего CapRes.Поле необходимо, если соответствующий маркер CapToken отсутствует или не содержит подходящих данных авторизационного запроса
CapPayloadСм. табл. 4.6.2.69
NewBatchIDЭто поле специфицирует новый идентификатор платежной линии; оно используется для запросов отзыва платежа для позиций, реализованных в рамках платежной линии, которая была закрыта. BatchID >в CapPayload идентифицирует исходную платежную линию.
CapRevOrCredReqDateДата подачи запроса
CapRevOrCredReqAmtВ кредитных запросах сумма запрашиваемого кредита, которая может отличаться от AuthAmt в CapToken и CapReqAmt в CapPayload
NewAccountIndУказывает, что новый номер счета специфицирован в PANToken; когда это поле установлено, новый номер счета будет записан поверх информации о старом номере счета в CaptureToken или авторизационных данных, хранимых банком продавца. Использование этого поля является предметом политики платежной системы карты или банка продавца.
CRvRqItemExtensionsДанные в расширении поля данных отзыва платежа или запроса кредита должны иметь финансовый характер и быть важными для осуществления отзыва платежа или кредита расчетным центром



Расчетный центр обрабатывает CapRevOrCredReqData следующим образом.
ШагДействие
1Обрабатываются CRvRqxtensions. Если неподдерживаемое расширение помечено как критическое, возвращается отклик Error = unrecognizedExtensions, а обрабатываемое сообщение отбрасывается.
2Обрабатывается каждое CapRevOrCredItem:Обрабатываются CRvRqItemExtensions. Если неподдерживаемое расширение помечено как критическое, возвращается отклик Error = unrecognizedExtensionsИзвлекается запись транзакции и производятся сравнения с TransIDs в CapRevOrCredItemПроверяется, что XID соответствует предшествующей транзакции. Если это не так, сообщение отбрасывается и посылается сообщение Error = unknownXID.Проверяется соответствие LID-C с записью транзакции. Если соответствия нет, сообщение отбрасывается и посылается отклик Error = unknownLIDПроверяется CapPayload на соответствие записи транзакции. Если равенства нет, позиция отбрасывается и возвращается CapRevOrCredCode = capDataMismatch.Если установлен идентификатор NewBatchID, проверить, что BatchID является открытой платежной линией для BrandAndBIN. Если платежная линия закрыта, возвращается код CapRevOrCredCode = batchClosed. Если платежная линия неизвестна, возвращается код CapRevOrCredCode = batchUnknown.Запоминается CapRevOrCredAmtЕсли установлен NewAccountInd, использовать номер счета в PANToken для работы с расчетной картой в финансовой сети.
3На основе TransIDs в AuthRevTags извлекается запись транзакции.
Расчетный центр формирует CapRevOrCredResData с помощью следующей последовательности операций.
ШагДействие
1Заполнить поле CapRevOrCredTags
2Заполнить текущий BrandCRLIdentifier, хранимый расчетным центром, если оттиск BrandCRLIdentifier не получен или устарел.
3Если Mthumb указывает, что продавец нуждается в новом Cert-PE при шифровании информации для расчетного центра, то:Ввести Cert-PE в цифровой конверт PKCS#7Ввести GKThumb в AuthResData, так как сам Cert-PE не защищен подписью
4Опционно ввести BatchStatus в поле BatchStatusSeq для каждой платежной линии, чье состояние запрошено.
5Для каждой позиции в соответствующем CapRevOrCredItems заполнить поле CapRevOrCredResItem следующим образом:Скопировать TransIDs из соответствующего CapRevOrCredReqItemЕсли доступно, скопировать RRPID из соответствующего CapRevOrCredItemЗаполнить CapRevOrCredResPayload следующим образом:Занести в CapRevOrCredCode результат кредита или отзыва платежаЗанести в CapRevOrCredActualAmt действительную сумму кредита или отзываЕсли имеется, скопировать BatchID и BatchSequanceNum из соответствующего CapRevOrCredReqItemОпционно заполнить CRvRsPayExtensions
6Опционно заполнить CRvRsExtensions
Структура данных CapRevOrCredResData имеет формат, описанный в таблице 4.6.2.73. Таблица 4.6.2.73.


Структура CapRevOrCredResData
CapRevOrCredResData{CapRevOrCredRRTags, [BrandCRLIdentifier],
[PEThumb], [BatchStatusSeq], CapRevOrCredResItemSeq, [CRvRsExtensions]
CapRevOrCredRRTagsRRTags; копируется CapRevOrCredRRTags из соответствующего поля CapRevOrCredReqData
BrandCRLIdentifierСписок текущих CRL для всех СА в зоне ответственности СА платежной системы.
PEThumbОттиск сертификата расчетного центра, поставляемого, если CapRevOrCredReq.MThumbs указывает, что продавец в нем нуждается
BatchStatusSeq {BatchStatus +}
CapRevOrCredResItemSeq{CapRevOrCredResItem +}
Один или более CapRevOrCredResItem в упорядоченном массиве
CRvRsExtensionsДанные в расширении поля данных отклика на запрос отзыва платежа или кредита должны иметь финансовый характер и быть важными для осуществления отзыва платежа или кредита расчетным центром
BatchStatusСм. табл. 4.6.2.53.
CapRevOrCredResItem{TransIDs, AuthRRPID, CapRevOrCredResPayload}
TransIDsКопируется из соответствующего CapRevOrCredReqData.AuthReqData.AuthTags
AuthRRPIDRRPID, который появляется в соответствующем AuthReq или AuthRevReq
CapRevOrCredResPayloadСм. табл. 4.6.2.74
Структура данных CapRevOrCredResPayload представлена в таблице 4.6.2.74. Таблица 4.6.2.74. Структура CapRevOrCredResPayload
CapRevOrCredResPayload{CapRevOrCredCode, CapRevOrCredActualAmt, [BatchID], [BatchSequenceNum], [CRvRsPayExtensions]}
CapRevOrCredCodeЧисловой код, характеризующий состояние отзыва платежа или кредита.
CapRevOrCredActualAmtКопируется из соответствующего CapRevOrCredReqItem.
BatchIDИдентификатор платежной линии сделки для банка продавца
BatchSequenceNumПорядковый номер позиции в последовательности платежей
CRvRsPayExtensionsРасширение поля данных отклика на запрос отзыва платежа или кредита должны иметь финансовый характер и быть важными для обработки отклика на отзыв платежа или кредит.
Допустимые значения кода CapRevOrCredCode представлены ниже
successПозиция была успешно обработана расчетным центром
unspecifiedFailureПричина неудачи не специфицирована
duplicateRequestЗапрос отзыва платежа или кредита для данной транзакции был уже обработан (XID и AuthRRPID)
originalProcessedЗапрос платежа для данной позиции был уже обработан
originalNotFoundСпецифицированная позиция расчетным центром не обнаружена
capPurgedИнформация о платеже была удалена из памяти транзакций расчетного центра
missingCapDataИнформация о платеже отсутствует в запросе отзыва платежа или кредита
missingCapTokenНеобходимый для обработки данной позиции маркер CapToken отсутствует в запросе отзыва платежа или кредита
invalidCapTokenМаркер CapToken некорректен
batchUnknownПлатежная линия для данной позиции расчетному центру неизвестна
batchClosedПлатежная линия для данной позиции уже закрыта
Обработка продавцом CapRevOrCredResData осуществляется следующим образом.
ШагДействие
1Обработать CRvRsExtensions. Если какое-то нераспознанное расширение помечено как критическое, сообщение отбрасывается и посылается отклик Error = unrecognizedExtension.
2Обработать CapRevOrCredTags
3Извлечь запомненную запись транзакции и обработать TransIDs следующим образом:Проверить, что XID согласуется с данными из записи транзакции. Если согласия нет, сообщение отбрасывается, а в журнал операций записывается Error = unknownXIDПроверить, что LID-C и LID-M согласуются с данными записи транзакции. Если согласия нет, сообщение отбрасывается, а в журнал операций записывается Error = unknownLID.
4Если в сообщение включен BrandCRLIdentifier, запомнить CRL.
5Проверить, что GKThumb согласуется с существующим сертификатом шифрования расчетного центра, если GKThumb присутствует. Если соответствия нет, актуализовать кэш сертификата с использованием текущего сертификата.
6Для каждого BatchStatus в batchStatusSeq обработать BatchStatus и запомнить результат
7Обработать каждый CapRevOrCredResItem в CapRevOrCredResItems следующим образомОбработать CRvRsPayExtensions. Если какое-либо не узнанное расширение помечено как критическое, сообщение отвергается и посылается отклик Error = unrecognizedExtensionИзвлечь записи транзакции, используя TransIDs. Если не удается найти транзакцию с подходящим TransIDs, отвергнуть сообщение и записать в журнал операций Error = unknownXIDСравнить LID-C и LID-M с данными в сообщении. Если согласия нет, сообщение отбрасывается, а в журнал операций записывается Error = unknownLID.Обработать CapRevOrCredPayload следующим образом:Обработать CapRevOrCredCode для получения результатаЕсли предоставление кредита или отзыв платежа прошел успешно, записать CapCode и CapAmtОбработать BatchID и BatchSequenceNum, если таковые имеются



Пара сообщений CapRevReq/ CapRevRes служит для сокращения или аннулирования суммы предшествующего платежа. Они используются после осуществления оплаты и до того, как записи платежа продавца и его банка устареют. Обмен такими сообщениями носит опционный характер. Сообщение CapRevReq может быть послано когда угодно после запроса платежа, направленного расчетному центру. Структура данных в запросе CapRevReq представлена в таблице 4.6.2.75. Таблица 4.6.2.75. Структура CapRevReq
CapRevReq<EncB(M, P, CapRevData, CapTokenSeq), EncBX(M, P, CapRevData, CapTokenSeq, PANToken)>
CapTokenSeq является внешним “багажом”.
Если PANToken содержится в сообщении, поле должно соответствовать одной записи в CapRevData.CapRevOrCredReqItemSeq и одному маркеру CapToken в CapTokenSeq
CapRevDataCapRevOrCredReqData
CapTokenSeq{[CapToken] +}Один или более CapTokens, при полном соответствии последовательности CapRevOrCredReqItem в
CapRevOrCredReqData.CapRevOrCredReqItemSeq.
Заметим, что только маркер CapToken может быть опущен; т.е., может быть нулем (NULL)
PANTokenСм. табл. 4.6.2.46
CapTokenКопируется из соответствующего AuthRes или AuthRevRes
Структура отклика показана ниже CapRevRes.
CapRevResEnc(P,M, CapRevResData)
CapRevResDataCapRevOrCredResData
Пары сообщений CredReq/CredRes используются для возвращения кредита по оплаченным ранее транзакциям. Они могут применяться вместо CapRevReq/Res, когда записи о конкретной транзакции у продавца и в расчетном центре оказались удаленными или устаревшими. Такая последовательность сообщений используется продавцом, который может послать запрос CredReq в любое время после согласования номера счета с банком продавца. Формирование запроса CredReq осуществляется в следующей последовательности.
ШагДействие
1Генерируется информация CredReqData
2Для каждой позиции CapRevOrCred в CapRevOrCredItems заполнить позицию в CapTokSeq следующим образом:Если доступно, записать CapToken для соответствующей транзакции.В противном случае (если недоступно), записать NULL.Результатом этого шага будет CapTokSeq с соответствием один-к-одному между позициями в CredReqData и CapTokSeq
3Если доступно или необходим новый PAN, заполнить PANToken в дополнительную нишу EncBX-инкапсуляции.
Если PANToken имеется, только одна позиция может присутствовать как в CredReqData, так и CapTokSeq
4Если PANToken имеется, использовать EncBX-инкапсуляцию, в противном случае EncB-инкапсуляцию.
5Вставить сообщение в цифровой конверт и послать владельцу карты



Структура запроса CredReq показана в таблице 4.6.2.76. Таблица 4.6.2.76. Структура CredReq
CredReq<EncB(M, P, CredReqData, CapTokenSeq), EncBX(M, P, CredReqData, CapTokenSeq, PANToken)>
CapTokenSeq является внешним “багажом”.
Если PANToken имеется, он должен соответствовать одной записи в CredReqData.CapRevOrCredReqItemSeq и одной CapToken в CapTokenS
CredReqDataCapRevOrCredReqData ; см. табл. 4.6.2.72.
CapTokenSeq{[CapToken] +}
Один или более CapTokens в соответствии один-к-одному с CapRevOrCredReqItem последовательностью в CapRevOrCredReqData.CapRevOrCredReqItemSeq.
Заметим, что любой маркер CapToken может быть опущен, т.е., может быть NULL
PANTokenСм. табл. 4.6.2.46
CapTokenКопируется из соответствующего AuthResили AuthRevRes
Расчетный центр обрабатывает полученный CredReq следующим образом.
ШагДействие
1Извлекается запрос из входного сообщения
2Для каждой позиции, для которой продавец получил маркер CapToken:Проверяется присутствие CapToken. Если CapToken отсутствует, позиция отвергается и присылается CapRevOrReqCode = capTokenMissingПроверяется CapToken
3Для каждой транзакции в сообщении реализовать кредитную операцию, используя существующую финансовую сеть платежной карты, как это специфицировано в содержимом CapRevOrCredItem.
Формирование CredRes осуществляется в следующей последовательности.
ШагДействие
1Получить отклик из финансовой сети платежной карты
2Сгенерировать CredResData, как это описано в CapRevOrCredResData, используя результаты из финансовой сети платежной карты. Заполнить RRTags, полученные в запросе
3Включить Enc-инкапсуляцию для полученных результатов
4Поместить сообщение в цифровой конверт и отправить владельцу карты
Формат отклика CredRes представлен ниже.
CredResEnc(P, M, CredResData)
CredResDataCapRevOrCredResData; см. табл. 4.6.2.74.
Продавец обрабатывает CredRes за два шага: Получается отклик CredRes из входного сообщенияОбрабатывается CredResData, как это описано в CapRevOrCredResData. Для каждого CapRevOrCredResItem проверяется CapRevOrCredCode, чтобы определить результат и записать успешно проплаченную сумму. Сообщения CredRevReq/CredRevRes обеспечивают для продавца механизм отзыва предоставленного ранее кредита.


Формирование запроса CredRevReq осуществляется следующим образом.
ШагДействие
1 Сформировать CredRevReqData, как это описано в разделе CapRevOrCredReq
2Для каждой позиции CapRevOrCred в CapRevOrCredItem заполнить позицию в CapTokSeq следующим образом:Если доступен, занести CapToken для соответствующей транзакцииВ противном случае, если маркер не доступен, записать NULL
3Если доступен или необходим новый PAN, занести PANToken в дополнительную нишу EncBX-инкапсуляции.Если PANToken в наличии, только одна позиция может присутствовать как в CredRevReqData, так и в CapTokSeq.
4Если PANToken присутствует, включить EncBX-инкапсуляцию. В противном случае - EncB-инкапсуляцию.
5Вставить сообщение в цифровой конверт и направить владельцу карты
Структура запроса CredRevReq показана в таблице 4.6.2.77. Таблица 4.6.2.77. Структура CredRevReq
CredRevReq<EncB(M, P, CredRevReqData, CapTokenSeq), EncBX(M, P, CredRevReqData, CapTokenSeq, PANToken)>
CapTokenSeq является внешним “багажом”.
Если PANToken имеется, он должен соответствовать одной записи в CredRevReqData.CredRevReqSeq и однму маркеру CapToken в CapTokenSeq.
CredRevReqDataCapRevOrCredReqData; см. табл. 4.6.2.72
CapTokenSeq{[CapToken] +}
Один или более CapTokens, в соответствии один-к-одному с CredRevReqItem в CapRevOrCredReqData.CapRevOrCredReqItemSeq.
Заметим, что любой CapToken может быть опущен, т.е. может быть NULL
PANTokenСм. табл. 4.6.2.46
CapTokenКопируется из соответствующего AuthRes<=2> или AuthRevRes
Расчетный центр обрабатывает запрос CredRevReq следующим образом.
ШагДействие
1Выделить запрос из входного сообщения
2Для каждой позиции, для которой продавец получил CapToken:Проверить присутствие CapToken. Если CapToken отсутствует, отвергнуть позицию, послав CapRevOrReqCode = capTokenMissingПроверить CapToken
3Для каждой транзакции в сообщении выполнить отзыв кредита, используя существующую финансовую сеть расчетной карты, как это специфицировано содержимым CapRevOrCredItem
Формирование отклика CredRevRes осуществляется в следующей последовательности.
ШагДействие
1Получить отклик из финансовой сети платежной карты
2Сформировать CredRevResData, как это описано в разделе CredRevOrCredResData, используя результаты из финансовой сети карты. Заполнить RRTags, полученные в запросе.
3Включить для полученного результата Enc-инкапсуляцию
4Вложить отклик в цифровой конверт и отправить владельцу карты



Отклик CredRevRes имеет достаточно простой формат:
CredRevResEnc(P, M, CredRevResData)
CredRevResDataCredRevOrCredResData; См. табл. 4.6.2.74.
Продавец обрабатывает полученный отклик следующим образом
ШагДействие
1Извлекается отклик из входного сообщения
2Обрабатывается CredRevResData, как это описано в разделе о CapRevOrCredResData. Для каждого CapRevOrCredResItem проверяется CapRevOrCredCode, чтобы определить результат и записать сумму успешного платежа.
Обработка запроса сертификата расчетного центра включает в себя два сообщения, запрос от продавца к расчетному центру и отклик последнего, направляемый продавцу. В запросе продавец просит расчетный центр прислать ему сертификат, который необходим для последующего шифрования сообщений от продавца к расчетному центру. Сертификат присылается в сообщении-отклике. Генерация запроса PCertReq выполняется в следующей последовательности.
ШагДействие
1Заполнить PCertTags, как это описано в разделе о RRTags табл. 4.6.2.52.
2Рекомендуется заполнить отклики Mthumbs путем вычисления оттисков сертификатов и CRL, хранящихся у продавца. Продавец должен занести оттиски в сообщение, которое может потребоваться позднее для верификации подписей и сертификатов, предоставленных расчетным центром. Включение этого поля служит оптимизации с целью уменьшения передач сертификатов и CRL в последующих сообщениях из расчетного центра.
3Заполнить BrandIDSeq одним или более BrandIDandBIN, для которого необходимы сертификаты:Заполнить поле BrandIDОпционно заполнить поле BIN
4Опционно заполнить поле PCRqExtensions
5Ввести S (см. описание оператора подпись выше)
6Вложить сообщение в цифровой конверт и отправить владельцу карты
Формат сообщения-запроса PCertReq представлен в таблице 4.6.2.78.
PCertReqS(M, PCertReqData)
PCertReqData{PCertTags, [MThumbs], BrandAndBINSeq, [PCRqExtensions]}
PCertTagsRRTags.
Новый RRPID для этого PCertReq, MerTermIDs, поставляемый продавцом, и текущая дата
MThumbsОттиски сертификатов расчетного центра, хранящиеся в кэше продавца.
BrandAndBINSeq{BrandAndBIN +}
Продавец запрашивает сертификаты расчетного центра для платежных систем карты, если оттиск текущего сертификата отсутствует в MThumbs
PCRqExtensionsЗапрос сертификата расчетного центра не шифруется, поэтому это расширение не должно содержать конфиденциальной информации
BrandAndBIN{BrandID, [BIN]}
BrandIDПлатежная система карты (без указания типа).
BINИдентификационный номер банка для обработки транзакции продавца в расчетном центре.



Таблица 4.6.2.78. Структура сообщения PCertReq Расчетный центр обрабатывает PCertReq следующим образом
ШагДействие
1Расчетный центр получает PCertReq из входного сообщения
2Обрабатываются расширения PCRqExtensions. Если встречается нераспознанное расширение, помеченное как критическое, прислается отклик unrecognizedExtensions, а PCertReq отбрасывается.
3Обрабатывается BrandIDSeq и MThumbs
4Формируется и посылается PCertRes
Формирование PCertRes осуществляется в следующей последовательности
ШагДействие
1Скопировать PCertTags из PCertReq в PCertRes
2Для каждого BrandAndBIN в BrandIDSeq из PCertReq:Если доступен корректный сертификат:Заполнить соответствующий сертификат шифрования расчетного центра Cert-PEЗанести в PCertCode, соответствующий PCertResItem c “успешным” кодом PCertCodeЗанести в CertThumb оттиск присланного сертификатаВ противном случае, если сертификаты недоступны, так как не поддерживается данная платежная система, занести PCertCode, соответствующего PСertResItem c кодом PCertCode = brandUnsupported и опустить CertThumbВ противном случае, если платежная система поддерживается, но BIN неизвестен, занести в поле PCertCode соответствующего PсertResItem код PCertCode = unknownBIN и опустить CertThumbВ противном случае занести в поле PCertCode соответствующего PCertResItem код PCertCode = unspecifiedFailure и опустить CertThumb
3Для каждой платежной системы, для которой необходим сертификат, прислать текущее значение BrandCRLIdentifier, если только Mthumbs не содержит оттиска для текущего BrandCRLIdentifier
4Опционно заполнить PCRqExtensions
Структура сообщения-отклика PCertRes представлена в таблице 4.6.2.79. Таблица 4.6.2.79. Структура PCertRes
PCertResS(P, PCertResTBS)
PCertResTBS{PCertTags, [BrandCRLIdentifierSeq], PCertResItems, [PCRsExtensions]}
PCertTagsRRTags; копируется из PCertReq.
BrandCRLIdentifierSeq{BrandCRLIdentifier +}
PCertResItems{PCertResItem +}Один или более статусных кодов и оттисков сертификатов, которые возвращаются в соответствии один к одному с PCertReq.BrandAndBINSeq
PCRsExtentionsСертификатный отклик расчетного центра не шифруется, по этой причине данное расширение не должно содержать конфиденциальных данных.
BrandCRLIdentifierСписок текущих CRL для всех CA в зоне ответственности CA платежной системы. См. раздел о BrandCRLIdentifier
PCertResItem{PCertCode, [CertThumb]}
PCertCodeЦифровой код, указывающий результат PCertReq
CertThumbОттиск возвращенного сертификата



Продавец обрабатывает PCertRes следующим образом.
ШагДействие
1Извлекается отклик из входного сообщения
2Обрабатываются PCRsExtensions. Если встречается нераспознанное расширение, помеченное как критическое, присылается отклик unrecognizedExtensions и отбрасывается PCertRes
3Извлекаются сертификаты из Cert-PE
4Проверяются сертификаты в Cert-PE путем сравнения их с CertThumbs в PCertResItems. Отбрасываются все сертификаты, которые не прошли сверку.
5Обработатывается каждый BrandCRLIdentifier из присланной последовательности таких идентификаторов.
6Продолжается обработка сообщений, которые ожидали сертификатов, присланных в PCertRes.
Стандартизованы следующие значения PcertCode, собранные в таблице 4.6.2.80. Таблица 4.6.2.80. Значения PCertCode
successЗапрос обработан успешно
unspecifiedFailureЗапрос не прошел из-за неспецифицированной причины
brandNotSupportedЗапрос не прошел из-за того, что платежная система, специфицированная в PCertReq, не поддерживается
unknownBINЗапрос не прошел из-за того, что BIN, специфицированный в PCertReq, не поддерживается.
Управление платежными линиями (Batch) Продавец посылает запросы управления платежными линиями расчетному центру для того, чтобы осуществлять контроль над последовательностями платежей расчетных транзакций. Операция управления платежной линией включает в себя обмен двумя сообщениями BatchAdminReq (запрос продавца в расчетный центр) и BatchAdminRes (отклик расчетного центра). Запрос может включать в себя инструкции открыть, очистить или закрыть платежную линию, а также передать или запросить информацию о состоянии платежной линии. Отклик несет в себе информацию о состоянии или запрошенные данные. Платежная линия формируется расчетным центром, когда продавец открывает ее для накопления транзакций и сумм. Все транзакции, которые проплачиваются, объединяются в специфическую группу (платежную линию - batch) или группу по умолчанию, если не определена специальная платежная линия (группа платежей). Следует учитывать, что в группу платежей могут входить операции, выполненные в рамках различных платежных систем.


Поддержка групп платежей позволяет продавцу и расчетному центру улаживать проблемы, связанные с различными несогласованностями. Если продавец контролирует содержимое групп платежей, каждая платежная линия открывается прежде, чем транзакции ассоциируются с ней путем включения BatchID и BatchSequenceNum в платежные транзакции. Продавец может также закрыть платежную линию в соответствии с требованиями бизнеса. Транзакции не ассоциируются с платежной линией после ее закрытия. Продавец может также иметь возможность удалить все транзакции из открытой платежной линии. Очистка платежной линии не означает ее закрытия. Если содержанием платежных линий управляет расчетный центр, продавец не должен вставлять BatchID и BatchSequenceNum в платежные транзакции. Открытие и закрытие платежной линии контролируется в этом случае расчетным центром, который может включать BatchID и BatchSequenceNum в возвращаемую структуру SaleDetail. Продавец при этом не может удалять транзакции из группы или закрывать платежные линии, определенные идентификаторами BatchID, сформированными расчетным центром. Продавец может запросить статусную информацию для любой платежной линии, которая имеет известный BatchID. Расчетный центр возвращает BatchStatus для запрошенной платежной линии. Продавец может запросить BatchStatus для определенных платежных систем или итоговый баланс для конкретной платежной линии. Если продавец управляет содержимым платежной линии, тогда он может предоставлять информацию BatchStatus расчетному центру для любого BatchID. Расчетный центр проверяет данные, предоставленные продавцом в BatchStatus путем сверки с информацией, накопленной у него. При этом продавец получит отклик, в котором будет отражено соответствие этих сумм. Если продавец предоставляет информацию о транзакции расчетному центру, последний выдает состояние серии платежей в отклике BatchAdminRes, который следует за BatchAdminReq. Продавец формирует запрос BatchAdminReq в следующем порядке.
ШагДействие
1Если это первое сообщение, направленное расчетному центру после получения нового секретного ключа, или если это первое сообщение в данный день, в цифровой конверт этого сообщения следует вложить сертификаты для секретных ключей и цепочку сертификатов платежной системы, выбранных продавцом для подписи и шифрования сообщений BatchAdmin.
2Сформировать RRTags
3Если новая платежная линия открыта:Установить BatchOperation = openЗанести в поле BatchID идентификатор для неиспользуемой платежной линии.Опционно занести в поле BrandAndBIN последовательность BrandID и опционно BIN, чтобы ограничить список транзакций, которые могут появиться в данной группе платежей.Установить ReturnBatchSummeryIndicator = FALSEОпустить все остальные поля сообщения
4Если платежная линия (группа платежей) пуста:Установить BatchOperation = purgedЗанести в BatchID идентификацию для неиспользуемой платежной линииОпционно занести в BrandandBIN последовательность BrandID и опционно BIN, чтобы ограничить список транзакций, которые удаляются из группы платежей.Установить ReturnBatchSummeryIndicator = FALSEОпустить все остальные поля сообщения
5Если платежная линия закрыта:Установить BatchOperation = closedЗанести в BatchID идентификацию для открытой платежной линииУстановить ReturnBatchSummeryIndicator = FALSEОпустить все остальные поля сообщения
6Если нужно запросить состояние платежной линии у расчетного центра:Опустить BatchOperationЗанести в BatchID идентификацию для платежной линииОпционно занести в BrandandBIN последовательность BrandID и опционно BIN, чтобы ограничить объем статусной информации, возвращаемой в BatchAdminRes.Установить ReturnBatchSummeryInd = TRUEОпустить все остальные поля сообщения
7Если нужно запросить детальные данные о платежной линии у расчетного центра:Опустить BatchOperationЗанести в BatchID идентификацию платежной линииОпционно занести в BrandandBIN последовательность BrandID и опционно BIN, чтобы ограничить список транзакций, которые удаляются из группы (платежной линии).Если необходима итоговая информация платежной линии, установить ReturnBatchSummeryInd = TRUE, в противном случае = FALSEЕсли это первый (или единственный) запрос в последовательности, установить StartingPoint =0, в противном случае установить StartingPoint равным значению NextSequence, полученному в предшествующем отклике BatchAdminRes для данной последовательности.Занести MaximumItems наибольший номер позиции, которую нужно послать в BatchAdminResОпустить все остальные поля сообщения
8Если нужно послать состояние платежной линии расчетному центру:Опустить BatchOperationЗанести в BatchID идентификацию для платежной линииОпустить BrandandBINУстановить ReturnBatchSummeryInd = FALSEСформировать BatchStatus:Занести в поле BatchTotals значения для всех транзакций данной группы (batch)Опционно занести BrandID и BatchTotals в BranchBatchDetails для одной или более платежных систем, используемых в рамках платежной линии.f) Опустить все остальные поля сообщения
9Если нужно передать расчетному центру детальные данные о платежной линии:Опустить BatchOperationЗанести в BatchID идентификацию для платежной линииОпустить BrandandBINУстановить ReturnBatchSummeryInd = FALSEЕсли это последний (или единственный) запрос в последовательности, установить StartingPoint =0, в противном случае установить NextStartingPoint равным значению, позволяющему расчетному центру проверить, что группа платежей принята в правильной последовательности.Заполнить TransactionDetail для набора позиций платежной линии.Если NextStartingPoint = 0, опционно сформировать BatchStatus:Занести в BatchTotals значения для всех транзакций платежной линии.Опционно занести BrandID и BatchTotals в BranchBatchDetails для одной или более платежных систем, используемых в рамках платежной линии.h) Если продавец хочет прервать передачу BranchBatchDetails, установить значение поля MaximumItem равным 0, в противном случае опустить это поле.
10Реализовать операцию подписи для результата шагов 1-9, используя сертификат подписи продавца для любой платежной системы, известной расчетному центру.
11Включить сертификат шифрования продавца для той же платежной системы, что была выбрана на предшествующем шагу. Общедоступный ключ этого сертификата будет использоваться расчетным центром при дешифровке сообщений BatchAdminRes.
12Зашифровать BatchAdminReqTBE, используя сертификат расчетного центра и установить тип содержимого равным id-set-content-BatchAdminReqTBE.
13Вложить сообщение в цифровой конверт и послать владельцу карты



Структура запроса BatchAdminReq представлена в таблице 4.6.2.81. Таблица 4.6.2.81. Структура BatchAdminReq
BatchAdminReqEnc(M, P, BatchAdminReqData)
BatchAdminReqData{BatchAdminRRTags, [BatchID], [BrandAndBINSeq], [BatchOperation], ReturnBatchSummaryInd, [ReturnTransactionDetail], [BatchStatus], [TransDetails], [BARqExtensions]}
BatchAdminRRTagsRRTags.
Новый идентификатор RRPID и Date (дата)
BatchID Идентификатор платежной линии для счета банка продавца
BrandAndBINSeq{BrandAndBIN +}
BatchOperationЧисловая величина, указывающая на операцию, которая должна быть выполнена в рамках платежной линии
ReturnBatchSummaryIndОбозначает, что в BatchAdminRes должны быть возвращены итоговые данные.
ReturnTransactionDetail{StartingPoint, MaximumItems, ErrorsOnlyInd, [BrandID]}
Если специфицирован BrandID, присылаются данные только для позиций, определяемых платежной системой карты.
BatchStatusСм. табл. 4.6.2.53.
TransDetails{NextStartingPoint, TransactionDetailSeq}
BARqExtensionsДанные в расширении административного сообщения платежной линии должны иметь финансовый характер и быть важными для обработки административных запросов.
BrandAndBIN{BrandID, [BIN]}
StartingPointНуль указывает на то, что следует прислать данные для первой группы позиций, в противном случае NextStartingPoint предшествующего BatchAdminRes
MaximumItemsМаксимальное число позиций, которые следует прислать в этой группе.
ErrorsOnlyIndБулево число, индицирующее, следует ли присылать только позиции с состоянием ошибки.
BrandIDТип платежной системы (без указания типа продукта).
NextStartingPointНуль индицирует, что это последняя группа позиций, в противном случае, используется значение, идентифицирующее начальную точку следующей группы позиций.
TransactionDetailSeq{TransactionDetail +}
BINИдентификационный номер банка для обработки транзакций продавца.
TransactionDetailСм. табл. 4.6.2.54
Расчетный центр обрабатывает запрос BatchAdminReq следующим образом.
ШагДействие
1Выделить запрос из входного сообщения
2Проверить подпись. Если проверка не прошла, присылается отклик Error c ErrorCode = signatureFailure.
3Проверить, что RRPID в BatchAdminReq соответствует RRPID в цифровом конверте сообщения. Если проверка не прошла, присылается отклик Error c ErrorCode = unknownRRPID.
4Если BatchOperation = open:Проверить, что BatchID еще не открыт. Если это не так, установить BAStatus = batchAlreadyOpen.Проверить, что BatchID доступен. Если это не так, установить BAStatus = batchIDUnavailable.Если имеется BrandIDSeq:Проверить, что каждый BrandID поддерживается. Если это не так, установить BAStatus = brandNOTSupported.Проверить, что каждый BIN поддерживается. Если это не так, установить BAStatus = unknownBIN.Запомнить платежные системы и BIN, которые можно использовать для данной платежной линии.Открыть платежную линию для использования продавцом и установить BAStatus = success.Продолжить процесс посылкой BatchAdminResЛюбые другие поля, присутствующие в сообщении BatchAdminReq будут игнорироваться, когда BatchOperation = open.
5Если BatchOperation = purge:
Проверить, что BatchID уже открыт. Если это не так, установить BAStatus = unknownbatchID.Если BrandIDSeq присутствует:Проверить, что каждый BatchID относится к данной платежной линии. Если это не так, установить BAStatus = brandBatchMismatch.Проверить, что каждый BIN относится к данной платежной линии. Если это не так, установить BAStatus = unknownBIN.Удалить все транзакции платежной линии, ассоциированные со специфицированной платежной системой и BIN.В противном случае, удалить все транзакции из группы платежейУстановить BAStatus = successПродолжить работу посылкой сообщения BatchAdminResЛюбые другие поля, присутствующие в сообщении BatchAdminReq, будут игнорироваться, когда BatchOperation = purge.
6Если BatchOperation = close:Проверить, что BatchID уже открыт. Если это не так, установить BAStatus = unknownbatchID.Установить BAStatus = successПродолжить работу посылкой сообщения BatchAdminResЛюбые другие поля, присутствующие в сообщении BatchAdminReq будут игнорироваться, когда BatchOperation = close.
7Если BatchOperation опущено, а возвращенное значение ReturnBatchSummaryInd = TRUE:Проверить, что BatchID доступен. Если это не так, установить BAStatus = batchIDUnavailable.Если BrandAndBIN включен:Проверить, что каждый BatchID относится к данной платежной линии. Если это не так, установить BAStatus = brandBatchMismatch.Проверить, что каждый BIN относится к данной платежной линии. Если это не так, установить BAStatus = unknownBIN.Вычислить BatchTotals и заполнить структуры данных BrandBatchDetails для каждого специфицированного значения BrandAndBIN.Вычислить BatchTotals для платежных систем, включенных в BrandAndBIN, или для всех транзакций, если BrandAndBIN отсутствует. Заполнить BatchTotals в структурах данных BatchStatus вычисленными значениями.Если TransmissionStatus и SettlementInfo доступны в клиринговой системе, используемой расчетным центром, занести эту информацию в BatchAdminRes.Если StartingPoint опущено, установить BAStatus = success и продолжить работу посылкой отклика BatchAdminRes, в противном случае перейти к следующему шагу.NextStartingPoint и TransactionDetailSeq игнорируются, если ReturnBatchSummaryInd = TRUE.
8Если включено поле StartingPoint:Если MaximumItem установлен равным 0, аннулировать любую предшествующую информацию для данной платежной линии и установить BAStatus = success и продолжить работу посылкой отклика BatchAdminRes.Проверить, что BatchID доступен. Если это не так, установить BAStatus = batchIDUnavailable.Если StartingPoint не равен нулю, проверить, что StartingPoint равен NextStartingPoint, присланном в предыдущем отклике BatchAdminRes.Если StartingPoint равен нулю, установить указатель на начало списка платежей, в противном случае установить указатель согласно содержимому StartingPoint.Если имеется BrandAndBIN:Проверить, что каждый BatchID имеет отношение к данной платежной линии. Если это не так, установить BAStatus = brandBatchMismatch.Проверить, что каждый BIN имеет отношение к данной платежной линии. Если это не так, установить BAStatus = unknownBIN.Если специфицировано поле MaximumItems, заполнить TransactionDetail вплоть до MaximumItems из текущей позиции и установить NextStartingPoint в позицию, из которой можно получить данные для последующих транзакций. Если система достигла конца списка платежей, установить NextStartingPoint = 0. Выбор позиции ограничивается BrandandBIN и ErrorOnlyInd.f) Установить BAStatus = success и продолжить работу посылкой отклика BatchAdminRes
9Если код BatchOperation опущен, а BatchStatus имеется:Проверить, что BatchID доступен. Если это не так, установить BAStatus = batchIDUnavailable.Если имеется поле BrandBatchDetails:Проверить, что каждый BatchID имеет отношение к данной платежной линии. Если это не так, установить BAStatus = brandBatchMismatch.Проверить, что каждый BIN имеет отношение к данной платежной линии. Если это не так, установить BAStatus = unknownBIN.Вычислить BatchTotals и заполнить информационные структуры BrandBatchDetails для каждого специфицированного BrandAndBIN.Вычислить BatchTotals для платежных систем, включенных в BrandAndBIN или для всех транзакций, если BrandAndBIN отсутствует.Для любого значения BatchTotals, которое не согласуется с приведенным в сообщении BatchAdminReq, занести вычисленные значения в BatchTotals информационной структуры BatchStatus.Если какое-либо итоговое значение не согласовано, установить BAStatus = totalsOutOfBalance и перейти к следующему пункту.Если поле TransactionDetails опущено, установить BAStatus = success и продолжить работу посылкой отклика BatchAdminRes
10Если код BatchOperation опущен и включено поле TransactionDetails:Проверить, что BatchID доступен. Если это не так, установить BAStatus = batchIDUnavailable.Если указатель StartingPoint не равен нулю и не согласуется с NextStartingPoint из предыдущего BatchAdminReq, установить BAStatus = unknownStartingPoint.Если NextStartingPoint не равен нулю, запомнить TransactionDetails, скопировать NextStartingPoint в сообщение BatchAdminRes и установить BAStatus = success. Продолжить работу посылкой отклика BatchAdminRes.Проверяется соответствие полученных транзакций с теми, что хранятся в расчетном центре. Если отличие обнаружено, установить BAStatus = totalsOutOfBalance. Продолжить работу посылкой отклика BatchAdminRes.Опционно установить BAStatus = stopItemDetail, чтобы проинформировать продавца о том, что расчетный центр не желает обрабатывать позиции в данной последовательности платежей (batch). Продолжить работу посылкой отклика BatchAdminRes.Установить BAStatus = success и продолжить работу посылкой отклика BatchAdminRes.Последовательность BrandAndBIN игнорируется.



Формирование отклика BatchAdminRes осуществляется согласно следующему алгоритму.
ШагДействие
1 Если BAStatus не установлен равным success (успех) или MaximumItems в BatchAdminReq установлен равным 0, аннулировать любую информацию в рамках платежной линии для заданной последовательности запросов BatchAdmin, посланных ранее продавцом.
2Используя сертификат расчетного центра, запустить операцию подписи для BatchAdminResData.
3Зашифровать BatchAdminResTBE, используя сертификат шифрования, поставляемый продавцом, и установить код типа содержимого равным id-set-content-BatchAdminResTBE.
4Вложить сообщение в цифровой конверт и послать владельцу карты.
Структура отклика BatchAdminRes представлена в таблице 4.6.2.82. Таблица 4.6.2.82. Структура BatchAdminRes
BatchAdminResEnc(P, M, BatchAdminResData)
BatchAdminResData{BatchAdminTags, BatchID, [BAStatus], [BatchStatus], [TransmissionStatus], [SettlementInfo], [TransDetails], [BARsExtensions]}
BatchAdminTagsRRTags; копируется из предшествующего BatchAdminReq
BatchIDИдентификатор платежной линии между продавцом и его банком.
BAStatusЧисловой код, указывающий на состояние открытой платежной линии.
BatchStatusСм. табл. 4.6.2.53.
TransmissionStatusЧисловое значение, индицирующее состояние передачи данных из расчетного центра системе вышестоящего уровня
SettlementInfo{SettlementAmount, SettlementType, SettlementAccount, SettlementDepositDate}
TransDetails{NextStartingPoint, TransactionDetailSeq}
BARsExtensionsДанные расширения административного отклика должны носить финансовый характер и иметь значение для обработки административного запроса по поводу платежной линии.
Информация, относящаяся к обработке запроса, должна появляться в расширении BatchAdminResData; информация, относящаяся к состоянию платежной линии, должна содержаться в расширении BatchStatus; информация, относящаяся к информационным деталям позиции в пределах платежной линии должна содержаться в расширении TransactionDetail.
SettlementAmountЗанесенная через сеть на счет продавца сумма
SettlementTypeЧисловой код, указывающий тип суммы
SettlementAccountСчет продавца
SettlementDepositDateДата, когда сумма SettlementAmount будет занесена или снята со счета продавца
NextStartingPointНуль индицирует, что это последняя группа позиций, в противном случае, для идентификации начальной точки следующей группы позиций используется скрытое значение
TransactionDetailSeq{TransactionDetail +}
TransactionDetailСм. табл. 4.6.2.54..



В ниже приведенной таблице представлены стандартизованные значения поля ReimbursementID
unspecifiedНеизвестное значение
standardСтандартная скорость обмена
keyEnteredСкорость обмена для транзакций key-entered (ввод с клавиатуры)
electronicСкорость обмена для электронных транзакций
additionalDataСкорость обмена для транзакций, которые включают в себя дополнительные клиринговые данные
enhancedDataСкорость обмена для транзакций, которые включают в себя усовершенствования (такие как данные дополнительной авторизации).
marketSpecificСкорость обмена для транзакций в пределах специфического сегмента рынка (такого как пассажирский транспорт).
Продавец получает и обрабатывает BatchAdminRes следующим образом.
ШагДействие
1Извлекается отклик BatchAdminRes из входного сообщения.
2Верифицируется подпись. Если проверка не прошла, присылается сообщение Error с ErrorCode = signatureFailed.
3Проверяется, что RRPID в BatchAdminReq соответствует RRPID в цифровом конверте. Если проверка не прошла, присылается сообщение Error с ErrorCode = unknownRRPID.
4Если BAStatus не равен success, а продавец передает или запрашивает подробности о платежной линии, аннулировать любую информацию, запомненную для данной платежной линии и перезапустить процесс, если детальные данные о платежах по-прежнему нужны.
5Если продавец получает детальные данные о платежной линии, запомнить NextStartingPoint для использования в последующих откликах BatchAdminRes. Значение нуль указывает, что все подробности о платежной линии переданы.
6Если продавец передает детальные данные о платежной линии, проверить, что NextStartingPoint согласуется со значением, посланным в BatchAdminReq. Если согласия нет, послать BatchAdminReq с MaximumItems = 0, чтобы расчетный центр аннулировал детали платежной линии, посланные ранее, после чего повторить посылку этих деталей расчетному центру в последующей серии запросов BatchAdmin.
7Запомнить детали из запроса BatchAdmin и передать их расчетным процедурам продавца.
Для реализации протокола SET в конкретных приложениях можно использовать утилиту Wallet () фирмы Microsoft (Microsoft Commerce Server).


Следует учитывать, что, так как система SET является достаточно сложной и дорогостоящей, а продавец должен платить за каждую операцию с кредитной карточкой, то через систему SET проходят платежи, превышающие 10$. Для осуществления более мелких платежей используются другие схемы (например, First Virtual, CyberCoin, DigiCash () или Millicent - ). Схема First Virtual () предназначена для продажи дешевых программных продуктов или услуг. Она предполагает регистрацию клиента, при которой он сообщает номер своей кредитной карточки и получает регистрационный номер (PIN). При покупке клиент вводит свой индивидуальный номер и, если он верен, немедленно получает доступ к нужному ему продукту. Позднее First Virtual связывается с клиентом по электронной почте, уведомляет о цене покупки, предоставляя ему одобрить или нет снятие соответствующей суммы с его кредитной карточки. Эта система зиждется на полном доверии и честности обеих сторон. Система CyberCash () базируется на схеме, сходной с SET. Здесь также используется специальное программное обеспечение со стороны клиента и продавца. Клиент при регистрации получает бесплатно программу CyberCash Wallet и заполняет идентификационную и платежную информацию. Данная информация в зашифрованном виде будет храниться на ЭВМ клиента. Эти данные посылаются при нажатии клиентом клавиши “оплатить”. Система предоставляет клиенту ряд дополнительных услуг, например просмотр баланса последних операций. Назад:
Оглавление:
Вперёд:

P- отклик на ping


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

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

$$-CyberCash-0.8-$$
type: ping-response
id: myCyberCashID [если присутствует в P1]
transaction: 12312313
date: 19950121100505.nnn
server-date: 19950121100506.nnn
swseverity: fatal/warning [отсутствует, если все в порядке]
swmessage; Говорит CyberApp, что оно использует устаревший протокол.
Данный текст отображается для пользователя. [Присутствует только при наличии SWSeverity.]
response-code: success/failure/etc.
message;
Свободный текст комментария об ошибке или успехе.
Этот текст должен быть отображен отправителю его прикладной программой CyberCash.
supported-versions: 08.win, 0.81win, 0.8mac

$$-CyberCash-End-7Tm/djB05pLIw3JAyy5E7A==-$$
#####################################################################
swversion не включается в P1 по соображениям секретности, по этой причине swseverity и swmessage присутствуют, только если сервер может сказать, что эти вещи устарели.
supported-versions позволяет клиенту знать как можно быстрее, какие версии поддерживаются приложением, а какие нет.

P- ping


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

#####################################################################
Отправитель: CyberApp
Получатель: CyberServer
#####################################################################
Пример сообщения:
$$-CyberCash-0.8-$$
type: ping
id: myCyberCashID [optional]
transaction: 123123213
date: 19950121100505.nnn
$$-CyberCash-End-7Tm/djB05pLIw3JAyy5E7A==-$$

#####################################################################
id является опционным, так как персона может быть еще не установлена.

Packaging HTML


PackagedContent может содержать HTML. В этом случае должны выполняться следующие условия:

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

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

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

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

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

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

В качестве руководства разработчику следует иметь в виду, что значения атрибутов Name, относящиеся к элементам PackagedContent, должны допускать извлечение каждого PackagedContent в каталог и отображение HTML непосредственно.

Пакетирование XML


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

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


Во время обработки блока могут произойти временные отказы, которые в принципе могут быть преодолены позднее повторной передачей исходного сообщения. В этом случае партнер информируется о переходной ошибке путем посылки компонента Error (смотри раздел 7.21) с атрибутом Severity равным TransientError и атрибутом MinRetrySecs равным некоторому значению, удобному для используемого транспортного механизма и/или платежного протокола (смотри соответствующие приложения транспортного и платежного протокола). Заметим, что переходные технические ошибки могут генерироваться любыми торговыми агентами, вовлеченными в транзакцию.

Платеж


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


Рис. .12. Проверка того, что Кассир может осуществить платеж

Далее выполняются следующие процедуры:

Идентификация платежного компонента (смотри раздел 7.9) в блоке полученного платежного запроса.

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

- идентификацию компонента списка видов платежей (смотри раздел 7.7), значение его ID-атрибута соответствует атрибуту BrandListRef платежного компонента. Если не обнаружено ни одного или более одного компонента списка видов платежа, возникает состояние ошибки.

- идентификацию компонента списка выбора вида платежа (смотри раздел 7.8), где значение его атрибута BrandListRef соответствует BrandListRef платежного компонента. Если не обнаружено ни одного или более одного компонента выбора вида платежа, возникает состояние ошибки.

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

 - Элемен вида платежа (смотри раздел 7.7.1), где значение его Id-атрибута соответствует значениюатрибута BrandRef выбора вида платежа. Если не обнаружено ни одного или более одного элемента вида платежа, возникает состояние ошибки.
 

- Протокольный элемент суммы (смотри раздел 7.7.3) является элементом, где значение его ID

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

 

- Элемент платежного протокола (смотри раздел 7.7.5) представляет собой элемент, значение Id

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

 

- Элемент валютной суммы (смотри раздел 7.7.4) представляет собой элемент, значение Id

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


Проверяется совместимость ссылок в списке видов платежа и компонентов выбора вида платежа:
 - проверяется, что ссылка элемента существует в атрибуте ProtocolAmountRefs идентифицированного элемента вида платежа, который соответствует ID-атрибуту идентифицированного элемента суммы. Если не может быть обнаружено ни одной или более одной подходящей ссылки элемента, возникает состояние ошибки.
 - проверяется, что атрибут CurrencyAmountRefs идентифицированного элемента суммы, содержит ссылку элемента, которая соответствует ID-атрибуту идентифицированного элемента вылютной суммы. Если не обнаружено ни одной или более одной подходящей ссылки элемента, возникает состояние ошибки.
 - проверяется совместимость элементов в списке видов платежа. В частности, элементы выбранного вида платежа, суммы, платежного протокола и валютной суммы являются дочерними элементами идентифицированного компонента списка видов платежа. Если это не так, то это ошибка.
Проверяется то, что кассир, который получил блок платежного запроса является кассиром, выбранным покупателем. Это включает в себя:
- идентификацию компонента Organisation для кассира. Это компонент Organisation, где его ID-атрибут соответствует атрибуту ActionOrgRef в идентифицированном элементе платежного протокола. Если не обнаружено ни одного или более одного подходящего компонента Organisation, возникает состояние ошибки.
- проверку компонента Organisation, который имеет элемент Trading Role с атрибутом Role кассира. Если его нет, происходит ошибка.
- наконец, если идентифицированный компонент Organisation не совпадает с полученным в блоке платежного запроса, это вызывает ошибку.


Платежное сообщение отклика


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

платежный блок отклика

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

Платежный блок отклика (смотри раздел 8.9) включает в себя:

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

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

опционный компонент накладной (Payment Note) (смотри раздел 7.12);

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

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

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

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

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

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

компонент накладной (Payment Note) из блока платежного отклика,

другие компоненты, на которые ссылается атрибут PayReceiptNameRefs (если имеется) компонента платежной расписки,

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

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

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

Платежный обмен


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

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

1.

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

C а MИнформация о том, что покупается (вне рамок стандарта IOTP)
2.

Продавец решает, какой тип и протокол платежа следует предложить, записывает эти данные в компонент Brand List и посылает покупателю.

C Я M

Компоненты: список типов платежей (Brand List)
3.

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

C а MКомпонент: Выбор из списка типов платежа (Brand List Selection)
4.

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

C Я M

Компонент: Платеж; Организации (продавец и кассир); опционная подпись отклика-предложения, которая подтверждает другие компоненты.

5.

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

C а P

ЗАПРОС ПЛАТЕЖА. Компоненты: Статус, Платеж; Организации (продавец и Кассир); Информация о торговых ролях (опционно); опционная подпись отклика-предложения, которая подтверждает все прочие компоненты. Данные о схеме платежа.

6.

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

C « PПЛАТЕЖНЫЙ ОБМЕН. Компонент: Данные о схеме платежа
7.

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

C « P

ОТКЛИК на ПЛАТЕЖ. Компоненты: Статус, платежная расписка; платежное заявление; данные о торговых ролях (опционно); опционная подпись отклика-предложения; опционная подпись платежной расписки, которая связывает платеж и предложение

8.Покупатель проверяет платежную расписку

Рис. .3. Платежный обмен Платежный обмен использует следующие торговые компоненты, которыми обмениваются покупатель, продавец и кассир: Компонент списка типов платежей содержит перечень допустимых видов платежа (например, MasterCard, Visa, Mondex, GeldKarte), платежные протоколы (например, SET Version 1.0, SCCD (Secure Channel Credit Debit - имя, используемое для платежей через кредитные карточки, где неавторизованный доступ блокируется с помощью механизма формирования безопасного транспортного канала, такого как SSL/TLS), а также сумма и вид валюты. Продавец посылает список типов платежей покупателю. Покупатель сравнивает типы платежей, протоколы, тип валюты и сумму со своими возможностями и делает выбор.Компонент выбора типа платежа содержит выбор покупателя. Тип платежа, протокол, вид валюты, сумма и возможно протокольно зависимая информация посылается продавцу. Эта информация используется для модификации данных предложения (Offer Exchange). Например, продавец может предложить скидку, с тем, чтобы стимулировать использование карточки накопления (store card).Компонент Статус используется, чтобы проинформировать кассира, что обмен предложения успешно завершился, и кассиром для сообщения о благополучном завершении платежного обмена.Компоненты Организаций генерируются Продавцом. Они содержат детали ролей Продавца и Кассира:
 - Роль продавца необходима для того, чтобы Кассир мог идентифицировать, какой продавец инициализировал платеж. Обычно, результатом платежа, реализованного кассиром в пользу продавца, является кредитная или дебитная операция, выполненная со счетом продавца. Эти операции находятся за пределами области действия IOTP
 - Роль кассира необходима, чтобы продавец мог проверить, что платежную операцию произвел именно тот Кассир, который нужно.
Компонент платеж содержит данные о сумме платежа, валюте и направлении оплаты (кто кому).Компонент подпись "Offer Response", если присутствует, цифровым образом подтверждает целостность и корректность всех остальных компонентов.


Заметим, что компоненты списка типов платежа (Brand List) и выбор типа платежа (Brand Selection) не подписываются до тех пор, пока платежные данные не сформированы (шаг 4 на диаграмме).Компонент данные о торговых ролях (Trading Role Data) содержит информацию о других ролях (например, продавца), о которых нужно проинформировать кассира.Компонент схема платежа (Payment Scheme) содержит сообщения платежного протокола, используемого при сделке. Например, это могут быть сообщения SET, сообщения Mondex, сообщения GeldKarte или какого-то другого метода платежа, поддерживаемого IOTP. Содержимое компонента схема платежа (Payment Scheme) определено в приложениях, которые описывают то, как работает IOTP с различными платежными протоколами.Компонент платежной расписки (Payment Receipt) содержит запись о платеже. Содержимое зависит от используемого платежного протокола.Компонент подпись платежной расписки (Payment Receipt) предоставляет подтверждение корректности платежа путем цифровой подписи компонентов платежной расписки и подписи отклика-предложения. Подпись предложения гарантирует целостность и корректность компонентов заказа, организаций, и доставки, содержащихся в предложении. Эта подпись соединяет платеж и предложение. Пример платежного обмена представленного выше, является наиболее общим случаем. Возможны и более простые варианты. Например, если сумма платежа не зависит от выбранного типа платежа и платежного протокола, тогда информация, генерируемая на этапе 3, может быть послана покупателю одновременно с формированием компонента список типов платежей (Brand List) на этапе 1. Эти и другие вариации описаны в разделе базовые торговые операции IOTP (смотри раздел 9.1.8).

Подписи и хэши


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

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

Поиск ошибки в последовательности блоков


Последовательность обработки блоков для роли покупателя та же, что и для IOTP-сервера (смотри раздел 4.5.2.4) за исключением того, что роль покупателя подставляется вместо роли сервера IOTP:

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

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

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

- если блок отклика доставки не относится к транзакции IOTP, которая распознана системой Покупателя, то это серьезная (Hard) ошибка, в противном случае,

 

- если блок отклика доставки не относится к транзакции IOTP, где только что послан блок запроса платежа или платежного обмена, то это серьезная (Hard) ошибка.



Получение логотипов


Ниже описано, как извлекать логотипы для отображения их программой IOTP, используя атрибут Logo Net Locations, содержащийся в элементе вида платежа (смотри раздел 7.7.1) и компоненте Organisation (смотри раздел 7.6). Полный адрес логотипа определяется следующим образом: Logo_address ::= Logo_net_location "/" Logo_size Logo_color_depth ".gif"

Где:

Logo_net_location получено из атрибута LogoNetLocn элемента вида платежа (смотри раздел 7.7.1) или компонента Organisation. Заметим, что:

- содержимое этого атрибута зависит от используемого транспортного механизма (такого как HTTP).

- разработчики должны проверить, что если самый правый символ в Logo Net Location представляет собой "/", тогда другой такой же символ не должен включаться в запись адреса логотипа

Logo_size идентифицирует размер логотипа,

Logo_color_depth идентифицирует насыщенность цвета логотипа;

"gif" идентифицирует, что логотип имеет формат "gif" .

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

Последовательность обработки для роли клиента


"Роль клиента" в IOTP является торговой ролью Покупателя.

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

В частности Покупатель должен быть способен:

oИнициировать транзакции (смотри раздел 4.6.1). Среди них могут быть:
 - платеж, связанный с транзакцией
 - инфраструктурные транзакции.
oВоспринять и обработать сообщение, полученное от другой торговой роли (смотри раздел 4.6.2). Сюда входит:
 - идентификация того, принадлежит ли сообщение транзакции, запущенной ранее;
 - обработка дублированных сообщений;
 - генерирование переходных ошибок, если сервер, который обрабатывет входное сообщение перегружен;
 

- обработка сообщения, если оно не имеет ошибок и, если необходимо, посылка отклика партнеру по результатам обработки.

oАннулировать текущую транзакцию, если поступил соответствующий запрос, например от пользователя (смотри раздел 4.6.3).
o

Повторно передать сообщение, если ожидаемый отклик не пришел своевременно (смотри раздел 4.6.4).



Последовательность обработки для роли сервера


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

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

Принять и обработать сообщение полученное от другой торговой роли (смотри раздел 4.5.2). Сюда относится:

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

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



Последовательности сообщений MM*


Последовательности сообщений CM* представляют собой первичную систему покупок с помощью кредитных карт CyberCash для безопасной обработки денежных оплат клиентами системы. Однако продавцы, которые авторизованы их банком для получения оплаты товаров и услуг, могут также получать оплату по телефону, по почте или наличными. Чтобы исключить для продавца необходимость иметь вторую параллельную систему обработки этих платежей, определены последовательности сообщений MM1 - MM6, которые служат для организации таких менее безопасных транзакций. Сообщения MM* очень похожи на последовательность сообщений CM*, но закрытая секция покупателя на самом деле подписана продавцом, при этом не требуется какого-либо дополнительного CyberCash ID покупателя или ссылки на его кредитную карту.

Повторная передача сообщений


Ретрансмиссия сообщений осуществляется так же, как и в случае сервера IOTP (смотри раздел 4.5.4).

Повторная посылка сообщений


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

оиз-за используемого танспортного механизма;
o

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

oзависит оттого, нужен или нет ввод со стороны человека.

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

o

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

oTimedOutNoRcvr, если транзакция невосстановима.


PR- запрос платежа (payment-request)


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

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

$$-CyberCash-0.8-$$
type: payment-request
merchant-ccid: ACME-012
merchant-order-id: 1231-3424-234242
merchant-date: 19950121100505.nnn
note;
Товары ACME

Покупка 4 пар "Rocket Shoes" по цене $39.95 каждая.
Доставка и вручение $5.00

Общая цена: 164.80

Доставить по адресу: Wily Coyote 1234 South St. Somewhere, VA 12345
merchant-amount: usd 164.80
accepts: visa:CC001, master:CC001,amex:CC001,JCPenny:VK005,macy:VK006
url-pay-to: http://www.ACME.com/CybercashPayment
>url-success: http://www.ACME.com/ordersuccess
>url-fail: http://www.ACME.com/orderfail
merchant-signed-hash:
a/0meaMHRinNVd8nq/fKsYg5AfTZZUCX0S3gkjAhZTmcrkp6RZvppmDd/P7lboFLFDBh
Ec0oIyxWeHfArb3OtkgXxJ7qe0Gmm/87jG5ClGnpBnw0dY7qcJ6XoGB6WGnD $$-CyberCash-End-lSLzs/vFQ0BXfU98LZNWhQ==-$$

Скрытая секция здесь отсутствует.
#####################################################################
При формировании подписанного продавцом хэша используется секретный ключ продавца. Хэш формируется для полей: type, merchant-ccid, merchant-order-id, date, note, merchant-amount, accepts, url-pay-to, url-success, url-fail
#####################################################################

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

accepts: Программа клиента распознает только одно слово имени карты из поля accepts сообщения PR1. Например,

MasterCard
AmericanExpress
Распознаны как
Master card
American express
Не распознаны. MasterCard и masterCard распознаются оба как master card.
За типом карты следует указатель ключа. Для основного ряда кредитных карт это будет CC*. Клиент может использовать или игнорировать * номер по своему выбору. Для личной карты это будет VK*, где * представляет собой ключ CheckFree, который следует использовать. Карты разделяются запятыми, указатель ключа следует за типом карты и двоеточием.

url-pay-to указывает, куда следует послать CH1.

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

Прикладные сообщения и уведомления об ошибках


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

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

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

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

использования ID-атрибутов


На диаграмме проиллюстрировано, как используются значения ID-атрибутов.

Рис. .8. Пример использования ID-атрибутов

подписи IOTP


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

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

Элемент Manifest в компоненте подписи содержит дайджесты TransRefBlock (не покаазан); ID-компонента транзакции (не покаазан); компонентов организаций (Продавца, Кассира, Агента доставки); компонент списка видов платежа; компонент заказа, платежный компонент, компонент доставки и компонент выбора вида платежа (если покупка зависит от вида платежа).

Рис. .11. Пример использование подписи при покупке

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


Для оплаты через 'British Airways' MasterCard для выше приведенного варианта и платежного протокола SET список вида платежа будет иметь вид:

<BrandSelection ID='C1.2' BrandListRef='M1.3' BrandRef='M1.5' ProtocolAmountRef='M1.7'
CurrencyAmountRef='M1.9' >
</BrandSelection>

Примеры логотипа для сетевой позиции


Если логотип сетевой позиции равен "ftp://logos.xzpay.com", тогда:

"ftp://logos.xzpay.com/medium.gif" извлечет логотип среднего размера с 256 цветами

"http://logos.xzpay.com/small4.gif" извлечет логотип малого размера с 16 цветами

Организации, которые делают логотип доступными для работы с IOTP должны всегда допускать размеры "small" и "medium" и использовать формат "gif".

Примеры сообщений


Простое сообщение от клиента:

$$-CyberCash-0.8-$$
id: DONALD-69
transaction: 918273645
date: 199512250102
cyberkey:CC1001
opaque:

GpOJvDpLH62z+eZlbVkhZJXtTneZH32Qj4T4IwJqv6kjAeMRZw6nR4f0OhvbTFfPm+GG
aXmoxyUlwVnFkYcOyTbSOidqrwOjnAwLEVGJ/wa4ciKKI2PsNPA4sThpV2leFp2Vmkm4
elmZdS0Qe350g6OPrkC7TKpqQKHjzczRRytWbFvE+zSi44wMF/ngzmiVsUCW01FXc8T9
EB8KjHEzVSRfZDn+lP/c1nTLTwPrQ0DYiN1lGy9nwM1ImXifijHR19LZIHlRXy8=
$$-End-CyberCash-End-jkn38fD3+/DFDF3434mn10==-$$

Сообщение от продавца:

$$-CyberCash-a.b.c-extra-$$
merchant-ccid: acme-69
merchant-date: 19951231115959
merchant-transaction: 987654321
label: value

labelx: multiple line
value...
# Комментарий
# еще одна строка комментария
label; text with a real
multi-line
format !
merchant-cyberkey: CC1001
merchant-opaque:

C1Q96lU7n9snKN5nv+1SWpDZumJPJY+QNXGAm3SPgB/dlXlTDHwYJ4HDWKZMat+VIJ8y
/iomz6/+LgX+Dn0smoAge7W+ESJ6d6Ge3kRAQKVCSpbOVLXF6E7mshlyXgQYmtwIVN2J
66fJMQpo31ErrdPVdtq6MufynN8rJyJtu8xSNolXlqIYNQy5G2I3XCc6D3UnSErPx1VJ
6cbwjLuIHHv58Nk+xxt/FyW7yAMwUb9YNcmOj//6Ru0NiOA9P/IiWczDe2mJRK1uqVpC
sDrWehG/UbFTPD26trlYRnnY
$$-CyberCash-End-kchfiZ5WAUlpk1/v1ogwuQ==-$$

Примеры видов платежа


Данный пример содержит три образца XML для компонента списка видов платежа:

вариант с просой кредитной карточкой;

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

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

Принципы обработки сообщений


При получении ссобщения-запроса TPO & Authentication (смотри ниже), аутентифицируемый может:

сформировать и послать аутентификатору сообщение-отклик аутентификации или

обнаружив ошибку в запросе аутентификации, послать аутентификатору блок Cancel, содержащий компонент Status аутентификации с атрибутом StatusType и/или ProcessState = Failed и кодом CompletionCode (смотри раздел 7.16.4) равным: AutEeCancel, NoAuthReq, TradRolesIncon или Unspecified.

Получив сообщение-отклик Authentication (смотри ниже), аутентификатор должен в ответ послать сообщение состояния аутентификации, содержащее блок Status с компонентом Status, где StatusType = Authentication и:

атрибут ProcessState компонента Status = CompletedOk, в случае успешного завершения проверки, или

атрибут ProcessState = Failed, а атрибут CompletionCode =: AutOrCancel, AuthFailed или Unspecified, в случае неудачи аутентификации,

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

oуспех аутентификации, тогда аутентифицируемый должен сделать следующее:
-продолжить следующий шаг транзакции, частью которой является документальный обмен аутентификации, или
-индицировать отказ продолжения транзакции путем посылки аутентификатору блока Cancel, содержащего компонент Status с атрибутом аутентификации StatusType, ProcessState = Failed и кодом CompletionCode (смотри раздел 7.16.4) = AutEeCancel.
oаутентификация не прошла, тогда аутентифицируемый должен быть оповещен о неудаче, а процесс остановлен.

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

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

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

сформировать и послать сообщение платежного отклика, если протокольный платежный обмен завершен или

индицировать сбой, послав покупателю блок Cancel, содержащий компонент Status с атрибутом StatusType = Payment, ProcessState = Failed и кодом CompletionCode (смотри раздел 7.16.4) равным: BrandNotSupp, CurrNotSupp, PaymtCancelled, AuthError, InsuffFunds, InstBrandInvalid, InstNotValid, BadInstrument или Unspecified.

Получив платежное ообщение, Покупатель может:

сформировать и послать платежное сообщение Кассиру или

индицировать сбой, послав кассиру блок Cancel, содержащий компонент Status с атрибутами StatusType = Payment, ProcessState = Failed и кодом CompletionCode (смотри раздел 7.16.2) равным: ConsCancelled или Unspecified.

Получив платежное ообщение, кассир может:

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

сформировать и послать сообщение платежного отклика, если протокольный платежный обмен завершен или

индицировать сбой, послав Покупателю блок Cancel, содержащий компонент Status с атрибутами StatusType = Payment, ProcessState = Failed и кодами CompletionCode (смотри раздел 7.16.2) равными: PaymtCancelled или Unspecified.

Получив платежное ообщение-отклик, Покупатель может:

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

остановиться, так как транзакция завершена или

индицировать сбой, послав Продавцу блок Cancel, содержащий компонент Status с атрибутами StatusType = Payment, ProcessState = Failed и кодом CompletionCode (смотри раздел 7.16.1) равным: ConsCancelled или Unspecified.

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

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

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


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

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

По получении сообщения платежного отклика и отклика доставки транзакция завершена.

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

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

Если продавец получает сообщение IOTP, содержащее блок Cancel, тогда покупатель должен прервать операцию платежа. В этом случае покупатель вероятно обратится в сетевой узел CancelNetLocn, специфицированный элементом торговой роли в компоненте Organisation для продавца. Здесь он может предпринять какие-то дальнейшие действия.


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

сформировать и послать покупателю сообщение-отклик доставки или

индицировать сбой путем посылки покупателю блока Cancel, содержащего компонент Status с StatusType = Delivery, ProcessState = Failed и кодом CompletionCode (смотри раздел 7.16.4) равными: DelivCanceled или Unspecified.

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

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

Принятие решения о применении электронной подписи


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

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

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

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

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

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

- будет ли сообщение принято налоговой службой, в качестве корректной записи транзакции;
- если нужна гарантия, например, от "Better Business Bureau" или подобной организации.

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

Привязка кредитных карт (Binding Credit Cards)


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

Процесс авторизации кредитной карты и расчета


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

(1)

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

(2)приобретение (capture): платежная информация для покупки вводится продавцом в расчетный документ.
(3)оплата (clearance): обработка перечня товаров. Это вызывает появление товаров из перечня в записи о покупке для данной кредитной карты. Эта запись посылается банку, предоставившему кредитную карту покупателю.
(4)урегулирование (settlement): межбанковская операция по пересылке денежных средств.
(5)удаление (void): продавец отменяет шаг 2 (или 6), сумма оплаты удаляется из расчетного документа. Операция должна быть выполнена до осуществления оплаты.
(6)кредит (credit): продавец вводит отрицательную сумму оплаты в расчетный документ. Эта сумма появится в записи о покупке владельца кредитной карты.

Четвертый шаг (settlement) реализуется исключительно в банковской среде. CyberCash 0.8 формирует сообщения для реализации шагов 1, 1&2, 2, 5 и 6. это справедливо для систем работы с кредитными картами, где данные о сделке накапливаются в банке или в системе продавец-банк. CyberCash 0.8 поддерживает такие системы. Другие системы работы с кредитными картами требуют того, чтобы все данные о сделке хранились у продавца. Такие системы часто называются "терминальными покупками" ("terminal capture"). Это делает операции 2, 5 и 6 внутренними для продавца, но требует сообщений для выполнения операции 3. Такие сообщения о денежных расчетах будут включены в будущие версии CyberCash для приложений продавца и сервера.

Простой пример, базирующийся на кредитной карте


Этот простой пример включает в себя:

только основные виды платежей с помощью кредитной карты;

одну цену и одну валюту;

одного Кассира и

один платежный протокол.

<BrandList ID='M1.2' XML:Lang='us-en' ShortDesc='Purchase book including s&h'
PayDirection='Debit' >
<Brand ID ='M1.30' BrandId='MasterCard' BrandName='MasterCard Credit'
BrandLogoNetLocn='ftp://otplogos.mastercard.com/mastercardcredit'
ProtocolAmountRefs='M1.33'>
</Brand>
<Brand ID ='M.31' BrandId='Visa' BrandName='Visa Credit'
BrandLogoNetLocn='ftp://otplogos.visa.com/visacredit' ProtocolAmountRefs='M1.33'>
</Brand>
<Brand ID ='M1.32' BrandId='AmericanExpress' BrandName='American Express'
BrandLogoNetLocn='ftp://otplogos.amex.com' ProtocolAmountRefs ='M1.33' >
</Brand >
<ProtocolAmount ID ='M1.33' PayProtocolRef='M1.35' CurrencyAmountRefs='M1.34'>
</ProtocolAmount>
<CurrencyAmount ID ='M1.34' Amount='10.95' CurrCode='USD'/>
<PayProtocol ID ='M1.35' ProtocolId='SCCD1.0' ProtocolName='Secure Channel Credit/Debit'
PayReqNetLocn='http://www.example.com/etill/sccd1' >
</PayProtocol>
</BrandList>

CyberCash Inc. представляет собой компанию,


Семёнов Ю.А. (ГНЦ ИТЭФ), book.itep.ru CyberCash Inc. представляет собой компанию, базирующуюся в штате Вирджиния и основанную в августе 1994. Целью компании является посредничество в сфере платежей через Интернет. CyberCash выполняет функцию посредника, через которого осуществляются финансовые операции между покупателем, продавцом и их банками. Важно то, что до начала операции участники могут не иметь никаких отношений друг с другом. CyberCash является третьей стороной, которая гарантирует надежную проводку платежа от одного партнера к другому.

Протокол микроплатежей MPTP (Micro Payment Transfer Protocol)


Разработчики технологии WWW, HTML и XML (группа W3C; ) разработали проект платежного протокола, который является модификацией алгоритма Pay-Word, предложенного Ривестом и Шамиром (“PayWord and MicroMint - Two Simple Micropayment Schemes”, R.L. Rivest and A.Shamir; ). Электронная коммерция предполагает рекламу, продажу материальных и нематериальных товаров. Материальные товары требуют доставки, что усложняет процедуру купли-продажи. Торговля через Интернет требует минимизации времени отклика для клиента. Кроме того, важно, чтобы издержки, сопряженные с торговыми операциями, составляли небольшую долю стоимости покупки, что становится весьма критично при низкой стоимости приобретаемого товара или услуги. При проектировании новых торговых систем следует учитывать, что процедуры верификации электронной подписи могут выполняться на стандартной рабочей станции со скоростью около 1000/сек, а вычисление однопроходной хэш-функции занимает примерно 10 мксек. Контроль хэш-функции в 100 раз быстрее, чем верификация RSA-подписи, и в 10000 раз быстрее формирования RSA-подписи. Таким образом, современная персональная ЭВМ вполне успешно может решать любые торговые операции даже в режиме сервера, который обслуживает десятки и сотни клиентов одновременно. Время отклика в любом случае не будет превышать одной секунды. Работа в реальном масштабе времени предлагает на два порядка более высокие требования, чем работа в режиме off-line.

Протокол MPTP является асинхронным (большинство операций выполняются в режиме off-line). MPTP не делает различия между покупателем и продавцом. Протокол предполагает существование посредника-брокера (B; банкира), который контролирует счета участников сделок. Под брокером может подразумеваться любая организация, способная работать со счетами достаточно большого числа клиентов при минимальных издержках. Брокером может быть сервис-провайдер (ISP), телефонная компания или банк.

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

Злоупотребление кредитом (осуществление платежей через счет без реального намерения платить)

Мошенничество (например, направление фиктивного платежного поручения).

Неавторизованный отзыв платежа

Неавторизованная модификация заказа

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

Дублирование платежного поручения (клиентом или третьим лицом)

Отказ от услуги (клиент или продавец отказываются использовать свои счета)

Отказ выполнения платежа

Недоставка (платеж получен, а товар не доставлен).

Протокол поддерживает любую политику платежей, которая может согласовываться покупателем (С) и продавцом (М).
Классическим объектом политики является, например, требование предоплаты. При обслуживании малоценных покупок целесообразен определенный уровень доверия и соответствующий ему уровень риска. При этом продавец мониторирует случаи отказов при платежах, выявляя недобросовестных покупателей. Стандартная схема работы с кредитной картой в данном случае является чрезмерно избыточной. Алгоритм платежа в MPTP основан схеме PayWord (1996 г.), где вычисляется цепочка значений хэш-функций c привлечением схемы MD5 или SHA. Полученные значения имеют 128 или 160 бит, допускается и меньшая длина. Схема PayWord является кредитной и практически реализует схему электронных монет. Пользователь запрашивает у брокера (банкира) счет и сертификат, передав ему по безопасному каналу номер своей кредитной карты, общедоступный ключ шифрования и адрес доставки (например, E-mail или IP-адрес). Брокер при этом посылает сертификат покупателя СП, который имеет вид: СП = [B, ID, AП, PKП, E, IП]SKB где B - идентификатор (имя) брокера; ID - идентификатор покупателя; AП - адрес доставки; PKП - общедоступный ключ покупателя; Е - время истечения действия сертификата (брокер может обновлять его, например, раз в месяц); IП - дополнительная информация, задаваемая брокером, например, серийный номер сертификата, лимит кредита и т.д.; SKB - секретный ключ брокера. Сертификат СП получен путем шифрования содержимого квадратных скобок с помощью SKB. В некоторых других платежных схемах сертификат формируется клиентом-покупателем. Сертификат устанавливает связь между общедоступным ключом покупателя и его счетом для заданного общедоступного ключа брокера. Предполагается, что общедоступный ключ брокера известен всем участникам платежного процесса. Генерация пар общедоступный-секретный ключ осуществляется каждым участником независимо. Данная схема не гарантирует анонимности (AП!), более того, здесь имеется риск утечки информации о номере кредитной карты пользователя. Сертификат гарантирует продавцу, что платежные слова (payWord) покупателя будут выкуплены брокером. Далее будем предполагать, что чтение одной страницы на коммерческом сервере продавца стоит один рубль (стоимость одного платежного слова согласуется на фазе инсталляции сессии). Когда пользователь обращается к коммерческой странице продавца, его броузер определяет, является ли данный вызов первым в этот день.


Если это первое обращение, программа покупателя формирует и подписывает обязательство, сопряженное с цепочкой платежных слов w1, w2, …, wn, где wn выбирается случайным образом. Значение n определяется клиентом. Все остальные платежные слова вычисляются рекурсивно, согласно соотношению: wi = H(wi+1) для i= n-1, n-2,…,0. Здесь w0 является корнем цепочки платежных слов, а не платежным словом. H - представляет собой однопроходную хэш-функцию типа MD5 или SHA. После этого клиент передает программе продавца обязательство и свой сертификат, программа верифицирует эти данные, используя общедоступный ключ брокера. i-платеж (для i = 1, 2, …) продавцу состоит из пары чисел (wi,i). Продавец может проверить это посылку, используя значение wi-1. Стоимость всех платежных слов (PayWord) w1, w2, …, wn идентична. Каждый платеж не предполагает каких-либо вычислений в программе покупателя и лишь одну хэш-операцию в программе продавца. Платежи должны быть индексированы в соответствии с порядком (i) сформированных платежных слов. Это исключает повторное использование платежных слов. Но возможна передача после платежного слова wi платежного слова wi+10, это будет означать оплату очередной покупки стоимостью 10 рублей (если одно платежное слово стоит один рубль). В конце каждого дня продавец передает брокеру последнее платежное сообщение за этот день (wl, L) каждого из покупателей, добавляя к нему соответствующее обязательство. Брокер снимает со счета покупателя L рублей (L платежных слов) и переводит их на счет продавца. Предполагается, что существует всего несколько брокерских центров на страну. Практически все операции выполняются в режиме off-line, а брокер не получает даже сообщений о каждом платеже (а только о последнем за данный день). Заметим, что в данной системе не специфицируется явно то, за какой товар или услугу осуществлен платеж. В некоторых платежных схемах обязательство выполняет функцию электронной кредитной карты или чека.

Проверка авторизованности операции


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

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

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

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

 - Продавец известен и существует соглашение с операционной организацией (кассиром или агентом доставки);
 

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

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

Проверка корректности подписей. Если подписи необходимы, они должны быть проверены. Это подразумевает:

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

транзакции (смотри раздел 9) может идентифицироваться одна или две подписи;

- проверку того, что компоненты подписи корректны. Это включает проверку того, что существуют элементы дайджеста в элементе Manifest, который относится к обязательным торговым компонентам (смотри раздел 6.3.3.1).


Проверка компонентов Correct, присутствующих в блоке запроса


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

Проверка корректности дайджестов подписи


Все компоненты Signature, содержащиеся в IOTP-сообщении должны включать элементы Digest, которые относятся к:

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

блоку ссылок транзакции (смотри раздел 3.3) первого сообщения IOTP, которое содержит подпись. Это связывает IotpTransId с информацией о сообщении IOTP, содержащемся в Id-компоненте сообщения (смотри раздел 3.3.2).

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

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

если подписант является продавцом, тогда:

 

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

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

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


Проверка корректности вычисления подписи


Проверка корректности вычисления электронной подписи является частью проверки ошибок уровня сообщения (смотри раздел 4.3.2).

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

проверка того, что блок подписи присутствует и содержит один или более компонентов подписи;

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

использование ID-атрибута компонента организации, чтобы найти элемент RecipientInfo, который содержит атрибут RecipientRefs, имеющий отношение к компоненту Organisation. Заметим, что может не быть подписи и по этой причине нечего проверять.

проверка компонента Signature, который содержит идентифицированный элемент RecipientInfo в виде:

 - используются атрибуты SignatureValueRef и SignatureAlgorithmRef, чтобы идентифицировать, соответственно: элемент Value, который содержит подпись, подлежащую проверке и элемент алгоритма подписи, который характеризует алгоритм вычисления подписи, предназначенный для ее верификации, затем
 - если элемент алгоритма подписи указывает, что использована асимметричная криптография, тогда для идентификации сертификата применяется SignatureCertRef;
 - если элемент алгоритма подписи указывает, что использована симметричная криптография, тогда для идентификации корректного значения общего ключа используется содержимое элемента RecipientInfo;
 - используется специфицированный алгоритм подписи для проверки того, что элемент Value правильно подписывает элемент Manifest;
 - проверется, что элементы Digest в элементе Manifest вычислены правильно. При этом предполагается, что компоненты или блоки, на которые ссылается дайджест, были получены организацией, выполняющей проверку подписи.


Проверка ошибок в последовательности блоков


Далее при объяснении поиска ошибок в последовательностях блоков выражение типа "относится к транзакции IOTP" следует интерпретировать как "содержится в сообщении IOTP, где TransRef Block включает в себя IotpTransId, который указывает на данную танзакцию". Так, например, "Если ошибка или аннулированный блок относится к транзакции IOTP, которая не распознана, тогда..." следует интерпретировать как "Если ошибка или аннулированный блок содержатся в сообщении IOTP, TransRefBlock включает в себя IotpTransId, который относится к транзакции IOTP, которая не распознана, тогда...”.

Ошибки в последовательности прихода блоков зависят от блока. Блоки, где требуется проверка последовательности:

Error и Cancel блоки. Если Error или Cancel блок относится к транзакции IOTP, которая не распознана, тогда это серьезная (Hard) ошибка. Чтобы избежать зацикливания, не следует посылать оповещения об ошибке, если получен Error или Cancel блок транзакции IOTP.

Блоки отклика и информационного запроса. Если блоки отклика и информационного запроса относятся к транзакции IOTP, которая не распознана, это серьезная (Hard) ошибка.

Блок запроса аутентификации. Если блок запроса аутентификации относятся к транзакции IOTP, которая распознана, это серьезная (Hard) ошибка.

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

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

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

oБлок выбора TPO (только для продавца) прооверяется следующим образом:
 - если блок выбора TPO не относится к транзакции IOTP, которая распознана, то это серьезная (Hard) ошибка, в противном случае,
 - если блок выбора TPO не относится к транзакции IOTP, где блок TPO и отклик предложения (в одном сообщении) были посланы ранее, то это серьезная (Hard) ошибка, в противном случае,
 

- если блок выбора TPO относится к транзакции IOTP, где только блок TPO (т.e. без отклика на предложение) был послан ранее, то это серьезная (Hard) ошибка, в противном случае,

 

- если блок выбора TPO для того же блока TPO получен ранее, то это серьезная (Hard) ошибка.

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

- если предыдущий платеж еще в работе, то это серьезная (Hard) ошибка.

o

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

 

- если блок платежного обмена не относится к транзакции IOTP, которая распознана, то это серьезная (Hard) ошибка, в противном случае

 - если платежный обмен не относится к транзакции IOTP, где такой обмен уже был, то это серьезная ошибка (Hard).
oЗапрос доставки (только для агентов доставки). Если блок запроса доставки относится к транзакции IOTP, которая распознана сервероим, то это серьезная ошибка.


Проверка платежа или доставки


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

При этом осуществляются следующие шаги:

проверка того, что платежный запрос или запрос доставки посланы правильной организацией;

проверка того, что в запросе представлены правильные компоненты IOTP;

проверка того, что платеж или доставка авторизованы.

В данном разделе используются следующие термины:

"Блок запроса" используется в связи с блоком запроса платежа (смотри раздел 8.7) или блоком запроса доставки (смотри раздел 8.10), если не специфицировано обратного;

"Блок отклика" используется в связи с блоком платежного отклика (смотри раздел 8.9) или блоком отклика доставки (смотри раздел 8.11);

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

"Операционная организация" используется в отношении Кассира или Агента доставки, которые реализуют операцию;

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

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

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

Проверка структуры и идентификация сообщений


Крайне важно проверить, что сообщение имее корректную XML-форму и идентификатор транзакции (IotpTransID-атрибут компонента TransId) в сообщении IOTP может быть распознан, так как IotpTransId будет нужен при формировании отклика.

Если входное сообщение сформировано некорректно, тогда генерируется компонент Error с атрибутом Severity равным HardError и код ошибки XmlNotWellFrmd.

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

oатрибутом Severity = HardError и кодом ошибки (ErrorCode) = AttMissing,
o

содержимым PackagedContent, включающим в себя "IotpTransId" потерянного атрибута.

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

Проверка того, что блок запроса послан правильной организацией


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

Проверки атрибутов блочного уровня и элементов


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

Проверки элемента и атрибута блочного уровня включают в себя:

проверку того, что значение каждого атрибута в каждом элементе блока согласуется с правилами спецификации IOTP;

проверку того, что содержимое каждого элемента согласуется с правилами спецификации IOTP;

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

Проверки согласованности компонентов и блоков


Проверки согласованности компонентов и блоков состоит из:

проверки того, что комбинации блоков и/или компонентов, присутствующих в сообщении IOTP, согласуются с правилами спецификации;

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

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

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

R- отклик регистрации


Это сообщение предоставляет отклик об успехе или неудаче R1.

#####################################################################
Отправитель: CyberServer
Получатель: CyberApp
#####################################################################

Пример сообщения:
$$-CyberCash-0.8-$$
transaction: 12312313
date: 19950121100505.nnn
opaque:
r1XfjSQt+KJYUVOGU60r7voFrm55A8fP5DjJZuPzWdPQjGBIu3B6Geya8AlJfHsW11u8
dIv1yQeeYj/+l9TD1dXW21/1cUDFFK++J2gUMVv8mX1Z6Mi4OU8AfsgoCliwSkWmjSOb
kE62sAlZTnw998cKzMFp70TSlI3PEBtvIfpLq5lDCNbWidX8vFZV0ENUmMQ9DTP3du9w
fsFGvz1mvtHLT/Gj8GNQRYKF4xiyx4HYzTkSMhgU5B/QDLPS/SawIJuR86b9X0mwsr0a
gbGTzECPJTiKkrhxxMG/eymptsVQSLqNaTCx6w==
$$-CyberCash-End-kchfiZ5WAUlpk1/v1ogwuQ==-$$
#####################################################################
Скрытый ключ. Тот же самый, что и ключ сессии для R1 в случае той же транзакции и того же соединения (ID может отсутствовать).
#####################################################################
Содержимое скрытой секции:
type: registration-response
server-date: 19950121100506.nnn
requested-id: MyRequestedCCID
response-id: CyberCashHandle
>email: myemail@myemailhost.com
response-code: success/failure/etc.
pubkey:
0VdP1eAUZRrqt3Rlg460Go/TTs4gZYZ+mvI7OlS3l08BVeoms8nELqL1RG1pVYdDrTsX
E5L+wcGCLEo5+XU5zTKkdRUnGRW4ratrqtcte7e94F+4gkCN06GlzM/Hux94
swseverity: fatal/warning [отсутствует, если все в порядке]
swmessage; Говорит CyberApp, что оно является устаревшим. Этот текст отображается для пользователя [присутствует только, если имеется SWSeverity].
message;
Произвольный текст уведомления об успехе или неудаче.
Этот текст должен быть отображен для владельца приложения CyberCash...
В принципе текст включает в себя: duplicate-id (дублированный ID), bad-signature (ошибочная подпись) или ill-formed-registration (некорректная регистрация).

Объяснение:

responseid

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

responseidпредоставляет действительный ID с присоединенными контрольными символами в случае успеха.
swseverityможет предупредить пользователя о том, что приложение устарело или о наличии в нем известных ошибок.


R- регистрация


Описание: Это исходное сообщение, посылаемое для формирования новой персоны CyberCash.

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

$$-CyberCash-0.8-$$
transaction: 123123213
date: 19950121100505.nnn
cyberkey: CC1001
opaque:
FrYOQrD16lEfrvkrqGWkajM1IZOsLbcouB43A4HzIpV3/EBQM5WzkRJGzYPM1r3noBUc
MJ4zvpG0xlroY1de6DccwO9j/0aAZgDi9bcQWV4PFLjsN604j3qxWdYn9evIGQGbqGjF
vn1qI1Ckrz/4/eT1oRkBBILbrWsuwTltFd84plvTy+bo5WE3WnhVKsCUJAlkKpXMaX73
JRPoOEVQ3YEmhmD8itutafqvC90atX7ErkfUGDNqcB9iViRQ7HSvGDnKwaihRyfirkgN
+lhOg6xSEw2AmYlNiFL5d/Us9eNG8cZM5peTow==
$$-CyberCash-End-kchfiZ5WAUlpk1/v1ogwuQ==-$$
#####################################################################
Скрытый ключ: Сгенерирован с использованием общедоступного ключа CyberCash, идентифицированного в CyberKey.
#####################################################################
Содержимое скрытой секции:
type: registration
swversion: 0.8win
content-language: en-us
requested-id: MyRequestedCCID
email: myemail@myemailhost.com
pubkey:
0VdP1eAUZRrqt3Rlg460Go/TTs4gZYZ+mvI7OlS3l08BVeoms8nELqL1RG1pVYdDrTsX
E5L+wcGCLEo5+XU5zTKkdRUnGRW4ratrqtcte7e94F+4gkCN06GlzM/Hux94
signature:
v6JGmxIwRiB6iXUK7XAIiHZRQsZwkbLV0L0OpVEvan9l59hVJ3nia/cZc/r5arkLIYEU
dw6Uj/R4Z7ZdqO/fZZHldpd9+XPaqNHw/y8Arih6VbwrO5pKerLQfuuPbIom
#####################################################################
подпись покрывает следующие поля: transaction, date, cyberkey, type, swversion, content-language, requested-id, email, pubkey
#####################################################################
Объяснение:
content-language (язык содержимого) берется из поля заголовка MIME (смотри RFC-1766) и соответствует языку, на котором должно быть написано сообщение (в настоящее время допустимо пока только en-us). swversion используется для проверки, не является ли приложение клиента устаревшим.

Рабочие ошибки


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

Например, "Недостаточно средств" является сообщением об ошибке при платеже, но не имеет никакого значения для доставки, в то время как "Back ordered" возможное сообщение об ошибке доставки, но не имеет смысла для платежа. Рабочие ошибки индицируются компонентом Status (смотри раздел 7.16) "блока отклика" соответствующего типа, например, блока Payment Response или Delivery Response. Это допускает любой дополнительный отклик, связанный с информацией, которая необходима для пояснения возникшей ошибки.

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

Рабочие ошибки блочного уровня


Если в процессе платежа или доставки происходит рабочая ошибка, тогда присылается соответствующий тип блока отклика, содержащий компонент Status (смотри раздел 7.16) с атрибутом ProcessState равным Failed и CompletionCode, указывающим на природу проблемы.

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

Преодоление переходных рабочих ошибок зависит от CompletionCode. Для понимания имеющихся возможностей смотри определение компонента Status. Заметим, что для рабочих ошибок не формируется компонент или блок Error.

Работа с кредитной картой


При использовании системы CyberCash для транзакций с применением кредитной карточки, покупателю, решившему произвести покупку, достаточно кликнуть на клавише CyberCash "PAY" панели продавца. Продавец посылает покупателю счет, который содержит информацию о покупке, отображаемую на экране дисплея покупателя. (Смотри описание сообщения PR1). Покупатель добавляет номер своей кредитной карточки и другую информацию путем выбора соответствующих пунктов из списка кредитных карт, зарегистрированных на его CyberCash-персону. Вся эта информация снабжается электронной подписью покупателя, реализуемой посредством программы СyberCash, шифруется, и передается продавцу вместе с хэш-кодом счета. (Смотри описание сообщения CH1.)

При получении этого сообщения, продавец добавляет туда информацию авторизации, которая шифруется, снабжается электронной подписью продавца и пересылается серверу CyberCash. (Смотри описание сообщений CM1 & CM2). Сервер CyberCash может аутентифицировать все подписи для подтверждения того, что покупатель и продавец согласились с корректностью счета и правильностью суммы стоимости сделки. Сервер CyberCash переадресует соответствующую информацию в банк, сопровождая ее запросом на производство платежа в пользу продавца, включая его авторизацию. Банк дешифрует и обрабатывает полученную информацию, после чего осуществляет соответствующую операцию с кредитной карточкой. Отклик банка передается серверу CyberCash, который присылает продавцу электронную квитанцию (смотри описание сообщения CM6) часть которой продавец переадресует покупателю (смотри описание сообщения CH2). На этом транзакция завершается.

Расширение IOTP


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

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