Серия статей по ДАС: структура и тезисы

!ai Документ подготовлен ИИ по вики ДАС, вики КТМ-А и коду стенда dev4. Предложения — гипотезы до решения.

Версия от 10.11.2026. Готового текста статей здесь нет, только структура и идеи. Сверено с вики ДАС (wiki/dac), вики КТМ-А (wiki/contracteum) и кодом реестра DID и сервиса удостоверений на стенде dev4.

Три статьи можно подать отдельно или объединить. Каждая следующая опирается на предыдущую: идентификаторы и удостоверения → цепочки зависимости удостоверений → доверенные агентные сети.

Статьи концептуальные: они показывают идею и то, как всё должно работать. Экспериментов и замеров нет. Работоспособность подтверждает демонстрация на стенде взаимодействия организаций.

Общее для серии

Принципы подачи

• Партнёров не называем. Вместо названий пишем роли: «изготовитель», «сертифицирующая организация», «покупатель-комплектатор», «внешняя система маркировки», «демонстрационный стенд взаимодействия организаций». Марку и модель прибора тоже не указываем, потому что они выдают изготовителя. Пишем «электромагнитный расходомер-счётчик», заводской номер и номер блока заменяем условными.

• Код и названия сервисов не раскрываем. Пишем «прототип реестра DID» и «сервис удостоверений».

• Реализованное и предлагаемое разводим явно. Для каждой части пишем: «показано на демонстрации» или «предлагается». Опираемся на отметки ✅ / 🟡 / ⬜ из вики ДАС.

• Формальная проверка — как предложение метода. Предлагаем проверять протоколы в ProVerif. ProVerif — программа автоматического анализа криптографических протоколов: противник полностью управляет сетью, а свойство либо доказывается, либо опровергается сценарием атаки. Пробная модель передачи владения уже нашла недостаток (см. статью 1) — это аргумент в пользу предложения.

• Аннотация, название и ключевые слова на английском обязательны почти во всех журналах ВАК, даже для русскоязычной статьи: это метаданные для РИНЦ.

Термины

«Свидетельство» как общий термин не используем: в метрологии это название документа («свидетельство об утверждении типа СИ»).

Общий пример

Сквозной сценарий демонстрационного стенда:

1. Сертифицирующая организация выпускает сертификат соответствия серии.

2. Изготовитель регистрирует DID прибора и выпускает паспорт со ссылкой на сертификат. Метка на приборе кодирует его DID.

3. Покупатель-комплектатор сканирует метку и получает паспорт и статус сертификата.

4. Покупатель проводит входной контроль и принимает владение. Передача идёт в два шага: изготовитель вписывает покупателя в контроллеры, покупатель своей подписью ставит себя владельцем.

5. Покупатель устанавливает прибор в технологический блок, у которого свой DID и паспорт.

6. Сертификат отзывают. Система находит затронутые паспорта и их текущих владельцев.

7. Агент сертифицирующей организации готовит карточку сертификата по исходному документу, подписывает сертификат человек.

Статья 1 берёт шаги 1–5, статья 2 — шаги 1, 2, 6 и связи между удостоверениями, статья 3 — шаг 7.

Вопросы ко всей серии

• Журналы: по одному на каждую статью или один на всю серию? От этого зависят шаблон и объём.

• Авторы и аффилиация каждой статьи.

Статья 1. Идентификаторы и удостоверения

Варианты названия

1. «Идентификация доверия: децентрализованные идентификаторы и проверяемые удостоверения для организаций и промышленного оборудования».

2. «Идентификация доверия, или пара слов о DID и VC» — рабочее; для РИНЦ нужен строгий подзаголовок.

3. «Децентрализованные идентификаторы с ответственным владельцем для межорганизационного документооборота».

Главная мысль

Идентификатор организации и изделия не принадлежит оператору системы. За изделие отвечает конкретная организация, и сменить её можно только с её согласия. Право выпускать удостоверения о субъекте следует за владельцем. Подпись проверяется по истории ключей, поэтому смена ключа не обесценивает прошлые документы.

Что заявляем как новое

• owner отделён от controller; владельца назначает только он сам своей подписью;

• право выпуска VC о субъекте есть только у его владельца или контроллера;

• подпись VC проверяется по версии DID-документа эмитента на момент выпуска (ключ действует / заменён / эмитент деактивирован);

• проверяемая история: каждая ревизия подписана, ревизии связаны хэш-цепочкой, голова цепочки фиксируется в Hyperledger Fabric;

• привязка DID организации к квалифицированному сертификату (ИНН, ОГРН);

• профиль ГОСТ Р 34.10-2012 для JWS;

• проверка протокола передачи владения в ProVerif.

Структура

Ответы на вопросы по частям (найдено в вики и коде)

• Оператор реестра — не доверенная сторона в части истории. Подделать ревизию он не может (подписи и хэш-цепочка, TD-01), но может скрыть или откатить её. От этого защищает фиксация в HLF (TD-02).

• Исключать ли изготовителя из **controller** после передачи. Сейчас этот шаг необязателен. Пока изготовитель остаётся контроллером, он вправе выпускать паспорт прибора. Предлагаем для оборудования сделать этот шаг обязательным.

• Ключи организаций на стенде хранятся на платформе. По спецификации метода ключ генерируется у субъекта, а реестр получает только открытый ключ. Хранение на стенде — упрощение демонстрации, и в статье так и пишем.

• Статус удостоверения хранит реестр, целевой вариант — в HLF. Битовый список W3C не используем: сведения об оборудовании открытые. Для персональных данных указываем битовый список как направление развития.

• Привязка к КЭП. В квалифицированном сертификате ОГРН лежит в атрибуте 1.2.643.100.1, ИНН юрлица — в 1.2.643.100.4 (по приказу ФСБ № 795; номера по памяти, сверить с текстом приказа). При реорганизации ОГРН меняется: делается новая операция привязки с подписью новым сертификатом, а старая привязка остаётся в истории.

• Имя **did:ru** оставляем. Спецификация метода уже отмечает, что это код страны и что перед подачей в реестр W3C нужно согласовать имя с редакторами (TD-04). В статье это пункт в «Ограничениях».

• ProVerif — в этой статье, потому что здесь описан протокол передачи. Пробная модель показала: на первом шаге получатель сразу становится полноправным контроллером и может передать прибор дальше, не приняв его. Предлагаемое исправление: отдельное поле «ожидающая передача», которое разрешает получателю только принять прибор и выпустить акт входного контроля. Исправление нужно описать в модели и проверить, после этого предложить в код.

• Замеры не нужны: статья про концепцию, демонстрации достаточно.

Вопросы

• Идентификаторы алгоритмов ГОСТ для JWS (GOST3410-2012-256 и т. п.) мы придумали сами. Есть ли у ТК 26 документ, на который можно сослаться, или в статье подаём их как своё предложение?

Что есть

Черновик в LaTeX — на сервере test-i, /home/dev/papers/did-ru/. Если текст пишете сами, его можно брать как источник формул, схем и модели ProVerif. В черновике пока не обезличены марка и модель прибора и номер блока.

Статья 2. Цепочки зависимости удостоверений

Варианты названия

1. «Доверяй, но проверяй: цепочки зависимости проверяемых удостоверений».

2. «Доверяй, но проверяй: что происходит с документами, когда отзывают то, на что они опираются».

3. «Доверяй, но проверяй: от утверждения типа средства измерений до паспорта изделия».

Главная мысль

Проверить одну подпись мало: нужно проверить, на что опирается удостоверение и действует ли это основание. В PKI цепочка подтверждает право подписи. Здесь цепочка подтверждает факты. Подлинность документа и его действительность — разные вещи: паспорт остаётся подлинным, даже если сертификат серии отозван.

Что заявляем как новое

• Типы ссылок и разная семантика отзыва:

  • replaces — новый паспорт отзывает прежний;

  • certificate — статус сертификата показывается отдельно, паспорт остаётся подлинным;

  • inputs — основания результата агента;

  • basedOn — документ человека опирается на черновик агента.

• Учёт времени: основание, отозванное до выпуска зависящего удостоверения, — часть его доказательной базы, и вывод остаётся в силе. Отозванное после — вывод устарел. В коде это состояния revoked_known и revoked_input.

• Поиск всех затронутых субъектов и их текущих владельцев при отзыве звена.

• Статус «исполнено» — удостоверение снимается не потому, что эмитент его отозвал, а потому что обязательство выполнено. Исполнение подписывают две стороны (пример «от мамы»).

Структура

Ответы на вопросы по частям

• Каскад или пометка. Пометка: зависящее удостоверение не отзывается автоматически, проверка показывает статус основания отдельно. Автоматический каскад — только для замены паспорта (replaces). Так в коде и в вики ДАС (тезис 6: «автоматически на всю историю не переносится»).

• Ссылка на ещё не выпущенное удостоверение. Паспорт может появиться раньше сертификата. Тогда паспорт заменяют новым со ссылкой на действующий сертификат: это описано в схеме паспорта.

• Кто эмитент утверждения типа и поверки. На стенде утверждение типа входит в паспорт номером, отдельного VC нет. Предлагаем подать так: в целевой модели эмитенты — Росстандарт (утверждение типа) и поверочная лаборатория (поверка). Пока они не выпускают VC, сведения берутся из «Аршина», и платформа выступает посредником с пометкой об источнике.

• Пример с долгом — это поручение «от мамы» из вики ДАС, сюжет описан выше.

• ProVerif в этой статье не нужен: проверка протокола передачи — в статье 1.

Вопросы

• Термин: «цепочки зависимости удостоверений» или «происхождение удостоверений» (credential provenance)?

• Статус «исполнено» вводим как предложение или сначала реализуем, чтобы показать на стенде?

Статья 3. Доверенные агентные сети

Варианты названия

1. «Доверенные агентные сети: полномочия и самопредставление программных агентов в межорганизационном документообороте».

2. «Доверенные агентные сети: мандат агента по образцу машиночитаемой доверенности».

3. «Доверенные агентные сети: агент как представитель организации».

Главная мысль

Агент — представитель организации, а не субъект права. Отвечает за него владелец. Агент действует только в пределах мандата: какие действия, по какой продукции (коды ОКПД2), в какой конфигурации. Что агенту разрешено, решает платформа по мандату, а не модель. Каждый результат агента подписан и ссылается на основания, а юридически значимый документ подписывает человек.

Как агент себя представляет (варианты)

Самопредставление словами модели («сообщи свои характеристики») ничего не доказывает. Каждое утверждение агента о себе должно опираться на подписанный артефакт. Инструментов для этого достаточно:

Что заявляем как новое

• мандат агента как аналог МЧД: выдаёт только владелец, перечисляет действия, продукцию и конфигурацию;

• область полномочий по ОКПД2 с учётом иерархии: код из мандата разрешает и все вложенные коды;

• «полномочия решает платформа, а не модель»: наличие инструмента не даёт права им пользоваться;

• самопредставление через подписанные артефакты (таблица выше) и сверка конфигурации с мандатом;

• разделение ролей: агент готовит черновик, человек подписывает юридически значимый документ.

Структура

Ответы на вопросы по частям

• Лаборатория и эксперименты — не упоминаем. Есть демонстрация, что схема работает.

• УПД. В вики КТМ-А УПД переименован в КХО (25.09.2026). Модель — два VC (PD-24), эпик в статусе «эскиз», кода в develop нет. В прототипе КТМ-А полномочия и МЧД не реализуют (решение от 28.07.2026), сервис МЧД есть в самой платформе. Поэтому КХО в статье — предлагаемый сценарий, а не демонстрация. Основной пример — карточка сертификата.

• Мандат и МЧД. Не утверждаем, что мандат — это МЧД. Сравниваем: общее — доверитель, представитель, перечень полномочий, срок, отзыв; отличие — мандат фиксирует ещё и конфигурацию исполнителя.

• ОКПД2 и типы изделий решают разные задачи. ОКПД2 ограничивает полномочия агента по продукции. Тип изделия определяет, к каким приборам применим сертификат соответствия. В статье 3 — только ОКПД2.

• Чем подтверждается самоотчёт. Сейчас ничем, кроме подписи самого агента. Это защищает от незаметного дрейфа конфигурации, но не от обмана. Подтверждение средой запуска и аппаратная аттестация — варианты 7–8 в таблице выше.

Вопросы

• Подписанное рассуждение (вариант 6): хранить у владельца только хэш журнала или класть журнал в удостоверение целиком? От этого зависит, что проверяющий увидит без запроса к владельцу.

• «Поверка» агента (вариант 8): кто третья сторона — сама организация, независимая лаборатория, сертифицирующая организация? Или вариант только упоминаем как направление развития?

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