Децентрализованные идентификаторы DID: реальные кейсы для бизнеса

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

Эта рутина кажется неизбежной, пока не посмотреть на неё как на задачу управления идентичностью. Компаниям приходится снова и снова доказывать один и тот же факт разным сервисам: сотрудник имеет определённую должность, поставщик зарегистрирован, подрядчик обладает нужной лицензией, клиент уже прошёл проверку в доверенной организации. Децентрализованные идентификаторы, или DID (Decentralized Identifiers), предлагают перенести часть такой работы из ручных проверок в машиночитаемую инфраструктуру.

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

Архитектура DID: от стандарта W3C к практической реализации в IT-системах

Что такое DID простыми словами

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

Формат выглядит как URI-строка:

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

Например, did:ethr:0x1234... может использоваться в экосистеме Ethereum-совместимых сетей, а did:web:example.com связывает идентификатор с доменом компании. В строке DID нет поля «логин», «пароль» или «email». Вместо этого есть указание на метод — набор правил, который определяет, как идентификатор создаётся, где публикуется его описание и каким образом проверяются изменения.

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

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

Методы и где они «живут»

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

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

did:web привязывает DID к домену компании. Такой вариант легче объяснить корпоративному IT-отделу: организация управляет доменом и публикует документ идентификатора в знакомой веб-инфраструктуре. Но вместе с этим она сохраняет существенную роль в управлении идентификатором. Если домен или сервер недоступен, это влияет на разрешение DID.

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

did:ion построен вокруг сети Bitcoin и надстройки Sidetree. Он рассчитан на работу с публичными идентификаторами без записи каждой операции непосредственно в основной блокчейн, но корпоративной команде всё равно придётся оценить зрелость инструментов, поддержку экосистемы и совместимость с внутренними системами.

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

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

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

Именно здесь часто возникает слишком широкое обещание: будто любой VC автоматически имеет дату окончания и полный журнал всех предъявлений. Это неверно. В одном решении удостоверение может содержать период валидности и ссылку на механизм отзыва, в другом статус проверяется отдельным сервисом, а в третьем информация о предъявлении вообще не сохраняется централизованно. Если бизнесу нужен аудит, его проектируют отдельно: определяют, какие события фиксируются, кто имеет к ним доступ и как не превратить систему минимального раскрытия данных в новый журнал персональной активности.

Практическая интеграция поэтому включает несколько независимых компонентов:

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

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

Уроки ShapeShift: почему централизованный KYC становится барьером для роста

В 2018 году криптовалютная платформа ShapeShift перешла к классической процедуре KYC с проверкой документов через централизованного поставщика. По сообщениям компании, после этого пользовательская база сократилась примерно на 95%. Сам по себе этот эпизод не доказывает, что KYC всегда вреден или что децентрализованная идентичность автоматически решает проблему конверсии. Он показывает другое: обязательная проверка, построенная вокруг повторной загрузки документов и ручной модерации, может стать серьёзным барьером даже для пользователей, которые не представляют повышенного риска.

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

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

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

Проблема тяжёлого KYC не только в объёме запрашиваемых данных, но и в том, что один и тот же процесс приходится повторять в каждом сервисе.

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

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

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

Автоматизация корпоративного доступа: опыт Microsoft Entra и кейс cellcentric

Корпоративный IT-отдел ежедневно решает задачу управления полномочиями. Нужно выдать сотруднику доступ к нужным системам, не открыть лишнее, быстро изменить права при переводе и закрыть их после увольнения. Классическая схема использует каталоги пользователей, логины, пароли, аппаратные токены и многофакторную аутентификацию. Она остаётся рабочей, но требует постоянной синхронизации между HR, службой безопасности и администраторами приложений.

Microsoft интегрировал поддержку DID и VC в Microsoft Entra Verified ID. Это коммерческое решение, которое связывает проверяемые удостоверения с корпоративными процессами. Один из публично описанных кейсов связан с cellcentric — совместным предприятием, разрабатывающим топливные элементы. В таком сценарии цифровое удостоверение используется для подтверждения роли и управления доступом к системам с повышенными требованиями.

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

Что именно может автоматизироваться:

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

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

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

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

Приватность в цепочках поставок: как защитить данные при проверке контрагентов

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

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

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

Возможные сценарии выглядят так:

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

Однако селективное раскрытие не является синонимом полной анонимности. Даже если содержание удостоверения ограничено, метаданные могут раскрывать многое: время предъявления, связь между адресами, частоту операций и принадлежность к определённой цепочке. Если бизнес действительно хочет минимизировать наблюдаемость, ему нужно проектировать не только формат VC, но и каналы обмена, хранение журналов, правила корреляции и доступ операторов.

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

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

Регуляторный комплаенс и DID: архитектурный сдвиг без отказа от AML

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

DID не освобождает бизнес от требований AML/KYC. Регулятор по-прежнему может потребовать установить личность клиента, проверить его по санкционным и иным ограничительным спискам, оценить риск операции и сохранить подтверждение проведённых процедур. Меняется не обязанность, а архитектура исполнения.

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

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

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

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

Для бизнеса архитектурный сдвиг может дать несколько эффектов:

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

2. Удешевление повторных проверок. Ранее подтверждённые атрибуты можно проверять машиночитаемым способом, не начиная весь процесс с нуля.

3. Разделение ответственности. Эмитент отвечает за качество первоначальной аттестации, проверяющий сервис — за применение удостоверения в своей процедуре, а владелец инфраструктуры — за ключи и доступность механизмов статуса.

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

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

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

Для IT-архитектора разумнее начинать с ограниченного процесса. Сначала DID может использоваться для внутренних удостоверений и доступа к корпоративным системам. Затем — для взаимодействия с поставщиками и партнёрами, где круг эмитентов заранее известен. Только после этого имеет смысл переходить к массовому клиентскому онбордингу, если есть понятная модель доверия, поддерживаемые кошельки и юридически приемлемый механизм проверки статуса.

Итог: что бизнес получает сегодня и где границы

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

Для бизнеса ценность технологии проявляется в нескольких сценариях:

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

Но эти преимущества появляются только при аккуратной архитектуре. Нет единого DID-метода, который одинаково хорошо подходит для публичного сервиса, корпоративного домена, закрытой сети и регулируемой финансовой операции. did:web, did:key, did:ethr, did:ion и другие методы различаются по зависимости от инфраструктуры, управлению ключами, способам обновления и модели доверия.

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

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

Поэтому децентрализованные идентификаторы DID для бизнеса стоит рассматривать не как замену всем существующим системам, а как дополнительный слой поверх IAM, CRM, HRM и комплаенс-процессов. Он может убрать повторную ручную работу и сократить объём избыточно передаваемых данных, но только если компания заранее определит, кому доверяет, какие атрибуты действительно нужны, как проверяется их актуальность и кто отвечает за ошибку.

В этом и заключается зрелый взгляд на технологии self-sovereign identity для компаний. Пользователь получает больше контроля над предъявлением своих данных, бизнес — более управляемый обмен подтверждениями, а регулятор — не обязательно меньше информации, а более чётко определённый процесс её получения. DID не отменяет доверие. Он заставляет разложить его на отдельные элементы: идентификатор, ключ, удостоверение, эмитента, статус и правила проверки. Для корпоративной инфраструктуры это уже достаточно серьёзный сдвиг.