Child Mission 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 26 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

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 15); 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 strict-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 15).¶

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

Delegation event:

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

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

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 parent Authority Set permits child delegation 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)
        |                             |
        | 1. PAR: child Mission       | resolve parent
        |    Intent + parent grant -->| verify active;
        |                             | verify delegation
        |<------- request_uri --------|
        |                             |
        | 2. approval or policy ----->| create child Mission
        |    adjudication             | record parent member
        |<---------- code ------------|
        |                             |
        | 3. token request ---------->| derive child token
        |<------ access token --------|

7. The parent Member

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

origin:

REQUIRED. The Parent Mission Issuer.¶

authority_hash:

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

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

Example:¶

{
  "mission": {
    "id": "msn_child_2Yt7Qv9LqMv4z7sA2bN1k0",
    "origin": "https://as.example.com",
    "authority_hash":
      "sha-256:Td9bM7sX1cF8gH2vJ4kE5pNQl3KvZ4mP5x0wQrR6tY2",
    "parent": {
      "id": "msn_parent_8RfX2Lqv9TqMv4z7sA2bN1k0",
      "origin": "https://as.example.com",
      "authority_hash":
        "sha-256:l3KvZ4mP5x0wQrR6tY2nD9bM7sX1cF8gH2vJ4kE5pNQ",
      "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 mission_expiry MUST NOT be later than the parent's mission_expiry (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 policy permits child delegation (Section 4.2), and any delegation policy on a child entry MUST be strictly narrower than the parent entry's;¶

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

9. Fan-Out Controls

Depth limits alone do not control breadth. A Parent Mission MAY permit many Child Missions at the same depth unless policy limits fan-out.¶

A Child-Mission-capable Mission Issuer MUST support at least one fan-out control:¶

max_child_missions:

Maximum number of Child Missions that can be active under a Parent Mission or Authority Set entry.¶

allowed_child_actors:

A constraint on which actors or actor classes may receive Child Missions.¶

child_creation_policy:

A policy reference evaluated before each child creation.¶

If a parent entry carries a fan-out 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]), or superseded ([I-D.draft-mcguinness-oauth-mission-expansion]). 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).¶

• 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. While the parent is suspended, a dependent child is reported as non-active with a parent projection (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.¶

The Mission Issuer MUST implement one of these cascade modes and record it 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.¶

bounded_staleness:

The Child Mission is treated as non-active no later than the cascade staleness bound. 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.¶

status_required:

Consumers MUST check parent state through Mission Status before accepting child Mission authority.¶

The cascade mode MUST NOT allow a Child Mission to continue deriving new credentials after the parent is known to be non-active.¶

11. Child Evidence

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

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

• child Mission identifier, origin, 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_parent_8RfX2Lqv9TqMv4z7sA2bN1k0",
    "origin": "https://as.example.com",
    "authority_hash":
      "sha-256:l3KvZ4mP5x0wQrR6tY2nD9bM7sX1cF8gH2vJ4kE5pNQ"
  },
  "child": {
    "id": "msn_child_2Yt7Qv9LqMv4z7sA2bN1k0",
    "origin": "https://as.example.com",
    "authority_hash":
      "sha-256:Td9bM7sX1cF8gH2vJ4kE5pNQl3KvZ4mP5x0wQrR6tY2"
  },
  "child_actor": {
    "sub": "subagent-contract-reviewer",
    "type": "ai_agent"
  },
  "attenuation": {
    "result": "strict_subset"
  },
  "fanout": {
    "active_children": 2,
    "max_child_missions": 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.¶

13. Relationship to Harnesses

A Mission-aware harness [I-D.draft-mcguinness-oauth-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.¶

14. 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.3).¶

15. 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 that performs lineage-sensitive policy, however, MUST understand the parent member before relying on it.¶

16. Security Considerations

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

18. 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 14.¶

• 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.3). Like the issuance profile's restraint with mission members, these are documented in this specification rather than placed in a new IANA registry: they are conveyed inside existing OAuth error responses and evidence at deployment-defined locations, not 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.¶

19. References

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