Кратко

  • RFC 9901 — спецификация IETF на пути стандартов для выборочного раскрытия отдельных элементов JSON в объектах JWS; основной сценарий — JWT.
  • Издатель помещает в подписанную полезную нагрузку дайджесты вместо открытых значений, а держатель передаёт отдельные Disclosures; проверяющий пересобирает только проверенную часть.
  • SD-JWT не является шифрованием, доказательством с нулевым разглашением или анонимным credential и сам по себе не гарантирует невозможность корреляции.

Для свойства объекта Disclosure содержит соль, имя claim и его значение. Для элемента массива она содержит соль и значение. JSON-массив кодируется в UTF-8 и затем Base64url перед хешированием. Каждая соль должна быть криптографически случайной, независимой и уникальной для каждого выборочно раскрываемого claim; до раскрытия она должна быть известна только держателю. Рекомендуемый минимум случайной части — 128 бит. Верхнеуровневый _sd_alg выбирает хеш раскрытия; вложенное применение запрещено. При отсутствии поля используется sha-256, который реализации обязаны поддерживать.

Подписанный издателем JWT должен иметь подпись; алгоритм none недопустим. Проверяющий сначала проверяет подпись издателя и каждый дайджест предъявленных Disclosures, а затем восстанавливает обработанную payload. Поддерживаются вложенные и рекурсивные раскрытия: скрытый дочерний элемент может зависеть от раскрытия родителя, поэтому держатель обязан сохранить корректную цепочку зависимостей. Decoy-дайджесты могут скрыть исходное число или наличие скрытых claims, но увеличивают размер токена и смягчают лишь побочный канал; они не предотвращают корреляцию.

Key Binding является необязательным, если только его не требует профиль или конкретный сценарий. При обязательном для профиля связывании SD-JWT содержит открытый ключ держателя либо ссылку на него, а держатель подписывает KB-JWT с typ: kb+jwt, iat, aud, nonce и sd_hash. sd_hash связывает KB-JWT с точным подписанным издателем JWT и выбранными Disclosures. Проверяющий должен проверить ключ держателя, подпись, алгоритм, typ, временное окно выпуска, audience, nonce и sd_hash.

Профиль должен определить обязательные claims, влияющие на действительность. Если, например, exp сделан выборочно раскрываемым, проверяющий может лишиться данных, необходимых для отклонения презентации; отсутствие требуемого claim нужно отклонять. RFC 9901 полагается на транспорт для конфиденциальности и не задаёт механизма шифрования. При риске пассивного наблюдения или корреляции конфиденциальный транспорт обязателен; на уязвимых каналах SD-JWT может быть инкапсулирован в JWE. Хранение следует ограничивать необходимым для работы объёмом.

Конкретные проверки соответствия

  1. Проверить JWS по RFC 7515 и базовые правила JWT по RFC 7519; отклонять none.
  2. Проверить _sd_alg, при отсутствии выбрать sha-256, а для каждой соли проверить случайность, независимость и уникальность; рекомендованный минимум — 128 бит.
  3. Пересчитать каждый digest из правильного представления Disclosure и отклонить несовпадение или отсутствующую родительскую Disclosure.
  4. Проверить обязательные claims, конфиденциальный транспорт и, если требуется, все поля KB-JWT вместе с sd_hash.

Путь решения оператора

Сначала определить минимальное доказательство для каждой цели. Claim, необходимый для проверки действительности, нельзя оставлять необязательным, если его отсутствие не ведёт к отказу. Затем спроектировать схему и уникальные соли, выбрать хеш, решить по политике, нужен ли Key Binding, и управлять nonce, audience, временным окном и жизненным циклом ключа держателя. После этого задать конфиденциальный транспорт, ограниченное хранение, аудит и при необходимости callbacks отзыва, не приписывая RFC конкретного механизма отзыва.

Источники