Философский вопрос.
Представим банк. В банке хранится информация по отчету по форме №1. Хранится в БД. Этот отчет передается между организациями в XML представлении.
Задача - обеспечить ЭП (квалифицированную) этого отчета по форме №1, его хранение в БД, и возможность передать отчет во внешнюю организацию, перед этим проверив валидность ЭП.
Данные по отчету хранятся в таблице в БД, система оперирует именно ими, хранить их в XML долго и не удобно - XML это только внешнее представление отчета.
Есть XSD описание XML формата представления отчета, которое всем известно и все оперируют именно им.

Use Case 1
1) Сотрудник банка или сотрудник внешний организации создают этот отчет по форме №1. После его создания сотрудник подписывает этот отчет своим сертификатом - он гарантирует что этот отчет верен. Видимо он подписывает именно XML представления отчета, и у нас есть большой XML в котором есть XML Signature и сам XML с данными.
2) Отчет в таком виде попадает в банк, банк из XML по XSD получает представление отчета в виде Java Bean (например). далее есть конвертор из Java Bean в Java ORM Bean и мы сохраняем данные отчета в БД.
3) Мы хотим хранить еще и ЭП, потому рядом с данными кладем XML + XML Signature.
Use Case 2
1) Внешняя организация запрашивает этот отчет.
2) Мы хотим перед отправкой отчета убедится что никто не изменил данные отчета в БД. Иначе Сотрудник, его создавший, не может за него отвечать. Достаем XML + Signature - проверяем что ЭП валидна на том XML представлении отчета что мы хранили. Все валидно. но дальше нам нужно понять что XML представление == данные отчета в таблице БД.
3) Мы из XML представления формируем Java Bean -> Конверторы -> Java ORM Bean1. Загружаем из БД Java ORM Bean2 и делаем простой compare() по ним.
Выглядит уже сложно, есть риск по однозначности Конверторов.
Вопрос - как это все упростить? Видимо если бы была общая функция по (набор данных отчета) -> hash. ЭП всегда по этому hash. Эта функция есть у всех и она единообразна и hash у всех организаций будет один. Это бы упростило ситуацию

Use Case 3
1) регламент изменился, изменился набор полей отчета по форме №1. В результате мы расширили таблицу с набором данных по отчету. (удалять атрибуты мы не можем - мы хотим хранить все старые отчеты. и хранить все отчеты в одном месте). Есть новый XSD версии 2012 года, который описывает отчет по форме №1. Мы пишем в БД данные и их ЭП уже по новому XSD.
Как выполнить проверку ЭП отчетов старой версии?

Предложение.
Есть XSLT, который приводит XML по старому XSD к новому XSD. Мы получаем XML представление отчета (по старому XSD) -> XSLT -> XML отчета (по новому XSD) -> Java Bean -> Конвертор -> Java ORM Bean1. Загрузили Java ORM Bean2 из БД и compare. ORM соответствует уже новой схеме БД и конверторы тоже.

Какое простое решение есть и общая практика? Хранить ЭП на данные в БД и проверять их - такое есть наверное в каждой организации.

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

ЭП может (должна?) формировать внешняя организация. Это означает что она выполняет подписание, а его могут проверить другие организации и мы сами. Следовательно правило конкатенации - это какая то функция которая известна всем.
Я уже делал такой подход в предыдущей системе - выпускали регламент, в котором указывали порядок полей, условия что если поле пустое то не включать его в документ и тп. В общем мало формализованное и искусственное описание функции. И под каждое изменение структуры документы, обновляли регламент. В каждой внешней системе только путем итеративного тестирования можно было убедится что их реализация функции конкатенации соответствует нашей. Все выглядело печально.
Документ определен для всех через XSD - потому не вижу как можно было бы уйти от XML DSign.