Mission Child Delegation 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 8 January 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") supports delegated Mission-bound tokens. It requires authority to narrow down the chain and records actor context. That is sufficient for many service-to-service and token-exchange cases. Agent harnesses introduce a related but distinct case: a parent agent starts a sub-agent or child worker with a durable task of its own. The child may have its own session, queue, tool handles, and runtime identity.¶

This document defines Child Missions for that case. A Child Mission is a Mission whose authority is a strict subset of a Parent Mission and whose lifecycle depends on the parent. It has its own Mission identifier and actor identity, but it cannot outlive, out-broaden, or escape the parent. The child is created through an explicit authorization step, not by inheriting a parent harness session.¶

2. Status: An OPTIONAL Extension

This document is OPTIONAL. It is a layered extension to the issuance profile, not a change to it. A deployment that implements [I-D.draft-mcguinness-oauth-mission] and never creates a Child Mission is fully conformant to that profile and is unaffected by this document: it accepts no parent or parent_token parameter, records no parent member, and applies no cascade revocation. The issuance profile's delegated-token mechanism is complete without Child Missions; the child machinery defined here is relevant only when a deployment creates Missions for sub-agents.¶

A Mission Issuer claims conformance to this document only when it creates Child Missions (Section 16); otherwise it remains a plain issuance-profile Mission Issuer. Nothing here places a new requirement back on the issuance profile.¶

3. Relationship to the Issuance Profile

This document depends normatively on the issuance profile and is not implementable alone. It reuses, without restating, that profile's Mission Intent, submission via PAR, authority derivation, approval event with its integrity anchors, Mission record, the mission claim, the subset rule, and the lifecycle and issuance gating. It uses the terms Agent (Client), Subject, Approver, Mission Issuer, Mission Intent, Authority Set, Mission, and derived token as defined there.¶

Cascade revocation (Section 10) additionally depends on the Mission Status and Lifecycle profile ([I-D.draft-mcguinness-oauth-mission-status]) and the Mission Expansion profile ([I-D.draft-mcguinness-oauth-mission-expansion]) where a deployment runs them, because those profiles define the suspended, completed, and superseded parent states the cascade rules react to. A deployment that runs neither still implements this profile: under the issuance profile's forward-compatibility rule, the cascade treats any non-active parent state as a terminal trigger.¶

A Child Mission is an ordinary Mission under the issuance profile with two additions: it is created under a parent grant rather than a first-party approval, and its record and tokens carry the parent member (Section 7). The child's own authority_hash remains the authority commitment for its tokens; the parent member is lineage and audit data only.¶

Where this document refers to "the issuance profile" without a section, it means [I-D.draft-mcguinness-oauth-mission] as a whole.¶

4. Scope

This document defines:¶

• Child Mission creation (Section 6);¶

• the parent lineage member (Section 7);¶

• strict-subset and expiry rules (Section 8);¶

• fan-out controls (Section 9);¶

• cascade revocation (Section 10);¶

• child evidence and audit requirements (Section 11); and¶

• conformance for a Child-Mission-capable Mission Issuer (Section 16).¶

This document does not replace ordinary delegated tokens under [I-D.draft-mcguinness-oauth-mission]. A deployment can use delegated tokens for short-lived delegation and Child Missions for durable sub-agent work that needs its own lifecycle handle.¶

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

This document uses the terms Mission, Mission Intent, Authority Set, Mission Issuer, Mission-bound token, and delegation from [I-D.draft-mcguinness-oauth-mission].¶

Parent Mission:

The active Mission from which a Child Mission derives its upper bound of authority.¶

Child Mission:

A Mission created for a child actor or sub-agent, with authority that is a strict subset of its Parent Mission and lifecycle that cascades from the parent.¶

Child actor:

The agent, workload, sub-agent, or component that receives authority under the Child Mission. The child actor is the OAuth client of the Child Mission (Section 6).¶

Delegation event:

The Mission Issuer event that creates the Child Mission and records the attenuation checks from parent to child.¶

A Child Mission is a new Mission with its own mission_id. It is not an attenuation child: the Mission Offline Attenuation profile ([I-D.draft-mcguinness-oauth-mission-attenuation]) defines a child as a narrower token minted under one Mission, not a new Mission.¶

6. Child Mission Creation

A Child Mission is created by submitting a Mission Intent through Pushed Authorization Requests [RFC9126] under the issuance profile, with child-specific binding to the parent. The request contains:¶

mission_intent:

REQUIRED. The proposed Child Mission Intent.¶

parent:

REQUIRED. The mission_id of the Parent Mission.¶

parent_token:

REQUIRED. A refresh token or other Mission-Issuer-accepted grant bound to the Parent Mission. The Mission Issuer resolves the Parent Mission from this grant. The parent parameter is a cross-check and audit value; it does not by itself authorize child creation.¶

child_actor:

REQUIRED. An object identifying the child actor that will hold or execute under the Child Mission, using the issuance profile's actor vocabulary ([I-D.draft-mcguinness-oauth-mission]):¶

sub:

REQUIRED. The child actor's identifier.¶

iss:

OPTIONAL. The issuer of sub when it is not the Mission Issuer's own namespace.¶

sub_profile:

RECOMMENDED. The actor-type classification (for example, ai_agent), matched against the parent entry's allowed_child_actors (Section 9).¶

A child_actor MAY be identified at instance granularity where the deployment authenticates client instances ([I-D.draft-mcguinness-oauth-client-instance-assertion]; for AI agents, [I-D.draft-mcguinness-oauth-ai-agent-instance]): sub carries the instance identifier and sub_profile the space-separated value list (for example, ai_agent client_instance). The child client-identity rule (Section 6.1), under which child credentials never transit the parent, composes naturally with instance-specific keys.¶

The Mission Issuer MUST resolve the parent from parent_token, verify that it matches parent, verify that the parent is active, and verify that the applicable parent Authority Set entry's delegation member carries a children object (Section 9) that permits child creation for the requested authority.¶

The Mission Issuer MUST reject a child creation request presented on a front channel with parent_token. The parent grant is presented only on the authenticated back channel.¶

 Parent agent / harness   Mission Issuer (AS)      Child actor
        |                        |                      |
        | 1. PAR: child Mission  | resolve parent       |
        |    Intent + grant ---->| verify active;       |
        |                        | verify children      |
        |<---- request_uri ------|                      |
        |                        |                      |
        | 2. approval or policy->| create child Mission |
        |    adjudication        | record parent member |
        |<-- grant reference ----|                      |
        |                        |                      |
        | 3. convey grant reference (deployment-defined) |
        | ---------------------------------------------->|
        |                        |                      |
        |                        | 4. token request     |
        |                        |    (child auth) <-----|
        |                        | derive child token    |
        |                        | ----- access token -->|

POST /par HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded

mission_intent=%7B...read-only%20Q3%20invoice%20extraction...%7D&
parent=msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-&
parent_token=<refresh%20token%20bound%20to%20the%20parent>&
child_actor=%7B%22sub%22%3A%22subagent-invoice-extractor%22%2C
  %22sub_profile%22%3A%22ai_agent%22%7D&
client_id=s6BhdRkqt3

{
  "iss": "https://as.example.com",
  "sub": "user_3p2q8mN1a0kV7tR",
  "aud": "https://erp.example.com",
  "client_id": "subagent-invoice-extractor",
  "iat": 1793607300,
  "exp": 1793607600,
  "jti": "at_5vB8nQ2xT7mK4rW1Zs9c",
  "authorization_details": [
    { "type": "mission_resource_access",
      "resource": "https://erp.example.com",
      "actions": ["invoices.read"],
      "constraints": {
        "resource_issued_after": "2026-07-01T00:00:00Z",
        "resource_issued_before": "2026-09-30T23:59:59Z"
      } }
  ],
  "cnf": { "jkt": "wZ5nT8qL2xV9rB4mC7sD1yF6jH3kP0aG5uE8oS2iN4w" },
  "mission": {
    "id": "msn_9KwP2rT6vX1nL4qY8sB3zC7mF5jD",
    "issuer": "https://as.example.com",
    "authority_hash":
      "sha-256:hQ2vJ4kE5pNQl3KvZ4mP5x0wRr6tY2nD9bM7sX1cF8g",
    "parent": {
      "id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-",
      "issuer": "https://as.example.com",
      "authority_hash":
        "sha-256:l3KvZ4mP5x0wQrR6tY2nD9bM7sX1cF8gH2vJ4kE5pNQ",
      "depth": 1,
      "delegation_id": "dlg_7pQ4m",
      "cascade_mode": "immediate"
    }
  }
}

{
  "error": "invalid_request",
  "mission_denial_reason": "not_strict_subset"
}

7. The Parent Mission Reference

A Child Mission carries a parent member in its Mission record and in the mission claim of tokens derived under the child:¶

parent:

REQUIRED for a Child Mission. An object containing:¶

id:

REQUIRED. The Parent Mission identifier.¶

issuer:

REQUIRED. The Parent Mission Issuer. The Child Mission's own issuer MUST equal this value (Section 6.2).¶

authority_hash:

REQUIRED. The Parent Mission authority commitment the child was derived under.¶

depth:

REQUIRED. An integer. The child-generation depth of this Child Mission: 1 for a child of a root Mission, incremented by one per generation. It lets issuers and consumers observe and bound generation depth without walking Mission Status.¶

delegation_id:

OPTIONAL. A Mission-Issuer-defined identifier for the child delegation event.¶

cascade_mode:

REQUIRED. The cascade mode from Section 10.¶

created_at:

OPTIONAL. The creation time of the Child Mission.¶

The parent member is lineage and audit data. It does not grant authority. The Child Mission's own authority_hash is the authority commitment for child tokens.¶

parent.depth counts upward from 1 across generations, while the parent entry's children.max_child_depth (Section 9) is a per-entry ceiling that decrements at each generation, so parent.depth never exceeds the depth the ancestor entries allowed.¶

Example:¶

{
  "mission": {
    "id": "msn_9KwP2rT6vX1nL4qY8sB3zC7mF5jD",
    "issuer": "https://as.example.com",
    "authority_hash":
      "sha-256:hQ2vJ4kE5pNQl3KvZ4mP5x0wRr6tY2nD9bM7sX1cF8g",
    "parent": {
      "id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-",
      "issuer": "https://as.example.com",
      "authority_hash":
        "sha-256:l3KvZ4mP5x0wQrR6tY2nD9bM7sX1cF8gH2vJ4kE5pNQ",
      "depth": 1,
      "delegation_id": "dlg_7pQ4m",
      "cascade_mode": "immediate",
      "created_at": "2026-11-02T08:14:00Z"
    }
  }
}

8. Attenuation Rules

A Child Mission MUST be bounded by the Parent Mission:¶

• every child Authority Set entry MUST be a subset of a parent entry under the subset rule of [I-D.draft-mcguinness-oauth-mission];¶

• the child MUST NOT include a resource, action, constraint relaxation, or delegation right not present in the parent;¶

• the child's expires_at MUST NOT be later than the parent's expires_at (so it transitively caps every child-derived token's exp, per [I-D.draft-mcguinness-oauth-mission]);¶

• the child MUST be created only where the applicable parent entry's delegation member carries a children object (Section 9), and a child entry's delegation policy MUST NOT be broader than the parent entry's: its max_depth MUST be no greater and its allowed_delegates MUST be no wider, per the subset rule of [I-D.draft-mcguinness-oauth-mission];¶

• non-delegable parent entries MUST NOT appear in child authority; and¶

• child authority MUST be bound to the child actor identified in the request.¶

The Mission Issuer MUST compute the Child Mission's authority_hash over the child Authority Set, not over the parent Authority Set. A Resource Server enforces child tokens exactly as Mission-bound tokens: the child authority_hash is the immediate authority commitment.¶

Child Mission tokens MUST be sender-constrained to the child actor's own key, matching the core's delegated-token posture ([I-D.draft-mcguinness-oauth-mission]).¶

9. Fan-Out Controls

This profile defines the on-switch for child creation as a member of the core's per-entry delegation object. The issuance profile lets a companion profile define additional delegation members that are policy, not authority, are never broadened downstream, and are carried unchanged when not understood ([I-D.draft-mcguinness-oauth-mission]); this profile's children member is such a member.¶

children:

OPTIONAL. An object. Its PRESENCE on a parent Authority Set entry's delegation member is what permits Child Mission creation for that entry; an entry whose delegation carries no children permits no child (Section 6.7). Its members are the fan-out controls, each applied per entry, per parent Mission:¶

max_children:

OPTIONAL. A positive integer. The maximum number of concurrently non-terminal Child Missions drawing on this entry, per parent Mission.¶

allowed_child_actors:

OPTIONAL. An array of matcher objects of the same form as the core's allowed_delegates ([I-D.draft-mcguinness-oauth-mission]), constraining which actors or actor classes may receive a Child Mission from this entry. Matchers are evaluated under the core's allowed_delegates matching rules, including the rule that a { "sub_profile": ... } matcher is satisfied when its value is among the actor's space-separated sub_profile values.¶

max_child_depth:

OPTIONAL. A positive integer, default 1. The maximum child-generation depth at which this entry may be included. A Child Mission's own entries carry children only with max_child_depth reduced by one, and an entry at depth equal to the limit carries no children, ending the lineage.¶

child_creation_policy:

OPTIONAL. A policy reference evaluated before each child creation.¶

Example parent Authority Set entry whose delegation carries children, so the entry permits Child Missions to depth 2, at most 5 concurrently, for ai_agent actors:¶

{
  "type": "mission_resource_access",
  "resource": "https://erp.example.com",
  "actions": ["invoices.read"],
  "delegation": {
    "max_depth": 2,
    "allowed_delegates": [{ "sub_profile": "ai_agent" }],
    "children": {
      "max_children": 5,
      "max_child_depth": 2,
      "allowed_child_actors": [{ "sub_profile": "ai_agent" }]
    }
  }
}

Depth limits alone do not control breadth: a Parent Mission MAY permit many Child Missions at the same depth unless max_children or child_creation_policy bounds fan-out. A Child-Mission-capable Mission Issuer MUST enforce every children control an entry carries. If an entry's children carries a control the Mission Issuer cannot enforce, it MUST refuse child creation for that entry.¶

10. Cascade Revocation

A Child Mission depends on the Parent Mission. The cascade trigger is any Parent Mission transition to a non-active state. This profile distinguishes terminal triggers from the one reversible trigger:¶

• Terminal triggers: parent revoked or expired ([I-D.draft-mcguinness-oauth-mission]), completed ([I-D.draft-mcguinness-oauth-mission-status]), superseded ([I-D.draft-mcguinness-oauth-mission-expansion]), or cascaded (Section 10.1, when the parent is itself a Child Mission that was cascade-terminated). On a terminal trigger the Mission Issuer MUST stop new derivation under dependent Child Missions and, under immediate cascade, transition each dependent child to the terminal cascaded state (Section 10.1). Cascade is transitive: the children of a cascaded parent cascade in turn under the same mode, in generation order, so a terminal trigger reaches every descendant.¶

• Reversible trigger: parent suspended ([I-D.draft-mcguinness-oauth-mission-status]). The Mission Issuer MUST stop new derivation under dependent Child Missions while the parent is suspended, but MUST NOT drive them to a terminal state. When the parent is resumed to active, dependent children return to their pre-suspension state and may derive again. Reporting of a dependent child while its parent is suspended is governed by Section 10.1.¶

A superseded parent does not transfer its Child Missions to the successor. The successor Mission carries a freshly derived Authority Set that does not inherit the predecessor's authority by reference ([I-D.draft-mcguinness-oauth-mission-expansion]), so a Child Mission that was a strict subset of the predecessor is not guaranteed to be a subset of the successor. The Mission Issuer therefore MUST treat superseded as a terminal cascade trigger and MUST NOT silently re-bind children to the successor. Continuing child work under the successor requires an explicit new Child Mission creation (Section 6) under a successor grant, which re-runs strict-subset validation (Section 8.1) against the successor's Authority Set.¶

Cascade under this profile is issuer-committed. The Mission Issuer MUST implement the immediate cascade mode and record the mode on the Child Mission:¶

immediate:

On a terminal trigger the Child Mission transitions to the cascaded state when the parent transition commits. On the reversible trigger the child is held non-active while the parent is suspended and restored to its prior state on parent resume.¶

Two consumer-verified cascade modes, bounded_staleness and status_required, which trade issuer-committed transitions for consumer-side parent-state checks, are experimental and defined in Appendix A. A cascade mode MUST NOT allow a Child Mission to continue deriving new credentials after the parent is known to be non-active.¶

The cascade behavior by trigger:¶

11. Child Evidence

The Mission Issuer MUST record a child delegation evidence record with:¶

• parent Mission identifier, issuer, and authority hash;¶

• child Mission identifier, issuer, and authority hash;¶

• child actor;¶

• requested and approved child authority;¶

• attenuation checks performed;¶

• fan-out counters or policy result;¶

• cascade mode;¶

• approval or policy basis; and¶

• creation time.¶

This evidence is audit material and does not grant authority.¶

{
  "evidence_id": "chd_8K2nP4qV",
  "parent": {
    "id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-",
    "issuer": "https://as.example.com",
    "authority_hash":
      "sha-256:l3KvZ4mP5x0wQrR6tY2nD9bM7sX1cF8gH2vJ4kE5pNQ"
  },
  "child": {
    "id": "msn_9KwP2rT6vX1nL4qY8sB3zC7mF5jD",
    "issuer": "https://as.example.com",
    "authority_hash":
      "sha-256:hQ2vJ4kE5pNQl3KvZ4mP5x0wRr6tY2nD9bM7sX1cF8g"
  },
  "child_actor": {
    "sub": "subagent-invoice-extractor",
    "sub_profile": "ai_agent"
  },
  "attenuation": {
    "result": "strict_subset"
  },
  "fanout": {
    "active_children": 2,
    "max_children": 5
  },
  "cascade_mode": "immediate",
  "decision": "created",
  "created_at": "2026-11-02T08:14:00Z"
}

12. Relationship to Expansion

Mission Expansion [I-D.draft-mcguinness-oauth-mission-expansion] creates a successor Mission that replaces a predecessor for a broader task. Child Mission Delegation creates a dependent Mission for a child actor with narrower authority. Expansion widens by fresh approval; Child Missions attenuate within parent authority. The two MUST NOT be conflated.¶

A Child Mission MAY be expanded, but only within the parent's authority: a successor Child Mission MUST remain a strict subset of the Parent Mission's Authority Set (Section 8.1) and keeps the same parent. Expanding a Child Mission beyond its parent requires expanding the parent first. Re-creation of children after a parent is expanded, and re-parenting a Child Mission to a different parent, are deferred work.¶

13. Composition with Offline Attenuation

A Child Mission's tokens MAY serve as attenuation roots under the Mission Offline Attenuation profile ([I-D.draft-mcguinness-oauth-mission-attenuation]). The attenuation chain's kill switch checks the Child Mission's state, and a parent stop reaches the chain through cascade (Section 10): when the parent terminates, the Child Mission becomes non-active and the chain rooted on its tokens stops at the next state check.¶

14. Relationship to Harnesses

A Mission-aware harness [I-D.draft-mcguinness-mission-harness] MUST NOT treat a sub-agent handle as authority. When durable sub-agent work requires a separate authority handle, the harness can request a Child Mission under this profile.¶

15. Authorization Server Metadata

A Mission Issuer that supports this profile SHOULD advertise it in its authorization server metadata [RFC8414] so a parent agent can discover child-delegation support before attempting child creation:¶

mission_child_delegation_supported:

OPTIONAL boolean. When true, the Mission Issuer accepts the child creation request of Section 6 and enforces the controls of this profile. A client MUST NOT infer the fan-out controls (Section 9) a deployment enforces from this member alone; an unenforceable requested control is refused at creation (Section 6.7).¶

16. Conformance

A conforming Child-Mission-capable Mission Issuer MUST:¶

• create Child Missions only through explicit authenticated requests;¶

• resolve the Parent Mission from a parent grant, not from the caller-supplied parent identifier alone;¶

• enforce strict-subset authority and expiry;¶

• enforce delegation and fan-out controls;¶

• record the parent member on child Mission records and tokens;¶

• implement cascade revocation; and¶

• record child delegation evidence.¶

A Resource Server does not need to understand this profile to enforce child tokens as Mission-bound tokens. A Resource Server MUST NOT apply lineage-sensitive policy from the parent member unless it implements the semantics of the parent-member (Section 7) and cascade (Section 10) sections.¶

17. Security Considerations

18. Privacy Considerations

The parent member exposes Mission lineage and can correlate child and parent activity. Deployments SHOULD minimize cross-audience disclosure of parent lineage when it is not needed for enforcement, and SHOULD restrict child delegation evidence to authorized audit consumers.¶

19. IANA Considerations

This document registers three parameters in the "OAuth Parameters" registry. For each: Parameter Usage Location authorization request; Change Controller IETF; Reference this document, Section 6.¶

• parent¶

• parent_token¶

• child_actor¶

As with mission_intent in the issuance profile, PAR [RFC9126] carries authorization-request parameters without a distinct usage location, so the pushed submission of these parameters needs no separate registration. parent_token carries a refresh token or other parent grant and MUST be submitted only through PAR on the authenticated back channel, never on a front-channel authorization request (Section 6).¶

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

• mission_child_delegation_supported¶

Consistent with the issuance profile, which registers the mission claim as an open object with no registry of its members, this document defines the parent member of the mission claim (Section 7) without a separate claim registration: it is a member defined by this profile, carried inside the already-registered mission claim.¶

This document defines one closed set of symbolic codes: the child creation denial reasons (Section 6.7). Like the issuance profile's restraint with mission members, these are documented in this specification rather than placed in a new IANA registry: they ride in the mission_denial_reason member of the OAuth error response body (Section 6.7) and in evidence, inside existing OAuth error responses rather than on a new wire surface, and the closed set is small and fully specified here. Should interoperable extension prove necessary, a future revision can create a "Mission Child Delegation Denial Reason" registry with a Specification Required [RFC8126] policy; this document does not create it.¶

20. References

Appendix A. Experimental Consumer-Verified Cascade Modes

This appendix is experimental: adopt it for evaluation, not as a stable interface. It defines two cascade modes that trade the issuer-committed transition of immediate (Section 10) for consumer-side parent-state checks, for deployments where the Mission Issuer cannot commit child transitions synchronously with the parent's. Each shifts a per-reliance obligation onto every consumer of child tokens, which is why they are not part of the base profile.¶

bounded_staleness:

The Child Mission is treated as non-active no later than the cascade staleness bound, measured from the consumer's last confirmed-active observation of the parent, aligned with the Status profile's freshness model ([I-D.draft-mcguinness-oauth-mission-status]). That bound is the deployment's mission_max_stale_seconds ([I-D.draft-mcguinness-oauth-mission-status]) unless the deployment publishes a different bound for child cascade. Under this mode a non-terminal child counts against max_children (Section 9.1) until the cascade window has closed or the child is otherwise confirmed non-active.¶

status_required:

Consumers MUST check parent state, per reliance decision and within the deployment's declared freshness window ([I-D.draft-mcguinness-oauth-mission-status]), before accepting child Mission authority. The Mission Issuer MUST select this mode only where every audience of child tokens is known, by registration or deployment policy, to implement this profile's parent-state check; otherwise the Mission Issuer MUST compensate with short child-token lifetimes or introspection-required paths.¶

The cascade behavior by trigger and mode:¶

A consumer that cannot obtain parent state MUST obey the mode: for status_required, it MUST refuse; for bounded_staleness, it MUST refuse after the bound. For derivation under these modes, the Mission Issuer MAY rely on a prior confirmed-active parent observation within the mode's freshness rules where it cannot observe the parent synchronously; a Child Mission MUST NOT derive after the parent is known to be non-active. The immediate rules of Section 10 and Section 10.1 otherwise apply unchanged.¶

Acknowledgments

This document is part of the Mission-Bound Authorization for OAuth 2.0 set and defines explicit child authority for sub-agent work.¶

Author's Address