Summary

  • Редакция 01 помещает подписанный Issuer JWT Credential в Authorization: DPoP и использует обычный proof RFC 9449 с htu, htm, jti, nonce и ath.
  • Корректный proof не определяет класс объекта. Resource Server должен различать Credential и access token по заранее доверенному iss и разрешённому typ.
  • Владение ключом для конкретного запроса не создаёт aud, не обновляет status, не ограничивает раскрытие claims, не выдаёт разрешение и не подтверждает результат операции.

Провод тот же, смысл другой

Holder передаёт весь Credential на месте токена и подписывает отдельный DPoP proof. ath по-прежнему равен SHA-256 от US-ASCII-байтов значения в полученном виде. Сервер проверяет подпись proof, свежесть, метод, URI, уникальность jti, требуемый nonce, а затем сопоставляет ключ с cnf.jkt либо с отпечатком cnf.jwk.

Эта цепочка подтверждает целостность предъявления и владение ключом. Она не выбирает модель полномочий. Профиль JWT access token в RFC 9068 требует aud и использует at+jwt. Credential из проекта обязан иметь определённый deployment тип, который не может быть at+jwt или типом ID Token. Если сервер принимает оба объекта, iss и typ должны направлять их в разные ветви. Иначе правильная криптография приведёт к неправильной политике.

URI запроса не становится audience

htu и htm привязывают proof к методу и URI. Это proof of possession на уровне запроса. aud, если он есть, устанавливает Issuer при выпуске и тем самым ограничивает набор Verifier. Holder выбирает адрес доставки, но не получает полномочий дописать audience задним числом.

Проект допускает Credential без aud. Его можно предъявить любому Resource Server, который доверяет тому же Issuer. Общий identity provider не означает общую интерпретацию claims или одинаковое право на действие. Поэтому локальная политика должна решать доступ после проверки, а валидность Credential не может сама считаться авторизацией.

Время переходит к status

Credential способен жить намного дольше access token. Рекомендуемый status компенсирует часть этого различия. Если claim присутствует, Verifier обязан получить и проверить состояние; невалидное состояние ведёт к отказу. Локальная политика может также отвергнуть долгоживущий Credential без статуса.

Срок cache списка превращается в задержку отзыва. Подпись Issuer, свежий DPoP proof и вчерашний status — три квитанции с разными часами. Отсутствие обращения к Issuer на каждом запросе снижает задержку и прямую наблюдаемость, но загрузка status всё равно способна раскрыть место использования.

Полное предъявление раскрывает всё

Holder не выбирает claims: каждый Verifier получает весь JWT. Стабильное значение подписи позволяет сопоставлять предъявления между сервисами. Authorization может оказаться в access logs или у proxy. TLS защищает канал, но не удаляет лишнюю claim и не стирает уже сохранённую копию.

Когда Verifier должен обнаружить доступные Credentials, запросить часть claims или получить согласие человека, нужен OpenID4VP либо другой согласовательный протокол. Здесь предполагается программа, заранее знающая адрес и допустимый Credential. Даже SD-JWT VC используется лишь как подписанный Issuer JWT без disclosures.

Minimum Initial Specification Лу Хэна отделяет повторное использование малого общего механизма от передачи ему всей власти. Running-Code Primacy требует фактических квитанций: выбранного typ, доверия к Issuer, ветви audience, возраста status, версии политики и результата ресурса.

Sources and limits

Источники не доказывают принятие OAuth WG, консенсус IETF, RFC, реализацию, совместимость, deployment агентов, фактический выпуск или отзыв, авторизацию либо результат сервиса. Существующая статья о RFC 9449 сохраняет общую тему sender constraint; эта статья посвящена только иной модели власти в той же wire-форме.