Show HN: подписанное утверждение не должно быть bearer-токеном

Подписанное JSON-удостоверение часто оказывается просто более красивой версией скана документа. Если я могу скопировать его с вашего телефона, из письма или из логов, почему я не могу предъявить его от вашего имени? С этой задачи начинается Persona Claims. Источник подписывает один факт, бумажник его хранит, а сервис проверяет и высказывание источника, и владение связанным с ним ключом.

Подпись — только половина доказательства

Источник подписывает canonical JSON алгоритмом Ed25519. В полезной нагрузке есть факт, срок, уникальный идентификатор и открытый ключ Ed25519 держателя. Подпись делает высказывание источника переносимым и локально проверяемым. Но она не доказывает, что предъявляющий JSON контролирует закрытый ключ, поэтому одной подписи недостаточно: утверждение превратилось бы в bearer-артефакт.

// issuer-signed envelope
{ iss, kid, dat, sig, crl? }

// canonical payload inside dat
{ sub, typ, dat, uid, iat, exp }

Свежий challenge создаёт сервис

Для каждого предъявления сервис создаёт nonce. Бумажник подписывает его закрытым ключом, соответствующим sub. Сервис принимает утверждение только после проверки этого подтверждения и подписи источника. Скопированный JSON не ответит на новый challenge. Мы используем одно подтверждение на каждый различный ключ держателя, а не на каждое утверждение: бумажник может предъявить несколько связанных фактов без лишних подписей.

Компромиссы — часть конструкции

Ключи источников находятся через DNS, при необходимости с проверкой DNSSEC, а не в глобальном реестре. Сервис также может привязать утверждение к собственному ключу и запретить повторное использование где-либо ещё. У обоих решений есть цена: у DNS бывают проблемы доступности и ротации; многократно используемые утверждения показывают один ключ держателя разным сервисам и могут быть сопоставлены. Persona Claims — не anonymous credentials. Протокол делает этот выбор явным, а продукт выбирает подходящий вариант.