Mission Orchestration and Unwinding 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

Mission-Bound Authorization for OAuth 2.0 [I-D.draft-mcguinness-oauth-mission] gives a task an approved authority and lifecycle. The runtime profile [I-D.draft-mcguinness-oauth-mission-runtime] checks each consequential action before it executes. These are necessary but not complete for long-running workflows. A Mission can terminate after some steps have completed and before others run. Some completed steps can be compensated. Some cannot. Some in-flight requests can be canceled. Some must be escalated to a human.¶

This document defines the orchestration layer that handles those cases. Before governed execution begins, the orchestrator records an unwind plan for each consequential step. When Mission state becomes non-active or cannot be established, the orchestrator stops new governed work and executes the plan: cancel, compensate, suppress, pause, or hand off to human review.¶

2. Scope

This document defines:¶

• action reversibility classes (Section 4);¶

• unwind plans (Section 5);¶

• behavior on Mission state changes (Section 6);¶

• in-flight request handling (Section 7);¶

• compensation and human review evidence (Section 9); and¶

• conformance for a Mission-aware orchestrator (Section 11).¶

This document does not define a workflow language, a compensation API, or a replacement for runtime PEP enforcement.¶

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 state, and consequential action from [I-D.draft-mcguinness-oauth-mission]; PEP, PDP, and runtime enforcement evidence from [I-D.draft-mcguinness-oauth-mission-runtime]; and the Decision Evidence and Execution Evidence objects from [I-D.draft-mcguinness-oauth-mission-authzen] (the runtime profile defers those object schemas; the AuthZEN profile defines them).¶

Orchestrator:

The component that schedules, sequences, retries, or coordinates governed actions in a Mission.¶

Unwind plan:

The per-step plan describing what the orchestrator does if Mission authority ends or cannot be established before or during that step.¶

Compensation:

A deployment-defined action intended to offset or reverse a prior action's effect. Compensation is not guaranteed reversal.¶

Safe point:

A workflow point at which the orchestrator can stop without starting another consequential action and with all prior outcomes recorded.¶

4. Reversibility Classes

Each consequential step in a governed workflow MUST be assigned one of these reversibility classes before execution:¶

read_only:

The step observes data and has no external side effect. Suppression prevents future exposure, but prior disclosure cannot be undone.¶

reversible_write:

The step changes state and has a known compensation action that can restore or materially offset the change.¶

irreversible_action:

The step cannot be reliably undone once completed.¶

external_commitment:

The step commits to an external party, sends communication, starts a payment, signs, files, orders, or otherwise creates an external reliance interest.¶

privileged_administration:

The step changes policy, access, configuration, or security posture.¶

irreversible_action, external_commitment, and privileged_administration are the identically-named action classes of [I-D.draft-mcguinness-oauth-mission-runtime] (Section "Action classification"); a step's reversibility class MUST be consistent with, and no lower than, the runtime action class that profile assigns the same operation. read_only and reversible_write are a reversibility refinement this profile adds that the runtime classification does not separately track.¶

The class MAY be raised by Resource policy or operation profile. As with the runtime classification floor ([I-D.draft-mcguinness-oauth-mission-runtime]), it MUST NOT be lowered by the orchestrator at runtime to avoid review or compensation requirements.¶

5. Unwind Plan

Before dispatching a consequential step, the orchestrator MUST have an unwind plan. The plan has these members:¶

step_id:

REQUIRED. A string identifying the workflow step.¶

mission_id:

REQUIRED. The Mission governing the step.¶

reversibility:

REQUIRED. One of the classes in Section 4.¶

pre_start_behavior:

REQUIRED. Behavior when Mission state is non-active before the step starts. One of suppress, pause, cancel_workflow, or human_review.¶

in_flight_behavior:

REQUIRED. Behavior when Mission state changes while the step is in flight. One of cancel_if_possible, wait_then_review, continue_to_safe_point, or human_review.¶

post_completion_behavior:

REQUIRED for reversible_write, irreversible_action, external_commitment, and privileged_administration. One of compensate, record_only, or human_review.¶

compensation_action:

REQUIRED when post_completion_behavior is compensate. A deployment-defined action reference.¶

review_queue:

REQUIRED when any behavior is human_review. A deployment-defined queue or escalation target.¶

safe_point:

OPTIONAL. A deployment-defined workflow point to which continue_to_safe_point may proceed.¶

evidence_policy:

OPTIONAL. Deployment-defined instructions for linking Decision Evidence, Execution Evidence, Harness Evidence, and Orchestration Evidence. Its members, including any retention token such as the example's mission_audit_horizon, are deployment-defined; the retention horizon aligns with the runtime profile's record-retention guidance ([I-D.draft-mcguinness-oauth-mission-runtime]).¶

The unwind plan does not authorize compensation by itself. A compensation action that is consequential MUST itself pass Mission or deployment emergency authorization as defined by policy.¶

{
  "step_id": "post_journal_entry",
  "mission_id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-",
  "reversibility": "external_commitment",
  "pre_start_behavior": "human_review",
  "in_flight_behavior": "wait_then_review",
  "post_completion_behavior": "human_review",
  "review_queue": "finance-control-review",
  "evidence_policy": {
    "link_runtime_evidence": true,
    "retain_for": "mission_audit_horizon"
  }
}

6. State-Change Behavior

When an orchestrator learns that a Mission is no longer active, or cannot establish active state within the deployment's staleness bound, it MUST:¶

1. stop dispatching new governed steps for that Mission;¶

2. suppress or pause queued work;¶

3. evaluate every in-flight step under Section 7;¶

4. execute or schedule post-completion behavior for completed steps whose unwind plan requires it; and¶

5. emit Orchestration Evidence under Section 9.¶

The states revoked and expired ([I-D.draft-mcguinness-oauth-mission]), suspended and completed ([I-D.draft-mcguinness-oauth-mission-status]), and superseded ([I-D.draft-mcguinness-oauth-mission-expansion]) are non-active for this profile. A deployment MAY define different operator handling for each state, but none allows new governed execution without a fresh authority path. In particular, a superseded Mission's work SHOULD re-bind to the successor Mission rather than be treated as a hard stop.¶

7. In-Flight Requests

For in-flight requests, the orchestrator MUST distinguish:¶

not_dispatched:

The step has not reached the PEP or external system. The orchestrator MUST suppress or pause it.¶

dispatched_not_committed:

The request was sent, but the deployment can still cancel or prevent commit. The orchestrator MUST attempt cancellation when the unwind plan says cancel_if_possible.¶

committed:

The action's effect occurred or the deployment cannot prove it did not occur. The orchestrator MUST apply post-completion behavior.¶

unknown:

The orchestrator cannot determine whether the action committed. The orchestrator MUST treat the outcome as requiring human review unless deployment policy defines a stricter default.¶

For irreversible actions, external commitments, and privileged administration, an unknown outcome MUST NOT be treated as success or as harmless suppression.¶

8. Compensation

Compensation is governed work. If a compensation action is performed under the original Mission after that Mission became non-active, the deployment MUST have a policy basis for emergency or remedial authority that is separate from ordinary Mission authority. Otherwise the orchestrator MUST escalate to human review.¶

The compensation record MUST link:¶

• the original Mission;¶

• the original decision and execution evidence when available;¶

• the state transition that triggered compensation;¶

• the compensation action;¶

• the authority basis for compensation; and¶

• the outcome.¶

9. Orchestration Evidence

An Orchestration Evidence record has these members:¶

event_id:

REQUIRED. A unique identifier.¶

mission:

REQUIRED. The Mission whose orchestration state changed, as the nested mission object (id, origin, and, when known, authority_hash), the same shape as the mission claim of [I-D.draft-mcguinness-oauth-mission] and the Harness Evidence object ([I-D.draft-mcguinness-oauth-mission-harness]).¶

workflow_id:

REQUIRED. The workflow or task graph identifier.¶

step_id:

OPTIONAL. The step affected.¶

mission_state:

REQUIRED. The state observed.¶

state_source:

REQUIRED. One of status, signal, runtime_decision, or a deployment-defined source, the same value space as the harness state_source ([I-D.draft-mcguinness-oauth-mission-harness]).¶

orchestration_decision:

REQUIRED. One of suppress, pause, cancel, compensate, human_review, or record_only. An unwind plan's pre_start_behavior/in_flight_behavior values map to these: both cancel_workflow and cancel_if_possible record as cancel, wait_then_review and a review queue record as human_review, and suppress/pause carry through unchanged.¶

reason:

REQUIRED. A string naming the condition.¶

occurred_at:

REQUIRED. An RFC 3339 [RFC3339] timestamp.¶

linked_evidence:

OPTIONAL. An array of Decision Evidence, Execution Evidence, Harness Evidence, or prior Orchestration Evidence identifiers.¶

outcome_state:

OPTIONAL. One of not_dispatched, dispatched_not_committed, committed, or unknown.¶

authority_basis:

OPTIONAL. Present when orchestration_decision is compensate.¶

evidence_envelope:

OPTIONAL. Integrity protection over the Orchestration Evidence object. When present with format jws-compact, its payload is the JCS canonical bytes of the object with evidence_envelope removed.¶

Example:¶

{
  "event_id": "orch_4r9SqLm8tY2p",
  "mission": {
    "id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-",
    "origin": "https://as.example.com",
    "authority_hash":
      "sha-256:l3KvZ4mP5x0wQrR6tY2nD9bM7sX1cF8gH2vJ4kE5pNQ"
  },
  "workflow_id": "wf_invoice_recon_2026q3",
  "step_id": "post_journal_entry",
  "mission_state": "suspended",
  "state_source": "status",
  "orchestration_decision": "human_review",
  "reason": "external_commitment_dispatched_unknown",
  "outcome_state": "unknown",
  "occurred_at": "2026-11-02T08:16:00Z"
}

10. Relationship to Harness and Runtime Profiles

The harness profile [I-D.draft-mcguinness-oauth-mission-harness] governs whether a session, queue item, or sub-agent handle may continue. This document governs how workflow state is unwound once continuation is stopped. The runtime profile [I-D.draft-mcguinness-oauth-mission-runtime] still governs each consequential action at the last controllable boundary. These checks compose; none replaces the others.¶

11. Conformance

A conforming Mission-aware orchestrator MUST:¶

• assign a reversibility class to each consequential step;¶

• record an unwind plan before dispatch;¶

• stop new governed work when Mission state is non-active or stale;¶

• classify in-flight steps under Section 7;¶

• apply post-completion behavior for committed or unknown outcomes;¶

• emit Orchestration Evidence; and¶

• document the policy basis for compensation after Mission termination.¶

A deployment MAY claim this profile for only some workflows, but it MUST identify workflows and paths outside the claim.¶

12. Security Considerations

13. Privacy Considerations

Orchestration Evidence can expose workflow structure, business milestones, resource names, and failure conditions. Deployments SHOULD limit evidence access to audit and operations roles with a need to know and avoid recording raw user content when identifiers are sufficient.¶

14. IANA Considerations

This document makes no IANA request.¶

15. References

Acknowledgments

This document is part of the Mission-Bound Authorization for OAuth 2.0 set and defines how Mission termination affects in-flight workflows.¶

Author's Address