Кратко

  • draft-ietf-oauth-transaction-tokens-11 описывает короткоживущий подписанный JWT, переносящий идентичность и контекст транзакции по Call Chain внутри Trust Domain, ограниченного aud. Это активный Standards Track Internet-Draft в состоянии WG Consensus: Waiting for Write-Up, а не RFC и не окончательное одобрение IETF.
  • Получатель обязан проверить JWS-подпись, audience и срок действия. Эти проверки подтверждают целостность и область применения контейнера, но сами по себе не показывают, было ли каждое значение rctx или tctx предоставлено, замечено, выведено либо независимо подтверждено.
  • Daniel Kade предлагает хранить рядом с решением конверт происхождения утверждения: источник, реально выполненную проверку, наблюдателя и время, преобразование, версию политики, свежесть, разрешённое применение, противоречия и результат. В нём могут быть хеши и ссылки вместо полного токена и лишних персональных данных. Это не требование IETF.

При разборе спорного допуска команда показала Transaction Token с корректной подписью и полем identity_verified: true. Но на вопрос «кем и каким способом?» ответом снова стал тот же токен. Запись не позволяла отличить проверенную внешнюю учётную запись от значения, которое запросивший workload передал в обычном JSON.

Подпись доказывала сохранность записи. Она не восстанавливала основание записанного факта.

Именно здесь криптографическая гарантия незаметно превращается в семантическую. JWS позволяет установить, что определённый ключ подписал определённые байты и те не менялись. Transaction Token Service выбирает claims, доступные получателям. Однако происхождение, проверка, время и допустимое применение каждого значения образуют отдельный слой assurance.

Статус редакции 11 нельзя повышать словом

Согласно Datatracker, редакция 11 датирована 30 июля 2026 года и остаётся активным Internet-Draft рабочей группы OAuth на Standards Track. На момент исследования состояние WG было WG Consensus: Waiting for Write-Up, состояние IESG — I-D Exists. Ответственный Area Director и дата telechat отсутствовали. Работа продвинута, но ещё не стала RFC или завершённым решением IETF.

История документа и официальный diff 10→11 показывают, что новая редакция исправляет опечатку в истории. Рассматриваемая здесь модель доверия уже присутствовала в версии 10. Объявление I-D подтверждает публикацию, но не завершение стандартизации.

Предложение отвечает реальной потребности. Внешний запрос нередко проходит через несколько workloads. Каждому нужны субъект, цель, scope и детали операции, но передача исходного внешнего credential на каждый шаг увеличивает экспозицию и заставляет все сервисы понимать его формат. Transaction Token переносит общий контекст как краткоживущий подписанный JWT внутри Trust Domain, названного в aud.

В каждом таком домене существует ровно один логический Transaction Token Service, хотя его могут обслуживать несколько экземпляров. TTS аутентифицирует запрашивающий workload, проверяет его полномочие на получение токена, формирует набор утверждений и подписывает результат. JWT задаёт формат claims, JWS — подписанное представление, а OAuth Working Group ведёт документ.

Проверка токена не снимает локальную ответственность

Получающий workload должен проверить JWS-подпись, убедиться, что aud указывает на его Trust Domain, и отклонить истёкший объект. После трёх успешных проверок он знает, что в отведённое время получил предназначенные своему домену байты, подписанные TTS.

Затем данные можно использовать для локальной авторизации, но её метод остаётся вне scope документа. TTS доставляет согласованный контекст. Сервис, совершающий действие, по-прежнему отвечает за то, какую доказательную силу он приписал использованным полям.

Transaction Token не является authentication credential и не должен использоваться как OAuth access token. В OAuth 2.0 access token представляет предоставленное полномочие; Transaction Token представляет контекст транзакции. Сходная кодировка не превращает описание в grant.

Токен также не получает replay resistance от подписи. Уникальный txn способен помочь выявить повтор или ввести одноразовое использование. Но строгая гарантия в распределённой Call Chain может потребовать общего состояния, которое непрактично. Неизменённые байты можно предъявить снова.

Авторитет над набором не означает общего источника

Обязательный scope определяет TTS. Он не вправе расширять scope исходного subject token. Если входной scope непонятен, запрос нужно отклонить, а не толковать неизвестность как отсутствие ограничений. Это конкретная нормативная защита от расширения прав.

В рекомендованном rctx помещается контекст запроса или окружения. Если его предоставляет запрашивающая сторона, TTS следует оценить входные данные. Конечное значение может точно совпасть с ними, быть из них выведено либо стать самостоятельным утверждением TTS. Сервис авторитетен в выборе доступного набора. Но выбор элемента не говорит, что каждый элемент независимо наблюдался и проверялся одинаково.

Рекомендованный tctx хранит детали транзакции, которые должны оставаться неизменными по всей Call Chain. Они могут повторять запрос, быть результатом преобразования или дополнительными claims TTS. Неизменность после выпуска отвечает на один вопрос; происхождение до выпуска — на другой.

Представим три значения. request_ip заметил аутентифицированный шлюз. transfer_amount скопирован из неподписанного объекта вызывающей стороны. risk_band вычислен TTS по политике 43 из проверенного credential и свежего внешнего сигнала. Одна подпись защищает всё. Но доказательность первого зависит от шлюза, второго — от права автора входа, третьего — от источников и версии вычисления.

Отсюда не следует, что rctx или tctx ненадёжны по своей природе. Некоторые поля могут иметь очень высокую assurance. Она просто принадлежит конкретной цепочке источника, проверки, времени, преобразования и применения. Разные классы могут сосуществовать в одном токене, если потребитель не скрывает их под общей меткой «подтверждено эмитентом».

Разные subject tokens требуют разных проверок

Subject token может быть OAuth- или SAML-токеном, самоподписанным JWT, неподписанным JSON-объектом либо иным понятным TTS форматом. TTS обязан его валидировать, включая подпись, если она есть. Поэтому одно слово «проверен» может означать различные действия: проверку issuer, ключа, алгоритма, audience, времени, схемы или защищённого канала.

JWT Best Current Practices объясняет, почему нельзя некритично выбирать алгоритм и ключ из самого токена. OAuth Token Exchange задаёт соседний механизм обмена security tokens, тогда как Transaction Tokens посвящены внутреннему контексту. Неподписанный JSON может быть допустимым входом по локальному защищённому договору, не приобретая криптографическое происхождение проверенного credential.

TTS отдельно аутентифицирует запросивший workload и проверяет его право получить нужный токен. Политика выдачи и бизнес-логика зависят от deployment и вынесены за рамки draft. Две соответствующие реализации способны по-разному проверять поле с одним названием. Без версии политики синтаксическое совпадение маскирует расхождение доверия.

exp не измеряет свежесть каждого входного факта

Transaction Tokens рассчитаны на минуты или меньший срок — только на ожидаемый вызов. Тем не менее политика TTS может разрешить новому токену жить дольше предъявленного subject token, а TTS следует оценить риск. Это бывает разумно для завершения уже начавшейся короткой цепочки. Но exp нового объекта не доказывает, что вся исходная информация перепроверена.

OAuth access token может быть аннулирован до календарного окончания. В зависимости от риска TTS может проверить текущий статус через token introspection или сходный механизм. Универсальной обязательной онлайн-проверки draft не устанавливает. «Не истёк» и «в 13:42 проверен как не отозванный» должны оставаться разными свидетельствами.

Replacement Token не может расширить разрешённые действия или изменить txn, sub, aud. Он может сузить scope, добавить assertions и при соответствующей политике продлить срок. Он обязан сохранять Call Chain запросивших workloads, но способ сохранения находится вне scope. Если новый claim не связан с конкретным этапом замены, итоговый токен превращает последовательную историю в мгновенный снимок.

Граница aud тоже содержательна. Transaction Token действует только внутри своего Trust Domain. Для перехода между доменами предназначена отдельная работа OAuth по identity-and-authorization chaining. Техническая возможность проверить чужую подпись не переносит локальные определения и доверительную политику.

Замечание одного рецензента не становится статистикой

В WGLC-сообщении от 8 августа 2026 года один рецензент поддержал продвижение документа и назвал свои комментарии неблокирующими. Он попросил повысить аудируемость replacement chains и предупредил, что реализаторы могут спутать информацию, переносимую в подписанном токене, с информацией, независимо подтверждённой эмитентом.

У источника есть чёткие пределы. Это мнение одного рецензента и заявленный им опыт реализации, не WG consensus, не измерение распространённости, не подтверждённый инцидент и не доказательство дефекта редакции 11. Письмо ценно тем, что называет правдоподобную операционную ошибку чтения.

Конверт происхождения должен сопровождать решение

Редакционное предложение Daniel Kade — создавать конверт происхождения для каждого значения, реально повлиявшего на решение. В нём указываются класс и несекретная ссылка на источник, выполненная в действительности проверка, наблюдатель и время, преобразование и версия кода или политики, при необходимости issuer, ссылка на ключ и граница Trust Domain, проверка свежести или отзыва, разрешённые применения, чувствительность, правило логирования, противоречия, downstream-решение, срок и закрытие.

Такой конверт не обязан находиться в Transaction Token и не навязывает универсальную схему claims. Он может ссылаться на квитанцию выпуска, хранить хеш токена или указывать на минимизированное доказательство. Draft запрещает дословно логировать полный токен из-за replay и чувствительных данных. Хеш подходит для корреляции с записью TTS; иногда можно сохранять неподписанный JWS payload. Но и payload способен содержать персональные сведения. Является ли IP-адрес или параметр среды персональными данными, зависит от юрисдикции; статья не делает правового вывода.

Цель записи — восстановить основание решения, не создавая второе хранилище пригодных к повторному применению bearer tokens и сырых персональных данных. Сохраняется родословная факта, а не секрет.

Источники