Mission Entry Discharge for OAuth 2.0

3.1. Relationship to the Issuance Profile

The completion capability depends normatively on the issuance profile and on its Mission Resource Access Profile ([I-D.draft-mcguinness-oauth-mission-resource-access]), and is not implementable alone. It reuses, without restating, the issuance profile's Mission, Authority Set, subset rule, integrity anchors, lifecycle states, and issuance gating, and the inert success_criteria member of the Mission Intent; and the Mission Resource Access Profile's mission_resource_access entry and Common Constraints registry. It uses Mission, Mission Issuer, Authority Set, and derivation as the issuance profile defines them, and the mission_resource_access entry as the Mission Resource Access Profile defines it.¶

It extends the Mission Resource Access Profile in one narrow, additive way: it registers terminal_when, an OPTIONAL Common Constraint on a mission_resource_access entry (Section 3.2), whose subset rule that profile's existing subset comparison applies (Section 3.4). It changes no Mission lifecycle state and no meaning of any existing member.¶

3.2. Entry Completion Conditions

This section defines terminal_when, a Common Constraint ([I-D.draft-mcguinness-oauth-mission-resource-access]) carried in the constraints object of a mission_resource_access entry. It is a specification-defined Common Constraint under the Mission Resource Access Profile's naming convention (Section 7).¶

terminal_when:

OPTIONAL. An array of one or more completion conditions. When any condition is met, the entry is discharged (Section 3.3). Each condition is an object with these members:¶

event_type:

REQUIRED. A string identifying the completion event. Its semantics are deployment- or registry-defined and opaque to this document, as purpose is ([I-D.draft-mcguinness-oauth-mission]).¶

discharge_authority:

OPTIONAL. A string, 1*64( ALPHA / DIGIT / "-" / "_" / ":" / "." ) [RFC5234], opaque. It names the authority approved to assert this condition, which the AS resolves to its discharge-authority mapping (Section 4.3.1).¶

The terminal_when array is part of the entry's constraints and so of the Authority Set: it is committed by authority_hash and reproducible under derivation ([I-D.draft-mcguinness-oauth-mission]). Condition identity is byte equality of the condition object's canonical form under the issuance profile's canonicalization; an AS refuses a value carrying two identical conditions, and an intersection of two arrays deduplicates by that identity and sorts by the lexicographic order of the canonical bytes (Section 7.1), so the intersected entry is one reproducible array. Whether a condition has fired is evaluated state, not part of authority_hash; folding fired status into the anchor would make the committed authority time-varying.¶

condition_digest, used to select a condition on the discharge operation (Section 4.3), is a canonical-object digest ([I-D.draft-mcguinness-oauth-mission]) over the exact canonical bytes of the single condition object, in the issuance profile's encoded form: the same canonical form the registration's no-duplicate rule above already fixes as condition identity (Section 7.1).¶

terminal_when is the enforceable counterpart of the inert success_criteria ([I-D.draft-mcguinness-oauth-mission]), which remains inert: success_criteria describe completion for the Approver, terminal_when acts on it. It is distinct from a cumulative consumption bound, which meters volume; a terminal_when condition is a single external event.¶

3.3. Discharge and Issuance Gating

When a condition in an entry's terminal_when has been met, the entry is discharged. The Authorization Server MUST NOT derive a token carrying a discharged entry, at the token endpoint, on refresh, or on Token Exchange, exactly as issuance is refused for a non-active Mission ([I-D.draft-mcguinness-oauth-mission]). A derivation that would carry only discharged entries MUST fail. A derivation that carries a mix MUST omit the discharged entries.¶

Discharge gates at the entry, not the Mission. The Mission remains active and continues to derive its other entries: a multi-resource Mission therefore completes partially, one entry at a time, as each entry's task finishes. The issuance profile's Mission states are unchanged; a deployment that also tracks Mission-level completion MAY transition a Mission whose entries are all discharged to the completed state the Status profile's Mission Lifecycle endpoint defines ([I-D.draft-mcguinness-oauth-mission-status]), but this section does not require it. Such a transition is performed through the Status profile's complete operation, as an issuer-initiated lifecycle operation, so the consolidated state machine's event sources remain authoritative ([I-D.draft-mcguinness-oauth-mission-status], Section "Consolidated State Machine").¶

Discharge gates new derivations only. A token already issued for an entry remains valid until it expires, as with revocation ([I-D.draft-mcguinness-oauth-mission]). A deployment that needs prompt cutoff relies on short token lifetimes or on the runtime layer denying a discharged entry at the point of use (Section 3.7).¶

3.4. Subset Rule

Because terminal_when is a Common Constraint, the issuance profile's subset comparison ([I-D.draft-mcguinness-oauth-mission]) applies its defined subset rule with no new clause: for a key present in the reference entry's constraints, the same key MUST be present in the candidate entry and its value MUST be no broader under the key's defined rule.¶

For terminal_when, a candidate value is no broader than a reference value when the candidate's condition array contains every condition of the reference, compared structurally after the canonicalization of the issuance profile ([I-D.draft-mcguinness-oauth-mission]); the candidate MAY add further conditions.¶

Conditions are compared structurally, not by event semantics. A child cannot drop or alter a parent's completion condition, only add more, so discharge composes monotonically: an added condition can only make an entry discharge sooner, which is a narrowing. Modifying a parent condition is forbidden because a verifier cannot decide whether the change discharges earlier or later from opaque event_type values.¶

3.5. Forward Compatibility

Because terminal_when is a constraints member, a consumer that does not recognize it fails closed by the issuance profile's Resource Server enforcement rule directly: a consumer MUST fail closed on any constraints key it does not understand, or understands but cannot enforce, refusing the request rather than granting access while ignoring the key ([I-D.draft-mcguinness-oauth-mission]). Discharge is load-bearing narrowing, so ignoring terminal_when would silently widen the grant. That enforcement rule is the honest basis of discharge's safety: an unrecognized terminal_when is refused, never dropped.¶

An Authorization Server that does not implement this capability simply does not emit terminal_when, and is unaffected. The fail-closed rule binds a consumer that encounters the constraint without implementing it.¶

3.6. Derivation Guidance

This guidance is non-normative. When the Authorization Server derives an entry from the Mission Intent, a reviewable rule governs what each element of the Intent becomes:¶

• an action if removing it would leave the task undefined;¶

• an ordinary constraints member if removing it would merely make the task less restrictive; and¶

• a terminal_when completion condition, itself a constraints member, if it defines when the task is satisfied, retiring the entry's authority rather than widening or restricting it.¶

The third case is what this capability adds. A bound that holds throughout the task is an ordinary constraint; an event that ends the task is a terminal_when condition. For example, "only invoices under 500 USD" is a max_amount constraint, while "until the Q3 close is finalized" is a completion condition.¶

3.7. Relationship to Runtime Enforcement

Discharge is an issuance-gating signal and is fully meaningful at the issuance profile alone: issuance-only discharge is a conforming posture, with the residual that a credential issued before a discharge stays valid until it expires (Section 3.3). Where the deployment also runs the runtime profile, that profile requires its PDP to refuse a discharged entry at the point of use ([I-D.draft-mcguinness-mission-runtime]), closing the window between discharge and token expiry the same way it refuses a revoked Mission. A Policy Enforcement Point learns that an entry is discharged from the Status profile's Mission Status operation or the token introspection projection (Section 3.3.1), the same way it learns a Mission is revoked. A runtime Policy Enforcement Point that does not recognize terminal_when fails closed for the entry per Section 3.5.¶

For that point-of-use denial this document defines the denial-reason identifier authority_discharged, a family-coordinated name under the AuthZEN profile's denial-reason extension rule ([I-D.draft-mcguinness-mission-authzen]), carried wherever the runtime layer's denial reasons travel: the decision response's context.reason and the runtime evidence companion's denial_reason. It means the entry was approved and its completion condition fired, so the Mission Issuer discharged it: distinct from a containment denial (trust withdrawn) and from an out-of-authority denial (never approved). A consumer treats an unrecognized value as a deny under the binding's own rule; no other semantics attach.¶

4.1. Discharge Commit

Every committed discharge, whichever way it is determined, has these semantics:¶

• Entry-level OR latch. The entry's terminal_when discharges on any condition being met (Section 3.2). The committed state is one monotonic latch on the entry, or on its selector equivalence class, one state-version increment, one audit record, and one notification. Issuance gating for a discharged entry is unchanged (Section 3.3).¶

• Duplicate entries. One entry_digest discharges every recorded entry resolving to that digest as a single equivalence-class transition, and therefore one version increment, under the Authority Set entry commitment's selector equivalence-class rule ([I-D.draft-mcguinness-oauth-mission]).¶

• States. Discharge applies while the Mission is active or suspended: a suspended Mission still narrows monotonically. A discharge determined after the Mission reaches completed, revoked, expired, or another terminal state MUST NOT create a transition or a version increment. Discharge never changes Mission-level state; a deployment that also tracks all-entry completion invokes the Status profile's complete operation separately ([I-D.draft-mcguinness-oauth-mission-status]).¶

• Atomicity. The entry latch (or its equivalence-class latch), the version increment, the audit and result record, and the durable propagation work (an outbox entry or a signal enqueue) commit as one unit. Where the deployment emits lifecycle events ([I-D.draft-mcguinness-oauth-mission-signals]), the signal enqueue is part of that same unit. Downstream materialization from the durable propagation work, including the child-delegation profile's entry-wise propagation to an already-justified Child Mission ([I-D.draft-mcguinness-oauth-mission-child-delegation]), is asynchronous and is not claimed atomic with this commit. Instead, a Child Mission's derivation MUST consult, or otherwise be gated by, the committed parent latch until that materialization completes, so no Child Mission can derive the discharged parent authority in the gap between the parent's commit and the child's materialized view.¶

• Propagation. The Mission Issuer MUST propagate a committed discharge to a Child Mission's entry exactly when that entry carries the fired condition and its recorded justification is the discharged entry, or, recursively, an entry the discharge has already reached. The recorded justification is the parent entry each child entry was derived from, which the child-delegation profile selects deterministically ([I-D.draft-mcguinness-oauth-mission-child-delegation], Section "Fan-Out Accounting"). Propagation runs downward only: the Mission Issuer MUST NOT discharge a parent's or a sibling's entry because a child entry was discharged.¶

Once committed, a discharge is recorded as Authorization-Server-side state and MUST NOT revert: a later delivery presenting any valid condition against an already-discharged entry is acknowledged already_discharged (Section 4.3.4) and does not restore the entry's authority.¶

A committed discharge also places a discharge restriction on the Mission's expansion chain, the successors linked to it through predecessor ([I-D.draft-mcguinness-oauth-mission-expansion]). The Mission Issuer MUST retain each restriction, with the discharged entry and the condition that discharged it, across every later successor in the chain. A restriction clears only for authority that a fresh human approval explicitly restores with the discharged entry and its condition disclosed; any authority that approval does not restore stays restricted. An intervening successor, an approval of unrelated authority, and a ceiling renewal under the progressive authorization profile ([I-D.draft-mcguinness-oauth-mission-progressive]) do not clear it. Restoration grants authority through the successor's own approval: the discharge never reverts, and the predecessor's entry stays discharged.¶

A committed discharge is a committed metadata-only change for the purposes of the state version ([I-D.draft-mcguinness-oauth-mission-status], Section "Response"): the Mission's state version increments at the commit, so a materialized policy view that commits a state version ([I-D.draft-mcguinness-mission-runtime]) is detectably obsolete after a discharge. Where Signals is deployed, the commit is carried by the generic authority_changed discriminator ([I-D.draft-mcguinness-oauth-mission-signals]); where Signals is not deployed, the version movement is what makes the change observable.¶

Before the AS receives and commits a discharge, it continues issuing against the entry. The posture this implies is stated plainly in Section 5.1.¶

4.2. Condition Selectors

A condition selector is an opaque string the Mission Issuer issues for one condition of one entry in one Mission record. It resolves to that condition's target, the (mission_id, entry_digest, condition_digest) triple of Section 4.3. A source that holds only its token's narrowed projection can then name the target without reconstructing the immutable record entry.¶

• A selector is lookup state the Mission Issuer holds. It is not committed: terminal_when, its Value Space, the subset rule, and authority_hash are unchanged by it.¶

• The Mission Issuer MUST issue at most one selector per target, and a selector MUST resolve to exactly one target. Byte-identical entries share one entry_digest, so they share one selector, as they share one equivalence-class latch (Section 4.1).¶

• A selector MUST NOT let its holder reconstruct the record entry or any part of it: it is never computed from the entry's content without a secret, so it is never an unsalted digest. Its syntax is 1*128( ALPHA / DIGIT / "-" / "_" ) [RFC5234].¶

• Knowing a selector authorizes nothing. Discharge authority (Section 4.3.1) and the pinned mapping decide, exactly as for the digest form.¶

• The Mission Issuer MUST keep a selector resolvable while its target can still be discharged, directly or by forwarding after carryover (Section 4.4), and for at least as long as Section 4.3.3 requires event-deduplication state to be retained, so a delayed assertion and a fresh-nonce event replay can still resolve it.¶

Where the AS supports token introspection [RFC7662] for Mission-bound tokens ([I-D.draft-mcguinness-oauth-mission], Section "Mission State via Token Introspection"), the mission member of the introspection response can carry discharge_selectors, a member this document defines. It is an array of objects, each with:¶

entry:

the zero-based index of a mission_resource_access entry in the response's authorization_details (number).¶

condition:

the zero-based index of a condition in that entry's terminal_when (number).¶

selector:

the condition selector for that condition's target (string).¶

The AS MUST NOT include a selector for an entry it does not return to that caller in the same response. A projected condition that has no counterpart in the immutable record entry, such as one a token projection added, has no target and so no selector. The OAuth binding's caller-authorization and minimization rules apply ([I-D.draft-mcguinness-oauth-mission], Section "Caller Authorization and Minimization"). An AS MUST NOT include discharge_selectors unless it is the Mission issuer ([I-D.draft-mcguinness-oauth-mission], Section "Only the Issuer Reports Mission State"). This document defines introspection carriage only.¶

The following is an example of an introspection response carrying a selector for the write entry of the worked example (Section 4.6):¶

{
  "active": true,
  "client_id": "s6BhdRkqt3",
  "exp": 1790000000,
  "authorization_details": [
    { "type": "mission_resource_access",
      "resource": "https://erp.example.com",
      "actions": ["journal-entries.write"],
      "constraints": {
        "max_amount": { "amount": "500.00", "currency": "USD" },
        "terminal_when": [
          { "event_type": "accounting-period-closed",
            "discharge_authority": "close-management-2026-q3" }
        ] } }
  ],
  "mission": {
    "id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-",
    "issuer": "https://as.example.com",
    "state": "active",
    "discharge_selectors": [
      { "entry": 0, "condition": 0,
        "selector": "dcs_4Kq9vT2mX7pL0sR3nB8wZ1" }
    ]
  }
}

4.3. Entry Discharge Operation

discharge commits that a terminal_when completion condition (Section 3.2) has fired, discharging the named Mission-record entry (Section 3.3). It is registered as an extension operation value on the Status profile's Mission Lifecycle endpoint ([I-D.draft-mcguinness-oauth-mission-status]). Beyond mission_id and nonce, it names its target in exactly one of two forms, a condition selector (Section 4.2) or the digest pair, and carries:¶

condition_selector:

CONDITIONAL. A string, a condition selector (Section 4.2). Present when the request does not carry entry_digest and condition_digest. The AS resolves it to its target.¶

entry_digest:

CONDITIONAL. A string. Present, with condition_digest, when the request does not carry condition_selector. The Authority Set entry commitment ([I-D.draft-mcguinness-oauth-mission]) of the mission_resource_access entry to discharge, computed over the immutable Mission-record entry, never over a narrowed token projection.¶

condition_digest:

CONDITIONAL. A string. Present with entry_digest. The digest identifying the single terminal_when condition that fired, defined beside that member (Section 3.2).¶

The AS MUST refuse a request that carries both target forms, or neither, with invalid_request. For a request carrying condition_selector, the rest of this section and its subsections apply to the resolved entry_digest and condition_digest exactly as to the digest form.¶

event_type:

REQUIRED. A string. Echoed from the fired condition and cross-checked against the condition the target names: a mismatch joins the not_found collapse, since distinguishing it would reveal information about a condition selected by digest (Section 4.3.2). event_type is never a selector by itself.¶

event_id:

REQUIRED. A string, 1*128( ALPHA / DIGIT / "-" / "_" / ":" / "." ) [RFC5234]. The identifier of the asserted external occurrence, used for evidence correlation and for the event-level deduplication of Section 4.3.3. It is distinct from nonce, the HTTP retry key of the Status profile's Idempotency and Conflicts rule ([I-D.draft-mcguinness-oauth-mission-status], Section "Idempotency and Conflicts").¶

evidence_ref:

OPTIONAL. A URI, maximum 512 characters. A reference to evidence of the asserted occurrence.¶

evidence_digest:

OPTIONAL. A string, the family's prefixed digest form (sha-256: plus base64url, no-padding encoding), classified as a raw-octet digest ([I-D.draft-mcguinness-oauth-mission], Section "Commitment Mechanisms"): computed over the exact octets of the referenced artifact as exchanged, with no canonicalization. evidence_ref and evidence_digest MAY both appear: when they do, evidence_digest MUST commit the bytes evidence_ref names. Present alone, evidence_digest is independent audit metadata.¶

evidence_ref and evidence_digest are bounded audit metadata about the asserted occurrence. The AS MUST NOT dereference evidence_ref in baseline processing and MUST NOT treat either member as authorization input.¶

observed_at:

OPTIONAL. An RFC 3339 [RFC3339] date-time: a caller assertion. The AS validates it for syntax and reasonable clock bounds only, never as trusted ordering or freshness, and records its own commit time as received_at in audit.¶

Semantics, beyond those every committed discharge has (Section 4.1):¶

• Condition selection. The request names the condition that fired. A later delivery presenting any valid condition against an already-discharged entry, a sibling condition, or the same condition under a different event_id, is acknowledged already_discharged (Section 4.3.4) and MUST NOT discharge the entry again or increment the version again; an exact event replay (the same tuple and the same fingerprint) is handled first by the dedup rule of Section 4.3.3.¶

• Terminal Missions. A delivery reaching the endpoint after completed, revoked, expired, or another terminal state returns an authenticated terminal_noop acknowledgement (Section 4.3.4). The AS reaches this determination only after the selector and authorization validation of Section 4.3.2, so a terminal Mission is never a shortcut past those checks.¶

• No expected_version. A stale-version refusal would delay a safety-reducing operation; the digest selectors above and the idempotency rules of Section 4.3.3 are the guards instead.¶

4.4. Discharge After Carryover

A discharge can target a Child Mission that has since been carried over to a replacement under a successor parent ([I-D.draft-mcguinness-oauth-mission-child-delegation], Section "Child Mission Carryover"). The targeted old child is then terminal and would answer terminal_noop, while its replacement keeps deriving the same authority until it expires. This section forwards the discharge instead.¶

• Resolution. When Carryover Evidence records the targeted Mission as carried, the AS MUST apply the discharge to the replacement's corresponding entry. The correspondence is the per-entry pairing Carryover Evidence records (the old record entry_digest paired with the replacement's), and the AS MUST NOT resolve it any other way, such as by matching resource and condition ([I-D.draft-mcguinness-oauth-mission-child-delegation], Section "Carryover Evidence and Observation"). A chain of carryovers resolves through each recorded pairing in turn. The AS MUST check the targeted entry's own latch in the old child before forwarding: an entry the old child had already discharged answers already_discharged without forwarding, since the replacement's effective set excludes it, and an exact event replay is handled first by Section 4.3.3. A targeted entry with no recorded counterpart for any other reason holds no authority in the replacement, and the request answers terminal_noop.¶

• Authorization. The AS MUST authorize the caller against the replacement's pinned mapping for the fired condition (Section 4.3.1). A caller that mapping does not admit gets the not_found collapse (Section 4.3.2).¶

• Commit. The replacement's entry is discharged under Section 4.1, with its own latch, version increment and commit boundary, before the response returns.¶

• Replay. The AS MUST record the resolved target in the operation's result record at first processing. A retry, including one after a further carryover, recovers that result and never resolves a new target. A replacement created after the discharge committed inherits it under carryover's no-reset rule ([I-D.draft-mcguinness-oauth-mission-child-delegation], Section "No State, Authority, Expiry, or Budget Reset").¶

• Response. The result describes the record that changed. Where the caller is authorized for the Mission Status operation on the replacement ([I-D.draft-mcguinness-oauth-mission-status], Section "Mission Status Operation"), the response is the replacement's signed Mission Status Response envelope, whose discharge_result carries forwarded_from (Section 4.3.4). A consumer verifies that response under the Status profile's procedure ([I-D.draft-mcguinness-oauth-mission-status], Section "Response"), with one change: in place of checking that mission.id equals the requested mission_id, it MUST verify that discharge_result.forwarded_from names the requested Mission and that mission.issuer equals its issuer, and it then reads mission as the replacement the result reports. A consumer that does not implement this document rejects such a response at that check, which fails closed. Otherwise the response is a Discharge Receipt (Section 4.4.1). Neither places the replacement's versions beside the old Mission's status.¶

4.5. Deployment-Internal Adjudication

A deployment that determines completion by means other than the discharge operation, such as a private status query or a recorded administrative action, invokes the same commit internally once it has decided, recorded under the same audited basis as any other lifecycle commit.¶

4.6. Worked Example

A Mission for alice reconciles Q3 payables. Its Authority Set has two entries: a read over the ledger, and a write to post journal entries, bounded to under 500 USD and discharged when the Q3 close is finalized:¶

[
  { "type": "mission_resource_access",
    "resource": "https://erp.example.com",
    "actions": ["invoices.read"] },
  { "type": "mission_resource_access",
    "resource": "https://erp.example.com",
    "actions": ["journal-entries.write"],
    "constraints": {
      "max_amount": { "amount": "500.00", "currency": "USD" },
      "terminal_when": [
        { "event_type": "accounting-period-closed",
          "discharge_authority": "close-management-2026-q3" } ] } }
]

discharge_authority names the authority approved to assert this condition: the close-management system's workload identity, not alice's agent, may assert accounting-period-closed (Section 4.3.1). The agent cannot drive its own discharge: it holds no mission_discharge authorization for that event_type.¶

While the period is open, the Authorization Server derives both entries. When the finance team finalizes the Q3 close, the close-management system calls discharge on the Mission Lifecycle endpoint, naming the write entry's entry_digest, this condition's condition_digest, event_type accounting-period-closed, and an event_id for its own occurrence record. The Authorization Server authenticates the caller against the resolved discharge_authority mapping, commits the latch, and returns a signed discharge_result of outcome discharged (Section 4.3.4). A Resource Server that holds a token for the write entry, and so cannot compute the record entry's digest, names the same target by the condition selector it reads from introspection (Section 4.2).¶

From then on the Authorization Server refuses to derive the write entry: a refresh returns a token carrying only the read entry. The Mission stays active, so the agent can still read the ledger to finish its reconciliation report, but it can no longer post journal entries. No revoke and no clock was needed; the write authority retired itself when the task it was granted for completed.¶

5.1. Entry Discharge

The completion capability (Section 3) adds the following:¶

• Monotonic by construction. Discharge only removes an entry's authority, so it is not a path to escalation; a compromised or injected agent cannot use terminal_when to widen authority, and the worst it can do is retire its own authority sooner. That is not an escalation, but a forced premature discharge is a denial-of-service on the task (authority the task still needs is withdrawn) and, where discharge is relied on as a guardrail, retires that guardrail early. Discharge authority (Section 4.3.1) bounds who can force it.¶

• Fail closed on unknown constraint. A consumer that does not understand the terminal_when constraint MUST refuse the entry (Section 3.5); ignoring the constraint would let a discharged entry continue to be narrowed, projected, or enforced, defeating discharge.¶

• Notification delivery is a temporary widening, not a fail-closed property. Before the AS receives and commits a discharge, it continues issuing against the entry: a lost or suppressed notification is a temporary widening relative to the real-world event, bounded by authenticated at-least-once delivery with retries to an idempotent acknowledgement (Section 4.3.4), monitoring and reconciliation, and the Mission's and its tokens' own lifetimes. This is not a fail-closed property: a deployment requiring cannot-determine-means-no-issuance runs a synchronous status or policy check outside this baseline.¶

• RS enforcement honesty. A stateless Resource Server cannot evaluate issuer-held discharge state from the token alone; it honors the issued token until expiry. Prompt cutoff on a discharged entry requires the Status profile's Mission Status operation or introspection projection, or runtime enforcement ([I-D.draft-mcguinness-oauth-mission-status], Section 3.7); an entry constraint the enforcing party does not understand still fails closed (Section 3.5).¶

• Already-issued tokens. The window between discharge and the expiry of a token already issued is the same residual revocation carries, bounded the same way (Section 3.3, Section 3.7).¶

• Forwarding after carryover. A delayed completion reaches the active replacement only through recorded entry pairings, never by matching, and a caller not authorized to inspect the replacement learns nothing about it from the Discharge Receipt (Section 4.4).¶

6.1. Completion Condition Disclosure

A terminal_when condition can reveal task structure: event_type may name a business event, a case, or a record whose mere existence is sensitive, and it rides the token where the entry is carried. A deployment SHOULD treat it as it treats other authority detail, and SHOULD avoid event identifiers that disclose more than the consuming party needs. discharge_authority is an opaque name and does not itself name a business event, but its resolution is deployment-defined and MAY correlate with a class of sensitive events; a deployment SHOULD weigh that when publishing its meaning. The event_id, evidence_ref, evidence_digest, and observed_at a discharge request carries (Section 4.3) do not ride the token; they land only in issuer audit records, which deployments MUST treat as Mission information-disclosure surfaces per the Status profile's audit-logging rule ([I-D.draft-mcguinness-oauth-mission-status], Section "Status Audit Logging").¶

A condition selector (Section 4.2) prevents reconstructing the record entry, but it is stable for its target and so can correlate a caller's requests over time. Its disclosure is limited to parties that already receive that entry's projection.¶

7.1. Common Constraints Registry: terminal_when

The completion capability (Section 3) registers one Common Constraint in the Mission Resource Access Profile's Mission Common Constraints registry ([I-D.draft-mcguinness-oauth-mission-resource-access]), under that registry's Specification Required policy. This document supplies the registration's required fields:¶

• Key Name: terminal_when¶

• Value Space: a JSON array of one or more completion-condition objects, each with a REQUIRED event_type (string) and an OPTIONAL discharge_authority (string, an opaque authority name); no two conditions in one array share a canonical form (Section 3.2). This Value Space is a breaking change, while this experimental draft's registration is still open, to the one a prior revision registered: event_source and max_staleness are removed and discharge_authority is added.¶

• Subset Rule: a candidate value is no broader than a reference value when the candidate's condition array contains every condition of the reference, compared structurally after the issuance profile's canonicalization; the candidate MAY add further conditions (Section 3.4).¶

• Intersection Rule: the union of the two condition arrays, where condition identity is byte equality of each condition object's canonical form under the issuance profile's canonicalization ([I-D.draft-mcguinness-oauth-mission]): byte-identical conditions collapse to one, and the union is sorted by the lexicographic order of those canonical bytes, so two implementations produce the identical array and the identical authority_hash.¶

• Change Controller: IETF¶

• Reference: this document, Section 3.2¶

terminal_when is a constraints member of the mission_resource_access authorization details type defined by the Mission Resource Access Profile ([I-D.draft-mcguinness-oauth-mission-resource-access]). event_type values are deployment- or registry-defined and opaque to this document, as purpose is, so this document establishes no registry of event types.¶

7.2. Media Type Registration

IANA is requested to register one media type per [RFC6838].¶

8.1. Completion Conformance

An Authorization Server claiming the completion capability MUST:¶

• treat an entry whose terminal_when has been discharged as discharged and refuse to derive it (Section 3.3);¶

• commit a discharge only through the discharge operation, meeting its authority, anti-oracle, and idempotency requirements (Section 4.3), or through an equivalently audited deployment-internal adjudication (Section 4.5);¶

• where it exposes the discharge operation, issue condition selectors and accept the operation's selector form as Section 4.2 defines, disclosing them through token introspection where it supports introspection for Mission-bound tokens;¶

• forward a discharge that targets a carried-over child as Section 4.4 defines;¶

• meet the commit semantics of Section 4.1, including atomicity, whichever way a discharge is determined;¶

• record a committed discharge as latched state that MUST NOT revert (Section 4.1);¶

• carry every parent completion condition into a derived entry when narrowing, permitting only added conditions (Section 3.4);¶

• where it offers the Status profile's Mission Status operation or the token introspection projection, omit a discharged entry from the authorization_details it returns (Section 3.3.1); and¶

• keep the terminal_when condition array committed by authority_hash and keep fired status out of it (Section 3.2).¶

A consumer claiming the completion capability MUST fail closed for an entry carrying a terminal_when constraint it does not understand (Section 3.5).¶

Normative References

[I-D.draft-mcguinness-oauth-mission]

McGuinness, K., "Mission-Bound Authorization for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission.html>.

[I-D.draft-mcguinness-oauth-mission-resource-access]

McGuinness, K., "Mission Resource Access Profile for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-resource-access.html>.

[I-D.draft-mcguinness-oauth-mission-status]

McGuinness, K., "Mission Status and Lifecycle for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-status.html>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC3339]

Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, <https://www.rfc-editor.org/rfc/rfc3339>.

[RFC5234]

Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/rfc/rfc5234>.

[RFC6838]

Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, <https://www.rfc-editor.org/rfc/rfc6838>.

[RFC7515]

Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, <https://www.rfc-editor.org/rfc/rfc7515>.

[RFC7662]

Richer, J., Ed., "OAuth 2.0 Token Introspection", RFC 7662, DOI 10.17487/RFC7662, October 2015, <https://www.rfc-editor.org/rfc/rfc7662>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC8725]

Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best Current Practices", BCP 225, RFC 8725, DOI 10.17487/RFC8725, February 2020, <https://www.rfc-editor.org/rfc/rfc8725>.

Informative References

[I-D.draft-mcguinness-mission-authzen]

McGuinness, K., "Mission-Bound Runtime Enforcement: AuthZEN Profile", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-authzen.html>.

[I-D.draft-mcguinness-mission-runtime]

McGuinness, K., "Mission-Bound Runtime Enforcement", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-runtime.html>.

[I-D.draft-mcguinness-oauth-mission-child-delegation]

McGuinness, K., "Mission Child Delegation for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-child-delegation.html>.

[I-D.draft-mcguinness-oauth-mission-expansion]

McGuinness, K., "Mission Expansion for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-expansion.html>.

[I-D.draft-mcguinness-oauth-mission-progressive]

McGuinness, K., "Mission Progressive Authorization for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-progressive.html>.

[I-D.draft-mcguinness-oauth-mission-signals]

McGuinness, K., "Mission Lifecycle Signals for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-signals.html>.