Decentralized Identifiers (DID) и on‑chain аттестации: как строить децентрализованную идентичность для KYC‑lite и подтверждения прав
В этой статье вы узнаете:
— Что такое DID и verifiable credentials (VC) простыми словами, и как они применимы к KYC‑lite и он‑чейн‑аттестациям.
— Минимальные/максимальные требования к доказательствам (уровни аттестации), TTL и аудит логов.
— Какие кошельки/идентификаторы и верификаторы нужны (wallets, DID resolvers, issuer/verifier roles).
— Пошаговую схему: выпуск DID, выдача VC, on‑chain anchoring, верификация и отзыв аттестаций.
— Частые проблемы: приватность, регуляторные требования, управление ключами и утрата аттестатов.
— Контекст по РФ и праздники: взаимодействие с банками и органами, сроки проверки документов.
— FAQ и вывод.
Что такое DID и Verifiable Credentials простыми словами
Decentralized Identifiers (DID) — это стандарт уникальных идентификаторов, контролируемых субъектом (человеком/организацией) с помощью ключей, не привязанных к централизованной базе. Verifiable Credentials (VC) — это подписанные аттестации (например, подтверждение Email, адреса, KYC‑уровня), которые выданы доверенным издателем (issuer) и могут быть проверены верификатором (verifier). DID+VC позволяют пользователю хранить свои аттестации в своём кошельке и предъявлять их выборочно, сохраняя приватность.
Минимальные/максимальные требования к аттестациям и TTL
— Минимум. Для KYC‑lite — email/phone и базовая проверка личности (ID hash) с short‑TTL (1–6 месяцев) для бизнеса B2C. Банковского уровня — расширенный VC с проверкой документов и PEP/Sanctions с TTL 12 месяцев и периодической реверфикации.
— Максимум. Для регуляторных требований (включая AML) используются крупные объёмы данных, e‑KYC и офф‑чейн документы. Такие credentials держатся дольше, но требуют audit trail и secure storage. TTL и срок ревалидации — ключевой параметр. Задайте интервал пересмотра в зависимости от риска (ежеквартально для высокорискованных профилей).
Кошельки/инструменты и роли
Для участников нужны:
a) Wallet (self‑custodial) для хранения DID keys и VC.
b) Issuer (организация, выдающая VC — банк, нотариус) с возможностью подписи.
c) Verifier (сервис, принимающий VC и сверяющий подпись/отзыв).
d) DID resolver для получения DID‑документа.
e) revocation registry — реестр отзывов. Инструмент сайд‑чейн/anchoring: для публичного реестра хешей VC используйте L1/L2 anchoring для доказуемости.
Пошаговая реализация DID+VC
1) Создание DID. Пользователь генерирует DID (ключи) в кошельке; DID‑документ хранится в DID‑resolver (decentralized registry), pointer публикуется публично.
2) Выдача VC. Issuer проводит проверку (KYC), формирует VC и подписывает её своим ключом; VC отправляется пользователю и хранится в кошельке (off‑chain), а хеш VC якорится on‑chain для неизменности.
3) Предъявление. Пользователь предъявляет VC верификатору, который проверяет подпись issuer, проверяет revocation‑registry (отзыв) и сверяет хеш с ончейн‑якорем.
4) Отзыв/ревокация. Issuer вносит запись в реестр отзывов (on‑chain/по ссылке), верификаторы учитывают это при проверке.
5) Ревалидация. Для VC с TTL задайте автоматические напоминания и порядок обновления.
Частые проблемы и решения
— Приватность и linkability. Предъявление VC напрямую раскрывает данные; используйте selective disclosure (zero‑knowledge proofs / selective disclosure schemes), чтобы выдавать только нужные атрибуты.
— Утрата ключей. Пользователь теряет DID‑ключ — вы должны иметь процедуру восстановления через recovery‑contacts или social recovery (multi‑signature, деление ключа).
— Ревокация и ревалидация. Реестр отзывов должен быть публично доступен и быстро проверяем; используйте efficient revocation lists (sparse merkle trees) для масштабирования.
Контекст по РФ и праздники
Работа с банковскими требованиями и KYC в РФ предполагает временные окна для подтверждения документов. Не откладывайте ревалидацию на канун праздников — банки и нотариусы работают в ограниченном режиме. Для критичных верификаций (кредиты, ипотека) согласуйте SLA заранее.
FAQ
— Можно ли подделать VC? Нет, если issuer подписывает VC своим ключом и хеш якорится on‑chain. Верификатор сверяет подпись и ревокацию.
— Что важнее — DID или VC? DID — идентификатор. VC — аттестация прав/фактов. Оба вместе дают мощный инструмент.
— Как масштабировать реестры отзывов? Используйте merkle‑based revocation registries и off‑chain индексаторы для быстрых проверок.
Вывод
DID + Verifiable Credentials даёт гибкую и приватную модель идентификации: пользователь контролирует данные, эмитенты гарантируют подлинность, а верификаторы быстро доверяют. Для применения в KYC‑lite и верификации прав — настройте TTL, selective disclosure и процедурную ротацию ключей. Планируйте обновления до праздников и держите резерв на офлайн‑восстановление.
