Summary

  • В редакции 01 as_signature охватывает только id и весь user_confirmation: точный текст на экране, действие пользователя и отметку времени.
  • audit_trail, предназначенный для объяснения семантического расширения до разрешённых операций, явно исключён. Локальная реконструкция сохранила один вход подписи при двух несовместимых версиях журнала.
  • Внешняя подпись целого JWT по-прежнему защищает все вложенные данные. Для непрозрачного токена TLS защищает получение, но не превращает извлечённый журнал в переносимое подписанное утверждение.

Что останется в деле об инциденте

draft-liu-oauth-authorization-evidence-01 предлагает полезный минимум для подтверждения: идентификатор доказательства, объект user_confirmation и отделённую JWS. В подтверждении сохраняются точное содержимое экрана, описание действия и время NumericDate.

Раздел 3.6 задаёт точную процедуру. Реализация создаёт новый JSON только из id и user_confirmation, канонизирует его по RFC 8785 JCS и подписывает полученные байты. Поля расширения сверх id, user_confirmation и as_signature включать нельзя. Следовательно, граница журнала аудита задана нормативно.

При расследовании валидная подпись позволяет сказать: сервер авторизации подписал такую запись подтверждения. Но проект отдельно предупреждает, что это не независимое доказательство фактического согласия пользователя. Интерфейс и ключ контролирует сервер. Для более сильной неотказуемости нужны пользовательская подпись или независимый аудит.

Это также не квитанция исполнения. Сервер ресурсов отдельно журналирует идентификатор, время и краткое содержание экрана, а затем выполненную операцию и её успех или отказ. Подтверждение, решение, отправка команды, выполнение и внешний результат — разные события.

В деле не хватает именно карты преобразования

Раздел 4 отводит audit_trail роль семантической прослеживаемости: показать, как намерение истолковано и преобразовано в разрешённые операции. Необязательные поля включают evidence_ref, уровень расширения и proposal_ref.

Уровни от none до high — классификация, а не воспроизводимая разница. Метка medium не объясняет, почему «дешёвые наушники» стали лимитом 50 долларов, какая категория выбрана и какая версия политики участвовала.

proposal_ref — непрозрачный URI сервера авторизации к предложению до оценки политики, сокращения области или изменения согласия. Редакция 01 не задаёт протокол получения, хеш содержимого, срок хранения или правила доступа. Ссылка может быть в деле, а исходные байты — уже недоступны проверяющему.

Это не утверждение об атаке. Система может хранить неизменяемое предложение, подписывать более широкий конверт или фиксировать ответ. Вывод уже: эти свойства не следуют из переносимого объекта проекта.

Два журнала, один подписываемый объект

Локально были собраны два объекта с одинаковыми id, текстом, действием и временем. В одном журнале стояли medium и ссылка на вариант 50, в другом — high и вариант 500. Полные канонические представления и их хеши различались. Проекция раздела 3.6 совпала и в обоих случаях дала aec26fa5351ab57f144fd6b387b297969f73e34ec3ea5a557592a0b2d3a7b512.

Реконструкция показывает только границу входа подписи. Она не проверяет сокращённую JWS из проекта, не ломает JWS/JCS, не исследует реальный продукт и не доказывает злой умысел, проведённую транзакцию или ущерб.

Сохранённый контейнер меняет доказательную картину

Если доказательство встроено в подписанный JWT-токен доступа RFC 9068, внешняя подпись покрывает весь вложенный объект, включая журнал. Изменение журнала внутри целого JWT обнаружится при проверке внешней подписи. Нельзя переносить узкую границу внутренней подписи на весь контейнер.

С непрозрачным токеном сервер ресурсов получает данные через интроспекцию RFC 7662 или отдельный endpoint. Проект называет as_signature единственной защитой целостности записи в таком случае и требует TLS. TLS защищает контрагента и ответ во время соединения. После извлечения, хранения или пересылки канал не становится подписью соседних метаданных.

Интроспекция отвечает на текущий вопрос авторизации. Значение active зависит от сервера, ответы могут отличаться по серверу ресурсов, кэширование меняет свежесть на нагрузку. Это не готовый архив преобразования смысла.

Доказательство причины не связывает политику действия

Сопутствующий проект Rego отделяет доказательство «почему разрешено» от политики «что агент может делать». В полном примере authorization_evidence и rego_policy — соседние объекты. Внутренняя подпись подтверждения не связывает URI политики, точку входа или входные данные оценки.

Целый внешний JWT может связать совокупное представление. В непрозрачной системе нужны собственные правила получения и хранения. Без них слово «разрешено» смешивает экран, интерпретацию, политику, решение ресурса, отправку, исполнение и эффект, оставляя полномочие заполнить пробел последнему компоненту.

Паспорт, пригодный для расследования

Для значимых действий нужен паспорт интерпретации: идентификаторы доказательства и сессии, хеш и язык экрана, исходное предложение или неизменяемый хеш, нормализованная операция и ограничения, семантическая разница и её генератор, идентификатор и хеш политики, точка входа и данные, издатель, аудитория, субъект, агент и клиент, решение сервера ресурсов, хеш фактически отправленного запроса, квитанция исполнения и отдельно наблюдавшийся результат.

Это аналитическое предложение Daniel Kade, а не требование редакции 01. Чувствительные данные можно держать в контролируемых хранилищах и связывать хешами. Минимальная спецификация должна оставить достаточно неизменяемых опор, чтобы независимый уполномоченный участник восстановил путь решения.

Sources and limits

Наблюдения зафиксированы 30 сентября 2026 года, Asia/Shanghai. Редакция 01 — активный индивидуальный Internet-Draft, а не RFC, консенсус рабочей группы OAuth или свидетельство внедрения. Локальная реконструкция подтверждает лишь заданную проекцию. Она не доказывает поломку JWS/JCS, подмену в TLS, дефект реализации, злоумышленный сервер, ущерб или завершённое действие. Проект может измениться, быть заменён или истечь.