использование подписи при покупке
Рисунок .11. Пример использование подписи при покупке
6.1.2. Элементы OriginatorInfo и RecipientInfo
Атрибут OriginatorRef элемента OriginatorInfo в компоненте подписи содержит ссылку на элемент (смотри раздел 3.5), которая указывает на комполнент организации, сгенерировавшей подпись. В данном примере это продавец.
Заметим, что значение элемента атрибута с атрибутом типа, устанавленным равным типу подписи IOTP, должно соответствовать торговой роли организации, которая его подписала. Если это не так, возникает ошибка. Корректные значения представлены ниже в таблице.
Тип подписи IOTP |
Корректная торговая роль |
| OfferResponse | Продавец |
| PaymentResponse | Кассир |
| DeliveryResponse | Агент доставки |
| AuthenticationRequest | Любая роль |
| AuthenticationResponse | Любая роль |
| PingRequest | Любая роль |
| PingResponse | Любая роль |
Атрибут RecipientRefs элемента RecipientInfo в компоненте подписи содержит ссылки элементов на компоненты организации, которая должна использовать подпись, чтобы проверить:
| о | они имеют отношение к организации, генерировавшей подпись, |
| о | данные, защищенные подписью, не были изменены, |
| о | данные были подписаны корректно |
| о | действия, которые нужно предпринять для продавца авторизованы. |
Заметим, что, если используется симметричная криптография, отдельные элементы RecipientInfo и Value для каждого набора общих секретных ключей размещаются в компоненте Signature. В противном случае, если используется асимметричная криптография, атрибут RecpientRefs одного элемента RecipientInfo может относиться к нескольким компонентам Organisation, если они все используют один и тот же сертификат.
6.1.3. Использование подписей для подтверждения корректного завершения операций
Проверка успешного завершения операции осуществляется с помощью подписи данных сообщений-откликов. В частности:
- для отклика предложения, когда продавец делает предложение Покупателю, котоорое может быть затем послано:
| - Кассиру, чтобы проверить, что продавец авторизует платеж; | |
| - Агенту доставки, чтобы проверить, что продавец авторизует доставку. |
- Для платежного отклика, когда Кассир генерирует платежную расписку, которая может быть послана:
| - Агенту доставки, в блоке запроса доставки для авторизации доставки вместе с подписью отклика предложения, или | |
| - другому кассиру во втором платежном запросе, чтобы авторизовать второй платеж в транзакции обмена ценностями. |
- Отклик доставки, когда Агент доставки генерирует накладную (Delivery Note). Это может быть использовано, чтобы проверить по завершении, что все сделано так как надо.
- Отклик доставки. Один метод аутентификации партнера по сделке заключается в посылке запроса аутентификации, где определено, что эта процедура предсматривает использование электронной подписи.
- Запрос состояния транзакции. Блок отклика информационного запроса может быть снабжен цифровой подписью, чтобы удостоверить аутентичность отклика.
- Ping. Отклик Ping может быть подписан, чтобы иметь возможность проверки распознаваемости подписи.
Проверка корректности вычисления электронной подписи является частью проверки ошибок уровня сообщения (смотри раздел 4.3.2).
Прежде чем торговая роль сможет проверить подпись, она должна идентифицировать, какой из элементов подписи следует проверить. При этом производятся следующие действия:
- проверка того, что блок подписи присутствует и содержит один или более компонентов подписи;
- идентификация компонента Organisation, который содержит OrgID-атрибут организации, осуществляющей проверку. Если не найдено ни одного компонента организации или обнаружено более одного такого компонента, фиксируется ошибка;
- использование ID-атрибута компонента организации, чтобы найти элемент RecipientInfo, который содержит атрибут RecipientRefs, имеющий отношение к компоненту Organisation. Заметим, что может не быть подписи и по этой причине нечего проверять.
- проверка компонента Signature, который содержит идентифицированный элемент RecipientInfo в виде:
| - используются атрибуты SignatureValueRef и SignatureAlgorithmRef, чтобы идентифицировать, соответственно: элемент Value, который содержит подпись, подлежащую проверке и элемент алгоритма подписи, который характеризует алгоритм вычисления подписи, предназначенный для ее верификации, затем | |
| - если элемент алгоритма подписи указывает, что использована асимметричная криптография, тогда для идентификации сертификата применяется SignatureCertRef; | |
| - если элемент алгоритма подписи указывает, что использована симметричная криптография, тогда для идентификации корректного значения общего ключа используется содержимое элемента RecipientInfo; | |
| - используется специфицированный алгоритм подписи для проверки того, что элемент Value правильно подписывает элемент Manifest; | |
| - проверется, что элементы Digest в элементе Manifest вычислены правильно. При этом предполагается, что компоненты или блоки, на которые ссылается дайджест, были получены организацией, выполняющей проверку подписи. |
6.3. Проверка платежа или доставки
Далее описываются процессы, необходимые для кассира или агента доставки, чтобы проверить возможность выполнения платежа или доставки. Это может включать проверку подписей, если она специфицирована продавцом.
При этом осуществляются следующие шаги:
- проверка того, что платежный запрос или запрос доставки посланы правильной организацией;
- проверка того, что в запросе представлены правильные компоненты IOTP;
- проверка того, что платеж или доставка авторизованы.
- "Блок запроса" используется в связи с блоком запроса платежа (смотри раздел 8.7) или блоком запроса доставки (смотри раздел 8.10), если не специфицировано обратного;
- "Блок отклика" используется в связи с блоком платежного отклика (смотри раздел 8.9) или блоком отклика доставки (смотри раздел 8.11);
- "Операция" используется в связи с операцией, которая реализуется при получении блока запроса. Операцией может быть платеж или доставка;
- "Операционная организация" используется в отношении Кассира или Агента доставки, которые реализуют операцию;
- "Подписант операции" используется в отношении организации, которая подписаладанные об операции с целью ее авторизации;
- "Верификатор операции" используется в отношении организаций, которые верифицируют данные, чтобы определить, авторизованы ли они для выполнения операции;
- атрибут ActionOrgRef содержит ссылки элемента, которые могут быть использованы для идентификации "Операционной организации", которая должна выполнить операцию.
Проверка того, послан ли блок запроса правильной организации, варьируется в зависимости от того платеж это или доставка.
6.3.1.1. Платеж
Кассир проверяет, может ли он принять или выполнить платеж путем идентификации компоненты платежа в полученном им блоке платежного запроса. Затем, используя ID плетежного компонента для идентификации организации, выбранной Покупателем, проверяет, что это та самая организация.Метод доступа к данным для решения поставленных задач проиллюстрирован на Рисунок .12.
