Перейти к содержанию
Financial Context Wiki

Децентрализованная идентичность (DID)

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

Обновлено

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

Краткий ответ

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

DID — URI вида did:example:123. Метод DID определяет создание, разрешение, обновление и деактивацию. Разрешение может вернуть документ DID с методами проверки, отношениями authentication или assertionMethod и необязательными сервисными точками. Контроль соответствующего ключа доказывает контроль DID по этому методу, но сам по себе не доказывает юридическое имя, возраст, уникальность, трудоустройство или владение внешней учётной записью.

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

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

Как это работает

  1. Определить утверждение и рамки доверия. Указать субъект, запрошенные атрибуты, допустимых эмитентов, процесс проверки, уровень доверия, хранение, юрисдикцию и обжалование. Криптографический формат не решает, является ли университет, государство, работодатель или сообщество подходящим органом.
  2. Создать или получить идентификаторы и ключи. Эмитент и держатель могут использовать DID, HTTPS URL и другие поддерживаемые идентификаторы. Для DID метод задаёт реестр и жизненный цикл. Контролёр защищает закрытый ключ; разрешённый документ раскрывает лишь нужные проверочные данные и точки.
  3. Проверить и связать субъект. Эмитент проверяет доказательства по политике и связывает утверждения с субъектом удостоверения. Связь может ссылаться на ключ держателя, учётную запись или другой идентификатор. Доказательство о человеке нужно отличать от доказательства контроля ключа текущим предъявителем.
  4. Выпустить удостоверение. Эмитент создаёт утверждения, сроки, схему или тип и ссылку на статус, затем защищает удостоверение поддерживаемым доказательством. В Data Integrity поля cryptosuite, verificationMethod, proofPurpose и proofValue задают способ проверки.
  5. Хранить и выбирать. Держатель сохраняет удостоверение в локальном или размещённом кошельке. Кошелёк должен объяснять запрос, раскрывать только необходимые данные, если формат позволяет, и не переиспользовать стабильный идентификатор в несвязанных контекстах незаметно.
  6. Предъявлять с актуальностью и привязкой к получателю. Проверяющая сторона отправляет идентичность, цель, nonce или challenge и срок. Держатель возвращает связанное с запросом удостоверение или производное предъявление. Проверки домена и challenge предотвращают повтор для другой стороны или сеанса.
  7. Проверить криптографию и политику. Получить проверочные данные эмитента из аутентифицированного источника; проверить набор, цель, challenge, домен, даты, схему и статус; затем применить бизнес-правила. verified: true — вход для авторизации, а не команда открыть доступ.
  8. Управлять жизненным циклом. Менять скомпрометированные ключи, приостанавливать или отзывать удостоверения, обновлять статус, обеспечивать восстановление и обжалование, хранить аудит и публиковать планы миграции или закрытия. Историческая проверка требует правил для старых ключей, документов и времени предъявления.

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

DID и VC независимы. VC может использовать идентификатор эмитента не-DID, а DID — работать без VC. Метод DID может применять блокчейн, распределённую базу, веб-домен или одноранговый обмен. Его безопасность и управление оценивают напрямую, а не выводят из префикса did:.

Практический пример

Сервису нужно подтвердить, что клиенту не менее 18 лет, не собирая дату рождения. Признанный орган проверяет клиента и выпускает возрастное удостоверение в кошелёк. Оно может содержать дату рождения или только утверждение ageOver18; варианты различаются по раскрытию и повторному использованию.

При регистрации сервис запрашивает для merchant.example предъявление возраста старше 18, challenge n-7f3a и окно 5 минут. Кошелёк показывает запрос и, если удостоверение и набор доказательств позволяют, создаёт предъявление только нужного предиката. Сервис проверяет метод, доказательство, challenge, домен, время и статус, затем сохраняет минимальный результат для аудита.

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

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

Риски и меры контроля

  • Ложные или чрезмерные утверждения: Действительная подпись сохраняет слова эмитента, но не делает их верными. Определите доказательства, ответственность, доверие, аудит, срок и исправление.
  • Слабая связь с держателем: Копию может использовать другой человек, если предъявление не доказывает контроль нужного ключа. При необходимости привязывайте владение к проверяющей стороне, challenge, цели и сеансу.
  • Компрометация ключа и кошелька: Вредоносное ПО, фишинг, захват облачного кошелька или слабая копия раскрывают удостоверения и ключи. Нужны устойчивое к фишингу подтверждение, аппаратная защита, сообщение и ограниченное восстановление.
  • Централизация восстановления: Один администратор может стать фактическим контролёром идентичности. Документируйте право замены ключей, доказательства, обнаружение злоупотреблений, обжалование и миграцию.
  • Корреляция: Повтор DID, метода, подписи, точки или пути статуса связывает действия между сервисами. Используйте парные идентификаторы, разделённые по доменам ключи или доказательства, приватный статус и тесты метаданных.
  • Публичные персональные данные: Документы DID и история реестра могут индексироваться и плохо удаляться. Не помещайте имена, номера, биометрию и личные утверждения в публичные документы и неизменяемые реестры.
  • Приватность и доступность статуса: Каждый запрос эмитенту раскрывает место использования; сбой блокирует законных пользователей. Предпочтительны приватный кэшируемый статус, предел свежести, аутентифицированные обновления и заданное поведение при сбое.
  • Злоупотребление отзывом: Эмитент или администратор может цензурировать держателей приостановкой или сменой статуса. Ограничьте полномочия, журналируйте, показывайте причину и обжалование, поддерживайте замену или других эмитентов.
  • Риск разрешения и метода: Резолвер может вернуть устаревший или вредоносный документ, метод — зависеть от центра. Аутентифицируйте результаты и оценивайте финальность, право обновления, доступность, управление и версии.
  • Семантическое расхождение: Одни поля могут по-разному трактовать утверждение, единицу, юрисдикцию или доверие. Используйте стабильные схемы и словари, проверяйте контекст и тип, версионируйте политику.
  • Повтор и путаница проверяющей стороны: Предъявление без привязки к nonce, получателю, домену, действию и сроку можно повторить или перенаправить. Проверяйте все связи протокола.
  • Избыточное раскрытие: Даже при выборочном раскрытии могут потребовать всё удостоверение. Применяйте минимизацию в политике и интерфейсе, фиксируйте цель и не превращайте необязательные поля в обязательные.
  • Привязка к экосистеме: Закрытые кошельки, доказательства, реестры и восстановление мешают переносимости. До запуска тестируйте соответствие, экспорт, несколько кошельков, криптографическую гибкость и миграцию.
  • Захват управления: Мультиподпись или реестр не гарантируют широкого контроля, если один поставщик выбирает эмитентов, обновления, схемы и статус. Отобразите полномочия по компонентам и опубликуйте контроль изменений.

Распространённые заблуждения

  • «DID доказывает, кто этот человек». DID идентифицирует субъект и может раскрыть методы; атрибутам нужны дополнительные утверждения, доказательства и решения о доверии.
  • «Действительное удостоверение делает утверждение истинным». Проверка показывает ожидаемое доказательство и неизменность данных, но не подтверждает исходное расследование эмитента.
  • «Держатель всегда является субъектом». Роли могут различаться; при необходимости нужна явная связь субъекта с предъявителем.
  • «Всё должно быть в блокчейне». Публичное неизменяемое хранение усиливает риски приватности, корреляции, удаления и управления. Многие держат удостоверения вне сети.
  • «Выборочное раскрытие гарантирует анонимность». Атрибуты, стабильные идентификаторы, отпечатки, запросы, время, IP и журналы всё ещё связывают предъявления.
  • «Децентрализация означает отсутствие доверенных эмитентов и администраторов». Доверие распределяется и становится явным, но не исчезает. Выпуск, проверка, кошельки, восстановление, статус и принятие управляются.
  • «Один DID равен одному человеку». Человек контролирует много DID; DID может обозначать организацию, устройство, данные, роль и иной субъект. Уникальность и человечность требуют отдельных механизмов.
  • «Подписи кошелька достаточно для аутентификации». Она доказывает контроль ключа при заданных условиях. Нужны также защита от фишинга, свежесть, получатель, авторизация и восстановление.

Связанные темы

Источники

Навигация

Поиск по вики...