Как архитектура цифрового доверия становится понятной, проверяемой и совместимой с международным цифровым пространством.

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

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

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

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

В этой модели домен .KG дает человеку понятный цифровой адрес, DID дает машинно-проверяемую идентичность, Verifiable Credentials описывают проверяемые полномочия и статусы, PROV показывает происхождение данных, Data Integrity защищает цифровые доказательства, а DLT и Арбитражный Архив фиксируют и сохраняют доказательства фактов.

Итог: цифровое доверие становится не только национальным, но и совместимым с международными архитектурными стандартами.

Что такое W3C-профиль

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

В рамках trust.asiainfo.kg W3C-профиль рассматривается как открытый слой совместимости для архитектуры доверия. Он не заменяет национальные законы, государственные стандарты, DLT-сеть или Арбитражный Архив. Его роль — дать системе общий международный язык данных и доказательств.

Зачем это нужно

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

Главная идея

Доверенная цифровая экосистема должна быть суверенной по управлению, но открытой по стандартам совместимости.

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

Формула W3C-профиля:

суверенная инфраструктура + открытые стандарты + проверяемые данные + криптографические доказательства + DLT-якорение + архивная сохранность

Как W3C встраивается в архитектуру доверия

W3C-профиль работает не отдельно, а внутри общей архитектуры цифрового доверия.

Слой архитектуры	Роль W3C-профиля
Identity / Naming Layer	DID и Verifiable Credentials помогают описывать цифровую идентичность субъектов, организаций, сервисов и узлов.
Document / Event Layer	JSON-LD помогает описывать документы и события в машинно-читаемой форме.
Crypto / Proof Layer	Data Integrity и JOSE/COSE помогают формировать проверяемые криптографические доказательства.
Provenance Layer	PROV помогает описывать происхождение документа или события: кто, что, когда и на каком основании создал.
DLT / Trust Layer	DLT фиксирует доказательство события, а W3C-структуры помогают сделать это доказательство понятным для внешних систем.
Archive / Legal Layer	Арбитражный Архив хранит юридически значимые пакеты, а W3C-метаданные помогают сохранить контекст происхождения и проверки.
Verification Layer	Проверяющая сторона может проверить DID, credential, proof, hash, DLT receipt и archive receipt через понятные интерфейсы.

Ключевые стандарты и технологические модели

1. DID — Decentralized Identifiers / децентрализованные идентификаторы

DID — это машиночитаемый идентификатор субъекта, сервиса, организации, документа, устройства или узла сети. Он позволяет связать цифровой объект с криптографическими ключами, методами проверки и сервисными точками.

В нашей архитектуре DID может использоваться для описания:

• организации или ИП;
• государственного органа или ведомственного сервиса;
• доверенного шлюза;
• DLT-узла;
• архивного сервиса;
• цифрового паспорта субъекта;
• системного участника или устройства.

Домен .KG остается человекочитаемым идентификатором, а DID добавляет машинно-проверяемый криптографический слой.

2. Verifiable Credentials / проверяемые цифровые удостоверения

Verifiable Credentials позволяют представить цифровой статус, полномочие, разрешение, лицензию, сертификат или паспорт субъекта в проверяемой форме.

В архитектуре доверия они могут использоваться для:

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

Модель Verifiable Credentials строится вокруг трех ролей: issuer (тот, кто выдает), holder (тот, кто хранит и предъявляет) и verifier (тот, кто проверяет).

3. Verifiable Presentations / проверяемые представления

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

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

4. Data Integrity / криптографическая целостность

Data Integrity описывает способ защиты цифрового объекта от подмены. Если документ, credential или proof изменится, проверка целостности покажет, что объект больше не соответствует исходному доказательству.

В архитектуре доверия Data Integrity используется вместе с хэшированием, подписью, временной меткой, DLT-якорением и архивной квитанцией.

5. JSON-LD / семантический JSON

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

JSON-LD помогает связать национальную модель данных с международными контекстами и словарями.

6. PROV / происхождение данных

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

В архитектуре доверия PROV отвечает на ключевые вопросы:

• кто создал документ;
• какое действие было совершено;
• в какой системе возникло событие;
• какая версия документа была исходной;
• какая версия является производной;
• кто несет ответственность за действие.

DLT фиксирует факт, а PROV объясняет происхождение этого факта.

7. WebAuthn / сильная веб-аутентификация

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

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

8. ODRL / политики доступа и использования

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

Для Арбитражного Архива и verification-сервисов это особенно важно: доступ к доказательствам должен быть управляемым, журналируемым и основанным на правовых основаниях.

9. RDF Dataset Canonicalization / канонизация данных

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

Канонизация помогает обеспечить стабильное доказательство для JSON-LD/RDF-данных, цифровых удостоверений и проверяемых событий.

10. Status List / статус цифрового удостоверения

Для цифровых удостоверений важно не только выдать credential, но и уметь проверить его текущий статус: действует ли он, отозван ли, приостановлен ли, заменен ли новым.

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

Как это работает вместе с DLT

W3C-профиль не заменяет DLT. Он подготавливает данные, идентичность, полномочия и доказательства в понятной форме. DLT фиксирует доказательство события так, чтобы его нельзя было незаметно изменить или удалить.

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

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

Как это работает вместе с Арбитражным Архивом

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

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

Базовая цепочка совместимости

1. Субъект получает цифровую идентичность: домен, учетную запись, DID или иной идентификатор.
2. Субъект получает проверяемое полномочие: Verifiable Credential.
3. Документ или событие создается в системе-источнике.
4. Событие получает структурированные метаданные и JSON-LD-контекст.
5. Формируется криптографическое доказательство: hash, signature, timestamp.
6. Provenance-модель описывает происхождение события.
7. Доказательство передается через Trust Gateway.
8. DLT фиксирует доказательство события.
9. Арбитражный Архив принимает архивный пакет.
10. Verifier проверяет credential, proof, DLT receipt и archive receipt.

Примеры применения

Сценарий	Как применяется W3C-профиль
Цифровой паспорт бизнеса	Компания получает проверяемое цифровое удостоверение с регистрационными данными, статусами, полномочиями и ссылками на официальные источники.
Полномочие директора	Полномочие оформляется как credential, который можно проверить до подписания документа.
Лицензия или разрешение	Лицензирующий орган выступает issuer, компания выступает holder, банк или контрагент выступает verifier.
Проверка документа	Документ связывается с proof, DLT receipt, archive receipt и provenance-цепочкой.
Архивное доказательство	Архивная квитанция содержит проверяемые идентификаторы, хэши, ссылки и статус хранения.
Международная интеграция	Внешняя система может понять структуру credential, проверить proof и сверить статус без раскрытия всех внутренних данных.

Что получает пользователь архитектуры

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

Что получает разработчик или интегратор

• единые модели данных для identity, credentials, events, proofs и receipts;
• понятные API для проверки;
• машиночитаемые схемы;
• возможность использовать JSON-LD и VC-совместимые структуры;
• разделение документа, доказательства, DLT-записи и архивного пакета;
• инженерную основу для RFC и последующих спецификаций.

Принципы W3C-профиля

• Открытость форматов: данные и доказательства должны быть понятны внешним системам.
• Суверенность управления: инфраструктура, домены, узлы и архив остаются в национальной архитектуре.
• Минимизация раскрытия: проверка не должна требовать передачи лишних персональных или коммерческих данных.
• Криптографическая проверяемость: любое доказательство должно быть проверяемым технически.
• Разделение ролей: issuer, holder, verifier, archive, DLT node и trust gateway должны иметь понятные функции.
• Долговременность: доказательство должно сохранять смысл через годы, даже если меняются системы-источники.

Заключение

W3C-профиль делает архитектуру доверия международно совместимой: DID описывает цифровую идентичность, Verifiable Credentials — проверяемые полномочия и статусы, JSON-LD — машинно-читаемую структуру данных, PROV — происхождение событий, Data Integrity — криптографическую целостность, а DLT и Арбитражный Архив обеспечивают неизменяемую фиксацию и правовую сохранность доказательств.