Данные от WCF клиента я выбирал из трейса, там есть обёртка Envelope и Body. Просто их не стал добавлять.
По поводу трансформации не очень понятно, т.к передаю SenderProvidedRequestData на подпись.
Так же не понятно, по какой причине DigestValue может отличаться...
Сегодня сделаю формирование запроса в файл, чтобы WCF не влиял на конечный результат. Т.к пока не могу понять на этапе формирования данных ошибка или на этапе отправки данных.
По результатам отпишусь.

Мне удалось добиться прохождения проверки. Для этого полностью отказался от использования сгенерированных классов и написал всё руками.
Буду делать свою библиотеку для решения взаимодействия со СМЭВ. Из коробки не работает :(

У меня получилось выполнить в итоге эталонные запросы. Тестовый проект смотрел))) Но он реализован очень запутанно. Я для наших проектов буду делать библиотеку свою.
Самое сложное - подписать данные в правильном виде. Сейчас сделал это с помощью костылей. Хочу в ближайшие дни заставить работать автосгенерированный код

Можно конечно было по проще написать, но тема сама по себе не простая. Рад если кому то помог пример кода. Ели бы еще где брали код поставили лайк. Было бы приятно и видно что код кому то помог)

Добрый день!
Немного странно, что форму проверки для СМЭВ 3 назвали как форму гис гмп. Все зависит от того, какие стандарты применены к документу. Общая мысль: C14N почти нигде не применяется в чистом виде, везде с дополнительными оговорками, подготовками или постобработками.

Для справки: из символов с кодом ниже пробела (32 или 0x20) в XML в принципе разрешены только символы с кодами 9, 10, 13 и никакие более. Если речь идет о нормализованном (в плане переводов строк) документе/фрагменте, то только символы 10 остаются в роли переводов строки. Сочетание 13+10 заменяется на 10, потом одиночные 13 заменяются на 10. Стандарт проверки электронной подписи подчеркивает, что фрагмент документа должен быть нормализован по переводам строк до передачи в C14N. Чистый алгоритм C14N действительно выдает 
 как каноническую форму символа с кодом 13, однако в случае электронной подписи 13 убираются в документе до C14N. Это совершенно точно касается всех текстовых узлов: кодов 13 нет ни в каком виде; коды 9,10, лишние пробелы - их обработка зависит от параметра PreserveWhitespace (причем не фигурирующего в подписи, только подбирать нужное значение методом тыка). Про значения атрибутов надо перечитать (там вообще головоломная система нормализации whitespace, возможно представление как 	 и так далее), все места кроме значений атрибутов и текстовых узлов "оптимизируются" в C14N - символов 9,10,13 не остается ни в каком представлении.

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

Далее, в СМЭВ 3 создателям надоело маяться с 9,10,13 и после C14N введен обязательный дополнительный трансформ до вычисления хэша. Один из пунктов обязательного трансформа: любые текстовые узлы состоящие только из символов 9,10,13 удаляются, то есть неопределенность с PreserveWhitespace почти обнулена. Почти - потому что любое значение можно обрамить 9,10,13, но это можно окончательно запретить благонамеренной схемой пространства имен. Другой пункт требований СМЭВ 3 гласит, что в самом фрагменте документа соответствующем SignedInfo и его потомкам переводы строк запрещены. Поэтому конечно без выполнения трансформа и требований проверить подпись не получится.

Отредактировано пользователем 5 февраля 2020 г. 8:58:06(UTC)  | Причина: Не указана