Спецификация децентрализованных идентификаторов (DID) W3C (RU)

Спецификация децентрализованных идентификаторов (DID) W3C определяет синтаксис URI, общую модель данных, DID-документы, основные свойства, представления, требования к методам и абстрактные интерфейсы для разрешения и дереферирования DID URL. DID Core 1.0 стал Рекомендацией W3C 19 июля 2022 года. DID Core 1.1 был опубликован как снимок Рекомендации-кандидата 5 марта 2026 года; это более новая работа на другом этапе стандартизации.

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

Основные выводы

• DID — это URI, а не учетные данные. Его общая форма: did:<method-name>:<method-specific-id>.
• Субъект и контроллер — это разные роли. Субъект — это то, что идентифицирует DID; контроллер уполномочен методом изменять DID-документ.
• Ключи требуют явных целей. Метод проверки становится пригодным для аутентификации, утверждения, согласования ключей, вызова возможностей или делегирования только через соответствующее отношение проверки.
• Метод предоставляет операционные правила. DID Core технологически нейтрален; метод определяет взаимодействие с реестром, авторизацию, обновление, деактивацию и разрешение, специфичное для метода.
• Разрешение само по себе не создает доверия. Разработчики должны аутентифицировать результаты метода, обеспечивать цель доказательства, управлять ключами и историей, защищать конфиденциальность и применять политику приложения.

Что такое децентрализованный идентификатор?

Децентрализованный идентификатор — это идентификатор, разработанный таким образом, чтобы контроль мог быть установлен без необходимости в одном центральном поставщике идентификаторов или центре сертификации для выдачи и обслуживания каждого идентификатора. Слово «децентрализованный» описывает способность архитектуры отделять контроль идентификатора от одного центрального эмитента; оно не означает, что каждая реализация является анонимной, публичной, неизменяемой или хранится в распределенном реестре.

DID может идентифицировать:

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

Идентифицируемая сущность является субъектом DID. Сама строка не раскрывает тип субъекта.

Синтаксис DID

Общий синтаксис:

did:<method-name>:<method-specific-id>

Например:

did:example:123456789abcdefghi

did — это схема URI. example — это имя метода DID. Оставшаяся строка — это идентификатор, специфичный для метода. Спецификация метода определяет, что означает это значение и как программное обеспечение его обрабатывает.

DID, выглядящий действительным, не обязательно пригоден для использования. Метод должен существовать, и резолвер должен его поддерживать.

DID URL: пути, запросы и фрагменты

DID URL начинается с DID и может добавлять путь, запрос или фрагмент:

did:example:123456789abcdefghi/path?service=messages#key-1

Эти компоненты могут идентифицировать или помогать выбирать:

• метод проверки внутри DID-документа;
• запись сервиса;
• другой фрагмент DID-документа;
• ресурс, доступный через сервис;
• версию или опцию, определенную методом.

Фрагмент #key-1 обычно идентифицирует метод проверки. Это не означает, что закрытый ключ находится в документе. DID-документы публикуют публичные материалы для проверки или ссылки; секретные материалы должны оставаться защищенными в другом месте.

Архитектура DID

Основные концепции взаимосвязаны, но не взаимозаменяемы:

Концепция	Роль
DID	Глобально уникальный идентификатор, соответствующий синтаксису DID
Субъект DID	Идентифицируемый человек, организация, вещь, ресурс или концепция
Контроллер DID	Сущность, уполномоченная в соответствии с методом DID изменять DID-документ
DID-документ	Данные, связанные с субъектом, включая разрешенные методы проверки и сервисы
Метод DID	Отдельная спецификация для синтаксиса и операций, специфичных для метода
Реестр проверяемых данных	Инфраструктура, используемая методом для создания, чтения, обновления или деактивации состояния DID
Резолвер DID	Программное или аппаратное обеспечение, выполняющее разрешение DID для поддерживаемых методов
Дереференцировщик DID URL	Программное или аппаратное обеспечение, получающее ресурс, идентифицированный DID URL

Субъект против контроллера

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

На верхнем уровне controller идентифицирует один или несколько контроллеров DID. Требуемый controller метода проверки идентифицирует того, кто контролирует этот метод; он не является автоматически контроллером DID верхнего уровня. Их путаница может привести к непреднамеренному предоставлению полномочий.

Что такое DID-документ?

DID-документ — это данные, связанные с субъектом DID в соответствии с моделью данных DID Core. Его корневой id — это DID. Необязательные основные свойства могут описывать контроллеры, альтернативные идентификаторы, методы проверки, отношения проверки и сервисы.

Этот упрощенный пример использует публичные материалы из пространства примеров спецификации:

{
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://w3id.org/security/suites/jws-2020/v1"
  ],
  "id": "did:example:123",
  "verificationMethod": [
    {
      "id": "did:example:123#key-1",
      "type": "JsonWebKey2020",
      "controller": "did:example:123",
      "publicKeyJwk": {
        "kty": "OKP",
        "crv": "Ed25519",
        "x": "VCpo2LMLhn6iWku8MKvSLg2ZAoC-nlOyPVQaO3FxVeQ"
      }
    }
  ],
  "authentication": [
    "did:example:123#key-1"
  ],
  "assertionMethod": [
    "did:example:123#key-1"
  ]
}

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

Основные свойства

• id: DID для субъекта; обязателен в корне документа.
• controller: один или несколько DID, уполномоченных вносить изменения в соответствии с методом.
• alsoKnownAs: другие URI, которые, как утверждается, идентифицируют того же субъекта.
• verificationMethod: публичные механизмы проверки, на которые могут ссылаться явные отношения.
• authentication: методы, разрешенные для аутентификации в качестве субъекта.
• assertionMethod: методы, разрешенные для выражения утверждений, таких как выдача учетных данных.
• keyAgreement: методы, предназначенные для вывода общего секретного материала.
• capabilityInvocation: методы, разрешенные для вызова возможностей.
• capabilityDelegation: методы, разрешенные для делегирования возможностей.
• service: конечные точки или механизмы взаимодействия, связанные с субъектом.

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

Модель данных и представления

DID Core определяет абстрактную модель данных и правила для создания и использования представлений. Модель данных не идентична одной сериализации JSON.

Требования к представлению зависят от версии:

• Рекомендация DID Core 1.0 2022 года определяет application/did+json и application/did+ld+json. Ее представление JSON-LD начинается с базового контекста https://www.w3.org/ns/did/v1.
• Рекомендация-кандидат DID Core 1.1 объединяет основной тип носителя в application/did. Ее представление JSON-LD начинается с https://www.w3.org/ns/did/v1.1.

Не смешивайте тип носителя или базовый контекст одной версии с утверждениями о соответствии другой. Закрепите версию спецификации, которую реализуют производители и потребители.

Реализаторы должны явно согласовывать и проверять представление. Подписание произвольных сериализованных JSON-байтов без определенной канонизации и механизма защиты не эквивалентно правильной обработке модели данных DID.

Методы проверки и отношения проверки

Метод проверки описывает, как может быть проверено доказательство. Он требует:

• id, выраженный как DID URL;
• type;
• controller;
• материал проверки, соответствующий этому типу.

Публичный материал может быть представлен через определенное свойство, такое как publicKeyJwk, или другую форму, разрешенную набором методов проверки. JWK в DID-документе не должен содержать материал закрытого ключа. Один и тот же материал проверки не должен дублироваться в нескольких свойствах материала в рамках одного метода.

Определение метода проверки не авторизует его для каждой цели. Авторизация исходит из пяти явных отношений проверки.

Отношение	Предполагаемая цель доказательства
authentication	Аутентификация в качестве субъекта DID через запрос-ответ или другой принятый механизм
assertionMethod	Выражение утверждений, включая подписание проверяемых учетных данных, где выбранный механизм защиты использует его
keyAgreement	Установление общего криптографического материала, часто для шифрования
capabilityInvocation	Вызов возможности объекта
capabilityDelegation	Делегирование возможности объекта

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

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

Сервисы и конечные точки сервисов

Необязательное свойство service может рекламировать способы связи или взаимодействия с субъектом DID. Каждая запись сервиса имеет:

• уникальный id;
• type;
• serviceEndpoint.

Конечная точка может быть URI или другой разрешенной структурой. Определения сервисов расширяемы, поэтому приложения должны понимать выбранный тип.

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

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

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

Что определяет метод DID

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

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

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

Критерии выбора метода

Перед выбором метода проверьте:

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

Изменение методов обычно означает введение нового идентификатора и надежного пути миграции.

Разрешение DID против дереферирования DID URL

Разрешение DID принимает DID и параметры разрешения и возвращает:

1. метаданные разрешения DID;
2. DID-документ, поток документов или отсутствие документа;
3. метаданные DID-документа.

Резолвер использует операцию «чтения», определенную методом. DID Core определяет абстрактные интерфейсы и общие концепции результатов; специфическая для метода связь и аутентификация остаются за методом.

Дереферирование DID URL принимает полный DID URL и возвращает:

1. метаданные дереферирования;
2. идентифицированный ресурс, если доступен;
3. метаданные содержимого.

Дереферирование может сначала разрешить базовый DID, а затем выбрать фрагмент, сервис или внешний ресурс. Это не синоним разрешения.

Отдельная спецификация W3C DID Resolution разрабатывает подробные алгоритмы разрешения и дереферирования. Ее последняя публикация — Рабочий проект W3C от 24 июля 2026 года, а дереферирование DID URL помечено как функция в зоне риска. Она остается работой на стадии стандартизации, а не частью Рекомендации DID Core 1.0 2022 года, поэтому закрепите проект, прежде чем заявлять о соответствии.

Доверие резолвера и кэширование

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

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

DID и проверяемые учетные данные

DID и проверяемые учетные данные являются взаимодополняющими спецификациями, а не одним и тем же объектом.

Базовый DID может идентифицировать:

• эмитента учетных данных;
• субъекта учетных данных;
• держателя.

Метод проверки, используемый механизмом защиты, вместо этого идентифицируется DID URL, обычно DID с последующим фрагментом, таким как #key-1.

Модель данных проверяемых учетных данных W3C 2.0 определяет учетные данные, представления, эмитента, держателя, субъекта, действительность, статус, схемы и механизмы защиты. Она не требует, чтобы каждый идентификатор был DID.

Когда DID используется для эмитента, верификатор может разрешить DID эмитента, найти метод проверки доказательства и подтвердить, что метод авторизован в соответствии с assertionMethod. Эта криптографическая проверка все еще не устанавливает:

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

Эти проверки относятся к механизму защиты, системе статуса, структуре доверия, привязке представления и политике полагающейся стороны.

Соображения конфиденциальности и безопасности

Избегайте персональных данных в публичных документах

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

Предотвращение корреляции

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

Ротация и восстановление ключей

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

Проверка цели доказательства

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

Осторожная обработка истории

Текущий DID-документ может больше не содержать старого ключа. Проверка исторического доказательства может потребовать поддерживаемой методом исторической версии и надежных доказательств времени доказательства. «Ключ не присутствует сейчас» и «доказательство никогда не было действительным» не являются эквивалентными выводами.

Распространенные ошибки реализации DID

Называние DID Core спецификацией блокчейна

DID Core технологически нейтрален. Блокчейны — одна из возможных архитектур реестра.

Рассмотрение DID как доказательства юридической личности

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

Использование любого перечисленного ключа для любой цели

Обеспечьте соблюдение явного отношения проверки и цели доказательства.

Автоматическое доверие конечным точкам сервисов

Проверяйте состояние метода и применяйте безопасность на уровне приложения, транспорта, URL и содержимого.

Предположение, что все DID являются частными или анонимными

Активность реестра, разрешение, повторно используемые материалы и сервисы могут выявить стойкую корреляцию.

Контрольный список реализации DID

Перед производством убедитесь, что:

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

Где DID встречаются с проверкой личности

DID могут идентифицировать субъектов и материалы для проверки, но они не выполняют проверку личности. Многоразовая система идентификации по-прежнему нуждается в надежных доказательствах и управляемом решении, прежде чем выдавать или принимать утверждения. Проверка личности Didit (ID Verification) может предоставить доказательства личности для такого решения, в то время как Reusable KYC поддерживает повторное использование предыдущей проверки в участвующих сервисах и указывается как бесплатная.

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

Часто задаваемые вопросы

Что определяет спецификация W3C DID?

Она определяет синтаксис DID и DID URL, общую модель данных, основные свойства DID-документа, представления, требования к методам и абстрактные интерфейсы разрешения и дереферирования.

Каждый ли DID использует блокчейн?

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

В чем разница между DID и DID-документом?

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

В чем разница между разрешением и дереферированием?

Разрешение получает DID-документ и метаданные для DID. Дереферирование получает ресурс, идентифицированный полным DID URL, возможно, после разрешения его базового DID.

Является ли DID тем же, что и проверяемые учетные данные?

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

Доказывает ли контроль над DID, кто является человеком?

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

Может ли DID-документ содержать закрытые ключи?

Нет. DID-документы содержат публичный материал для проверки или ссылки. Материал закрытого ключа не должен появляться и должен оставаться защищенным системой управления ключами контроллера.

Основные ссылки

• W3C Decentralized Identifiers (DIDs) v1.0
• W3C Decentralized Identifiers (DIDs) v1.1
• W3C Decentralized Identifier Resolution
• W3C DID Specification Registries
• W3C Verifiable Credentials Data Model v2.0

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