DID-реестр в HLF и раскладка данных — на утверждение

20.10.2026 · для аналитика

Статус. Чейнкод реестра DID и запись ревизий в очередь на стороне did-svc реализованы и покрыты тестами. Не развёрнуто и не подключено: нет адаптера к blockchain-svc, чейнкод не установлен в канал. Сейчас ревизии вместо реестра пишутся в журнал сервиса. Документ — на утверждение схемы до подключения.

1. Коротко

  • Реестр HLF хранит только отпечатки и связи: кто владелец DID, кто контроллер, какими ключами можно подписывать, цепочку хэшей ревизий. Ни паспорта, ни сертификата, ни договора в реестре нет и не будет.

  • Чейнкод проверяет сам, а не верит сервису: что ревизия продолжает цепочку и что её подписал тот, кто имеет право, — по ключам, уже записанным в реестре.

  • Полные документы (заводской паспорт, УПД/КХО, договор) — документы Контрактиума (documents-svc); в блокчейн — через docs-chaincode формализованным телом (после KCONT-2249). Коллекция в реестре одна на всех участников: разграничения доступа между клиентами блокчейн в Прототипе не даёт, доступ — через наш сервис. Файлы (сканы, tiff, pdf) в блокчейн не идут — только в storage-svc (PD-35), в реестре — их отпечаток.

  • VC — проверяемая выжимка для того, кто сканирует метку: поля для проверки + отпечаток исходного файла.

2. Общая схема

Слой

Где

Кто видит

Что лежит

Реестр DID

did-registry, world state канала

все участники канала

отпечатки ревизий, владелец, контроллеры, публичные ключи, подпись операции

VC

vc-svc

любой со ссылкой с метки (скан публичный)

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

Тело документа

documents-svc; в реестр — docs-chaincode (KCONT-2249)

через сервис, по правам; в реестре — одна коллекция на всех

формализованный документ целиком; файлы — только отпечаток

3. Как устроен чейнкод did-registry

Что хранит одна запись (ревизия DID)

Поле

Что это

Зачем

did, version

DID и номер версии (1, 2, 3…)

адрес записи

operation

create, update, deactivate

что произошло

digest

SHA-256 ревизии (документ + подпись + отпечаток предыдущей)

сверка с базой did-svc: подмену видно

prevDigest

отпечаток предыдущей ревизии

цепочка

owner

организация, за которой числится прибор или агент

владение

controller

кто ещё может менять документ (в т.ч. получатель при передаче)

права

keys, authentication, capabilityInvocation

публичные ключи и какими из них можно менять DID

проверка подписей следующих ревизий

proof, signerDid, keyId

подпись операции и кто подписал

неотказуемость

recordedAt

когда записано в did-svc

—

proofStatus (ставит чейнкод)

verified / unsigned / not_checked

что реестр проверил сам

Не попадает в реестр: адреса сервисов из DID-документа, тела запросов, любые данные паспорта или сертификата, названия и реквизиты организаций, персональные данные.

Функции

Функция

Что делает

AnchorRevision

принимает ревизию, проверяет, записывает; событие DIDRevisionAnchored

GetHead

последняя версия DID: номер, отпечаток, деактивирован ли

GetRevision

ревизия по номеру

VerifyDigest

записана ли ревизия с таким отпечатком (для внешней сверки)

Что чейнкод проверяет сам

  1. Цепочка: первая запись — create версии 1; каждая следующая — ровно версия + 1 и prevDigest равен отпечатку последней записанной. После деактивации записей нет.

  2. Право подписи: подписал сам DID, его контроллер или владелец предыдущей версии.

  3. Владение: новым владельцем можно стать только своей подписью (передача прибора в два шага).

  4. Ключ подписавшего берётся из реестра (его последней записанной версии), а не из запроса; ключ должен быть разрешён для изменения DID.

  5. Подпись: EdDSA (Ed25519) и ECDSA P-256/384/521 проверяются в чейнкоде; RSA и ГОСТ — запись принимается с proofStatus: not_checked (проверка у PKI-сервиса).

  6. Повтор той же записи — без ошибки (сервис может повторить после сбоя связи); другая запись с той же версией — конфликт.

Как ревизия попадает в реестр

В истории DID (/dids/{did}/history/verify) у каждой ревизии видно: подпись verified, в реестре pending → anchored.

Пример — передача прибора «Взлёт» → ОЙЛТИМ даёт в реестре две записи:

Версия

Подписал

owner

controller

2

«Взлёт»

«Взлёт»

прибор, ОЙЛТИМ

3

ОЙЛТИМ

ОЙЛТИМ

прибор

Запись версии 3, подписанную не ОЙЛТИМ, чейнкод отклонит, даже если did-svc её пропустит.

Что не сделано до выката

Что

Оценка

Адаптер did-svc → blockchain-svc (InvokeSmartContract), по образцу documents-svc

~2 дня

Учётная запись did-svc в сети (кто подписывает транзакции), политика одобрения транзакций

решение + девопс

Установка чейнкода в канал (как внешний сервис CCAAS), образ, переменные

девопс

TLS между peer и чейнкодом: сейчас выключен — привести к остальным чейнкодам (mTLS)

~0,5 дня

Статусы VC в реестре (выпуск/отзыв сертификата проверяется по реестру, а не по базе vc-svc)

~2 дня, см. вопрос 5

4. Какие поля куда — по присланным документам

Принцип: реестр — отпечатки и права; VC — то, что нужно проверяющему по метке; тело документа — всё остальное. VC публичен для владельца метки, поэтому персональные данные и коммерческие условия в VC не попадают.

Обозначения: ✅ есть в схеме сейчас · ➕ предлагается добавить · — не кладём.

Сертификат соответствия (РОСС RU.32968.04ИЦМ0.ОСП01.Н00020/24)

Поле документа

VC

Тело

Реестр

Номер сертификата

✅ number

✔

—

Срок действия с / по

✅ validFrom / validUntil

✔

—

Орган по сертификации

✅ издатель VC (DID органа) + ➕ certificationBodyRegNumber

✔

DID органа

Аттестат аккредитации органа

➕ accreditation

✔

—

Продукция

✅ scope → ➕ productName

✔

—

Серийный выпуск / партия

➕ productionType

✔

—

Коды ОКПД2, ТН ВЭД

➕ okpd2, tnved

✔

—

Нормативные документы (ТУ, ГОСТ 14254 IP…)

✅ standards

✔

—

Изготовитель, держатель (ИНН, ОГРН, адрес)

субъект VC (DID изготовителя); реквизиты — в карточке организации

✔

DID изготовителя

Протокол испытаний, лаборатория

➕ testReport

✔

—

Схема сертификации (1С)

➕ scheme

✔

—

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

➕ documentDigest (SHA-256 файла)

✔ файл

—

Телефоны, e-mail, подписи и печати

—

✔

—

Заводской паспорт («ВЗЛЕТ ЭР» Лайт М, зав. № 2208748)

Поле документа

VC

Тело

Реестр

Заводской номер

✅ serialId

✔

— (в DID-документ не кладём)

Модель

✅ nomenclature

✔

—

Модификация (Лайт М), исполнение (ЭРСВ-440ЛВ)

➕ modification, execution

✔

—

Типоразмер DN 150, вид потока

➕ nominalDiameter, flowDirection

✔

—

Дата приёмки ОТК (22.02.2023)

➕ acceptedOn (вместо manufacturedOn)

✔

—

№ в Госреестре СИ (52856-13)

➕ typeApprovalNumber

✔

—

ТУ (ШКСД.407212.006 ТУ)

➕ specification

✔

—

Гарантия 72 мес., межповерочный интервал 4 года

➕ warrantyMonths, verificationIntervalYears

✔

—

Код изделия со штрихкода (AF00002860148)

➕ productCode

✔

—

Ссылка на сертификат соответствия

✅ certificate

—

—

Технические и метрологические характеристики

— (по модели, не по экземпляру)

✔

—

Калибровочные коэффициенты, константы выходов

— (см. вопрос 3)

✔

—

ФИО контролёра ОТК

— (персональные данные)

✔

—

Комплект поставки, отметки о работах, поверка

— (отдельные будущие документы)

✔

—

Файл паспорта

➕ documentDigest

✔ файл

—

Прибор (экземпляр)

субъект VC

—

✔ DID прибора, владелец, история передач

Договор поставки (ТДВП-26)

Что

VC

Тело

Реестр

Текст, цены, спецификации, реквизиты

—

✔ формализованным телом (не tiff); сервис — уточнить: contracts-svc (аналитик) или documents-svc (вики, код)

docs-chaincode, не did-registry

Основание передачи прибора

➕ ссылка из документа приёмки: id договора/УПД + SHA-256

✔

—

Правила приёмки (2 рабочих дня по количеству, 30 дней по качеству, фото серийных номеров при расхождении)

→ требования к будущему документу приёмки (тезис 5)

✔

—

Карточка организации

Поле

VC

Реестр

Название, ИНН, ОГРН, роль

✅ OrganizationCredential (самозаявлено до УКЭП ЮЛ)

—

DID, ключи

—

✔

5. Вопросы на утверждение

  1. Три слоя (реестр — отпечатки и права; VC — выжимка для проверки; тело — документ целиком) — принимаем?

  2. Состав полей VC сертификата и паспорта (➕ в таблицах) — утвердить, поправить, что лишнее.

  3. Калибровочные коэффициенты: только в теле документа (как предлагаем) или нужны в VC для поверителя / эксплуатанта?

  4. Ссылки паспорта: только сертификат соответствия или ещё декларации ТР ТС 004/020/032, утверждение типа СИ, сведения о поверке (ФГИС «Аршин»)? Сейчас ссылка одна.

  5. Статусы VC в реестре: записывать выпуск/отзыв сертификата в did-registry, чтобы отзыв проверялся по реестру, а не по базе vc-svc? Тогда в реестр нужно добавить и ключи подписи VC (assertionMethod) — сейчас записываются только ключи изменения DID.

  6. Один чейнкод на DID и статусы VC (предлагаем — проще одобрение транзакций) или два.

  7. Орган по сертификации в демо: по присланному сертификату это ИЦ «Метрика»; «Русский регистр» сертифицирует систему менеджмента качества «Взлёта». Меняем в сценарии или оставляем условным?

  8. Кто пишет в реестр: учётная запись did-svc в сети и политика одобрения (одна организация / большинство).

6. Сверка с вики (US-07-09, PD-35, модель сущностей КТМ-А) — 20.10.2026

Совпадает: DID и VC первыми в блокчейн (PD-32, PD-35в); world state, а не SideDB (US-07-09 R4.1, встреча 14.10); выпуск DID только с подписью, приём VC только с проверкой (R2, R3); хэш-цепочка версий (R2.3); подписи перепроверяет чейнкод (R4.2); PostgreSQL — кэш (PD-21); файлы в блокчейн не идут (PD-35); регистрация агента организацией, мандат, runtime-VC, вход по ключу (R6–R8); вход партнёров «API Key + VC» (стенд ДАС, 02.10).

Расходится — нужны решения:

#

Вики

Сделано у нас

Что решить

Р1

PD-35а: все сервисы пишут в блокчейн через docs-chaincode-svc; US-07-08 модель А: два чейнкода (DID, VC); US-07-09: один новый; OQ-67 открыт

отдельный did-registry, только DID

в OQ-67: свой чейнкод DID/VC или через docs-chaincode (редизайн world state)

Р2

ЦП — отдельная DID-сущность-агрегат с did-расширением (entityType, статус, иерархия, журнал событий) по JSON-schema, её ведёт assets-app; объект — свой DID с VC характеристик (AssetAttributes), связь — VC PassportData; статусы — DapStatusCredential; идентификаторы — uuid (модель сущностей, 11.08)

DID прибора + VC паспорта — это их DID актива + VC характеристик; DID-агрегата ЦП и did-расширения нет; идентификаторы выводятся из ключа

нужен ли DID-агрегат ЦП; поддержать did-расширение в did-svc; uuid или из ключа

Р3

имена методов в самой вики не сведены: прибор — did:ktm:asset (модель 08.2026, PD-18) или did:scada:device (встреча 14.10, черновик; US-07-09); паспорт — did:pass:uuid / did:ktm:pass / did:passport; организации — did:ru:org, агенты — did:ru:agent

did:ru:org, did:ru:device, did:ru:agent (согласовано устно)

закрепить таблицу методов решением PD и поправить модель сущностей, PD-18, US-07-09 R5.1

Р4

КХО (бывш. УПД) — два VC: титул продавца и покупателя (PD-24), статусы «Отправлен»/«Получен» (PD-25)

передача — две подписанные ревизии DID

смена владельца DID по исполненному КХО (связать) или заменить

Р5

договор — существующая сущность documents-svc (EPIC-03); аналитик 20.10 — contracts-svc; договор раньше всех действий

шаг договора в сценарии нет

где живёт договор; в демо — шаг «договор подписан» первым

Р6

VC — событие, основание перехода статуса (PD-23, PD-26)

VC — и документы (паспорт, сертификат), и события (заключение, мандат)

достаточно ли этого или паспорт — только DID + события-VC

Р7

cspgw/cspemul нет в глоссарии (В5); проверка PKI — ветки OSSL ГОСТ и vipnet (PD-38)

план ГОСТ через cspemul/CSP

соотнести с PD-38

Задача в трекере по вики — KCONT-2290 (US-07-09).

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

Дата

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

Автор

2026-11-05

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

Дис