"Стандарт Банка России "Финансовые сообщения в НПС. Правила обмена данными в национальной платежной системе" СТО БР НПС-1.4-2019"

СТАНДАРТ БАНКА РОССИИ

СТО БР НПС-1.4-2019

ФИНАНСОВЫЕ СООБЩЕНИЯ В НПС

ПРАВИЛА ОБМЕНА ДАННЫМИ В НАЦИОНАЛЬНОЙ ПЛАТЕЖНОЙ СИСТЕМЕ

Дата введения: 2019-09-30

Предисловие

ПРИНЯТ И ВВЕДЕН в действие приказом Банка России от 20 сентября 2019 года N ОД-2191 "О введении в действие стандарта Банка России СТО БР НПС-1.4-2019 "Финансовые сообщения в НПС. Правила обмена данными в национальной платежной системе".

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

Введение

Настоящий Стандарт содержит рекомендации по реализации обмена данными в соответствии со стандартом ISO 20022 <1> при переводе денежных средств в национальной платежной системе (далее - НПС).

--------------------------------

<1> Международный стандарт ISO 20022 "Финансовые услуги - Универсальная схема сообщений для финансовой отрасли" (Financial services - Universal financial industry message scheme).

1. Область применения

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

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

2. Термины и определения

В настоящем Стандарте применяются термины в соответствии со Стандартом Банка России СТО БР НПС-1.0-2017 "Финансовые сообщения в НПС. Общие положения" и Федеральным законом от 06.04.2011 N 63-ФЗ "Об электронной подписи", а также следующие термины с соответствующими определениями.

3. Общие положения

В соответствии с положениями части 6 "Характеристики транспортировки сообщений" (ISO 20022-6 "Message transport characteristics") стандарта ISO 20022 обмен данными в рамках НПС выполняется в следующих слоях:

- бизнес-слой - самый верхний слой, в котором определены правила и сценарии обмена бизнес-сообщениями, а также структуры бизнес-сообщений, используемых в процессах обмена в рамках конкретных моделей связей НПС. Бизнес-слой эквивалентен добавлению уровня 9 к Сетевой модели ВОС;

- слой транспортировки сообщений - слой, в котором определены правила обмена электронными сообщениями, независимо от бизнес-слоя. Слой транспортировки сообщений эквивалентен добавлению уровня 8 к Сетевой модели ВОС;

- прикладной слой - самый нижний слой обмена, соответствующий уровню 7 Сетевой модели ВОС.

Настоящий Стандарт определяет рекомендации по обмену данными в рамках НПС в каждом из указанных выше слоев. Соблюдение настоящих рекомендаций позволит обеспечить функциональную совместимость (интероперабельность) взаимодействующих в рамках НПС информационных систем, поддерживающих ISO 20022.

4. Бизнес-слой

В бизнес-слое обмен данными реализуется путем передачи бизнес-сообщений. Бизнес-сообщение представляет собой совокупность бизнес-заголовка и содержимого сообщения, описанного в Стандартах ISO 20022 НПС.

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

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

Бизнес-сообщения должны быть представлены в виде XML-документов и должны соответствовать XML-схемам и правилам заполнения документов, описанным в Стандартах ISO 20022 НПС.

4.1. Правила обмена данными в бизнес-слое

Правила обмена данными в бизнес-слое определяются Стандартами ISO 20022 НПС, содержащими модели связей между участниками перевода денежных средств, а также используемые в рамках этих моделей сообщения.

При описании обмена в бизнес-слое задаются Способы доставки сообщений (MessageTransportMode), которые определяют группы характеристик доставки сообщений, описанные в части 1 "Метамодель" (ISO 20022-1 "Metamodel") стандарта ISO 20022 <2>. Характеристики доставки сообщений справочно приведены в Таблице 4.1 настоящего Стандарта.

--------------------------------

<2> www.iso20022.org.

Определенные в бизнес-слое Способы доставки сообщений должны быть реализованы в слое транспортировки сообщений и (или) прикладном слое.

ТАБЛИЦА 4.1. ХАРАКТЕРИСТИКИ ДОСТАВКИ СООБЩЕНИЙ

4.2. Структура бизнес-сообщений

Бизнес-сообщение имеет следующую структуру:

    <BusinessMessage xmlns="urn:cbrf:iso:20022:business-message">
      <AppHdr xmlns="urn:iso:std:iso:20022:tech:xsd:head.001.001.01">
        <!-- Содержимое заголовка -->
      </AppHdr>
      <Document xmlns="urn:iso:std:iso:20022:tech:xsd:xxxx.nnn.nnn.nn">
        <!-- Содержимое документа -->
      </Document>
    </BusinessMessage>

В качестве заголовка бизнес-сообщения используется структура Business Application Header (BAH). Структура задана в документе "ISO 20022 Business Application Header. Message Definition Report" (версия от 1 июня 2010 года) <3>. Рамочные правила ее использования заданы в документе "ISO 20022 Business Application Header Message Usage Guide Version 1.8" (версия от апреля 2016 года). Описание структуры заголовка бизнес-сообщения и правила ее заполнения для целей использования в НПС приведены в Таблице 4.2.

--------------------------------

<3> www.iso20022.org.

ТАБЛИЦА 4.2. СТРУКТУРА ЗАГОЛОВКА БИЗНЕС-СООБЩЕНИЯ

5. Слой транспортировки сообщений

5.1. Правила обмена данными в слое транспортировки сообщений

Обмен данными в слое транспортировки сообщений выполняется с использованием транспортных сообщений, в которые упакованы бизнес-сообщения. Структура и правила формирования транспортных сообщений определены в разделе 5.2 Стандарта.

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

1. Отправитель формирует бизнес-сообщение;

2. Отправитель упаковывает сформированное бизнес-сообщение в транспортное сообщение;

3. Отправитель отправляет транспортное сообщение получателю;

4. Получатель принимает транспортное сообщение;

5. Получатель распаковывает транспортное сообщение и извлекает из него бизнес-сообщение;

6. Если процедура распаковки закончилась неудачей, Получатель формирует сообщение об ошибке в соответствии с правилами раздела 5.2.5 Стандарта и отправляет его Отправителю;

7. Получатель выполняет валидацию бизнес-сообщения, если необходимость валидации определена на бизнес-уровне;

8. Получатель выполняет обработку бизнес-сообщения в случае успешной валидации (либо если валидация не проводилась);

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

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

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

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

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

На уровне транспортировки сообщений информационное взаимодействие осуществляется в соответствии со спецификацией WS-I Basic Profile Version 2.0.

5.2. Структура и правила формирования транспортного конверта сообщения

5.2.1. Общие правила формирования транспортного конверта сообщения

При описании структуры и правил формирования транспортного сообщения используются спецификации, указанные в Таблице 5.1.

ТАБЛИЦА 5.1. ИСПОЛЬЗУЕМЫЕ СПЕЦИФИКАЦИИ

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

ТАБЛИЦА 5.2. ПЕРЕЧЕНЬ ПРОСТРАНСТВ ИМЕН

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

    <soap:Envelope
        xmlns:soap="http://www.w3.org/2003/05/soap-envelope"
        xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing"
        xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-
wssecurity-utility-1.0.xsd">
      <soap:Header>
        <!-- Заголовок транспортного конверта сообщения -->
      </soap:Header>
      <soap:Body wsu:Id="BusinessMessage">
        <!-- Бизнес-сообщение -->
      </soap:Body>
    </soap:Envelope>

При формировании электронных сообщений используется кодировка UTF-8.

5.2.2. Двоичные вложения

Бизнес-сообщение может содержать в своей структуре двоичные вложения. При передаче бизнес-сообщений в составе транспортного сообщения двоичные вложения могут передаваться в теле сообщения в стандарте кодирования Base64 (согласно RFC 4648) или быть оформлены в виде отдельных MIME-частей.

Оформление двоичных вложений в виде отдельных MIME-частей выполняется для оптимизации процессов передачи и уменьшения объемов сообщений с двоичными вложениями.

При передаче двоичных вложений в виде отдельных MIME-частей в теле сообщения создается ссылка на MIME-часть согласно спецификации XML-binary Optimized Packaging.

MIME-части сообщения используются исключительно для оптимизации процессов передачи сообщения. Обработка сообщения должна осуществляться согласно модели обработки XOP спецификации XML-binary Optimized Packaging.

Рекомендуется оформлять двоичные вложения в виде MIME-частей в том случае, если размер двоичного вложения превышает 100 Кб.

5.2.3. Подписание сообщений и проверка электронной подписи сообщений

Подписание и проверка электронной подписи сообщений осуществляются в соответствии со спецификацией WS Security 1.1.1. Рекомендации по созданию и проверке электронной подписи приведены в Приложении 1.

Структура элемента wsse:Security, содержащего электронную подпись, представлена в Таблицах 5.3 - 5.4.

ТАБЛИЦА 5.3. СТРУКТУРА ЭЛЕМЕНТА WSSE:SECURITY, СОДЕРЖАЩЕГО ЭЛЕКТРОННУЮ ПОДПИСЬ

ТАБЛИЦА 5.4. СТРУКТУРА ЭЛЕКТРОННОЙ ПОДПИСИ (DS:SIGNATURE)

5.2.4. Шифрование и расшифрование сообщений

Шифрование и расшифрование сообщений осуществляются в соответствии со спецификацией WS Encryption 1.1. Шифрование сообщений выполняется после их подписания.

Шифрование сообщения осуществляется следующим образом.

1. В заголовок транспортного конверта сообщения добавляется элемент wsse:Security. Данный элемент должен предшествовать элементу wsse:Security, содержащему электронную подпись, если таковой имеется.

2. Сертификат открытого ключа, с помощью которого шифруется сообщение, включается в элемент wsse:Security/wsse:BinarySecurityToken. Сертификат соответствует стандарту X.509 (указывается в атрибуте ValueType) и кодируется с использованием стандарта кодирования Base64 (указывается в атрибуте EncodingType).

3. В элементе wsse:Security/xenc:EncryptedKey/ds:KeyInfo указывается ссылка на сертификат открытого ключа.

4. Бизнес-сообщение, содержащееся в элементе soap:Body шифруется в соответствии со спецификацией XML Encryption 1.1. Зашифрованное сообщение помещается в элемент xenc:EncryptedData, который заменяет исходное бизнес-сообщение.

5. В элементе wsse:Security/xenc:EncryptedKey/xenc:ReferenceList указывается ссылка на зашифрованное сообщение.

Расшифрование сообщения осуществляется следующим образом.

1. Если в заголовке транспортного конверта сообщения содержится элемент wsse:Security/xenc:EncryptedKey, то сообщение является зашифрованным и требуется его расшифрование.

2. Для сертификата открытого ключа, ссылка на который указана в элементе wsse:Security/xenc:EncryptedKey/ds:KeyInfo, определяется закрытый ключ для расшифрования сообщения.

3. Данные, ссылка на которые указана в элементе wsse:Security/xenc:EncryptedKey/xenc:ReferenceList, дешифруются с помощью закрытого ключа. Результат помещается в сообщение вместо зашифрованных данных.

4. Из сообщения удаляется элемент wsse:Security, содержащий сведения о шифровании сообщения.

5. В случае невозможности расшифровать сообщение формируется сообщение об ошибке в соответствии с требованиями раздела 5.2.5 Стандарта.

Структура элемента wsse:Security, содержащего сведения о шифровании сообщения, описана в Таблицах 5.5 - 5.6.

ТАБЛИЦА 5.5. СТРУКТУРА ЭЛЕМЕНТА WSSE:SECURITY, СОДЕРЖАЩЕГО СВЕДЕНИЯ О ШИФРОВАНИИ СООБЩЕНИЯ

ТАБЛИЦА 5.6. СТРУКТУРА СВЕДЕНИЙ О ЗАШИФРОВАННЫХ ДАННЫХ (XENC:ENCRYPTEDKEY)

Структура зашифрованных данных представлена в Таблице 5.7.

ТАБЛИЦА 5.7. СТРУКТУРА ЗАШИФРОВАННЫХ ДАННЫХ (XENC:ENCRYPTEDDATA)

5.2.5. Формирование сообщений об ошибках

Сообщения об ошибках формируются в соответствии со спецификацией SOAP 1.2.

Сведения об ошибке передаются в теле транспортного конверта и должны быть единственным элементом.

ТАБЛИЦА 5.8. СТРУКТУРА СВЕДЕНИЙ ОБ ОШИБКЕ (SOAP:FAULT)

Элемент soap:Code/soap:Value заполняется согласно требованиям спецификации SOAP 1.2.

Перечень типовых кодов ошибок представлен в Таблице 5.9.

ТАБЛИЦА 5.9. ПЕРЕЧЕНЬ ТИПОВЫХ ОШИБОК

В случае несоответствия сообщения правилам формирования (vr:MessageRulesViolated, vr:BusinessRulesViolated) в элемент soap:Fault/soap:Detail включаются элементы vr:Result, содержащие сведения о результатах валидации.

Для каждого провалидированного элемента и каждого правила формируется отдельный элемент vr:Result. Сведения об ошибках валидации (error) включаются в сообщение в обязательном порядке. В отладочных целях в сообщение об ошибке могут быть включены сведения об иных результатах валидации (valid, irrelevant, absent, unsupported).

ТАБЛИЦА 5.10. СТРУКТУРА СВЕДЕНИЙ О РЕЗУЛЬТАТАХ ВАЛИДАЦИИ

6. Прикладной слой

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

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

- HTTPS: Hypertext Transfer Protocol - HTTP/1.1 (RFC 2616) совместно со спецификацией HTTP Over TLS (RFC 2818);

- AMQP: ISO/IEC 19464:2014 Information technology - Advanced Message Queuing Protocol (AMQP) v1.0 specification.

Приложение 1

Подписание сведений, передающихся в транспортном конверте сообщения с помощью электронной подписи, осуществляется следующим образом (см. рисунок А.1). Для краткости на схеме опущены объявления пространств имен, а значения некоторых атрибутов приведены с сокращениями.

РИСУНОК А.1. СХЕМА ПОДПИСАНИЯ СООБЩЕНИЯ

На 1-м шаге формируется транспортный конверт сообщения (1-й шаг не имеет непосредственного отношения к формированию подписи, однако приводится в настоящем алгоритме как подготовительное мероприятие для создания XML-структур, в которые будут погружены подпись и подписываемые сведения).

На 2-м шаге в элемент soap:Body транспортного конверта помещается бизнес-сообщение. В атрибуте @wsu:ID элемента soap:Body задается идентификатор, который должен быть уникальным в рамках конверта и его содержимого; для идентификации тела сообщения рекомендуется использовать значение "BusinessMessage". Формируемая электронная подпись будет ссылаться по данному идентификатору на подписываемые данные.

На 3-м шаге в заголовке транспортного конверта сообщения формируется блок сведений wsse:Security. У элемента задается атрибут @soap:mustUnderstand со значением "true". Это обязывает получателя сообщения обрабатывать данный блок сведений. В случае если он не сможет обеспечить обработку электронной подписи, то он должен уведомить отправителя соответствующим сообщением об ошибке.

На 4-м шаге в блок сведений wsse:Security включается элемент wsse:BinarySecurityToken, содержащий сертификат ключа проверки электронной подписи. В атрибуте @wsu:Id указывается идентификатор сертификата, который должен быть уникальным в рамках конверта и его содержимого; для идентификации сертификата рекомендуется использовать значение "SigningCertificate". Формируемая электронная подпись будет ссылаться на сертификат по этому идентификатору. Сертификат должен соответствовать стандарту X.509 и кодироваться с использованием стандарта кодирования Base64.

Стандарт сертификата указывается в атрибуте @ValueType со значением "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3". Схема кодирования сертификата указывается в атрибуте @EncodingType со значением "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary".

На 5-м шаге формируется хеш бизнес-сообщения. Для этого в блоке сведений wsse:Security формируется элемент ds:Signature/ds:SignedInfo/ds:Reference. В атрибуте @URI этого элемента указывается ссылка на подписываемое бизнес-сообщение (если на 2-м шаге задан рекомендуемый идентификатор, то в атрибуте @URI должна быть указана ссылка "#BusinessMessage"). Если двоичные вложения передаются в виде MIME, то далее они должны быть перенесены в бизнес-сообщение согласно алгоритму, описанному в спецификации XML-binary Optimized Packaging. После этого бизнес-сообщение приводится к каноническому виду с помощью алгоритма Exclusive XML Canonicalization Version 1.0. Для полученного фрагмента XML-документа в соответствии с ГОСТ Р 34.11-2012 вычисляется 256-битный хеш, который записывается в элемент ds:DigestValue.

Алгоритм каноникализации указывается в атрибуте ds:Transforms/ds:Transform/@Algorithm со значением "http://www.w3.org/2001/10/xml-exc-c14n#". Алгоритм вычисления хеша указывается в атрибуте ds:DigestMethod/@Algorithm со значением "urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr34112012-256".

На 6-м шаге для хеша бизнес-сообщения формируется электронная подпись. Для этого в элемент ds:Signature/ds:SignedInfo добавляются сведения об алгоритме его каноникализации (Exclusive XML Canonicalization Version 1.0) и алгоритме вычисления электронной подписи (ГОСТ 34.10-2012, 256 бит). Затем с помощью указанных алгоритмов элемент ds:Signature/ds:SignedInfo приводится к каноническому виду и для полученного фрагмента XML-документа вычисляется электронная подпись. Полученное значение записывается в элемент ds:SignatureValue.

Алгоритм каноникализации указывается в атрибуте ds:CanonicalizationMethod/@Algorithm со значением "http://www.w3.org/2001/10/xml-exc-c14n#". Алгоритм вычисления электронной подписи указывается в атрибуте ds:SignatureMethod/@Algorithm со значением "urn:ietf:params:xml:ns:cpxmlsec: algorithms:gostr34102012-gostr34112012-256".

На 7-м шаге в сведениях об электронной подписи в элементе ds:KeyInfo формируется ссылка на сертификат ключа проверки электронной подписи. Для этого используется элемент wsse:SecurityTokenReference. Ссылка на сертификат указывается в атрибуте wsse:Reference/@URI (если на 4-м шаге задан рекомендуемый идентификатор, то в атрибуте @URI должна быть указана ссылка "#SigningCertificate"). Стандарт сертификата указывается в атрибуте wsse:Reference/@ValueType со значением "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3".

Проверка электронной подписи сообщения осуществляется следующим образом (см. рисунок А.2). Для краткости на схеме опущены объявления пространств имен, а значения некоторых атрибутов приведены с сокращениями.

На 1-м шаге в заголовке транспортного конверта сообщения проверяется наличие элемента wsse:Security/ds:Signature. Если элемент присутствует, то сообщение является подписанным и требуется проверка наложенной электронной подписи.

На 2-м шаге проверяется сертификат открытого ключа электронной подписи в элементе wsse:BinarySecurityToken. Сертификат должен быть корректным, а в элементе ds:KeyInfo/wsse:SecurityTokenReference должна присутствовать ссылка на него.

На 3-м шаге проверяется действительность электронной подписи. Для этого элемент ds:SignedInfo приводится к каноническому виду с помощью алгоритма Exclusive XML Canonicalization Version 1.0. Для полученного фрагмента XML-документа вычисляется 256-битное значение электронной подписи в соответствии с ГОСТ 34.10-2012. Если результат совпадает со значением элемента ds:SignatureValue, то подпись является действительной.

Проверяется значение атрибута ds:SignedInfo/ds:CanonicalizationMethod/@Algorithm, оно должно соответствовать используемому методу каноникализации и иметь значение "http://www.w3.org/2001/10/xml-exc-c14n#". Проверяется значение атрибута ds:SignedInfo/ds:SignatureMethod/@Algorithm, оно должно соответствовать используемому алгоритму вычисления электронной подписи и иметь значение "urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr34102012-gostr34112012-256".

На 4-м шаге проверяется целостность бизнес-сообщения. Если двоичные вложения передаются в виде MIME, то перед проверкой целостности они должны быть перенесены в бизнес-сообщение согласно алгоритму, описанному в спецификации XML-binary Optimized Packaging. Затем бизнес-сообщение приводится к каноническому виду с помощью алгоритма Exclusive XML Canonicalization Version 1.0. Для полученного фрагмента XML-документа в соответствии с ГОСТ Р 34.11-2012 вычисляется 256-битный хеш. Если полученное значение совпадает со значением элемента ds:SignedInfo/ds:Reference/ds:DigestValue, то бизнес-сообщение целостно.

Проверяется значение атрибута ds:SignedInfo/ds:Reference/ds:Transforms/ds:Transform/@Algorithm, оно должно соответствовать используемому методу каноникализации и иметь значение "http://www.w3.org/2001/10/xml-exc-c14n#". Проверяется значение атрибута ds:SignedInfo/ds:Reference/ds:DigestMethod/@Algorithm, оно должно соответствовать используемому алгоритму вычисления хеша и иметь значение "urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr34112012-256".

В случае неудачной проверки электронной подписи формируется сообщение об ошибке в соответствии с требованиями раздела 5.2.5 Стандарта.

РИСУНОК A.2. СХЕМА ПРОВЕРКИ ЭЛЕКТРОННОЙ ПОДПИСИ

Приложение 2

XML-ЫСХЕМА БИЗНЕС-СООБЩЕНИЯ

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema
    xmlns:xs="http://www.w3.org/2001/XMLSchema"
    xmlns="urn:cbrf:iso:20022:msg"
    targetNamespace="urn:cbrf:iso:20022:msg"
    xmlns:bah="urn:iso:std:iso:20022:tech:xsd:head.001.001.01"
    elementFormDefault="qualified">
  <xs:import namespace="urn:iso:std:iso:20022:tech:xsd:head.001.001.01"/>
  <xs:element name="BusinessMessage" type="BusinessMessageType" />
  <xs:complexType name="BusinessMessageType">
    <xs:sequence>
      <xs:element ref="bah:AppHdr"/>
      <xs:any processContents="strict" />
    </xs:sequence>
  </xs:complexType>
</xs:schema>

Приложение 3

ПРИМЕР СООБЩЕНИЯ С ЭЛЕКТРОННОЙ ПОДПИСЬЮ

    <soap:Envelope
        xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
      <soap:Header>
        <wsse:Security
            xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-
wssecurity-secext-1.0.xsd"
            xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-
wssecurity-utility-1.0.xsd"
            xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
            soap:mustUnderstand="true">
          <wsse:BinarySecurityToken
              wsu:Id="SigningCertificate"
              ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-
token-profile-1.0#X509v3"
              EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-
message-security-1.0#Base64Binary">
            <!-- Сертификат ключа проверки электронной подписи -->
          </wsse:BinarySecurityToken>
          <ds:Signature>
            <ds:SignedInfo>
              <ds:CanonicalizationMethod
                  Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
              <ds:SignatureMethod
                  Algorithm=
   "urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr34102012-gostr34112012-256"/>
              <ds:Reference URI="#BusinessMessage">
                <ds:Transforms>
                  <ds:Transform
                      Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                </ds:Transforms>
                <ds:DigestMethod
                    Algorithm=
   "urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr34112012-256"/>
                <ds:DigestValue>
                  <!-- Хеш -->
                </ds:DigestValue>
              </ds:Reference>
            </ds:SignedInfo>
            <ds:SignatureValue>
              <!-- Значение электронной подписи -->
            </ds:SignatureValue>
            <ds:KeyInfo>
              <wsse:SecurityTokenReference>
                <wsse:Reference
                    URI="#SigningCertificate"
                    ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-
x509-token-profile-1.0#X509v3" />
              </wsse:SecurityTokenReference>
            </ds:KeyInfo>
          </ds:Signature>
        </wsse:Security>
      </soap:Header>
      <soap:Body wsu:Id="BusinessMessage">
        <!-- Бизнес-сообщение -->
      </soap:Body>
    </soap:Envelope>

Приложение 4

ПРИМЕР ЗАШИФРОВАННОГО СООБЩЕНИЯ

    <soap:Envelope
        xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
      <soap:Header>
        <wsse:Security
            xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-
wssecurity-secext-1.0.xsd"
            xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-
wssecurity-utility-1.0.xsd"
            xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
            xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
            soap:mustUnderstand="true">
          <wsse:BinarySecurityToken
              wsu:Id="EncryptionCertificate"
              ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-
token-profile-1.0#X509v3"
              EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-
message-security-1.0#Base64Binary">
             <!-- Сертификат открытого ключа -->
          </wsse:BinarySecurityToken>
          <xenc:EncryptedKey>
            <xenc:EncryptionMethod
                Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
            <ds:KeyInfo>
              <wsse:SecurityTokenReference>
                <wsse:Reference
                    URI="#EncryptionCertificate"
                    ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-
x509-token-profile-1.0#X509v3" />
              </wsse:SecurityTokenReference>
            </ds:KeyInfo>
            <xenc:ReferenceList>
              <xenc:DataReference URI="#EncryptedMessage"/>
            </xenc:ReferenceList>
          </xenc:EncryptedKey>
        </wsse:Security>
      </soap:Header>
      <soap:Body>
        <xenc:EncryptedData Id="EncryptedMessage">
          <xenc:EncryptionMethod
              Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
          <xenc:CipherData>
            <xenc:CipherValue>
              <!-- Зашифрованное сообщение -->
            </xenc:CipherValue>
          </xenc:CipherData>
        </xenc:EncryptedData>
      </soap:Body>
    </soap:Envelope>