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

Децентрализованная идентичность (DID) — это подход, при котором пользователь владеет своей цифровой личностью сам: идентификатор и верифицируемые удостоверения контролируются криптографическими ключами, а не хранятся под полным контролем одной платформы. Идея — дать человеку контроль над своими данными и переносимую идентичность. Примечание: эта позиция в каталоге дублирует услугу DID (1085); содержание идентично, см. 1085 как основную. Честно про незрелость, это главное: DID — передовая, но ещё незрелая область. Стандарты (DID-методы, verifiable credentials) развиваются и меняются, реализаций много и они несовместимы, реальная поддержка сервисами узкая — мало кто принимает DID для входа/верификации. Внедрять DID сейчас — работать с движущейся, нишевой технологией. Мы честно об этом предупреждаем. Честно про ответственность за ключи, это критично: контроль над идентичностью = контроль над ключами. Потеря ключа = потеря доступа к идентичности без «восстановить через поддержку». Для обычного пользователя это серьёзный барьер; нужны механизмы восстановления (social recovery) со своими компромиссами. Честно про «не для большинства»: для подавляющего большинства обычных приложений привычная аутентификация (email, OAuth, телефон) проще, зрелее, удобнее и достаточно безопасна. DID оправдан там, где реально нужна переносимая, независимая от платформы идентичность или верифицируемые удостоверения между организациями — нишевые сценарии. Тащить DID в обычный продукт — over-engineering. Честно про «не панацея приватности»: DID даёт больше контроля над раскрытием данных, но не делает систему приватной автоматически; публичные блокчейн-компоненты, наоборот, могут раскрывать информацию. Честно про дубль: раз эта услуга повторяет 1085, мы честно укажем это и не будем создавать путаницу — реализация одинакова. Честно про эффект: для реальных DID-сценариев даёт пользователю контроль над идентичностью и переносимость, но это незрелая нишевая технология с серьёзной ответственностью за ключи. Честно про доступ: нужны реальная потребность и готовность к незрелости. Важная граница: это DID (= 1085); обычная аутентификация — стандарт; Web3-логин — 1078; SSI (самоуправляемая идентичность) — 1139; soulbound — 1086. Базовая цена — от 90 000 ₽ (зависит от сценария).

• Нужна переносимая идентичность, не привязанная к одной платформе.
• Нужны верифицируемые удостоверения между организациями.
• Хочется DID для обычного продукта — но это незрелый over-engineering.
• Не учтено, что потеря ключа = потеря идентичности без восстановления.

• Внедрение DID под сценарий (идентификаторы, verifiable credentials) — см. 1085
• Честная оценка: нужна ли DID или обычная аутентификация достаточна
• Механизмы восстановления/social recovery (с компромиссами)
• Учёт незрелости стандартов и риска устаревания
• Честные границы (незрелая/нишевая; ответственность за ключи; потеря ключа невосстановима; не панацея приватности; не для большинства; дублирует 1085)
• Связка с Web3-логином (1078) и SSI (1139)
• Документация и передача
• Разбор с вами

• Самоуправляемая идентичность под реальный DID-сценарий
• Контроль пользователя над раскрытием данных (с оговорками)
• Честная оценка: для обычного продукта обычная аутентификация лучше
• Честные границы (незрелость; ответственность за ключи; не панацея приватности; ниша; = 1085)

• Оцениваем сценарий: нужна ли DID или хватит обычной аутентификации
• Внедряем DID/credentials с восстановлением, учитываем незрелость
• Честно ставим границы (ключи, зрелость, дубль 1085) и передаём вам

• DID нужна моему приложению вместо обычного входа?

  Для большинства — нет, честно: для обычных приложений привычная аутентификация (email, OAuth, телефон) проще, зрелее и достаточно безопасна. DID — незрелая, нишевая технология; в обычный продукт это over-engineering. Она оправдана лишь там, где реально нужна переносимая, независимая от платформы идентичность или верифицируемые удостоверения между организациями. Мы честно оценим, ваш ли это случай (и учтём, что это дубль услуги 1085).

• DID готова к продакшену и широко поддерживается?

  Честно: это передовая, но ещё незрелая область. Стандарты (DID-методы, verifiable credentials) меняются, реализации несовместимы, реальная поддержка сервисами узкая — мало кто принимает DID для входа/верификации. Есть риск устаревания выбранного стека. Мы честно предупреждаем о незрелости и нишевости, а не выдаём DID за готовый зрелый стандарт.

• Если пользователь потеряет ключ от DID?

  Это серьёзный риск, честно: контроль над идентичностью = контроль над ключами. Потеря ключа = потеря доступа к идентичности без «восстановить через поддержку». Для обычного пользователя это барьер. Можно добавить social recovery, но у него свои компромиссы. Мы честно закладываем эту ответственность за ключи, а не выдаём DID за беззаботную идентичность.