Network Working Group K. McGuinness Internet-Draft Independent Intended status: Standards Track 25 June 2026 Expires: 27 December 2026 Mission Offline Attenuation for OAuth 2.0 draft-mcguinness-oauth-mission-attenuation-latest Abstract Mission-Bound Authorization for OAuth 2.0 derives delegated authority through the Authorization Server: each narrowing is a Token Exchange at the issuer. For deep sub-agent fan-out, the common agent topology, that puts the Authorization Server in the hot path as a latency and availability dependency. This document defines an OPTIONAL Mission Offline Attenuation profile. It profiles Attenuating Agent Tokens so a Mission-bound token holder can mint a narrower child token offline, with no Authorization Server round- trip, carrying the same mission claim. The narrowing is verifiable from the carried token chain, and the Mission kill switch is preserved because consumption is gated by the runtime enforcement layer, which re-checks Mission state at use; a revoked Mission stops the whole chain even though no issuer minted the children. Offline attenuation is offered alongside, not instead of, Authorization- Server-mediated delegation. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://mcguinness.github.io/draft-mcguinness-oauth-mission/draft- mcguinness-oauth-mission-attenuation.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft- mcguinness-oauth-mission-attenuation/. Source for this draft and an issue tracker can be found at https://github.com/mcguinness/draft-mcguinness-oauth-mission. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 27 December 2026. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction 2. Status: An OPTIONAL Extension 3. Relationship to the Issuance Profile 4. Conventions and Terminology 5. Mission-Bound Attenuation Roots 6. Offline Attenuation 7. The Kill Switch Requires Runtime Enforcement 8. Relationship to Other Delegation 9. Worked Example 10. Conformance 11. Security Considerations 12. IANA Considerations 13. References 13.1. Normative References 13.2. Informative References Acknowledgments Author's Address 1. Introduction The issuance profile [I-D.draft-mcguinness-oauth-mission] (the "issuance profile") narrows authority through the Authorization Server: a delegated or narrowed token is derived at the issuer, and cross-domain projection is a Token Exchange. For an agent that fans out to many sub-agents, each needing a slice of the Mission's authority, that makes the Authorization Server a per-delegation latency and availability dependency on the execution hot path. This document removes the issuer from that path for narrowing. It profiles Attenuating Agent Tokens [I-D.draft-niyikiza-oauth-attenuating-agent-tokens] (the "attenuation substrate"), in which a token holder mints a narrower child token offline by signing it with the key the parent token's cnf binds, and the child commits to its parent by hash. A Mission-bound token can be an attenuation-substrate root; its holder then derives narrower children for sub-agents with no Authorization Server contact. Three things make this safe within the Mission model, and this document requires all three (Section 7): the child carries the parent chain, so a consumer verifies the narrowing from the tokens it holds; the Mission kill switch is preserved because consumption is gated by the runtime enforcement layer re-checking current Mission state, not by the issuer (the attenuation substrate defines no revocation of its own); and authority_hash rides the chain as a lineage anchor, not as the child's own authority commitment. 2. Status: An OPTIONAL Extension This document is OPTIONAL. A deployment that narrows authority only through the Authorization Server is fully conformant to the issuance profile and is unaffected by this document. It places no new requirement on the issuance profile, and it does not replace Authorization-Server-mediated delegation; a deployment offers offline attenuation in addition, for the fan-out paths where issuer round- trips are the bottleneck. A deployment claims this profile only when it issues or accepts Mission-bound attenuation-substrate tokens. 3. Relationship to the Issuance Profile This document depends normatively on the issuance profile and the attenuation substrate, and is not implementable alone. It reuses the issuance profile's Mission, mission claim, Authority Set, subset rule, and lifecycle, and the attenuation substrate's token format, offline derivation, chain linkage, capability monotonicity, and proof-of- possession. It uses Agent (Client), Mission Issuer, Mission, and derived token as the issuance profile defines them, and root token, derived token, par_hash, del_depth, and capability monotonicity as the attenuation substrate defines them. 4. Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Mission-bound attenuation root: An attenuation-substrate root token, issued by the Mission Issuer, that carries the mission claim and whose authority is bounded by the Mission's Authority Set. Offline attenuation: A token holder minting a narrower child of a Mission-bound attenuation token, signed with the parent's confirmation key, without contacting the Mission Issuer. 5. Mission-Bound Attenuation Roots A Mission-bound attenuation root is a Mission-bound token ([I-D.draft-mcguinness-oauth-mission]) whose carried authority is an attenuating_agent_token authorization detail ([I-D.draft-niyikiza-oauth-attenuating-agent-tokens], [RFC9396]). The Mission Issuer derives that authority from the Mission's Authority Set: the root's tool and argument constraints MUST be within the Mission's approved authority under the issuance profile's subset rule. The root carries the mission claim (id, origin, authority_hash) and the holder's confirmation key, as both profiles require. A Mission-bound attenuation root is one shape of Mission-bound token. A deployment MAY also issue ordinary mission_resource_access tokens for the same Mission; the two are derived from the same Authority Set and gated on the same Mission state. 6. Offline Attenuation The holder of a Mission-bound attenuation token mints a narrower child offline, by the attenuation substrate's derivation: it selects a narrower tool and constraint set, increments del_depth, signs with the key the parent's cnf binds, and sets par_hash to the parent's commitment. No Mission Issuer contact occurs. The mission claim rides the chain unchanged: every token in the chain carries the same id, origin, and authority_hash as the root. The child's narrowing is governed entirely by the attenuation substrate's capability monotonicity, which is the subset relation a consumer checks; because the child carries the parent chain, a consumer holding only the leaf and its chain can verify that the leaf is a subset of the root, without holding the Mission's full Authority Set. authority_hash on a derived token is a lineage anchor, not the child's authority commitment. The child's authority is its own carried constraints, narrower than the root's; authority_hash still commits the root Mission's Authority Set, so it links the chain to the approved Mission for audit and remains an audit anchor a consumer cannot recompute from the narrowed leaf, exactly as for any narrowed Mission-bound token ([I-D.draft-mcguinness-oauth-mission]). 7. The Kill Switch Requires Runtime Enforcement The attenuation substrate defines no revocation: a child, once minted, is valid by its signature chain until its exp, and no issuer can reach it. The Mission kill switch is therefore not automatic for offline children; it is delivered only by the runtime enforcement layer. A consumer of a Mission-bound attenuation chain MUST evaluate it under the runtime enforcement profile ([I-D.draft-mcguinness-oauth-mission-runtime]): before each consequential action it MUST establish that the chain's Mission is active, within the deployment's staleness bound, from a Mission state source, in addition to verifying the attenuation chain and the proof- of-possession. A revoked or expired Mission MUST cause refusal of every token in the chain, regardless of the children's own exp. A deployment MUST NOT accept Mission-bound attenuation tokens on a path that does not enforce current Mission state: without that check the offline chain is ungoverned bearer authority until it ages out, which defeats the purpose of binding it to a Mission. Offline attenuation is thus an enforced-tier capability; it is not available to a deployment that relies on token lifetime alone. 8. Relationship to Other Delegation Offline attenuation sits beside two existing mechanisms and is distinct from both: * Authorization-Server-mediated delegation (the issuance profile's act chain and Token Exchange) narrows at the issuer, online, and is the right choice when an issuer round-trip is acceptable and a deployment wants the issuer to observe each delegation. Offline attenuation trades that observation for removing the issuer from the path. * Child Mission Delegation ([I-D.draft-mcguinness-oauth-mission-child-delegation]) creates a separate Child Mission with its own mission_id, lifecycle, and approval. Offline attenuation creates no new Mission: every child rides the same mission claim and dies with the same Mission. Use a Child Mission when the sub-agent needs its own durable, separately revocable Mission; use offline attenuation when it needs a narrower token under the same Mission, fast, at fan-out scale. 9. Worked Example An orchestrator agent (s6BhdRkqt3), acting for alice under Mission msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9- to reconcile Q3 invoices, holds a Mission-bound attenuation root. Its authority covers reading Q3 invoices and posting journal entries under $500; del_max_depth allows two levels of offline narrowing. Decoded root token: { "iss": "https://as.example.com", "sub": "user_3p2q8mN1a0kV7tR", "client_id": "s6BhdRkqt3", "iat": 1797840000, "exp": 1797840300, "jti": "aat_root_7M2R4kP9sT1x", "cnf": { "jkt": "0ZcOCORZNYy-DWpqq30jZyJGHTN0d2HglBV3uiguA4I" }, "del_depth": 0, "del_max_depth": 2, "mission": { "id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-", "origin": "https://as.example.com", "authority_hash": "sha-256:l3KvZ4mP5x0wQrR6tY2nD9bM7sX1cF8gH2vJ4kE5pNQ" }, "authorization_details": [ { "type": "attenuating_agent_token", "tools": { "erp.invoices.read": { "period": { "constraint_type": "exact", "value": "2026-Q3" } }, "erp.journal-entries.write": { "amount_usd": { "constraint_type": "range", "max": 500 } } } } ] } The orchestrator spawns a read-only extraction sub-agent and, with no Authorization Server contact, mints a child that drops the write tool and keeps only the Q3 invoice read. It signs the child with the key the root's cnf binds, sets iss to that key's thumbprint, increments del_depth, and commits the parent by par_hash: { "iss": "urn:ietf:params:oauth:jwk-thumbprint:sha-256:0ZcOCORZNYy-DWpqq30jZyJGHTN0d2HglBV3uiguA4I", "sub": "user_3p2q8mN1a0kV7tR", "iat": 1797840030, "exp": 1797840300, "jti": "aat_child_2Yt7Qv9Lq", "cnf": { "jkt": "kP3xR9sQ7nM2vL4tY6bD1eF8jC5wH0pV2nR3kQ4mZ7t" }, "par_hash": "9XbVt2nD9bM7sX1cF8gH2vJ4kE5pNQl3KvZ4mP5x0wQ", "del_depth": 1, "del_max_depth": 2, "mission": { "id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-", "origin": "https://as.example.com", "authority_hash": "sha-256:l3KvZ4mP5x0wQrR6tY2nD9bM7sX1cF8gH2vJ4kE5pNQ" }, "authorization_details": [ { "type": "attenuating_agent_token", "tools": { "erp.invoices.read": { "period": { "constraint_type": "exact", "value": "2026-Q3" } } } } ] } The mission claim is unchanged, the write tool is gone, and the read constraint is unchanged (a permitted narrowing). To read an invoice the extractor presents the chain [root, child] and a per-invocation proof-of-possession to the gateway. The gateway verifies the chain (the child's signature under the root's cnf key, par_hash, the depth and capability monotonicity), verifies the proof-of-possession under the child's cnf key, and, because this is Mission-bound, checks that msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9- is active within its staleness bound (Section 7). A write attempt by the extractor fails on capability monotonicity: erp.journal-entries.write is not in its tools. And when alice revokes the Mission, the next read fails the state check and the whole chain stops, even though no issuer ever saw the child and the child's exp has not passed. 10. Conformance A Mission Issuer conforming to this profile MUST bound a Mission- bound attenuation root by the Mission's Authority Set and carry the mission claim and confirmation key on it. A consumer conforming to this profile MUST verify the attenuation chain and proof-of- possession per the attenuation substrate, MUST carry the mission claim unchanged across the chain, and MUST enforce current Mission state per Section 7. A deployment MUST NOT claim this profile on a path that does not enforce Mission state. 11. Security Considerations The security considerations of the issuance profile, the runtime profile, and the attenuation substrate apply. This profile adds: * No native revocation. Offline children cannot be recalled by the issuer; the kill switch is the runtime Mission-state check (Section 7), which is mandatory for this profile. A deployment that cannot enforce Mission state MUST NOT accept these tokens. * Stale authority. A child's exp bounds its life absent a state check; a deployment SHOULD keep child lifetimes short so that even a path with a coarse staleness bound limits exposure. * Holder-key compromise. A compromised holder can mint any narrower child within its authority, offline and unobserved. The bound is that it can only narrow, never broaden (capability monotonicity), and that the runtime layer still gates every action against the Mission; the compromise does not widen authority or evade revocation. * Depth and fan-out. del_max_depth bounds chain depth; a deployment SHOULD set it, and SHOULD bound fan-out breadth by policy, since offline minting is unobserved by the issuer. * Audit. Because the issuer does not observe offline derivations, the consuming enforcement points are the only place a derivation is seen; runtime enforcement evidence ([I-D.draft-mcguinness-oauth-mission-runtime]) is the audit record for offline-attenuated actions. 12. IANA Considerations This document makes no IANA request. A Mission-bound attenuation root carries the mission claim, which the issuance profile registers as an open object, and the attenuating_agent_token authorization detail, which the attenuation substrate registers; this profile combines them by reference and defines no new claim, parameter, or registry. 13. References 13.1. Normative References [I-D.draft-mcguinness-oauth-mission] McGuinness, K., "Mission-Bound Authorization for OAuth 2.0", Work in Progress, Internet-Draft, draft-mcguinness- oauth-mission, 2026, . [I-D.draft-mcguinness-oauth-mission-runtime] McGuinness, K., "Mission-Bound Runtime Enforcement for OAuth 2.0", Work in Progress, Internet-Draft, draft- mcguinness-oauth-mission-runtime, 2026, . [I-D.draft-niyikiza-oauth-attenuating-agent-tokens] Aimable, N., "Attenuating Authorization Tokens for Agentic Delegation Chains", Work in Progress, Internet-Draft, draft-niyikiza-oauth-attenuating-agent-tokens-01, 15 June 2026, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC9396] Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0 Rich Authorization Requests", RFC 9396, DOI 10.17487/RFC9396, May 2023, . 13.2. Informative References [I-D.draft-mcguinness-oauth-mission-child-delegation] McGuinness, K., "Child Mission Delegation for OAuth 2.0", Work in Progress, Internet-Draft, draft-mcguinness-oauth- mission-child-delegation, 2026, . Acknowledgments This document is part of the Mission-Bound Authorization for OAuth 2.0 work and profiles Attenuating Agent Tokens for offline, holder- derived narrowing of Mission authority. Author's Address Karl McGuinness Independent Email: public@karlmcguinness.com