Интегрированные сети ISDN

         

Значения кодов RequestType



Таблица 4.6.2.19. Значения кодов RequestType



Тип запроса

Только сертификат подписи

Только сертификат шифрования

Оба сертификата

Начальный запрос владельца карты

1

2*

3*

Запрос обновления владельца карты

10

11*

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:
        1. Заполнить поле причины информацией об отказе обслуживания, которая будет отображена владельцу карты.
        2. Опционно записать в поле ReferralLoc почтовый адрес и/или URL, где пользователь может получить дополнительную информацию о причине отказа обслуживания.

    2

    Подписать результат шага 1 (то есть данные RegFormTBS), установить contentType для SignedData равным id-set-content-RegFormTBS.

    3

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

    Структура сообщения RegFormRes представлена в таблице 4.6.2.20.



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