Идентичность: кошелёк, DID, удостоверения и имена

Адрес кошелька выглядит как удостоверение личности, но это не оно. Он не говорит, человек ты или скрипт, один ты или сто, есть ли тебе восемнадцать и не выдал ли ты себя за кого-то другого. Этот урок про то, из чего в этой среде собирают идентичность, и почему большинство задач вида «докажи, что тебе можно» решаются иначе, чем кажется.

Три разных вопроса, которые путают

Слово «идентичность» склеивает три задачи, и разбирать их надо по отдельности.

Идентификатор. Как тебя устойчиво называть. Адрес, DID, имя. Требование к нему одно: он должен принадлежать тебе и не подделываться.

Утверждения. Что про тебя правда: возраст, гражданство, диплом, право подписи от организации. Сам ты этого о себе доказать не можешь, нужен тот, кто ручается.

Репутация. Что ты делал раньше. Она накапливается по действиям и, в отличие от утверждений, никем не выдаётся.

Кошелёк закрывает только первую задачу. Причём хорошо: подпись доказывает контроль над ключом, и подделать её нельзя. Всё остальное надстраивается сверху.

Вход по кошельку: что он даёт и чего нет

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

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

Три детали, без которых схема ломается, и все три ты уже видел в уроке про безопасность: случайная строка от сервера (иначе подпись переиспользуют), срок годности (иначе она вечна) и привязка к домену (иначе подпись, собранную на чужом сайте, предъявят у тебя).

И отдельная тонкость: если пользователь заходит смарт-контрактным кошельком, обычной проверки подписи недостаточно, у контракта нет приватного ключа. Для таких случаев есть стандартный способ спросить сам контракт, считает ли он подпись действительной.

DID: идентификатор, который не принадлежит платформе

Адрес кошелька привязан к конкретной цепи и к конкретной схеме подписи. Хочется чего-то более общего, и такой стандарт есть.

DID устроен просто: строка did:метод:значение разрешается в документ, где перечислены ключи субъекта и то, для чего каждый ключ годится.

Метод отвечает на вопрос, где искать документ:

• did:key. Документ выводится прямо из ключа, никакой сети не нужно. Идентификатор нельзя обновить, но и инфраструктуры не требуется.
• did:web. Документ лежит файлом на домене. Просто, понятно, и доверие ровно такое же, как к домену.
• методы поверх цепи. Документ хранится или выводится из состояния блокчейна, что даёт обновляемость ключей без централизованного реестра.

Заметь, чего DID не делает: он не говорит, кто ты. Он лишь даёт устойчивое имя и способ проверить твою подпись. Смысл появляется, когда к идентификатору привязывают утверждения.

Верифицируемые удостоверения: треугольник ролей

Модель, вокруг которой сошлись стандарты, состоит из трёх ролей.

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

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

Дальше начинается самое интересное для нас. Удостоверение о дате рождения содержит дату, а бару нужен только факт совершеннолетия. Показывать дату избыточно. Отсюда выборочное раскрытие: подпись устроена так, что можно предъявить часть полей, не раскрывая остальные. А в предельном варианте не раскрывается ничего: предъявляется доказательство утверждения «в моём подписанном государством удостоверении дата рождения такова, что мне больше восемнадцати». Проверяющий видит доказательство и подпись издателя, но не видит ни даты, ни имени.

Вот где нулевое разглашение работает по прямому назначению, в отличие от rollup-ов, где нужна была только краткость.

Отзыв: самая недооценённая часть

Удостоверение иногда надо отозвать: диплом аннулирован, сотрудник уволен, права изъяты. И вот тут схема начинает бороться сама с собой.

Наивное решение это список отозванных на сервере издателя. Но тогда проверяющий обращается к издателю при каждой проверке, и вся приватность, ради которой всё затевалось, теряется.

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

Если в схеме отзыва не разобрался, считай, что схемы идентичности у тебя нет: именно на отзыве ломаются красивые прототипы.