Сущности, взаимодействие и границы готовности DID/VC

Метка

Значит

✅ работает

сервис проверяет значение и опирается на него в логике

📦 хранится

сохраняется и отдаётся как есть, сервис его не проверяет и не использует

🧩 заглушка

поле есть, но смысл не реализован (фиксированное значение, демо-данные, «на потом»)

⬜ нет

в модели отсутствует

Поле

Статус

Что делает

id

✅

для did:ru выводится из ключа — чужой DID с другим ключом занять нельзя

controller

✅

кто может подписывать изменения документа

owner

✅

организация, от имени которой агент/прибор; обязателен у agent, device; назначается только подписью нового владельца; двухшаговая передача

verificationMethod[].publicKeyJwk

✅

строгая проверка: длины, кривая, модуль RSA; ключи-заглушки отклоняются

verificationMethod[].publicKeyJwk.x5c

🟡

проверяется только, что ключ листового сертификата совпадает с JWK; цепочка до УЦ, срок, отзыв (CRL/OCSP) — не проверяются

authentication

✅

ключи для входа (/auth/challenge → verify)

assertionMethod

✅

ключи, которыми издатель подписывает VC

capabilityInvocation

✅

ключи для подписанных операций DID; первый — источник id

keyAgreement

🟡

X25519 проверяется как ключ, но шифрованного канала, который бы его использовал, нет

capabilityDelegation

📦

хранится, делегирования нет

service[]

📦

хранится и отдаётся при резолве; сервис эти адреса не вызывает и не проверяет

didDocumentMetadata.versionId, created, updated, deactivated

✅

версии, ?versionId= для исторического резолва, деактивация запрещает новые подписи

nextUpdate, nextVersionId

✅

заполняются при резолве исторической версии

Поле

Статус

Что делает

operation (create/update/deactivate)

✅

proof.jws (DID-Operation-Proof)

✅

JWS по DID, предыдущей версии и хэшу тела; повтор — 409; режим DID_OPERATION_PROOF=off/optional/required

proof.signerDid, keyId

✅

подписант — контроллер или владелец; ключ из его capabilityInvocation

digest, prevDigest

✅

хэш-цепочка; history/verify ловит правку в БД даже с пересчётом хэша

статус якорения pending/anchored

🧩

при DID_ANCHOR=log «якорь» — строка в логе; в HLF не пишется

Поле / механизм

Статус

Что делает

подпись издателя (application/vc+jwt)

✅

ключ из assertionMethod издателя, на версии DID издателя; VC_PROOF=required отклоняет неподписанные; правка в БД → proof: invalid

validFrom / validUntil

✅

учитываются при verify, мандатах и сертификате паспорта

credentialStatus

🟡

свой простой статус (active/revoked, тип SimpleStatus2026) по URL сервиса; не W3C Bitstring Status List — внешние верификаторы его не поймут

отзыв

✅

только с Credential-Operation-Proof издателя; чужой отзыв — 422

credentialSubject

📦 / ✅

хранится как произвольный JSON; проверяются только поля из таблицы типов ниже

Тип VC

Издатель (проверяется)

Поля субъекта с логикой

Остальное

ConformityCertificateCredential — сертификат соответствия серии продукции (не сертификат ключа подписи X.509)

любой подписант

—

📦 номер, серия, сроки — как прислали

InstrumentPassportCredential — VC паспорта экземпляра: подписанная проверяемая версия данных ЦПА, не замена ему

✅ владелец или контроллер DID прибора

✅ certificate — действующий сертификат соответствия серии

📦 характеристики прибора; связи с документом ЦПА в assets-app пока нет

AgentMandateCredential

✅ текущий владелец DID агента

✅ manifest + manifestDigest

—

AgentRuntimeCredential

✅ сам агент

✅ manifestDigest сравнивается с мандатом → approved/not_approved/no_mandate

—

AnalysisCredential

✅ агент did:ru — только с действующим мандатом

✅ inputs — существующие VC (отозванное допустимо, если заключение о нём); verify → valid / revoked_known (основание отозвано ещё до заключения — учтено) / revoked_input (отозвано после — заключение устарело) / missing_input

📦 вывод анализа

PersonCredential, DeviceCredential

identity-система / любой

—

📦

Поле

Статус

Что делает

instructions[] (path, digest)

✅

хэши AGENTS.md/CLAUDE.md считаются по файлам

skills[] (name, version, digest)

✅

хэш каталога скилла

mcpServers[] (name, did, configDigest, toolsDigest, tools)

🟡

хэши конфигурации; что MCP-сервер реально тот же — не проверяется (нет его подписи)

peers[]

🟡

список DID собеседников хранится; при обмене между агентами не проверяется (транспорта нет)

routes[] (method, path)

✅

/agents/authorize пускает только на эти маршруты

model.kind/provider/modelId

✅

входят в хэш

model.weightsDigest, tokenizerDigest, runtime, seed, temperature

✅

для D3 обязательны, temperature = 0

quantization, topP, maxTokens

📦

входят в хэш, отдельно не проверяются

determinismClass (D0–D3)

✅

проверка полноты полей по классу

Поле

Статус

did, systemDid

✅ DID персоны выпускает и подписывает identity-система (IDENTITY_SYSTEM_KEY), она же владелец

info.lastName/firstName/patronymic

📦

info.snils, info.inn

🧩 сохраняются после обрезки пробелов; ни формат, ни контрольные суммы, ни принадлежность человеку не проверяются

Где

Алгоритмы

Статус

Ключи в DID (publicKeyJwk)

Ed25519 (OKP), ECDSA P-256/P-384/P-521 (EC), RSA, X25519 (только keyAgreement)

✅ строгий разбор

Подпись операций DID, VC, отзыва, входа

JWS compact: EdDSA (Ed25519), ES256/ES384/ES512, RS256, PS256

✅

Формат VC

VC-JWT (application/vc+jwt)

✅

Идентификатор did:ru

SHA-256 JWK-отпечатка (RFC 7638), base58btc

✅

Хэш-цепочка ревизий, манифест

SHA-256

✅

Консоль

WebCrypto: Ed25519 / P-256 в браузере

✅ (нужен localhost или HTTPS)

x5c в ключе

совпадение ключа листа

🟡

Чего нет

Зачем

Где точка входа

ГОСТ Р 34.10-2012 / 34.11-2012 (подпись, хэш)

юридически значимые операции, УКЭП (US-3)

didproof.Verifiers.Register и vc.WithVerifiers — верификатор подключается без правки логики. Работающей проверки ГОСТ-подписи в платформе нет (раздел 6): для стенда — cspemul-svc (/cms/verify, OpenSSL GOST, не для прода), для прода — CSP (Криптосмарт / КриптоПро)

Проверка цепочки сертификата x5c до доверенного УЦ, сроков, отзыва (CRL/OCSP)

ключ в DID доказуемо принадлежит юрлицу

didkey — сейчас только совпадение ключа листа

Хранение ключей (HSM / KMS / облачная КЭП)

сейчас ключи у клиента (браузер, didsign seed в файле), у identity-системы — seed в env

вне сервиса

W3C Bitstring Status List

отзыв, понятный внешним верификаторам

credentialStatus

Data Integrity / JSON-LD proofs, SD-JWT

совместимость с экосистемой, выборочное раскрытие

формат VC

Шифрование по keyAgreement (DIDComm / JWE)

защищённый канал агент ↔ агент (US-15)

транспорта нет

Аттестация рантайма агента

доказать, что агент запущен с конфигурацией мандата

runtime — самоотчёт

Подпись MCP-серверов и инструментов

что агент пользуется теми самыми инструментами

в манифесте только хэши конфигов

Якорение в HLF

голова истории DID в реестре консорциума (US-17)

чейнкод did-registry готов, адаптера к blockchain-svc нет

Что

Где в платформе

Что там есть на деле

Как соотносится с DID/VC

Сертификат ключа электронной подписи (X.509, УКЭП)

pki-svc

разбор сертификата и класс владельца (ФЛ/ЮЛ/ИП) по атрибутам, выпуск тестовых сертификатов; подписи не проверяет

ключ DID может нести x5c; класс и атрибуты владельца брать из pki-svc вместо своей логики

Вход по УКЭП

auth-svc → verifications-svc (ProbePKI/CheckPKI)

сертификат проверяется только по сроку; проверка УЦ и CRL — // TODO, проверка подписи закомментирована

вход агента по DID — отдельный механизм с реальной проверкой подписи; общий ГОСТ-верификатор нужен обоим

Подписи документов (CAdES, PKCS#7, XMLDSig, ПЭП)

go-lib/sigutils (documents-svc)

все четыре валидатора возвращают «действительна» без проверки

VC-JWT проверяется по-настоящему (EdDSA/ES*/RS*/PS*); подключение ГОСТ-верификатора закрыло бы обе стороны

ГОСТ-подпись транзакций HLF

cspgw-svc (Криптосмарт)

подписывает /invoke и /query чейнкода ключом организации

не проверяет сторонние подписи; для якорения DID через blockchain-svc — тот же путь

ГОСТ на стенде

cspemul-svc

эмулятор OpenSSL GOST: ключи, cms/sign, cms/verify; «Not for production»

кандидат для ГОСТ-верификатора DID/VC на стенде

Цифровой паспорт актива (ЦПА)

assets-app (шаблон ktma-passport в documents-svc; ветки КТМ-А не влиты в develop)

продуктовый паспорт с полями изделия; пишется в HLF синхронизатором documents-svc

VC паспорта — подписанная проверяемая проекция ЦПА для внешних сторон; связать: assets-app при создании и изменении ЦПА выпускает VC со ссылкой на документ (US-20)

Сертификат соответствия продукции

— (в платформе нет)

—

ConformityCertificateCredential — новая сущность сценария стенда; не путать с сертификатом ключа

Область

Есть

Частично

Нет

Идентификаторы

did:ru из ключа, owner, контроллеры, деактивация

—

регистрация метода в W3C

Изменение DID

подписанные операции, согласие владельца, история и её проверка

якорение (лог)

HLF-адаптер

VC

VC-JWT, отзыв издателем, связи паспорт→сертификат, анализ→входы

статус-лист (свой формат)

Bitstring Status List, SD-JWT

Агенты

мандат, манифест D0–D3, вход по ключу, authorize

peers, MCP — только хэши

аттестация, межагентный канал

Крипто

EdDSA, ES*, RS256, PS256

x5c

ГОСТ, цепочка УЦ, HSM

Интеграции

консоль, CLI, ленты событий

—

notifications-svc, assets-app (ЦПА), ГОСТ-верификатор (cspemul / CSP), pki-svc

Дата

Перечень изменений

Автор

2026-11-05

Перенесён из архива DID-VC-итоги-2026-11-03 без изменения содержания.

Дис