Первые открытые инженерные спецификации для доверенных цифровых событий, цифровой идентичности, цифровой первички и DLT-доказательств.

RFC (Request for Comments / проектная спецификация для обсуждения) — это рабочий формат описания архитектурных решений. Через RFC фиксируются модели данных, форматы квитанций, правила идентичности, схемы событий, API и принципы совместимости.

Страница RFC публикует не маркетинговые описания, а технический язык архитектуры доверия: что такое доверенное цифровое событие, как субъект получает идентичность, как создается цифровая первичка и как DLT фиксирует доказательство факта.

Коротко за 30 секунд

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

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

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

Что такое RFC в архитектуре доверия

RFC (Request for Comments / запрос комментариев) — это инженерный документ, который описывает одно архитектурное решение или один технический профиль. RFC может находиться в статусе draft (черновик), candidate (кандидат), stable (стабильная версия) или deprecated (устаревшая версия).

В контексте trust.asiainfo.kg RFC используются как открытые проектные спецификации. Они позволяют публиковать архитектуру постепенно, получать обратную связь, фиксировать версии и разделять большую экосистему на управляемые технические блоки.

RFC не заменяют государственный стандарт, закон или внутренние регламенты. Их задача — описать инженерные модели, которые затем могут быть использованы в стандартах, API, документации, пилотах и интеграциях.

Зачем публиковать RFC

Чтобы архитектура доверия была прозрачной для разработчиков и интеграторов.
Чтобы модели данных были версионируемыми и не зависели от одного закрытого описания.
Чтобы документы, события, доказательства и квитанции имели единые форматы.
Чтобы W3C-профиль, DLT-слой, Арбитражный Архив и verification API развивались согласованно.
Чтобы каждый новый участник экосистемы понимал, какие правила применяются к идентичности, документу, событию, доказательству и проверке.

Первые 4 проектные спецификации

RFC	Назначение	Публичный результат
RFC-001	Trust Event Model / модель доверенного цифрового события	Единая структура события: субъект, действие, документ, время, полномочие, доказательство, маршрут и статус.
RFC-002	Domain / DID Identity Profile / профиль доменной и DID-идентичности	Связь человекочитаемых доменов .KG с машинно-проверяемой цифровой идентичностью.
RFC-003	Digital Primary Document Model / модель цифровой первички	Структура исходно цифровых документов: договор, акт, счет, накладная, уведомление и другие первичные документы.
RFC-004	DLT Receipt Format / формат DLT-квитанции	Проверяемое подтверждение фиксации цифрового события в DLT-сети.

RFC-001: Trust Event Model

Русское название: модель доверенного цифрового события.

Назначение: RFC-001 описывает базовую единицу архитектуры доверия — доверенное цифровое событие (Trust Event). Событие возникает тогда, когда субъект совершает юридически или операционно значимое действие: создает документ, подписывает акт, отправляет уведомление, меняет статус, подтверждает полномочие или инициирует передачу в архив.

Trust Event связывает в одну сущность несколько обязательных элементов: кто действует, от чьего имени, какое действие совершено, какой документ или объект затронут, когда это произошло, через какой маршрут прошло событие, какое криптографическое доказательство сформировано и в каком статусе находится событие.

Что определяет RFC-001

структуру Trust Event;
обязательные и дополнительные поля события;
типы событий;
связь события с документом, субъектом, полномочием и маршрутом;
правила формирования event_id, trace_id и route_id;
связь события с proof layer, DLT receipt и archive receipt;
статусы события: draft, validated, anchored, archived, verified, rejected.

Минимальная структура Trust Event

{
«event_id»: «EVT-2026-000001»,
«event_type»: «DOCUMENT_CREATED»,
«subject_id»: «SUBJ-000001»,
«actor_id»: «USER-000001»,
«authority_id»: «AUTH-000001»,
«document_id»: «DOC-2026-000001»,
«timestamp»: «2026-01-01T12:00:00+06:00»,
«trace_id»: «TRACE-000001»,
«route_id»: «ROUTE-000001»,
«proof»: {
    «hash»: «sha256:…»,
    «signature»: «…»,
    «proof_type»: «DataIntegrityProof»
},
«status»: «VALIDATED»
}

Публичный результат RFC-001

После публикации RFC-001 у архитектуры появляется единый язык для описания всех значимых действий. Любой документ, проверка, квитанция или маршрутизация может быть связана с конкретным Trust Event.

RFC-002: Domain / DID Identity Profile

Русское название: профиль доменной и DID-идентичности.

Назначение: RFC-002 описывает, как человекочитаемая доменная идентичность связывается с машинно-проверяемой цифровой идентичностью. Домен позволяет человеку и организации понимать, кто является субъектом или сервисом. DID (Decentralized Identifier / децентрализованный идентификатор) позволяет системе проверить субъект криптографически.

В этой модели домен .KG выступает как устойчивый публичный адрес, а DID — как технический идентификатор для ключей, сервисов, endpoint-адресов, полномочий и проверяемых удостоверений.

Что определяет RFC-002

профиль доменной идентичности;
правила связи домена и DID;
типы субъектов: организация, ИП, госорган, сервис, узел, шлюз;
структуру DID Document;
сервисные endpoint-адреса;
связь с Verifiable Credentials;
правила доверия к домену, ключу, сервису и узлу.

Пример связи домена и DID

Домен:        org.asiainfo.kg
DID:          did:kg:asiainfo:org
Сервис:       https://trust.asiainfo.kg/verify
DLT-узел:     node01.dlt.trust.asiainfo.kg
DID узла:     did:kg:dlt:node01
Archive API: https://archive.trust.asiainfo.kg/receipt

Минимальная структура DID-профиля

{
«id»: «did:kg:asiainfo:org»,
«controller»: «org.asiainfo.kg»,
«verificationMethod»: [
    {
      «id»: «did:kg:asiainfo:org#key-1»,
      «type»: «JsonWebKey2020»,
      «controller»: «did:kg:asiainfo:org»,
      «publicKeyJwk»: { }
    }
],
«service»: [
    {
      «id»: «did:kg:asiainfo:org#verify»,
      «type»: «VerificationService»,
      «serviceEndpoint»: «https://trust.asiainfo.kg/verify»
    }
]
}

Публичный результат RFC-002

После публикации RFC-002 участники экосистемы получают понятный принцип цифровой идентичности: домен дает читаемую привязку, DID дает машинную проверку, ключи и service endpoints обеспечивают интеграцию.

RFC-003: Digital Primary Document Model

Русское название: модель цифровой первички.

Назначение: RFC-003 описывает модель документа, который создается сразу в цифровой форме. Это не скан бумажного документа и не PDF-копия. Digital Primary Document (цифровой первичный документ) рождается в системе как структурированный цифровой объект: с реквизитами, метаданными, субъектами, полномочиями, версией, статусом, хэшем и связью с Trust Event.

Модель применима к договорам, актам, счетам, накладным, уведомлениям, протоколам, справкам, решениям и иным документам, которые должны быть проверяемыми, трассируемыми и пригодными для архивирования.

Что определяет RFC-003

структуру цифрового первичного документа;
обязательные реквизиты;
метаданные и версии;
связь документа с субъектами и полномочиями;
связь с Trust Event;
правила формирования хэша;
состояния документа: draft, issued, signed, sent, received, archived, revoked;
подготовку документа к DLT-якорению и архивированию.

Минимальная структура цифрового первичного документа

{
«document_id»: «DOC-2026-000001»,
«document_type»: «ACT_OF_SERVICE»,
«version»: «1.0»,
«issuer»: «did:kg:company:123456»,
«recipient»: «did:kg:company:987654»,
«created_at»: «2026-01-01T12:00:00+06:00»,
«status»: «SIGNED»,
«metadata»: {
    «amount»: «15000.00»,
    «currency»: «KGS»,
    «contract_id»: «CON-2026-000010»
},
«hash»: «sha256:…»,
«event_id»: «EVT-2026-000001»,
«trace_id»: «TRACE-000001»
}

Публичный результат RFC-003

После публикации RFC-003 становится понятно, чем цифровая первичка отличается от электронной копии. Документ создается как цифровой объект, сразу пригодный для проверки, маршрутизации, DLT-фиксации и архивирования.

RFC-004: DLT Receipt Format

Русское название: формат DLT-квитанции.

Назначение: RFC-004 описывает формат DLT-квитанции (DLT Receipt) — проверяемого подтверждения того, что конкретное цифровое событие было зафиксировано в распределенном реестре доказательств.

DLT-квитанция не раскрывает полный документ. Она подтверждает факт: событие с таким идентификатором, таким хэшем, такой временной меткой и таким статусом было принято DLT-сетью и подтверждено узлами.

Что определяет RFC-004

структуру DLT-квитанции;
связь с Trust Event;
связь с document_id и hash;
временную метку фиксации;
подтверждения узлов;
статус фиксации;
ссылку на архивную квитанцию, если документ был архивирован;
правила публичной или ограниченной проверки.

Минимальная структура DLT-квитанции

{
«dlt_receipt_id»: «DLT-2026-000001»,
«event_id»: «EVT-2026-000001»,
«document_id»: «DOC-2026-000001»,
«hash»: «sha256:…»,
«anchored_at»: «2026-01-01T12:00:05+06:00»,
«network»: «trust-dlt-kg»,
«confirmations»: [
    «NODE-ASIAINFO»,
    «NODE-GOV»,
    «NODE-ARCHIVE»
],
«status»: «CONFIRMED»,
«archive_receipt_id»: «ARCH-2026-000001»
}

Публичный результат RFC-004

После публикации RFC-004 появляется единый формат доказательства DLT-фиксации. Участник может проверить не весь документ, а факт его существования, неизменность хэша, время фиксации и подтверждение узлов.

Как первые 4 RFC работают вместе

RFC-001 описывает событие. RFC-002 описывает цифровую идентичность субъекта. RFC-003 описывает цифровой документ. RFC-004 описывает квитанцию, подтверждающую фиксацию доказательства в DLT.

Вместе они формируют минимальное инженерное ядро архитектуры доверия:

Identity → Document → Trust Event → Proof → DLT Receipt → Verification

Эта цепочка позволяет строить проверяемые цифровые процессы без передачи полного содержания документа всем участникам сети.

Как читать статус RFC

Draft / черновик: спецификация опубликована для обсуждения и проверки архитектурной логики.
Candidate / кандидат: структура стабилизирована и готовится к пилотному применению.
Stable / стабильная версия: спецификация может использоваться в интеграциях и документации.
Deprecated / устаревшая версия: спецификация заменена новой редакцией, но может сохраняться для обратной совместимости.

Связь RFC с W3C-профилем

Первые RFC должны быть совместимы с международными архитектурными подходами. Поэтому в них учитываются W3C DID, Verifiable Credentials, JSON-LD, Data Integrity, PROV и связанные модели проверки.

Это не означает, что архитектура становится внешне зависимой. Суверенная инфраструктура управляется внутри национального контура, но данные, идентичность и доказательства описываются в форматах, которые понятны международному цифровому пространству.

Что будет дальше

После первых четырех RFC планируется публикация следующих проектных спецификаций:

RFC-005: Archive Receipt Format / формат архивной квитанции;
RFC-006: Provenance Model / модель происхождения данных;
RFC-007: Trust Gateway API / API доверенного шлюза;
RFC-008: Verification API / API проверки;
RFC-009: Business Passport Credential / проверяемый цифровой паспорт бизнеса;
RFC-010: T+1 Event Model / модель событий для аналитики T+1.

RFC: проектные спецификации архитектуры доверия