Summary

  • draft-li-oauth-delegated-authorization-03 предлагает корневой token от authorization server, локально подписанные дочерние tokens и DPoP-доказательство владения ключом последнего звена.
  • Проверка устанавливает непрерывность ключей и сужение permissions, audience, срока и глубины. Она не доказывает причину выбора делегата, человеческий замысел задачи, доставку отзыва offline-серверу или итоговый эффект.
  • Daniel Kade предлагает отдельную квитанцию намерения делегирования: корневой мандат, custody каждого перехода, граница задачи и эффекта, свежесть отзыва, решение ресурса и закрытие — без хранения credentials.

Не передавать исходную власть целиком

Оркестратор может иметь доступ к нескольким системам, а узкому агенту требуется только часть работы. Передача исходного access token выдаёт лишние права. Совместное использование private key уничтожает атрибуцию. Обращение к authorization server за каждым подзаданием возвращает всю координацию в центр.

Revision 03 определяет Delegated Authorization Token, привязанный к ключу. Authorization server подписывает root и помещает в cnf.jkt thumbprint публичного ключа первого client. Пока глубина разрешает, этот client подписывает child своим связанным ключом и привязывает новый token к ключу следующего delegate client.

Resource server получает полную упорядоченную цепочку. Root verification key берётся из trusted configuration или authenticated metadata. Для каждого child thumbprint публичного JWK из protected header должен совпасть с cnf.jkt parent по RFC 7638. Leaf client добавляет DPoP proof, связанный с HTTP method, target URI, точной сериализацией всей цепочки и freshness.

Поэтому украденной строки недостаточно: предъявитель обязан контролировать leaf private key. Проект вводит HTTP authentication scheme DA и запрещает принимать Delegated Authorization Token как Bearer.

Итог точен: связанный ключ в каждом звене санкционировал следующий ключ под вычисляемыми ограничениями, а последний requester владеет ожидаемым ключом. Организационная цель из этого не следует.

Сужение прав нельзя измерить длиной JSON

Child не вправе расширять permissions, audience, validity period или remaining delegation depth. Для обычного scope работает включение множеств. Значение, которого нет в effective scope parent, не может появиться у child. Отсутствие scope отбрасывает этот компонент разрешений.

С authorization_details всё сложнее. Смысл зависит от сумм, resources, actions, arrays, wildcards и defaults. Более короткий объект может оказаться шире, если пропущенное ограничение включает разрешающий default.

Поэтому спецификация каждого detail type должна определить детерминированное containment. Равенства сырого JSON или одного type недостаточно. Если verifier не умеет доказать, что child покрывается effective parent, он обязан отклонить chain.

То же относится к extension claims, влияющим на авторизацию. Нельзя считать их ограничением, если не все предполагаемые verifiers реализуют семантику делегирования. Подписанное поле, которое resource server игнорирует, создаёт лишь видимость сужения.

Таким образом, monotonicity зависит от vocabulary и версии comparator не меньше, чем от signature. Audit должен сохранять правило, обработавшее defaults, wildcards и actions.

Глубина считает переходы, а не ущерб

Каждый root содержит конечный max_delegation_depth. Ноль запрещает valid child. При положительном m child может установить от нуля до m-1; отсутствие claim даёт m-1. Authorization server задаёт локальный максимум, а реализации отдельно ограничивают token count, size и verification cost.

Число описывает рёбра графа, но не последствия. Один terminal hop может разрешить необратимую запись, а три перехода — чтение справочника. Ноль не означает низкий риск, знакомство человека с последним client или согласие на конкретную transaction.

Если grant связан с resource owner, исходное решение должно охватывать право client выпускать children без нового взаимодействия и максимальную глубину. Обычное согласие на access нельзя трактовать как согласие на delegation. Отказ от явно запрошенной глубины нельзя превратить в молчаливую выдачу меньшей.

Однако проект не определяет, как показать такую способность человеку. Формулировка «два следующих уровня» может быть протокольно верной и практически пустой. Она не называет будущих делегатов, key discovery, задачи и эффекты, требующие повторного согласования.

Задача находится за границей общего формата

Вне scope оставлены client key discovery, out-of-band negotiation, доставка нескольких chains, binding полученной цепочки к конкретному request или task, правила сравнения для каждого application type и distribution revocation status.

Именно эти поверхности соединяют общую власть с операционным решением.

Research agent может получить read на одну knowledge API, десять минут жизни, одну audience и depth 0. Полностью valid chain всё равно не различает «сделать резюме утверждённого файла» и «искать по всем доступным кадровым документам». Resource policy и request context могут запретить второе, но человеческая причина задачи не находится в key continuity.

Проект прямо говорит: chain validation сама по себе не авторизует protected resource request. Resource server ещё проверяет DPoP, request binding, audience и application permissions. Даже allow не доказывает успешное исполнение. Операция может завершиться ошибкой или вызвать downstream effect.

Root mandate, custody переходов, task intent, current validity и observed effect — пять разных вопросов.

У отзыва два времени

Revocation root инвалидирует все начинающиеся от него цепочки. Revocation child инвалидирует каждую цепочку с этим token и всех descendants, но не parent, siblings или другие tokens на том же key. Target должен иметь однозначный идентификатор, например collision-resistant digest точной сериализации.

Успешный revocation request записывает состояние у authorization server. Он не доставляет его offline resource server. Revision 03 не определяет механизм распространения. Short lifetime ограничивает окно неизвестности, но не доказывает момент получения у каждого verifier.

Поэтому нужны две временные отметки: когда отзыв зарегистрировали и какую status version, age и failure policy имел ресурс при решении. Центральная запись в 10:00 не означает периферическое знание в 10:01.

Cache не отменяет эту границу. Signatures и effective restrictions можно кэшировать по digest exact chain, но запись должна учитывать expiration, key status, local policy и действительно полученную revocation information. DPoP freshness и replay detection остаются per request.

Видимость перемещается, а не исчезает

Local delegation избавляет authorization server от обязательного наблюдения за каждым delegate, resource, access time и multi-hop pattern. Это может уменьшить центральную концентрацию данных.

Зато resource server видит complete ordered chain. Claims могут раскрыть issuer, subject, отношения clients, audiences, permissions и workflow structure. Стабильные cnf.jkt, root jti и другие identifiers помогают корреляции между запросами и ресурсами.

Audit visibility просто распределяется: root issuance видит authorization server, local delegation — подписывающий client, validation и resource decision — resource server. Проект рекомендует связывать события one-way digest цепочки, удалять Authorization и DPoP headers из обычных logs и защищать authorization details.

Нужен не центральный архив credentials, а минимальная reconciliation доказательств разных наблюдателей.

Один ключ и использует, и воспроизводит власть

Bound private key подтверждает владение текущим token и, если остаётся глубина, подписывает child. При compromise злоумышленник может использовать неистёкшие права и создавать descendants в их пределах.

Проект советует non-exportable keys и узкие signing APIs, различающие token-signing и proof-signing inputs. Разные keys для разных tokens уменьшают correlation и incident radius.

Есть дополнительная тонкость: client-issued token не содержит parent identifier. Он может быть valid в другой цепочке, где предыдущий token связывает тот же signing key и effective restrictions охватывают child. Это намеренное свойство начального формата. Для one-parent binding нужны разные parent keys или application restriction.

Thumbprint обозначает ключ, но не процесс, который им управлял, не policy signing API и не задачу, которую предполагала организация.

Квитанция намерения делегирования

Я предлагаю квитанцию намерения делегирования. Это governance-конструкция Daniel Kade за пределами протокола, не новый OAuth claim и не требование Internet-Draft.

Root-раздел содержит безопасный digest authorization event и версии consent presentation, issuer и trusted-metadata snapshot, delegation capability, effective permissions, audiences, lifetime и depth. Token, private key, DPoP proof, raw headers и лишние subject data туда не входят.

Для каждого local hop фиксируются exact-chain digest, публичные parent/child thumbprints, restrictions до и после, containment rule и version, signing service identity и минимальное основание выбора client. Key reuse и one-parent requirement отмечаются отдельно.

Затем добавляется то, чего нет в generic credential: digest конкретной task, acceptable output и effect boundary; decision owner; environment, transaction или action limit; условия нового человеческого взаимодействия. Чувствительное содержание задачи копировать не нужно.

При resource decision сохраняются policy version, semantic comparator, версия и freshness полученного revocation state, DPoP result, effective authority и allow/deny. Closure указывает operation class, success/failure, существенные secondary effects и rollback либо incident reference.

Минимальная начальная схема — root mandate, hop digest, task/effect digest, revocation freshness и final decision. Она не пытается философски доказать намерение; она сохраняет операционные свидетельства, которые chain не предназначена переносить.

Не расширять смысл зелёного результата

Revision 03 — индивидуальный Internet-Draft, обновлённый 24 июля 2026 года. Это не adopted OAuth WG document, не IETF consensus, Last Call, IESG approval, RFC или действующая IANA registration. Подробность текста не доказывает deployment или adoption.

В этих границах предложение ценно. Оно даёт local delegation проверяемую key lineage, запрещает рост authority, требует fail-closed при неизвестной семантике и честно показывает внешний долг revocation distribution.

Valid chain доказывает, что определённая последовательность ключей могла сужать и использовать grant в вычисленных границах. Она не доказывает, что человек хотел именно этого delegate, task и effect.

После disclosure данных или изменения системы поздняя signature не восстановит отсутствующий замысел. Полномочия могут идти по цепочке; намерение должно быть сохранено рядом до совершения действия.

Источники

  1. Lu Heng — The Policy Mirror
  2. Lu Heng — Minimum Initial Specification, Localized Future Decision and Voluntary Adoption
  3. Lu Heng — Why BTW Media Exists
  4. OAuth 2.0 Delegated Authorization, revision 03
  5. Карточка проекта в Datatracker
  6. История проекта Delegated Authorization
  7. Charter рабочей группы OAuth
  8. RFC 6749: OAuth 2.0 Authorization Framework
  9. RFC 7009: OAuth 2.0 Token Revocation
  10. RFC 7638: JSON Web Key Thumbprint
  11. RFC 8414: OAuth 2.0 Authorization Server Metadata
  12. RFC 8707: Resource Indicators for OAuth 2.0
  13. RFC 8725: JSON Web Token Best Current Practices
  14. RFC 9396: OAuth 2.0 Rich Authorization Requests
  15. RFC 9449: OAuth 2.0 Demonstrating Proof of Possession
  16. RFC 9700: Best Current Practice for OAuth 2.0 Security
  17. RFC 9728: OAuth 2.0 Protected Resource Metadata