Кратко

  • В редакции -02 индивидуального Internet-Draft предлагается отклонять весь предъявленный токен, если проверяющая сторона не может оценить хотя бы один элемент authorization_details. Незаметно выбросить непонятный элемент и вернуть успех означало бы одобрить неполную проверку.
  • Вызывающей стороне следует понять, что повторная отправка того же токена не поможет, но не получать сведения о конкретном элементе, пути делегирования или вышестоящем разрешении, где произошёл сбой. Полная причина остаётся в защищённой записи аудита проверяющего.

Точный ответ об ошибке — не всегда безопасный ответ. Агент из одной организации предъявляет токен сервису другой. Проверяющий видит, что одно из звеньев или один из типов разрешения не поддаётся оценке. Сообщение «истекло родительское разрешение номер X» помогло бы отправителю понять отказ, но одновременно позволило бы исследовать внутреннее состояние цепочки чужой организации. Сообщение, похожее на временную техническую неполадку, таит другую проблему: агент может многократно посылать неизменный токен, который никогда не пройдёт.

Эту развилку выделяет новая редакция работы Уэса Джексона Verifier-Side Evaluation Semantics for Delegated Authority Chains от 29 сентября 2026 года. Datatracker IETF обозначает её как индивидуальный Internet-Draft со статусом I-D Exists; стандартизационный поток не определён. Это не принятый рабочей группой WIMSE текст, не RFC и не свидетельство внедрения. Предписывающие формулировки документа следует приписывать автору проекта, а не представлять как уже действующий стандарт IETF.

Сравнение с редакцией -01 показывает, зачем изменился словарь. Ранее правило 4.1 называлось «Process Every Entry or Reject», теперь — «Process Every Entry or Refuse». Проект различает отказ проверяющего принять токен или запись и окончательное отклонение утверждающим лицом отложенного вызова. Первый результат означает, что доказательство полномочий не прошло оценку; второй относится к человеческому решению о конкретном действии. При общей метке «отклонено» легко перепутать, кто решил и что именно прекратилось.

Раздел 4.1 новой версии требует, согласно предложению автора, обработать каждый предъявленный элемент authorization_details либо отказаться от токена. Если тип не поддерживается, его нельзя молча убрать и назвать остаток полностью одобренным. В тексте такой отказ назван окончательным для предъявленного токена: повторение тех же байтов не расширит возможности проверяющей стороны. Это не запрет получить другой токен. Разница между «этот токен не сработает» и «никакой новый токен не сработает» принципиальна для стратегии клиента.

Раздел 5 обращается уже к информации в ответе. Вызывающей стороне желательно отличать безнадёжный повтор с тем же токеном от временного сбоя. Однако ответ не должен указывать на провалившийся элемент, конкретный путь делегирования или состояние вышестоящего grant, кроме свойств самой проверяющей стороны, уже доступных публично. Иначе серия отказов превратится в способ построить карту чужих разрешений. Подробность должна находиться в записи аудита, которую читает уполномоченный оператор проверяющего.

Разделение краткого внешнего исхода и точной внутренней диагностики — операционный вывод Daniel Kade; проект не учреждает обязательную форму такого «двухчастного» сообщения.

Существующие коды OAuth иллюстрируют границы, а не дают единый шаблон. RFC 9396 определяет invalid_authorization_details в контексте сервера авторизации и регистрирует его для конечных точек авторизации и выдачи токена. RFC 6750 описывает invalid_token для сервера ресурсов, принимающего bearer token; клиент может запросить новый токен доступа и повторить запрос ресурса. Джексон ссылается на оба документа, но не вводит ни нового кода, ни общего формата ответа. Как именно выразить итог без утечки сведений, зависит от протокола и границы доверия.

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

Источники