Mission Offline Attenuation for OAuth 2.0

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 22 February 2027.¶

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

Mission-Bound Authorization for OAuth 2.0 [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 ([I-D.draft-mcguinness-oauth-mission-cross-domain]). 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. At machine speed that dependency is the bottleneck: a swarm forking sub-agents per subtask cannot afford an issuer round trip per fork, and localized, offline, cryptographically verifiable narrowing is the shape that load requires from day one. This profile is the family's OAuth-lane answer to it; its Experimental status reflects the maturity of the attenuation substrate it profiles, not a judgment that the capability is optional. The stable path meanwhile is issuer-mediated child delegation ([I-D.draft-mcguinness-oauth-mission-child-delegation]). The saving is amortization, not elimination: because a root's lifetime is kept short (Section 14), the holder returns to the issuer once per subtree per root-lifetime window to mint the root, and every narrowing within that window is then offline. The issuer leaves the per-fork hot path; it is not removed from the deployment.¶

This document removes the issuer from that per-fork path for narrowing within a root's lifetime. 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 8, Section 9):¶

• the child carries the parent chain, with audience and expiry bounded per hop, 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 Experimental Extension

This document is optional and experimental: adopt it for evaluation, not as a stable interface. 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 described in Section 1.¶

A deployment claims this profile only when it issues or accepts Mission-bound attenuation-substrate tokens. Because the Mission kill switch reaches offline-minted tokens only through per-presentation runtime state checks (Section 9), this profile is available only to deployments running the runtime enforcement profile ([I-D.draft-mcguinness-mission-runtime]); on such a deployment the offline mint saves issuer round-trips, not enforcement checks. Weigh that saving against the chain-verification surface before adopting.¶

This profile also depends normatively on the Attenuating Agent Tokens substrate ([I-D.draft-niyikiza-oauth-attenuating-agent-tokens]), an in-progress Internet-Draft whose details may change; an implementation tracks that work as it evolves. Authorization-Server-mediated delegation, which depends only on ratified OAuth, is the stable path; a deployment uses offline attenuation where its substrate dependency is acceptable and treats the interface as tracking the substrate.¶

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:¶

• from the issuance profile: the Mission, the mission claim, the Authority Set, the subset rule, and the lifecycle; and¶

• from the attenuation substrate: the 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.¶

Attenuating Holder:

The holder of a Mission-bound attenuation token, in its role of minting narrower children offline under this profile.¶

In this profile a child is a token: a narrower token minted under one Mission, not a new Mission. The Mission Child Delegation profile ([I-D.draft-mcguinness-oauth-mission-child-delegation]) defines Child Missions, which are new Missions with their own mission_id; the two are distinct.¶

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 by the mapping of Section 5.1. The root carries the mission claim (id, issuer, authority_hash) and the holder's confirmation key, as both profiles require.¶

The root's iss MUST equal its mission.issuer: only the Mission Issuer mints a Mission-bound root, and it signs the root with its own keys. It MUST carry aud per the issuance profile's token rules ([I-D.draft-mcguinness-oauth-mission]), identifying the Resource Server(s) authorized to consume its authority.¶

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. Requesting a Root and Discovery

A Mission Issuer that supports this profile advertises it in its authorization server metadata [RFC8414]:¶

mission_attenuation_supported:

OPTIONAL boolean. When true, the Mission Issuer issues Mission-bound attenuation roots (Section 5) and derives their authority from the Mission's Authority Set (Section 5.1).¶

A client requests a Mission-bound attenuation root at the token endpoint, on any grant the issuance profile uses to issue a Mission-bound token (for example, the Mission's refresh_token grant). The request combines a selector, a confirmation key, and an optional narrowing detail, each with a distinct role:¶

mission_attenuation_root:

OPTIONAL boolean. When true on a Mission-bound token request it selects root issuance: the Mission Issuer issues the token as a Mission-bound attenuation root (Section 5) rather than an ordinary mission_resource_access token. A request that omits it or sets it false is an ordinary Mission-bound token request. The attenuation substrate defines no OAuth Token Exchange [RFC8693] requested-token-type for asking for a root, so this boolean, not a token-type identifier, is what asks for one.¶

The client MUST carry the holder's confirmation key, which binds the root to the holder as both profiles require ([I-D.draft-niyikiza-oauth-attenuating-agent-tokens], Section 5).¶

The client MAY carry an attenuating_agent_token authorization detail [RFC9396] to request a root narrower than the full mapped Authority Set: its tools and argument constraints are the requested subset.¶

When the detail is present, the Mission Issuer MUST validate it against the root mapping (Section 5.1). It MUST reject, with invalid_request, any tool or argument constraint not within the mapped Authority Set. When the detail is absent, the Mission Issuer derives the full mapped root from the Mission's delegable Authority Set entries (Section 5.1). A client-requested root is therefore always at most the mapped Authority Set, never broader.¶

7. Offline Attenuation

The holder of a Mission-bound attenuation token mints a narrower child offline, by the attenuation substrate's derivation. The holder:¶

• 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.¶

par_hash commits to the exact parent token bytes, per the attenuation substrate's cryptographic linkage rule ([I-D.draft-niyikiza-oauth-attenuating-agent-tokens]): its value is the base64url encoding, without padding, of the SHA-256 digest of the parent token's JWS Signing Input.¶

The child's aud MUST equal its parent's aud or be a subset of it. For this comparison the aud is treated as a set of audience values: a string aud is the one-element set of that string, and an array aud is the set of its members. Values are compared as case-sensitive, byte-exact strings, with no URI normalization; a single-string aud and a one-element array carrying the same value are therefore equivalent.¶

The child's exp MUST NOT exceed its parent's exp. Because the Mission Issuer caps the root's exp at the Mission's expires_at ([I-D.draft-mcguinness-oauth-mission]), the per-hop exp rule bounds the whole chain transitively: no descendant outlives the root, hence none outlives the Mission.¶

The mission claim rides the chain unchanged: every token in the chain carries the same id, issuer, 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]).¶

8. Verifying the Mission Binding

A consumer verifies the chain linkage, capability monotonicity, depth, and proof-of-possession under the attenuation substrate ([I-D.draft-niyikiza-oauth-attenuating-agent-tokens]). This profile adds checks on the mission claim, which the substrate does not define because it has no concept of the Mission binding. In addition to the substrate's chain verification, a consumer MUST:¶

• reject the chain unless every token in it carries a mission claim and every claim carries the same id, issuer, and authority_hash as the root. A child cannot re-bind to a different Mission or change the lineage anchor; a link whose mission claim differs from the root's, or that omits it, MUST cause the whole chain to be refused, not treated as a narrower grant; and¶

• reject the chain unless the root's iss equals its mission.issuer, and verify the root's signature under the Mission Issuer's published keys (those of that iss). A root whose iss is not its mission.issuer, or whose signature does not verify under the Mission Issuer's keys, MUST cause the whole chain to be refused: only the Mission Issuer mints a Mission-bound root; and¶

• treat a chain whose root carries no mission claim as outside this profile: it is an ordinary attenuation chain with no Mission binding, and a consumer MUST NOT apply the Mission-state kill switch (Section 9) to it or report it as Mission-bound;¶

• reject the chain if any child's aud is not equal to, or a subset of, its parent's aud (Section 7); and¶

• reject the chain if any child's exp exceeds its parent's exp (Section 7).¶

These checks fail safe: a chain that does not present a single, unchanged Mission binding, an audience within its parent's, and an expiry within its parent's is refused, not evaluated against a guessed Mission.¶

Verification cost scales with the chain: a consumer performs one signature verification per link, the proof-of-possession check, and the Mission-state check (Section 9) on every presentation. A consumer SHOULD bound the chain length it accepts, independently of the del_max_depth the chain carries, so an adversarially deep chain is refused rather than verified.¶

9. 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-mission-runtime]). On every presentation of a token in the chain, regardless of action class, in addition to verifying the attenuation chain and the proof-of-possession, the consumer:¶

1. MUST establish that the chain's Mission is active, within the deployment's declared freshness bound, from a Mission state source; and¶

2. MUST refuse if it cannot establish the Mission as active within the bound, including when the state source is unreachable, as the runtime profile fails closed on unestablished state ([I-D.draft-mcguinness-mission-runtime]).¶

Where a deployment also runs the Mission Containment profile ([I-D.draft-mcguinness-oauth-mission-containment]), active is not the same question as uncontained: a contained Mission stays active, so this check alone does not stop a root minted before the contain transition, or the offline children it keeps minting under it. Containment gates derivation at the issuer and propagates to Child Missions; it defines no consumer-side check that this profile's per-presentation state evaluation picks up, so an attenuation root already in a holder's possession keeps minting against the Mission's pre-containment authority until the root's own exp or del_max_depth ends it, or the Mission itself is revoked or expires (Section 14).¶

A cached chain does not bypass this: a chain held in a harness cache is still re-checked against current Mission state on every presentation, since the cache is never evidence of continuing authority ([I-D.draft-mcguinness-mission-harness]). 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 a capability for deployments running the runtime enforcement profile ([I-D.draft-mcguinness-mission-runtime]); it is not available to a deployment that relies on token lifetime alone.¶

10. Relationship to Other Delegation

Offline attenuation sits beside two other narrowing mechanisms: Authorization-Server-mediated delegation (the issuance profile's act chain and Token Exchange), which narrows at the issuer, online, so the issuer observes each delegation; and Mission Child Delegation ([I-D.draft-mcguinness-oauth-mission-child-delegation]), which creates a separate Child Mission with its own mission_id, lifecycle, and approval. The Mission Child Delegation profile sets out how the three differ. Offline attenuation creates no new Mission: every child rides the same mission claim and dies with the same Mission. Use offline attenuation when a sub-agent needs a narrower token under the same Mission, fast, at fan-out scale; use a Child Mission when it needs its own durable, separately revocable Mission.¶

11. Actor Attribution on the Chain

The chain identifies holders by key possession: each token binds its holder through cnf, and possession is proven at use. This document defines no actor-identity member on chain tokens. A profile that adds named-actor attribution to chain artifacts is bound by the following model; the cross-organizational delegation companion ([I-D.draft-mcguinness-oauth-mission-cross-org-delegation]) defines the member and its verification semantics.¶

Each artifact names only its own hop's actor. The complete actor history is reconstructed from the validated root-to-leaf chain; it is never duplicated as a nested history inside each artifact, and a consumer MUST reject a chain that presents conflicting or duplicated actor representations. A materialized nested act projection ([RFC8693], shaped per the Actor Profile, [I-D.draft-mcguinness-oauth-actor-profile]) is constructed from the validated chain at a consuming boundary, a PDP, an introspection responder, or a destination Authorization Server; it is not carried on the artifacts.¶

The root actor is asserted by the Mission Issuer and bound to the root presenter key: the root names the originally approved agent, so the approved-agent identity travels with the chain instead of resting on a Mission Record the verifier may not hold. A parent signature on a later hop proves only that the parent delegated to the child key; it does not authenticate the identity values the parent asserts. A named actor on a holder-created hop therefore counts only when the issuer-qualified actor identifier is independently bound to that hop's cnf key through a validated workload credential or attestation. Absent that binding the hop is key-only: its asserted identity is informational provenance at most and MUST NOT satisfy an eligibility matcher (the issuance profile's allowed_delegates or a sub_profile selector, [I-D.draft-mcguinness-oauth-mission]) or otherwise influence authorization; where policy requires a named actor and the binding is absent or invalid, verification fails closed.¶

12. 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 (illustrative; this Mission's Authority Set extends the single-domain walkthrough's, its write entry also carrying a delegation member with max_depth 2, so both mapped entries are delegable to depth 2 under the root-shaping rules of Section 5.1 and its authority_hash differs from that example's). Decoded root token:¶

{
  "iss": "https://as.example.com",
  "sub": "user_3p2q8mN1a0kV7tR",
  "client_id": "s6BhdRkqt3",
  "aud": "https://erp.example.com",
  "iat": 1793606400,
  "exp": 1793606700,
  "jti": "aat_root_7M2R4kP9sT1x",
  "cnf": { "jkt": "0ZcOCORZNYy-DWpqq30jZyJGHTN0d2HglBV3uiguA4I" },
  "del_depth": 0,
  "del_max_depth": 2,
  "mission": {
    "id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-",
    "issuer": "https://as.example.com",
    "authority_hash":
      "sha-256:X1cF8gH2vJ4kE5pNQl3KvZ4mP5x0wQrR6tY2nD9bM7s"
  },
  "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 root's erp.invoices.read and erp.journal-entries.write tools map to the invoices.read and journal-entries.write actions on https://erp.example.com, and the amount_usd argument maps to the Mission Common Constraint max_amount (Section 5.1); its aud names that Resource Server.¶

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 (the iss value is one line, wrapped here for display):¶

{
  "iss":
    "urn:ietf:params:oauth:jwk-thumbprint:sha-256:0ZcOCORZNYy-
     DWpqq30jZyJGHTN0d2HglBV3uiguA4I",
  "sub": "user_3p2q8mN1a0kV7tR",
  "aud": "https://erp.example.com",
  "iat": 1793606430,
  "exp": 1793606640,
  "jti": "aat_child_2Yt7Qv9Lq",
  "cnf": { "jkt": "kP3xR9sQ7nM2vL4tY6bD1eF8jC5wH0pV2nR3kQ4mZ7t" },
  "par_hash": "9XbVt2nD9bM7sX1cF8gH2vJ4kE5pNQl3KvZ4mP5x0wQ",
  "del_depth": 1,
  "del_max_depth": 2,
  "mission": {
    "id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-",
    "issuer": "https://as.example.com",
    "authority_hash":
      "sha-256:X1cF8gH2vJ4kE5pNQl3KvZ4mP5x0wQrR6tY2nD9bM7s"
  },
  "authorization_details": [
    { "type": "attenuating_agent_token",
      "tools": {
        "erp.invoices.read": {
          "period":
            { "constraint_type": "exact", "value": "2026-Q3" } } } }
  ]
}

The mission claim is unchanged, the child's aud equals the root's, its exp (1793606640) ends before the root's (1793606700), within the per-hop bound, the write tool is gone, and the read constraint is unchanged (a permitted narrowing). The child's cnf.jkt is the JWK thumbprint [RFC7638] of the delegate extractor's own key, which its per-invocation proof-of-possession must match. The child's par_hash derives as Section 7 states, the base64url SHA-256 digest, without padding, of the root token's JWS Signing Input; the value shown is illustrative, since the example gives the root's decoded claims rather than its serialized bytes. 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, capability monotonicity, and the aud and exp bounds), verifies the proof-of-possession under the child's cnf key, and, because this is Mission-bound, checks on this presentation that msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9- is active within the deployment's declared freshness bound (Section 9). 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 presentation 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.¶

For contrast, suppose the extractor presents a chain whose child carries "exp": 1793606760, sixty seconds past the root's. The per-hop bound check (Section 8) fails before any tool or Mission-state evaluation: a child that outlives its parent breaks the chain's transitive expiry bound, so the gateway refuses the whole chain. A chain whose child carried a mission claim differing from the root's is refused the same way, as a re-bound chain, not read as a narrower grant.¶

13. Conformance

A Mission Issuer conforming to this profile MUST bound a Mission-bound attenuation root by the Mission's Authority Set (Section 5.1) and carry the mission claim, the confirmation key, and aud on it.¶

An Attenuating Holder conforming to this profile:¶

• MUST carry the mission claim unchanged into every child it mints;¶

• MUST only narrow authority and never broaden it;¶

• MUST keep each child's aud within its parent's and its exp within its parent's; and¶

• MUST increment the depth member the attenuation substrate defines (del_depth, [I-D.draft-niyikiza-oauth-attenuating-agent-tokens]).¶

A consumer conforming to this profile:¶

• MUST verify the attenuation chain and proof-of-possession per the attenuation substrate;¶

• MUST verify that the mission claim is unchanged across the chain and that each child's aud and exp are within its parent's (Section 8); and¶

• MUST enforce current Mission state per Section 9.¶

A deployment MUST NOT claim this profile on a path that does not enforce Mission state.¶

14. 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 9), 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. The cnf key of an attenuation root is nonetheless two things at once: the presentation key for one token and the offline minting key for its whole subtree, and a key whose theft mints credentials warrants a higher custody class than one whose theft replays a credential. A deployment SHOULD hold attenuation-root keys under the mediating component's custody (the runtime profile's mediated custody, [I-D.draft-mcguinness-mission-runtime]), hardware-backed where available, rather than loose in the agent process.¶

• Depth and fan-out. del_max_depth bounds chain depth; a deployment SHOULD set it. Because offline minting is unobserved by the issuer, breadth is bounded at consumption, not at issuance: PEPs SHOULD meter the distinct leaf jti and cnf values they see per Mission and alert or refuse beyond a deployment-set bound. Issuers SHOULD keep root lifetimes short. This metering bound is per-PEP: each enforcement point counts only the leaves it sees, so the effective breadth limit is per-PEP unless the deployment aggregates leaf counters across its PEPs into a shared count. An issuer-side breadth control like Child Delegation's max_children ([I-D.draft-mcguinness-oauth-mission-child-delegation]) is structurally unavailable here, because the issuer never observes an offline mint and so cannot count children at issuance.¶

• Per-branch revocation. The only kill switch is whole-Mission: revoking the Mission stops the entire chain, but this profile provides no way to revoke a single branch or leaf without revoking the Mission. Per-branch revocation is deferred work. As a deployment mitigation, a PEP MAY maintain a denylist keyed by leaf jti or cnf to refuse specific leaves.¶

• Containment does not reach an already-minted root. The Mission Containment profile narrows a live Mission's effective authority while keeping the Mission active ([I-D.draft-mcguinness-oauth-mission-containment]). Because the kill switch of Section 9 checks only active, a root minted before the contain transition, and the subtree of offline children under it, keep minting against the pre-containment authority for the root's own lifetime: containment narrows what a fresh root can carry, but it is not a way to stop an outstanding one early. A deployment that relies on containment to bound offline attenuation SHOULD keep root lifetimes short and del_max_depth conservative for this reason, and MAY apply the per-branch denylist mitigation above to a specific root or subtree it learns is contained.¶

• 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-mission-runtime]) is the audit record for offline-attenuated actions. PEP evidence for an action under an attenuated token SHOULD carry the chain linkage, the leaf's jti, its del_depth, and its par_hash, so offline derivations are reconstructable in audit.¶

15. Privacy Considerations

The mission claim (id, issuer, authority_hash) rides every token in an attenuation chain unchanged (Section 7), so every consumer of any child sees the same durable Mission correlator and lineage anchor. The chain is therefore a correlation surface across the sub-agents and resources it reaches: two consumers that compare the Mission identifiers they were shown can tell the tokens belong to one Mission. This profile does not narrow that correlation; the single-canonical-mission cross-audience linkability the issuance profile acknowledges ([I-D.draft-mcguinness-oauth-mission]) applies to offline children as well, and unlinkable or per-audience presentation of Mission-bound authority is out of scope and deferred.¶

Because the child carries the parent chain, every consumer of a leaf sees each ancestor's full authority, not only the leaf's narrowed slice. A leaf presented to one Resource Server therefore discloses the broader authority of every token above it. To minimize that disclosure, a deployment SHOULD mint narrowly scoped, per-subtree roots rather than one broad root fanned out across unrelated subtrees, so a leaf reveals only the ancestors of its own subtree.¶

Offline minting is unobserved by the Mission Issuer, so which children were minted and to whom is visible only at the consuming enforcement points, not in the issuer's records. A deployment SHOULD treat the runtime enforcement evidence those points produce ([I-D.draft-mcguinness-mission-runtime]) as the privacy-relevant record of offline derivations and protect it accordingly.¶

16. IANA Considerations

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 or registry. It registers one metadata member and one request parameter.¶

This document registers one member in the existing "OAuth Authorization Server Metadata" registry [RFC8414]: Change Controller IETF; Reference this document, Section 6.¶

• mission_attenuation_supported¶

This document registers one parameter in the "OAuth Parameters" registry: Parameter Usage Location token request; Change Controller IETF; Reference this document, Section 6.¶

• mission_attenuation_root¶

17. References

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