DID/VC сервис DiCE: итоги работы

03.11.2026. Сводка по работе над did-svc с 15.10 по 03.11.2026. Исходные документы лежат в этом архиве, ссылки ведут на них.

Содержимое архива

Кратко

DID/VC-сервис доведён до рабочего реестра с подписями. Он отыграл демо стенда 5 DiCE 30.10.2026 на develop4, где им сейчас пользуются компании. Не выложено только якорение в блокчейн HLF.

• Что это. Два сервиса в did-svc. did хранит DID-документы организаций, приборов и ИИ-агентов с проверяемой историей. vc хранит подписанные документы (VC): паспорта приборов, сертификаты соответствия, акты входного контроля, паспорта блоков, мандаты агентов.

• Зачем. Любая сторона сканирует метку прибора и без доверия к оператору проверяет, кто выпустил паспорт, действует ли сертификат и кто владелец.

• Было до работы (develop, 15.10). Ключи в DID были заглушками. Операции и VC никто не подписывал. Флаг cryptographicallyVerified всегда был false. Отозвать VC мог кто угодно.

• Стало. Всё подписано, проверяется и привязано к ключам. Есть метод did:ru, портал трёх компаний, скан метки, интеграция с BIMAR и ЦП Контрактиума, агент с ограниченным мандатом.

• Открыто. Якорение в HLF лежит в ветке и не выложено, работа на паузе. ГОСТ и проверка цепочки сертификатов ждут PKI-сервиса. Режим «подпись обязательна» включён только на стенде.

Как работает

Каждая запись в реестре подписана ключом своей стороны. Реестр принимает запись, только если подписант вправе её сделать.

vc проверяет каждую подпись ключом издателя из did. Пунктир — якорение в HLF: оно сделано, но не выложено.

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

• Формат: did:ru:<org|device|agent>:<id>. id выводится из открытого ключа, поэтому занять чужой DID нельзя. Старые did:i:* и did:scada:* принимаются как раньше.

• У прибора и агента есть владелец (owner) — организация. Владелец и контроллер (controller) меняют документ своей подписью.

• Подпись операции передаётся в заголовке DID-Operation-Proof (JWS). Она привязана к DID, версии и телу запроса. Повтор даёт 409, чужой ключ — 401, не владелец — 403.

• Ревизии DID связаны хэш-цепочкой. GET /v1/dids/{did}/history/verify находит правку ревизии прямо в БД.

• Передача прибора идёт в два шага: transfer делает получателя контроллером, accept его подписью делает его владельцем. Есть и отказ — decline.

Документы (VC)

Формат — VC-JWT (application/vc+jwt). Подпись проверяется ключом издателя на момент выпуска. Отозвать документ может только его издатель. Состав полей задаётся данными (credschema/default.json) и отдаётся как JSON Schema.

Применимость сертификата к прибору

Решает только тип изделия (указание от 28.10). Сертификат подходит, если выполнены три условия:

1. Держатель сертификата — издатель паспорта, то есть изготовитель.

2. Тип изделия из паспорта (type или productTypeId из справочника) входит в область сертификата.

3. Сертификат не отозван и не в архиве.

Название модели, номенклатура и один только изготовитель не считаются. Явная ссылка на сертификат в паспорте необязательна, а если она есть, то тоже проверяется. Подходящий сертификат находится даже тогда, когда он выдан позже паспорта.

Кто подписывает

• Ключ в браузере. Портал и консоль подписывают через WebCrypto Ed25519. Новый ключ даёт новую организацию.

• Ключ у платформы (custody). Рабочее место станции и BIMAR предъявляют токен организации, а платформа подписывает её ключом (/api/v1/custody/*). Правила те же, что для подписанных запросов.

• Токен партнёра (API_TOKENS) отвечает на вопрос «какая система», подпись — на вопрос «кто решил». Скан, метки, схемы и чтение остаются публичными.

Интерфейсы

Отозванные сертификаты можно убрать в архив (archived_at): они пропадают из рабочих списков и из проверки, но сохраняются для трассировки. Старые версии паспортов скрыты и открываются переключателем истории.

Подробно: did-vc/README.md, руководство ведущего, контракт для партнёров.

Что сделано

Из восьми требований эпика KCONT-2290 (R1–R8) четыре работают на develop4 полностью (R2, R5, R6, R7), три — частично (R1, R3, R8), одно не выложено (R4). Слабое место — блокчейн и ГОСТ. Статусы указаны на 03.11.2026.

Сверх эпика: стенд 5 DiCE и интеграции. Всё перечисленное работает на develop4.

• Схемы полей документов, коды ошибок code / field, токены партнёров, партнёрский контракт OpenAPI 3.1 (did-svc/docs/partner/).

• Портал трёх станций, скан, метки QR, печатный паспорт, веб-консоль.

• Типы приборов с характеристиками, акты входного контроля, паспорта блоков, справочник типов изделий, применимость сертификата по типу.

• Custody: токены организаций для станций и BIMAR. Маркеры и пулы маркеров BIMAR, ссылка на карточку BIMAR в DID прибора.

• ЦП Контрактиума читает те же подписанные паспорта и сертификаты (витрина /assets, GET /api/v1/passports). На портале компаний приборы BIMAR показаны рядом с паспортами Контрактиума.

• Агент: MCP-сервер agentmcp, карточка сертификата по скану, защитный опыт (платформа отказывает при смене seed и при выпуске сертификата агентом).

• Архив сертификатов и скрытие старых версий паспортов без удаления данных.

Доработки ЦП Контрактиума и стенда (28–30.10).

• Передача ЦП: выбор получателя из организаций договорного контура, кнопка «Принять ЦП» у получателя. При импорте паспортов из XML маршрут выбирается явно («Передать получателю» или «Передать в надзор»).

• Карточка ЦП: в «Сводке» видны DID изделия, DID изготовителя, ID VC и ссылка на проверку. Сертификат, выданный на портале, появляется во вкладке «Характеристики» (статус кэшируется до 20 секунд).

• Вложения ЦП открываются и скачиваются, включая отдельный файл подписи. Наличие файла подписи не выдаётся за проверенную или квалифицированную ЭП.

• «Скачать паспорт PDF» формирует печатную форму по шаблону Контрактиума: характеристики, цифровая идентификация, вложения, формуляр.

• Ошибки показываются понятным текстом вместо RPC/SQL-дампов. Интерфейс ЦП переведён на русский («Поставки МРТиО» и др.).

• Инициализация стенда работает с постоянным комплектом и не генерирует тестовые паспорта. При рассогласовании PKI останавливает выдачу, а не создаёт новый набор поверх старых DID.

• Портал: кнопки заполнения демо-полей (форма заполняется, документ не выпускается), SHA-256 считается по выбранному файлу. Технические пояснения убраны. Сертификаты видны с любого устройства (раздел «Держатель и издатель»), а не только со станции-издателя.

• Консоль: «Сбросить сценарий» отзывает только документы встроенного сценария и сохраняет ключи и DID. Сброс ЦП и приборов A/B отзывает сертификаты ключом их издателя и переносит их в архив.

• Swagger DID и VC на стенде открывается корректно.

Проверки. Локально проходят go test ./... (включая интеграционные на Postgres), сквозной прогон стенда через API (10/10), смоук консоли (18/18) и Playwright-тест портала (11/11). Ключевые правила проверены мутациями: если отключить проверку, тесты падают.

Хронология

Работа шла с 15.10 по 03.11.2026: сначала криптография реестра, потом стенд 5 по методичке, затем выкладка на общий develop4 и демо.

Ключевые решения и что отбросили.

• Имя метода менялось: did:contracteum → did:aid → did:ru. Остановились на did:ru «хотя бы для концепта». W3C может не принять код страны в имени, имя вынесено в константу. did:pki уже занят чужим методом.

• Подпись ставится над точными байтами тела (JWS в заголовке) без канонизации JSON. API остался совместим.

• Режимы off / optional / required. По умолчанию стоит optional, чтобы не сломать старых клиентов.

• Назначить владельца можно только его собственной подписью. Иначе любой мог бы объявить чужую организацию своим владельцем.

• Для DID сначала предлагался свой чейнкод did-registry в world state. По вики (PD-35а) сделан второй вариант — запись через общий docs-chaincode (ветка ledger-hlf). Вопрос OQ-67 открыт.

• Сертификат сначала применялся «по изготовителю и модели». С 28.10 применимость определяется только по типу изделия, сопоставление по модели отменено.

• От режима «сброс и новый комплект» на develop4 отказались: стенд уже используют компании. Лишнее скрывается и архивируется, а не удаляется.

• Инициализация стенда больше не генерирует 140 тестовых паспортов. Комплект закреплён постоянным.

Стенд develop4 и демо 30.10

Демо 30.10 прошло на develop4 (develop4.contracteum.com): все шаги сценария с приборами BIMAR записаны в реестр. Стенд общий и уже передан компаниям, поэтому данные на нём не стираются.

Что развёрнуто.

• Пространство имён develop-contracteum4, сервисы did и vc с общей базой PostgreSQL. Режимы подписи required, якорение идёт в журнал.

• Портал компаний /portal, скан, печать, справочник типов изделий. Витрина ЦП в Контрактиуме читает те же паспорта и сертификаты.

• Участники обезличены: Изготовитель (Контрактиум и BIMAR), Орган по сертификации, Получатель / комплектатор. Плашка «демонстрационная версия» оставлена.

• Документы ЦП КТМ-А синхронизируются в тестовую сеть HLF через documents-svc (KCONT-2249). DID и VC в HLF пока не пишутся.

Как деплоится. Образы публикуются в gitlab.procsy.ru:5050/contracteum/network. Тег меняется в cicd/contracteum/develop4-values.yaml (ветка develop), дальше ArgoCD применяет изменение за 3–6 минут. Текущий образ vc — dice-bimar-20261030.

Итоги демо (время московское).

ЦП Контрактиума в демо не участвовал: ни сертификатов, ни передач по нему не было.

Что мешало участникам. «Сброс токена» в портале на самом деле создаёт новую организацию с ключом в браузере. Сертификат, выданный такой организации, не подходит прибору другого изготовителя, и со стороны это выглядит как ошибка. Решение — переподключить станцию её токеном. В интерфейсе эту разницу стоит показывать явно.

Сценарий прогона: dev4-scenario.md.

Открытые вопросы

Главное несделанное — блокчейн. Якорение DID и VC в HLF лежит готовым в ветке и ждёт решения, куда писать. Остальное — согласования и зависимости от соседних команд.

Не сделано или не выложено

Нужно решение аналитика

• Куда писать DID/VC в HLF: свой чейнкод или docs-chaincode (OQ-67, расхождения Р1–Р7 со схемой от 20.10 — заметка)

• Формат подписи VC: оставить VC-JWT или перейти на Data Integrity

• Имя DID-метода: оставить did:ru или выбрать функциональное имя под регистрацию в W3C

• Кто подписывает акт входного контроля: получатель (как сейчас) или лаборатория, как в SCADA DEMO API

• Может ли изготовитель отозвать свой паспорт после продажи прибора

• Реальные характеристики приборов и окончательный состав полей паспорта и сертификата (сейчас учебные)

Техдолг. Код на стенде собран из локальных веток и не смержен в develop монорепозитория. В репозитории лежит старая версия did-svc. На develop4 остались тестовые сертификаты участника демо (RR-0042, три штуки) и паспорт SN-0001: не решено, убирать ли их в архив.

Документы в архиве

Эта сводка заменяет рабочие заметки. Ниже — что смотреть для деталей.

Устарели и в архив не вошли: «Готовые правки и применение» от 28.10 (правило «сертификат по изготовителю и модели» и инструкции по очистке отменены), скрипты очистки и сброса стенда, «Тезисы к демо», «Утренний отчёт», «Тезисы» от 16.10 (вошли в «10 тезисов»), «Отчёт стенд 5» от 22.10 (вошёл в эту сводку), протоколы локальных смоук-прогонов, рабочий журнал задачи и фоллоуапы.

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