Mission Orchestration and Unwinding

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") gives a task an approved authority and lifecycle. The runtime profile [I-D.draft-mcguinness-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.¶

The boundary with the harness profile ([I-D.draft-mcguinness-mission-harness]) is the question each answers. The harness answers "may this unit of work continue." This document answers "how is in-flight state unwound once continuation is stopped." The runtime profile still gates each action. The checks compose; none replaces the others (Section 12).¶

This is a newer profile than the rest of the Mission-Bound Authorization family and is not part of the recommended v1 deployment bundles. The unwind, compensation, and reversibility model it defines is less exercised than the issuance core and the runtime layer, and compensation is inherently domain-specific. Its details may change; treat it as a direction, not yet as a stable interface.¶

2. Scope

This document is experimental: adopt it for evaluation, not as a stable interface. Safe unwinding of in-flight agent work is the least settled layer of the suite, and this profile is expected to change with implementation experience.¶

This document defines:¶

• action reversibility classes (Section 5);¶

• unwind plans (Section 6);¶

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

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

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

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

This document does not define a workflow language, a compensation API, or a replacement for runtime PEP enforcement. Its object shapes (the unwind plan and the evidence record) bind what a deployment records and proves, not how an orchestrator is internally structured.¶

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]; and PEP, PDP, and runtime enforcement evidence from [I-D.draft-mcguinness-mission-runtime]. Where a deployment uses the AuthZEN profile ([I-D.draft-mcguinness-mission-authzen]), its Decision Evidence and Execution Evidence objects are examples of the runtime enforcement evidence records this document links.¶

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. Mission Substrate

This profile is defined against the Mission model rather than against OAuth 2.0 mechanics. It consumes these substrate primitives: the Mission identifier; the lifecycle state space with its only-active-permits rule; the runtime enforcement evidence its records link; the integrity-anchor envelope, used for unwind_plan_hash; and the substrate's Mission state, against which a compensation authority basis resolves (Section 9.1): a separate_mission basis requires a Mission that is active under the binding in use, and a resource_policy basis lies outside Mission authority entirely. The issuance profile [I-D.draft-mcguinness-oauth-mission] is this version's normative substrate; another substrate that provides the same primitives can host this profile unchanged.¶

5. 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-mission-runtime] (Section "Action classification"). A step's reversibility class MUST be at least the minimum this table maps from the runtime action class the runtime 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-mission-runtime]), it MUST NOT be lowered by the orchestrator at runtime to avoid review or compensation requirements.¶

6. Unwind Plan

Before dispatching a consequential step, the orchestrator MUST have an unwind plan. The plan is deployment documentation committed for audit (Section 6.1), not a wire format; the members below are the information it MUST record, in whatever representation the deployment commits. 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 5.¶

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 runtime enforcement evidence ([I-D.draft-mcguinness-mission-runtime]), 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-mission-runtime]).¶

The unwind plan does not authorize compensation by itself. A compensation action that is consequential MUST itself be authorized under one of the compensation authority bases (Section 9.1): resource policy or a separate active Mission, never the terminated Mission.¶

{
  "step_id": "post_journal_entry",
  "mission_id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-",
  "reversibility": "irreversible_action",
  "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"
  }
}

{"iss":"https://as.example.com","typ":"mission-unwind-plan","value
":{"evidence_policy":{"link_runtime_evidence":true,"retain_for":"m
ission_audit_horizon"},"in_flight_behavior":"wait_then_review","mi
ssion_id":"msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-","post_completion_
behavior":"human_review","pre_start_behavior":"human_review","reve
rsibility":"irreversible_action","review_queue":"finance-control-r
eview","step_id":"post_journal_entry"}}

unwind_plan_hash =
  sha-256:jKxM47ygRiTXYVfKjrVE34VZx8nsxg1I9OPPeHnO-_c

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

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

5. emit Orchestration Evidence under Section 11.¶

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 all non-active. The orchestrator needs none of those companion profiles to be conformant: per the issuance profile's forward-compatibility rule it treats any state other than active as non-active. 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 continued work SHOULD proceed under the successor Mission through a fresh derivation from the successor's grant, not by rebinding the predecessor's authority; the successor carries its own Authority Set ([I-D.draft-mcguinness-oauth-mission-expansion]).¶

8. In-Flight Requests

An in-flight step moves through these outcome classes:¶

 not_dispatched --> dispatched_not_committed --> committed
                              |
                              +-------------------> unknown

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

9. Compensation

Compensation is governed work. After a Mission becomes non-active, a compensation action MUST NOT be performed by presenting that Mission's authority. It proceeds only under one of the bases of Section 9.1: resource_policy or separate_mission. If neither applies, the orchestrator MUST escalate to human review.¶

The compensation record is an Orchestration Evidence record (Section 11) with orchestration_decision set to compensate. In that case its authority_basis, linked_evidence, compensation_action, and compensation_outcome members are REQUIRED. Through those members the record links:¶

• the original Mission (the record's mission);¶

• the original runtime enforcement evidence when available (linked_evidence);¶

• the state transition that triggered compensation (mission_state and reason);¶

• the compensation action (compensation_action);¶

• the authority basis for compensation (authority_basis); and¶

• the outcome (compensation_outcome).¶

10. Human Review

When the orchestrator routes a step to human review (human_review), the review concludes with one of three outcomes:¶

approve:

The reviewer permits the work to continue.¶

reject:

The reviewer refuses the work.¶

expire:

The item reached its parked maximum age without a review decision.¶

A parked item MUST carry a deployment maximum age. The orchestrator MUST record the outcome and its authority basis in Orchestration Evidence.¶

11. Orchestration Evidence

An Orchestration Evidence record is a JSON object [RFC8259] with these members:¶

event_id:

REQUIRED. A unique identifier.¶

mission:

REQUIRED. The Mission whose orchestration state changed, as the nested mission object (id, issuer, 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-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. A value from the shared state_source value space defined by the Harness profile ([I-D.draft-mcguinness-mission-harness]): status, signal, runtime_decision, harness, operator, or a deployment-defined source. This profile does not define its own; a trigger source from Section 7.1 maps to the corresponding value (a harness stop decision to harness, an operator action to operator).¶

orchestration_decision:

REQUIRED. One of suppress, pause, cancel, continue_to_safe_point, 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, continue_to_safe_point carries through unchanged, 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 runtime enforcement evidence records ([I-D.draft-mcguinness-mission-runtime]), Harness Evidence, or prior Orchestration Evidence identifiers. REQUIRED when orchestration_decision is compensate.¶

outcome_state:

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

unwind_plan_hash:

REQUIRED on the step's first Orchestration Evidence record. The integrity anchor over the step's unwind plan (Section 6.1).¶

authority_basis:

REQUIRED when orchestration_decision is compensate; otherwise absent. One of resource_policy or separate_mission (Section 9.1).¶

compensation_action:

REQUIRED when orchestration_decision is compensate. The deployment-defined compensation action reference.¶

compensation_outcome:

REQUIRED when orchestration_decision is compensate. The outcome of the compensation action.¶

evidence_envelope:

OPTIONAL. Integrity protection over the Orchestration Evidence object. When present with format jws-compact, it is a JWS [RFC7515] Compact Serialization whose payload is the JCS [RFC8785] canonical bytes of the object with evidence_envelope removed. When present, it MUST identify the signer: the JWS protected header MUST carry alg, iss, kid resolvable under deployment policy, and a typ naming the record's own media type, matching the suite's evidence-envelope convention ([I-D.draft-mcguinness-mission-runtime]).¶

Example:¶

{
  "event_id": "orch_4r9SqLm8tY2p",
  "mission": {
    "id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-",
    "issuer": "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",
  "unwind_plan_hash":
    "sha-256:jKxM47ygRiTXYVfKjrVE34VZx8nsxg1I9OPPeHnO-_c",
  "occurred_at": "2026-11-02T08:16:00Z"
}

A later record for the same step carries the compensate decision. Review confirmed that the posting committed before the Mission was revoked; a pre-provisioned remedial Mission that is active authorizes the reversing entry (Section 9.1). The record links the review record above and the original runtime enforcement evidence, and omits unwind_plan_hash because it is not the step's first record:¶

{
  "event_id": "orch_9wK2nR5vXq7t",
  "mission": {
    "id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-",
    "issuer": "https://as.example.com",
    "authority_hash":
      "sha-256:l3KvZ4mP5x0wQrR6tY2nD9bM7sX1cF8gH2vJ4kE5pNQ"
  },
  "workflow_id": "wf_invoice_recon_2026q3",
  "step_id": "post_journal_entry",
  "mission_state": "revoked",
  "state_source": "status",
  "orchestration_decision": "compensate",
  "reason": "committed_step_reversed_after_review",
  "outcome_state": "committed",
  "linked_evidence": [
    "orch_4r9SqLm8tY2p",
    "dec_8K2nP4qV9rL3tY6sB1zN0eF7jB"
  ],
  "authority_basis": "separate_mission",
  "compensation_action": "erp.journal_entry.reverse",
  "compensation_outcome": "completed",
  "occurred_at": "2026-11-02T09:03:00Z"
}

12. Relationship to Harness and Runtime Profiles

The two execution profiles share, rather than duplicate, their common machinery: the state_source value space is defined once by the Harness profile ([I-D.draft-mcguinness-mission-harness]) and reused here (Section 11), and the Orchestration Evidence mission descriptor is the same shape as the Harness Evidence descriptor. A deployment that needs both records emits each at its own decision point; neither subsumes the other. The runtime profile [I-D.draft-mcguinness-mission-runtime] still governs each consequential action at the last controllable boundary, whichever execution profile stops or unwinds the work.¶

13. 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 8;¶

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

14. Security Considerations

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

16. IANA Considerations

This document makes no IANA request.¶

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