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 25 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

The issuance profile [I-D.draft-mcguinness-oauth-mission] 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. Scope

This document defines:¶

• Child Mission creation (Section 4);¶

• the parent lineage member (Section 5);¶

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

• fan-out controls (Section 7);¶

• cascade revocation (Section 8);¶

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

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

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

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

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

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

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:Td9bM7sX1cF8gH2vJ4kE5pNQl3KvZ4mP5x0wQrR6tY2n",
    "parent": {
      "id": "msn_parent_8RfX2Lqv9TqMv4z7sA2bN1k0",
      "origin": "https://as.example.com",
      "authority_hash":
        "sha-256:l3KvZ4mP5x0wQrR6tY2nD9bM7sX1cF8gH2vJ4kE",
      "delegation_id": "dlg_7pQ4m",
      "cascade_mode": "immediate",
      "created_at": "2026-11-02T08:14:00Z"
    }
  }
}

6. Attenuation Rules

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

• every child Authority Set entry MUST be a subset of a parent entry;¶

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

• child delegation depth MUST be lower than the remaining parent delegation depth;¶

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

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

8. Cascade Revocation

A Child Mission depends on the Parent Mission. When the Parent Mission becomes non-active (revoked, expired, suspended, completed, or superseded), the Mission Issuer MUST prevent new derivation under dependent Child Missions.¶

The Mission Issuer MUST implement one of these cascade modes and record it on the Child Mission:¶

immediate:

The Child Mission transitions to a non-active state when the parent transition commits.¶

bounded_staleness:

The Child Mission is treated as non-active no later than the deployment's published cascade staleness bound.¶

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

9. 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:l3KvZ4mP5x0wQrR6tY2nD9bM7sX1cF8gH2vJ4kE"
  },
  "child": {
    "id": "msn_child_2Yt7Qv9LqMv4z7sA2bN1k0",
    "origin": "https://as.example.com",
    "authority_hash":
      "sha-256:Td9bM7sX1cF8gH2vJ4kE5pNQl3KvZ4mP5x0wQrR6tY2n"
  },
  "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"
}

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

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

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

13. Security Considerations

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

15. IANA Considerations

This document makes no IANA request. It defines the parent member of the open Mission claim object by profile, without registering a new JWT claim.¶

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