Web3 Identity: как децентрализованные идентификаторы меняют архитектуру безопасности

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

Поверхность атаки централизованной модели

yellow.com верно фиксирует ключевую проблему: централизованное хранилище атрибутов — это fat target. Одна утечка компрометирует пул учётных записей целиком, а пользователь теряет контроль над персональными данными в момент их передачи провайдеру. Дополнительный оверхед — зоопарк паролей и credential reuse, классический preimage для брутфорса и credential stuffing.

Криптографически задача сводится к двум вопросам: как доказать владение атрибутом без раскрытия его значения и как верифицировать аттестацию без слепого доверия к единственному эмитенту. yellow.com упоминает SSI как ответ, но обходит молчанием конкретные примитивы для selective disclosure и оверхед ончейн-верификации. Для аудитора это критический пробел: без схем с открытой верификацией — range proofs, Merkle inclusion, zk-аттестаций — разговор остаётся на уровне маркетинга.

Архитектурный сдвиг и его скрытая цена

Self-Sovereign Identity переносит trust anchor с сервера на пользовательский кошелёк. Приватные ключи остаются у субъекта, в публичный реестр уходят только DID и verifiable credentials, подписанные эмитентами. Верификатор проверяет подпись и актуальный статус аттестации — ровно так, как описано в материале.

Однако аналогия с моделью доверия Bitcoin, которую проводит yellow.com, хромает. В Bitcoin потеря seed означает потерю монет, но монеты гомогенны. Потеря ключа идентичности обрушивает всю социальную и финансовую репутацию субъекта без процедуры восстановления. Это не периферийный нюанс — это фундаментальный риск, который обзорный материал полностью игнорирует. Есть и слепая зона по revocation: либо список ведёт эмитент (и мы возвращаемся к исходной проблеме доверия), либо он пишется ончейн с соответствующим оверхедом на хранение и обновление. Без решения этого вопроса «user control» остаётся декларацией.

Что требовать на code review

Прежде чем доверять платформе, называющей себя identity layer, стоит запросить три вещи. Первое — где хранятся приватные ключи: custodial кошелёк означает, что никакой децентрализации нет, а провайдер остаётся single point of failure. Второе — конкретная криптосхема верификации аттестаций и ончейн-след: размер доказательства, стоимость газа, поддерживаемые примитивы. Третье — механизм key rotation и recovery: без social recovery или мультиподписной схемы пользователь обречён на полную потерю идентичности при компрометации одного устройства.

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