Демо: DID/VC для организаций, приборов и ИИ-агентов

Всё, что умеют did-svc и vc-svc, по шагам: веб-консоль для показа, curl и утилиты — для проверки руками.

1. Запуск

make build                                   # bin/did, bin/vc, bin/didsign, bin/agentmanifest
export IDENTITY_SYSTEM_KEY=$(bin/didsign keygen | sed -n 's/^seed: //p')
DID_OPERATION_PROOF=required VC_PROOF=required DID_ANCHOR=log docker compose up -d --build

Что

Адрес

Веб-консоль

http://localhost:8081/console

Swagger DID

http://localhost:8080/swagger

Swagger VC

http://localhost:8081/swagger

Режимы (по умолчанию в compose — мягкие, чтобы не ломать стенды):

Переменная

Значения

Для демо

DID_OPERATION_PROOF

off, optional, required

required — без подписи DID не меняется

VC_PROOF

off, optional, required

required — неподписанные VC не принимаются

DID_ANCHOR

off, log

log — ревизии «якорятся» в лог (вместо HLF), в истории видно anchored

IDENTITY_SYSTEM_KEY

seed Ed25519

identity-система подписывает DID и VC персон

2. Портал участников и скан метки

/portal — работа от лица трёх компаний (переключатель вверху). «⚡ Зарегистрировать три компании» создаёт ключи в браузере, DID организаций и их подписанные карточки (название, ИНН, роль).

Компания

Что делает

🏛️ «Русский регистр»

«＋ Выдать сертификат» соответствия серии изготовителю; «Кого касается» — паспорта и текущие владельцы; «Отозвать»

🏭 «Взлёт»

«＋ Новый прибор» → сразу паспорт (поля — из схемы); «🏷 Метка» — QR, PNG, печать; «🤝 Передать» (шаг 1)

🛢️ ОЙЛТИМ

«🤝 Передачи» → «✍️ Принять» (шаг 2, своей подписью становится владельцем)

Формы строятся по GET /api/v1/schemas: новый состав полей появляется в портале и на скане без правки страниц. Ошибки — по-русски по коду и полю (missing_field → «не заполнено обязательное поле — «Номер сертификата»»).

/scan — камера (BarcodeDetector или jsQR), фото метки или ссылка; /s/<DID> открывается сразу из QR. Сверху — вердикт: ✅ подлинный и действует / ⚠️ подлинный, но сертификат отозван / ❌ недействителен; ниже — прибор, владелец (и передача, если не подтверждена), паспорт, сертификат, что проверено.

Порядок показа: регистр выдаёт сертификат → Взлёт регистрирует прибор с паспортом и показывает метку → передаёт ОЙЛТИМ → ОЙЛТИМ принимает → скан метки (✅, владелец ОЙЛТИМ) → регистр отзывает сертификат → скан (⚠️).

Если реестр запущен с API_TOKENS — «🔑 Токен» в портале (консоль берёт тот же токен).

3. Веб-консоль (для показа аналитику)

Откройте /console (нужен localhost или HTTPS: ключи и подписи — WebCrypto в браузере).

Сценарий стенда DiCE (кнопка «Пройти всё» или по шагам ▶):

#

Шаг

Что видно

1

Участники

«Русский регистр», «Взлёт», ОЙЛТИМ получают did:ru:org:…, каждый подписал свой DID

2

Прибор

did:ru:device:… расходомера, владелец — «Взлёт», подпись «Взлёт»

3

Сертификат серии

ConformityCertificateCredential от «Русского регистра»

4

Паспорт

InstrumentPassportCredential от «Взлёт» со ссылкой на сертификат

5

Скан метки

резолв DID → VC прибора → паспорт подлинный, сертификат действует

6–7

Приёмка

«Взлёт» вписывает ОЙЛТИМ в контроллеры → ОЙЛТИМ своей подписью становится владельцем

8

Попытка присвоить

посторонний назначает себя владельцем — 403

9

Отзыв сертификата

«Взлёт» отозвать не может (422), «Русский регистр» — может

10

Затронутые паспорта

кого касается отзыв и кто владелец сейчас (ОЙЛТИМ); паспорт подлинный, сертификат revoked

11

История прибора

все ревизии verified, якорение pending → anchored

ИИ-агент:

#

Шаг

Что видно

1

DID агента

did:ru:agent:…, владелец ОЙЛТИМ, регистрирует ОЙЛТИМ

2

Мандат

AgentMandateCredential: AGENTS.md, MCP mcp-link, маршруты API, open-weights модель, seed 42, класс D3

3

Runtime

агент сам сообщает конфигурацию — mandate: approved

4

Вход в КТМ

challenge → подпись ключом агента → вошёл, видно владельца

5

Маршрут

разрешённый маршрут — true, прочий — false (route_not_allowed)

6

Анализ

AnalysisCredential агента со ссылкой на паспорт, inputs: valid

7

Смена seed

агент поменял seed без нового мандата — runtime_not_approved, доступ закрыт

Проводник: любой DID → документ, история с проверкой и статусом якорения, его VC с кнопкой verify; ленты событий DID (did.owner_changed при приёмке) и VC (vc.revoked); сертификаты, истекающие за 30 дней.

Журнал запросов внизу — каждый HTTP-запрос и ответ: удобно показывать, что именно подписано.

Автопроверка консоли без браузера (Node 22): node scripts/console-smoke.mjs docs/vc/console.html http://localhost:8081.

4. То же руками: curl + утилиты

B=http://localhost:8080/api/v1; V=http://localhost:8081/api/v1
bin/didsign keygen -type org  > org.key      # seed, jwk, did
bin/didsign keygen -type agent > agent.key

Действие

Команда

подпись операции DID

bin/didsign sign -seed $SEED -kid $DID#key-1 -op create|update|deactivate -did $TARGET [-prev N] -body body.json → заголовок DID-Operation-Proof

подпись VC

bin/didsign sign-vc -seed $SEED -kid $DID#key-1 -body vc.json → тело application/vc+jwt

подпись отзыва

bin/didsign sign-revoke -seed $SEED -kid $DID#key-1 -id $VC_ID → заголовок Credential-Operation-Proof

манифест агента из каталога

bin/agentmanifest -dir ./agent -did $AGENT -model model.json -routes routes.txt [-issuer $ORG]

Подробные пошаговые сценарии: подписанные операции DID, подписанные VC.

5. Карта API

DID (did-svc, :8080)

Метод

Путь

Что

POST/PUT/PATCH

/v1/dids[/{did}]

создание / замена / изменение и деактивация — с DID-Operation-Proof

GET

/v1/dids/resolve?did=&versionId=

резолв, в т.ч. исторической версии

GET

/v1/dids/{did}/history[/verify]

история; проверка подписей, хэш-цепочки, якорения

GET

/v1/dids/events?after=

лента изменений DID

POST

/v1/auth/challenge, /v1/auth/verify

вход по ключу DID

VC (vc-svc, :8081)

Метод

Путь

Что

POST

/v1/credentials

JSON-запрос (сервис собирает VC) или application/vc+jwt (подписанный издателем)

POST

/v1/credentials/{id}/verify

подлинность (proof), ключ издателя, статус, срок, сертификат паспорта, мандат runtime, входы анализа

POST

/v1/credentials/{id}/revoke

отзыв — с Credential-Operation-Proof издателя

GET

/v1/credentials/search

по типу, издателю, статусу, полю субъекта, сроку

GET

/v1/credentials/{id}/dependents

VC, ссылающиеся на данный (паспорта сертификата), + текущие владельцы

GET

/v1/credentials/events?after=

лента выпусков и отзывов

GET

/v1/agents/{did}/mandate

действующий мандат агента

POST

/v1/agents/authorize

можно ли агенту вызвать маршрут

POST

/v1/agents/manifest

проверить манифест и посчитать manifestDigest

6. Отрицательные кейсы для показа

Что сделать

Ответ

создать DID без подписи (required)

401 + WWW-Authenticate: DID-Operation-Proof

ключ-заглушка "x": "public-key-value"

422 Ed25519 "x" must be 32 bytes

did:ru:agent:… не из ключа

422 derived from their first capabilityInvocation key

агент без owner

422

повтор той же подписи

409

подпись чужим ключом с правильным kid

401 invalid JWS signature

VC от не-владельца прибора (паспорт) / мандат не от владельца агента

422

правка ревизии DID или VC прямо в БД

history/verify: broken; VC verify: proof: invalid

повтор входа тем же challenge

401

Журнал изменений

Дата

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

Автор

2026-11-05

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

Дис