Приложение R: Протокол Integrity Anchoring
Integrity Anchoring Protocol for DID Documents

Приложение Q вводит в стандарт SOLPDT 1.1 поддержку децентрализованных идентификаторов W3C DID и объекта owner_identity. Для методов DID, использующих внешние резолверы (did:web, IPFS), идентификационные данные владельца (публичные ключи, политики аутентификации) хранятся вне Initial-Dossier — по ссылке did_document_url.

Данная архитектура создает риск подмены DID-документа третьей стороной (атака Man-in-the-Middle, компрометация DNS-хостинга владельца, изменение файла на сервере). Без механизма контроля целостности злоумышленник может подменить публичный ключ в DID-документе и получить контроль над ИИ-агентом, сохранив при этом валидный DID.

Integrity Anchoring (якорение целостности) — это метод криптографической фиксации состояния внешнего документа в момент выпуска Authoritative Attestation (sig.a).

Принцип работы:

1. При первичной верификации агента Уполномоченный Лицензиар (DAT-A) загружает DID-документ по ссылке did_document_url, предоставленной владельцем.
2. DAT-A вычисляет SHA-256 хеш содержимого документа и фиксирует его в поле did_doc_hash объекта owner_identity внутри Initial-Dossier.
3. Initial-Dossier подписывается Лицензиаром (sig.a) и становится неизменяемым эталоном.
4. При каждой последующей верификации агента Compliance-Gateway (CGW) повторно загружает DID-документ, вычисляет его текущий хеш и сравнивает с did_doc_hash, зафиксированным в досье.
5. Совпадение хешей гарантирует, что DID-документ не был изменен с момента первичной верификации. Расхождение хешей запускает процедуру дополнительной проверки.

Поле did_doc_hash включается в объект owner_identity (Приложение Q) и имеет следующие характеристики.

При обработке транзакции агента, в Initial-Dossier которого присутствует объект owner_identity с external_resolver: true, Compliance-Gateway выполняет следующую последовательность действий.

Шаг 1. Загрузка внешнего DID-документа.

• CGW выполняет HTTP GET запрос к did_document_url.
• Таймаут соединения: 5 секунд.
• При недоступности документа — переход к разделу 7 настоящего Приложения.

Шаг 2. Вычисление текущего хеша.

• CGW вычисляет SHA-256 хеш тела ответа (до парсинга JSON).
• Формат хеша: sha256:{hex}.

Шаг 3. Сравнение хешей.

• Если current_hash == did_doc_hash — переход к Шагу 4 (Key Alignment Check).
• Если current_hash != did_doc_hash — переход к разделу 5 (Статусы и действия).

Шаг 4. Key Alignment Check (проверка соответствия ключей).

• CGW извлекает из DID-документа массив verificationMethod.
• CGW проверяет, что все публичные ключи, перечисленные в verification_methods (Initial-Dossier), присутствуют в verificationMethod внешнего документа.
• Если все ключи найдены — статус VERIFIED. Транзакция разрешена.
• Если хотя бы один ключ отсутствует — статус KEY_MISMATCH. Транзакция отклонена.

По результатам проверки Integrity Anchoring CGW присваивает транзакции один из следующих статусов.

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

1. Публикация обновления. Владелец публикует обновленный DID-документ по тому же did_document_url.
2. Обнаружение расхождения. При следующей транзакции агента CGW обнаруживает расхождение did_doc_hash и присваивает статус PENDING_UPDATE.
3. Проверка авторизации. CGW проверяет, что:
   • Новый DID-документ содержит ключ, которым подписана текущая транзакция.
   • Контроллер DID (поле controller) не изменился или изменение авторизовано через recovery_did.
4. Запрос подтверждения. Если проверка успешна, CGW направляет запрос Мастер-Лицензиару (DAT-M) на подтверждение легитимности обновления.
5. Выпуск Update Attestation. DAT-M проверяет цепочку владения (связь с SOL-Активом v1.0) и выпускает Update Attestation.
6. Обновление досье. Initial-Dossier агента обновляется: новое значение did_doc_hash, актуальный список verification_methods. Старая версия досье архивируется.
7. Восстановление статуса. Статус агента возвращается к VERIFIED.

Временная недоступность did_document_url (ошибки 4xx/5xx, таймаут соединения, проблемы DNS) не должна приводить к немедленной блокировке агента.

Правила обработки:

• Первое обнаружение недоступности: CGW разрешает транзакцию, но помечает агента флагом RESOLVER_WARNING. Статус nma сохраняется.
• Повторная недоступность в течение 24 часов: CGW разрешает транзакцию, флаг RESOLVER_WARNING повышается до RESOLVER_CRITICAL. DAT-A получает уведомление.
• Недоступность более 72 часов подряд: CGW переводит агента в статус PENDING_VERIFICATION. nma временно приостанавливается до восстановления доступа к DID-документу. Транзакции агента отклоняются.
• Восстановление доступа: После восстановления доступа и успешной проверки хеша статус агента автоматически восстанавливается до VERIFIED.