Кратко

  • RFC 9901 позволяет Holder предъявить ноль, часть или все выданные Disclosures; Verifier сопоставляет каждое предъявленное значение с digest в подписанном Issuer JWT.
  • Такое сопоставление подтверждает происхождение предъявленного значения в подписанной структуре, но не полноту набора, не текущую истину и не решение о допуске.

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

SD-JWT из RFC 9901 устроен иначе. Issuer подписывает JWT. Для selectively disclosable claim он может включить digest, а не открытый текст. Disclosure содержит случайную соль, имя claim, когда оно нужно, и значение. Holder получает материалы при выдаче и затем сам выбирает, какие Disclosures отдать каждому Verifier. Тот пересчитывает digest и проверяет, что он находится в подписанном JWT.

Положительный ответ узок: показанное значение принадлежит обещанию, которое подписал этот Issuer. Holder вправе отправить любое подмножество, в том числе пустое. Issuer может сочетать всегда видимые claims с выборочными и добавлять decoy digests. Поэтому из непоказанного значения нельзя честно вывести ни «такого свойства нет», ни «оно не важно», ни даже надёжное число скрытых свойств.

Нужно отдельно назвать владельцев каждого шага. Issuer создаёт утверждение и решает, что допускает выборочное раскрытие. Holder собирает конкретное предъявление. Verifier проверяет подписи и digests. Локальное приложение толкует claims, применяет свою политику и, возможно, меняет состояние. Формула «документ доказал право» выдаёт за один факт работу разных сторон.

Подпись Issuer защищает целостность структуры после выдачи. Она не рассказывает, каким наблюдением получено утверждение, остаётся ли оно верным сейчас и что оно означает для любого приложения. RFC 7519 задаёт форму claims, реестр IANA — общие имена. Обязательность, достаточность и срок применимости определяет профиль и политика Verifier. RFC 8725 рекомендует явные типы и правила проверки, зависящие от конкретного использования JWT.

Key Binding добавляет ещё одно, но необязательное доказательство. Если этого требует политика, Holder подписывает KB-JWT с hash SD-JWT, nonce и audience. Так Verifier может установить владение закрытым ключом в этой презентации. Это не доказывает полноту раскрытия, актуальность фактов или разрешение на следующий шаг. Если Key Binding не требуется, любой владелец SD-JWT может переслать его третьей стороне и удалить Disclosures.

Стандарт не предлагает скрыть решающие условия за приватностью. Issuer не должен делать выборочно раскрываемым содержание, критичное для аутентичности или действительности; точный набор определяет профиль. Verifier обязан проверить подпись Issuer и каждый digest. А правило, какой набор достаточен для действия, остаётся у локальной системы, которая способна отказать.

Для объяснимого контроля сохраняйте Issuer и политику ключей, тип и профиль, требовавшиеся и показанные claims, результаты digest, требование Key Binding, nonce, audience, версию политики и фактический итог. Метрика «токен валиден» склеивает доказательства, которые нельзя склеивать.

Различение Heng Lu между представлением, локальным решением и исполненным результатом здесь работает как редакционная дисциплина. RFC 9901 делает ограниченное утверждение переносимым и проверяемым. Он не наделяет видимую выборку властью полного досье и не избавляет исполняющую систему от её собственного решения.

Sources