От паролей к портативным доказательствам: Руководство по Web3-идент ификации для разработчиков в 2025 году
Большинство приложений по-прежнему привязывают идентификацию к именам пользователей, паролям и централизованным базам данных. Эта модель хрупка (утечки), негерметична (перепродажа данных) и неуклюжа (бесконечные повторения KYC). Новая архитектура, формирующаяся вокруг децентрализованных идентификаторов (DIDs), проверяемых учетных данных (VCs) и аттестаций, указывает на другое будущее: пользователи несут криптографические доказательства фактов о себе и раскрывают только то, что необходимо — ни больше, ни меньше.
Этот пост описывает текущую ситуацию и предлагает практический план, который вы можете реализовать уже сегодня.
Сдвиг: От аккаунтов к учетным данным
Ядро этой новой архитектуры идентификации построено на двух основополагающих стандартах W3C, которые кардинально меняют подход к обработке пользовательских данных.
- Децентрализованные идентификаторы (DIDs): Это контролируемые пользователем идентификаторы, которые не требуют центрального реестра, такого как система доменных имен. Думайте о DID как о постоянном, самостоятельном адресе для идентификации. DID разрешается в подписанный «DID-документ», содержащий публичные ключи и конечные точки сервисов, что позволяет осуществлять безопасную, децентрализованную аутентификацию. Стандарт
v1.0стал официальной рекомендацией W3C 19 июля 2022 года, что ознаменовало важную веху для экосистемы. - Проверяемые учетные данные (VCs): Это защищенный от подделки цифровой формат для выражения утверждений, таких как «возраст старше 18 лет», «имеет диплом Университета X» или «прошел проверку KYC». Модель данных VC 2.0 стала рекомендацией W3C 15 мая 2025 года, заложив современную основу для того, как эти учетные данные выдаются и проверяются.
Что меняется для разработчиков? Сдвиг глубок. Вместо хранения конфиденциальной персонально идентифицируемой информации (PII) в вашей базе данных, вы проверяете криптографические доказательства, предоставленные кошельком пользователя. Вы можете запросить только ту конкретную информацию, которая вам нужна (например, проживание в определенной стране), не видя базового документа, благодаря мощным примитивам, таким как выборочное раскрытие.
Где это встречается с уже используемыми вами логинами
Этот новый мир не требует отказа от привычных способов входа. Напротив, он их дополняет.
- Ключи доступа (Passkeys) / WebAuthn: Это ваш выбор для аутентификации, устойчивой к фишингу. Ключи доступа — это учетные данные FIDO, привязанные к устройству или биометрическим данным (например, Face ID или отпечатку пальца), и они теперь широко поддерживаются во всех основных браузерах и операционных системах. Они предлагают бесшовный, безпарольный вход в ваше приложение или кошелек.
- Вход с помощью Ethereum (SIWE / EIP-4361): Этот стандарт позволяет пользователю доказать контроль над блокчейн-адресом и связать его с сеансом приложения. Он работает через простое, подписанное сообщение на основе nonce, создавая чистый мост между традиционными сеансами Web2 и управлением Web3.
Лучшая практика — использовать их вместе: внедрить ключи доступа для основного, повседневного входа и предложить SIWE для потоков, связанных с кошельком, где пользователю необходимо авторизовать крипто-нативное действие.
Основы для выдачи и проверки учетных данных
Чтобы учетные данные были полезными, нам нужны стандартизированные способы их выдачи пользователям и их представления пользователями приложениям. OpenID Foundation предоставляет для этого два ключевых протокола.
- Выдача: OpenID для выдачи проверяемых учетных данных (OID4VCI) определяет API, защищенный OAuth, для получения учетных данных от эмитентов (таких как государственное учреждение или поставщик KYC) в цифровой кошелек пользователя. Он разработан как гибкий, поддерживающий несколько форматов учетных данных.
- Представление: OpenID для проверяемых представлений (OID4VP) стандартизирует, как ваше приложение делает «запрос доказательства» и как кошелек пользователя на него отвечает. Это может происходить через классические перенаправления OAuth или через современные API браузера.
При разработке вы столкнетесь с несколькими ключевыми форматами учетных данных, разработанными для различных экосистем и вариантов использования:
- W3C VC с наборами целостности данных (JSON-LD): Часто сочетается с криптографией BBS+ для обеспечения мощного выборочного раскрытия.
- VC-JOSE-COSE и SD-JWT VC (IETF): Эти форматы созданы для экосистем на основе JWT и CBOR, также обладая мощными возможностями выборочного раскрытия.
К счастью, совместимость быстро улучшается. Профили, такие как OpenID4VC High Assurance, помогают сузить технические варианты, делая интеграции между различными поставщиками гораздо более разумными для разработчиков.
Методы DID: Выбор правильной схемы адресации
DID — это просто идентификатор; «метод DID» определяет, как он привязан к корню доверия. Вам захочется поддерживать несколько распространенных методов.
- did:web: Этот метод поддерживает DID с доменом, который вы контролируете. Он невероятно прост в развертывании и явл яется отличным выбором для предприятий, эмитентов и организаций, которые хотят использовать свою существующую веб-инфраструктуру в качестве якоря доверия.
- did:pkh: Этот метод выводит DID непосредственно из блокчейн-адреса (например, адреса Ethereum). Это очень полезно, когда ваша пользовательская база уже имеет криптокошельки, и вы хотите связать их личность с ончейн-активами.
Практическое правило: Поддерживайте как минимум два метода — did:web для организаций и did:pkh для индивидуальных пользователей. Используйте стандартную библиотеку DID-резолвера для обработки поиска и консультируйтесь с официальными реестрами для оценки безопасности, постоянства и управления любым новым методом, который вы рассматриваете для добавления.
Полезные строительные блоки, которые вы можете подключить
Помимо основных стандартов, несколько инструментов могут улучшить вашу архитектуру идентификации.
- ENS (Ethereum Name Service): Предоставляет удобочитаемые имена (
yourname.eth), которые могут быть сопоставлены с блокчейн-адресами и DIDs. Это бесценный инструмент для улучшения пользовательского опыта, уменьшения ошибок и предоставления простого слоя профиля. - Аттестации: Это гибкие, проверяемые «факты о чем угодно», которые могут быть записаны ончейн или офчейн. Ethereum Attestation Service (EAS), например, предоставляет надежную основу для построения репутации и графов доверия без хранения PII в публичном реестре.
Регуляторные факторы, за которыми следует следить
Регулирование часто рассматривается как препятствие, но в этой области оно являетс я мощным ускорителем. Рамочная программа цифровой идентификации ЕС (eIDAS 2.0), официально принятая в качестве Регламента EU 2024/1183 20 мая 2024 года, является наиболее значимым событием. Она обязывает все государства-члены ЕС предлагать гражданам бесплатный Цифровой кошелек ЕС (EUDI). С публикацией имплементационных регламентов 7 мая 2025 года это является мощным сигналом для внедрения учетных данных на основе кошельков как в государственных, так и в частных службах Европы.
Даже если вы не работаете в ЕС, ожидайте, что кошелек EUDI и его базовые протоколы будут формировать ожидания пользователей и стимулировать внедрение кошельков по всему миру.
Рабочие паттерны проектирования в продакшене (2025)
- Сначала без пароля, кошельки опционально: По умолчанию использу йте ключи доступа для входа. Это безопасно, просто и привычно. Вводите SIWE только тогда, когда пользователям необходимо выполнить крипто-связанное действие, такое как минтинг NFT или получение выплаты.
- Запрашивайте доказательства, а не документы: Замените неуклюжую загрузку документов четким запросом доказательства VC с использованием OID4VP. Вместо запроса водительских прав, запросите доказательство «возраста старше 18 лет» или «страны проживания X». Принимайте учетные данные, поддерживающие выборочное раскрытие, такие как использующие BBS+ или SD-JWT.
- Не храните PII на своих серверах: Когда пользователь что-то доказывает, записывайте аттестацию или кратковременный результат проверки, а не сами исходные учетные данные. Ончейн-аттестации — это мощный способ создания аудируемой записи — «Пользователь Y прошел KYC у Эмитента Z в дату D» — без хранения каких-либо персональных данных.
- Позвольте организациям быть эмитентами с did:web: Предприятия, университеты и другие организации уже контролируют свои домены. По звольте им подписывать учетные данные в качестве эмитентов, используя
did:web, что позволит им управлять своими криптографическими ключами в рамках их существующих моделей веб-управления. - Используйте ENS для имен, а не для идентификации: Рассматривайте ENS как удобный для пользователя дескриптор и указатель профиля. Это отлично подходит для UX, но сохраняйте авторитетные заявления об идентичности в учетных данных и аттестациях.
Стартовая архитектура
Вот план современной системы идентификации на основе учетных данных:
- Аутентификация
- Вход по умолчанию: Ключи доступа (FIDO/WebAuthn).
- Крипто-связанные сеансы: Вход с помощью Ethereum (SIWE) для действий, связанных с кошельком.
- Учетные данные
- Выдача: Интегрируйтесь с конечными точками OID4VCI от выбранных вами эмитентов (например, поставщика KYC, университета).
- Представление: Запускайте запросы доказательств OID4VP из вашего веб- или нативного приложения. Будьте готовы принимать как W3C VCs (с BBS+), так и SD-JWT VCs.
- Разрешение и доверие
- DID-резолвер: Используйте библиотеку, которая поддерживает как минимум
did:webиdid:pkh. Поддерживайте список разрешенных доверенных DID эмитентов для предотвращения спуфинга.
- DID-резолвер: Используйте библиотеку, которая поддерживает как минимум
- Аттестации и репутация
- Надежные записи: Когда вам нужен аудируемый сигнал о проверке, создайте аттестацию, содержащую хеш, DID эмитента и метку времени, вместо хранения самого утверждения.
- Хранение и конфиденциальность
- Минимализм: Резко минимизируйте PII, которую вы храните на сервере. Шифруйте все данные в состоянии покоя и устанавливайте строгие политики времени жизни (TTL). Отдавайте предпочтение эфемерным доказательствам и активно используйте доказательства с нулевым разглашением или выборочное раскрытие.
Уроки UX
- Начинайте незаметно: Для большинства пользователей лучший кошелек — это тот, о котором им не нужно думать. Используйте ключи доступа для бесшовного входа и отображайте взаимодействия с кошельком только контекстуально, когда они абсолютно необходимы.
- Прогрессивное раскрытие: Не запрашивайте все сразу. Запрашивайте наименьшее возможное доказательство, которое разблокирует непосредственную цель пользователя. При выборочном раскрытии вам не нужен полный документ пользователя для проверки одного факта.
- Восстановление ключей имеет значение: Учетные данные, привязанные к одному ключу устройства, являются уязвимостью. Планируйте перевыпуск и переносимость между устройствами с первого дня. Это одна из ключевых причин, по которой современные профили принимают такие форматы, как SD-JWT VC и привязка держателя на основе утверждений.
- Удобочитаемые дескрипторы помогают: Имя ENS гораздо менее пугающе, чем длинный шестнадцатеричный адрес. Оно уменьшает ошибки пользователя и добавляет слой узнаваемого контекста, даже если истинный авторитет находится в базовых учетных данных.
Что выпустить в следующем квартале: Прагматичная дорожная карта
- Недели 1–2:
- Добавьте ключи доступа для вашего основного потока входа.
- Защитите все крипто-нативные действия проверкой SIWE.
- Недели 3–6:
- Проведите пилотный проект по простой проверке возраста или региона с использованием запроса OID4VP.
- Принимайте учетные данные VC 2.0 с выборочным раскрытием (BBS+ или SD-JWT VC).
- Начните создавать аттестации для событий «проверка пройдена» вместо логирования PII.
- Недели 7–10:
- Подключите партнера-эмитента (например, вашего поставщика KYC), используя
did:web, и реализуйте список разрешенных DID. - Предложите связывание имени ENS в профилях пользователей для улучшения UX адресов.
- Подключите партнера-эмитента (например, вашего поставщика KYC), используя
- Недели 11–12:
- Разработайте модель угроз для ваших потоков представления и отзыва. Добавьте телеметрию для распространенных режимов отказа (истекшие учетные данные, недоверенный эмитент).
- Опубликуйте четкую политику конфиденциальности, объясняющую, что именно вы запрашиваете, почему, как долго вы это храните и как пользователи могут это проверить.
Что быстро меняется (следите за этим)
- Развертывание кошельков EUDI в ЕС: Внедрение и тестирование на соответствие этих кошельков значительно повлияют на возможности и UX верификации по всему миру.
- Профили OpenID4VC: Совместимость между эмитентами, кошельками и верификаторами постоянно улучшается благодаря новым профилям и наборам тестов.
- Криптографические наборы для выборочного раскрытия: Библиотеки и руководства для разработчиков как для BBS+, так и для SD-JWT VC быстро развиваются, что упрощает их реализацию.
Принципы, которыми следует руководствоваться при разработке
- Доказывайте, не храните: По умолчанию проверяйте утверждения, а не храните необработанные PII.
- Совместимость по умолчанию: Поддерживайте несколько форматов учетных данных и методов DID с первого дня, чтобы обеспечить перспективность вашей архитектуры.
- Минимизируйте и раскрывайте: Запрашивайте наименьшее возможное утверждение. Будьте прозрачны с пользователями относительно того, что вы проверяете и почему.
- Сделайте восстановление скучным: Планируйте потерю устройст ва и смену эмитента. Избегайте хрупкой привязки ключей, которая оставляет пользователей в затруднительном положении.
Если вы создаете финтех-, социальные или платформы для авторов, идентификация на основе учетных данных — это уже не ставка на будущее, а кратчайший путь к снижению рисков, более плавному онбордингу и глобальной совместимости.