Mission-Bound Runtime Enforcement 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") makes a Mission a first-class OAuth artifact: a structured, human-approved, integrity-bound task whose authority bounds and outlives every token an agent derives. But it is deliberately an issuance-and-derivation layer. As its security considerations state, it does not evaluate individual runtime actions, so an active Mission still bounds a set of authority an agent may exercise freely within a token's lifetime, and preventing that authority from becoming ambient for individual consequential actions requires a separate runtime enforcement layer.¶

This document is that layer. It delivers exactly the four things the issuance profile names as out of scope, plus enforcement of the constraints that profile carries but does not evaluate:¶

1. evaluation of a request's parameters against the Mission at the point of use (Section 6, Section 7);¶

2. per-action runtime enforcement evidence (Section 10);¶

3. binding of the invoked tool or function identity to the Mission's approved authority (Section 6);¶

4. execution-time re-evaluation that closes the approval-to-execution (time-of-check to time-of-use) gap (Section 7);¶

and, additionally, metering of the consumption bounds (budget, call counts, duration) the issuance profile carries as constraints but leaves to this layer to enforce (Section 8).¶

The model is a Policy Enforcement Point (PEP) at each consequential execution boundary that, before the action runs, obtains a decision from a Policy Decision Point (PDP) evaluating the action against the Mission. Mission-bound tokens bound what authority may exist; this profile defines where and how that authority is re-checked before consequential effects occur.¶

This profile specifies enforcement invariants, not a wire protocol: it does not standardize a PDP decision API, an enforcement-scope discovery format, a Mission Status endpoint, or a portable audit receipt. It defines what a deployment MUST satisfy when it claims runtime Mission enforcement; the surfaces it deliberately leaves to deployments or future work are collected in Section 12.¶

2. 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 specification uses the terms "access token", "Authorization Server", "client", "protected resource", "resource owner", and "Resource Server" from OAuth 2.0 [RFC6749] through the terminology incorporated by [I-D.draft-mcguinness-oauth-mission]. It also uses the Mission, Mission Intent, Mission Issuer, Authority Set, Approver, delegation, and mission claim terminology from [I-D.draft-mcguinness-oauth-mission].¶

Policy Enforcement Point (PEP):

The component that can prevent a consequential action and that obtains and enforces a decision before the action runs. Depending on the action this is a Resource Server, an MCP server, an egress proxy, a workflow engine, or the orchestrator itself.¶

Policy Decision Point (PDP):

The component that evaluates a consequential action against the Mission and returns permit or deny. Its placement is a deployment choice (Section 6).¶

Resource policy:

Local policy of the Resource Server or protected resource, including object-level authorization, tenant configuration, legal holds, service invariants, and risk decisions. Mission authority is an upper bound and does not override Resource policy.¶

Consequential action:

An action that has external visibility or effect and so MUST be evaluated before it runs (Section 3.3).¶

Decision:

A PDP's permit-or-deny result for one action, bound to the inputs it evaluated (Section 6).¶

Policy-view version:

A deployment-opaque identifier the PDP emits for the materialized policy and Mission view it evaluated against, so a permit and its evidence record tie to a reproducible decision basis. It need not reveal policy content; it is a correlator that lets an operator determine which materialized policy, Mission state view, and constraint interpretation a decision used. It is local to the runtime layer and is distinct from the issuance profile's policy_version Mission-record field ([I-D.draft-mcguinness-oauth-mission]); this document does not interpret it beyond correlation, and defines no portable policy-version registry.¶

Runtime enforcement evidence:

The record a consequential action produces for a PDP decision or a PEP refusal path (Section 10).¶

Enforcement scope:

The set of resources, action classes, execution paths, PEP placements, supported authorization details, state sources, and evidence mechanisms for which a deployment claims conformance to this profile.¶

Operation profile:

Deployment documentation that defines operation-specific runtime semantics needed for interoperable enforcement within that deployment, including parameter normalization rules and duration measurement.¶

Resource Server runtime profile:

A deployment's Resource Server-facing conformance statement for this profile. It defines which protected resources and operations the Resource Server enforces, where the PEP sits, how local Resource policy composes with Mission authority, and which operation profiles apply.¶

Mission state source:

A deployment-trusted source from which the PDP establishes the Mission lifecycle state or the freshness of that state (Section 6.1).¶

Mission-bound token:

An access token issued under a Mission per [I-D.draft-mcguinness-oauth-mission], carrying authorization_details and a mission claim.¶

3. Runtime model

 Agent          PEP (action boundary)        PDP
   |                  |                        |
   |- action+params ->|                        |
   |                  | validate token         |
   |                  |- evaluate vs Mission ->|
   |                  |  (authority, params,   |
   |                  |   actor, state)        |
   |                  |<---- permit / deny ----|
   |                  | bind to params;        |
   |                  | write evidence         |
   |<- execute/refuse-|                        |

4. Resource Server runtime profile

An OAuth Resource Server that claims conformance to this runtime profile MUST publish or otherwise make available a Resource Server runtime profile for the protected resources and operations in scope. The Resource Server runtime profile is a deployment conformance statement, not an OAuth Authorization Server metadata extension and not a new access token format.¶

The Resource Server runtime profile MUST define:¶

• the protected resources, endpoint families, methods, tools, or operation identifiers for which Mission runtime enforcement applies;¶

• the minimum action class for each protected operation, including any Resource policy floor that raises the class above the default classification in Section 3.3;¶

• the PEP location that can prevent each protected operation and any known execution path that is outside the claim;¶

• the PDP or PDPs used for Mission-bound runtime decisions, including how the PEP and PDP authenticate and integrity-protect decision requests and responses when they are separate components;¶

• the supported authorization_details types, action identifiers, and constraint vocabularies for those operations;¶

• the operation profile for each protected operation or operation family, including parameter normalization, default insertion, omitted optional fields, set-like array handling, idempotency-key handling, and duration measurement when duration can be metered;¶

• the Mission state source, maximum staleness bound, and permit validity window used for each action class;¶

• how Resource policy is evaluated and composed with Mission authority, including local object authorization, tenant configuration, legal holds, service invariants, and risk policy;¶

• replay controls for permit use, including where single-use decision identifiers and idempotency keys are recorded and how long consumed identifiers are retained;¶

• any consumption-metering topology and consistency bound, including reserve, commit, settlement, retry, and reconciliation behavior; and¶

• the runtime enforcement evidence fields, retention window, and privacy treatment for decision and refusal records.¶

A Resource Server MUST NOT claim this runtime profile for an operation unless the operation's consequential effects pass through a PEP that can refuse the operation after token validation and before execution. A Resource Server that only validates the access token and checks static token audience or scope claims does not implement this runtime profile.¶

The Resource Server runtime profile MAY be documented in Resource Server configuration, resource-server metadata defined elsewhere, a contractual deployment profile, or another deployment-specific mechanism. This document does not define a discovery document, registry, or wire format for publishing it.¶

5. Token presentation and validation

The runtime decision is downstream of ordinary access token validation. Before using a token's Mission, authority, subject, client, actor, or confirmation-key values as decision inputs, the PEP MUST establish that the access token is valid for the protected resource and request. For the Mission-bound JWT access tokens defined by the issuance profile, this means validating the JWT per [RFC9068], verifying the issuer and audience, checking token expiry, and verifying any sender-constraint binding (cnf) under the proof-of-possession rules of the issuance profile ([I-D.draft-mcguinness-oauth-mission]); this profile defines no proof-of-possession mechanism of its own.¶

The underlying OAuth deployment MUST follow the applicable security best current practice in [RFC9700]. In particular, a Resource Server PEP MUST refuse a token whose audience is not intended for that Resource Server, and MUST verify the proof-of-possession check for a sender-constrained token before treating its cnf binding as authenticated.¶

A PEP MUST NOT ask a PDP to authorize an action from unverified token claims. If token validation fails, or if the deployment requires Mission governance for the protected operation and the token lacks a mission claim, the PEP MUST refuse before runtime Mission evaluation. When the PEP is an OAuth Resource Server, it uses the normal OAuth error behavior for the protected resource (for example, Bearer token errors under [RFC6750]); this profile defines no new OAuth error code.¶

Where the PEP and PDP are separate components, the decision request and response MUST be integrity-protected and the parties MUST authenticate each other. The PDP MUST accept token-derived inputs only from a PEP authorized for the declared enforcement scope. A deployment can satisfy this with a mutually authenticated channel, a signed decision request and response, or another mechanism with equivalent security properties. The PEP SHOULD send the PDP the minimum token-derived claims needed for the decision rather than the presented access token. If a deployment sends the access token itself to the PDP, the PDP MUST treat it as a credential, protect it against disclosure, and MUST NOT use it outside the declared enforcement scope.¶

6. The decision

Before a consequential action runs, its PEP MUST obtain a permit from a PDP that evaluates the action against the Mission the acting token is bound to. This is the normative contract. The decision API wire format is a deployment choice; Section 11 gives a non-normative example binding.¶

The PEP MUST supply the inputs the PDP needs for the Mission-bound decision. Runtime enforcement MUST evaluate:¶

• Authority. The action MUST be authorized by an applicable authorization_details entry the Mission-bound token carries, or that is otherwise available to the PEP or PDP for that token under the issuance profile (for example, through introspection when the authority is not represented inline). For an entry of type mission_resource_access, the action's resource and invoked action or tool identity MUST be within that entry's resource and actions, under the subset rule of [I-D.draft-mcguinness-oauth-mission]. The PEP asserts the capability identity (for example, the tool or function name) it will invoke; the PDP MUST refuse an identity outside the approved actions. For any other authorization_details type, the PDP MUST evaluate the action under that type's documented runtime semantics and MUST refuse if it does not understand or cannot enforce those semantics. For a capability sourced from a discovered catalog (an MCP tool catalog, an OpenAPI document, or an equivalent source), where the validating server recorded a source-content digest for the capability at derivation, the PDP MUST also refuse the action when the current source digest differs from the digest recorded at derivation (capability drift); the recorded digest is part of the derived authority and is covered by authority_hash ([I-D.draft-mcguinness-oauth-mission]). Cross-format canonicalization, signed capability manifests, and cross-catalog identity remain out of scope (Section 12).¶

• Resource policy. The runtime decision MUST include any applicable Resource policy. A Mission-bound token and runtime permit are an upper bound on authority, not a command for the Resource Server to perform the action. Resource policy MAY be evaluated by the PDP, by the Resource Server or PEP as a composed local authorization step, or by both. The action MUST fail closed unless both Mission authority and Resource policy permit it. Resource policy includes object-level authorization, tenant configuration, legal holds, service invariants, and risk policy.¶

• Parameters. Every constraints value on the applicable entry MUST be evaluated against the concrete action parameters. A constraint the PDP does not understand or cannot enforce or meter MUST cause refusal; it MUST NOT be ignored or reduced to disclosure-only treatment.¶

• Actor. When delegation is in effect, the PDP MUST evaluate the authenticated act chain as part of the runtime actor context and refuse a chain that is missing or malformed. Runtime enforcement consumes the actor context that results from the issuance profile's delegation checks; it does not recompute the issuance-time subset validation, and the runtime decision MUST NOT expand authority beyond the issued authorization_details. The issuance profile's delegation constraints are not re-applied here unless the deployment documents them as runtime Resource policy, but a deployment MAY apply additional actor-sensitive Resource policy (Section 6). When an act chain is present, the PDP MUST NOT treat client_id alone as the immediate actor.¶

• Time. The PDP MUST refuse if the decision context indicates the token is expired. The issuance profile caps a derived token's exp at mission_expiry, so the exp check enforces the Mission's expiry transitively. The standard mission claim and introspection do not surface mission_expiry; where a Mission state source does expose it (or reports the Mission expired), the PDP MUST refuse on it independent of the token's own exp. The PDP sets the permit's validity window from these inputs; that the action actually executes within that window is the executing PEP's reverification, not a decision input (Section 7).¶

• State. The PDP MUST refuse unless the Mission is active (Section 6.1).¶

On a deny, the PEP MUST refuse the action. Authority-expandable denials and the escalation workflow that turns a deny into a Mission expansion are out of scope and deferred (Section 12); in this profile a deny is terminal for the attempted action.¶

The PDP's placement is a deployment choice (co-located with the Mission's origin, embedded in the Resource Server, a tenant-scoped service, or a shared service); this document does not mandate one. The requirement is only that a PEP at each consequential boundary can reach an applicable PDP.¶

7. Parameter binding and time-of-check to time-of-use

A permit for an operation does not authorize arbitrary parameter values. For consequential writes, irreversible actions, external commitments, and privileged administration, the PDP MUST bind its permit to the normalized action parameters through a parameter_digest, and the executing PEP MUST recompute and reverify that digest immediately before acting.¶

• parameter_digest is sha-256: followed by the base64url, no padding, SHA-256 [RFC6234] of the JCS [RFC8785] serialization of the normalized parameter object. It MUST be computed under the same canonicalization rules the issuance profile defines (duplicate member rejection, significant array order, byte-for-byte URI comparison); this document does not define a second canonicalization.¶

• The operation profile MUST define default insertion, omitted optional fields, and set-like array handling before canonicalization.¶

• The permit MUST also bind the Mission reference, token issuer when available, token audience or protected resource, sub, client_id, actor context, sender-constraint confirmation key when present, action, resource, the authorizing authorization_details entry or an entry digest, the PDP's policy-view version, and a permit lifetime control bounded by the Mission state freshness requirement (Section 6.1). For a reversible consequential write, the control MUST be either a single-use decision identifier or a short validity window combined with an idempotency key that prevents repeat execution of the same normalized action. For an irreversible action, an external commitment, or privileged administration it MUST be a single-use decision identifier: a validity window alone does not bound how many times such a permit executes.¶

• Where a single-use decision identifier is used, the enforcing component MUST record consumed identifiers for at least the permit lifetime and MUST refuse, fail closed, any second presentation of a consumed identifier. This is independent of consumption metering and applies even when the action carries no consumption bound.¶

• The executing PEP MUST verify those bindings and MUST recompute the parameter_digest against the parameters it is about to use. A mismatch MUST cause refusal: the permit does not authorize the changed parameters.¶

This closes the time-of-check to time-of-use gap and prevents a permit from being replayed for a different request (the parameter_digest mismatches). For non-idempotent consequential writes, irreversible actions, external commitments, and privileged administration, the single-use decision identifier or idempotency key also prevents repeat execution of the same normalized action. Consequential reads do not require a parameter digest by default; the evaluation request still appears in the evidence record, by digest where the parameters are sensitive (Section 10).¶

Deployments MUST require parameter binding for consequential reads when read parameters materially change the effective resource set or disclosure risk. Independent of that risk judgment, a binding floor applies: a consequential read whose parameters select a cross-tenant or cross-audience scope, request a bulk or export-like result, or choose the returned fields or destination MUST bind those parameters; a deployment MUST NOT classify such a read as not materially affecting the resource set. Other examples that materially change the resource set or disclosure risk include privacy-sensitive filters and aggregation level. Ordinary reads that do not change the resource set or disclosure risk can remain unbound.¶

8. Consumption metering

Consumption bounds the Mission carries are enforced here, not at issuance. The issuance profile ([I-D.draft-mcguinness-oauth-mission]) defines three Mission-level consumption bounds in the Mission context that this layer meters:¶

• max_budget ({ amount, currency }): the PDP performs an atomic reserve-or-charge against the remaining balance for each consequential action and MUST refuse when the remaining balance is insufficient.¶

• max_calls ([ { call_class, count } ]): the PDP increments an atomic counter for the named call_class and MUST refuse a call past count.¶

• max_duration (an ISO 8601 duration, e.g. PT8H; the duration rule in Appendix A of [RFC3339]): the cumulative wall-clock duration of consequential activity under the Mission, as the issuance profile defines it (distinct from mission_expiry). The PDP accumulates the duration of consequential activity it reserves, commits, or permits and MUST refuse once that total would exceed the bound. For an action whose duration is not known before execution, the PDP MUST either reserve a bounded maximum duration or issue a duration lease that expires unless renewed; the PEP MUST stop the action or obtain a new permit before the reservation or lease is exhausted. After execution, the PEP MUST report the measured duration so the PDP can commit actual use and release any unused reservation. The operation profile defines how a single action's duration is measured so that PDPs accumulate consistently.¶

A per-entry constraints value that expresses a consumption bound is metered the same way. When an applicable entry or the Mission's context carries such a bound, the PDP MUST meter use against it and MUST refuse a consequential action that would exceed it.¶

The exactness of a consumption bound depends on the decision topology, and this profile does not overpromise:¶

• Under a single serializing PDP for the Mission, the check and decrement can be atomic, and the bound is exact.¶

• Under multiple or distributed PDPs (for example, Resource Server-hosted PDPs), an exact global counter is a distributed-counting problem. Such a deployment MUST publish the consistency bound it operates under (for example, per-PDP sub-budgets, or a bounded reconciliation window), and the effective guarantee is that bound, not exact-to-the-call enforcement.¶

A deployment MUST NOT advertise exact consumption enforcement it cannot meet under its chosen topology. As with all constraints, an unmetered or unrecognized consumption bound MUST cause refusal rather than silent pass-through.¶

For a metered permit, the PDP and PEP MUST define retry and idempotency behavior. A retry of the same normalized action under the same idempotency key or single-use decision identifier MUST NOT consume the bound twice. Reuse of an idempotency key or decision identifier for a different normalized action MUST cause refusal. For irreversible actions and external commitments, a deployment MUST define whether metering is reserved before execution and committed after success, or committed before execution; it MUST NOT leave the decrement ambiguous.¶

9. Failure modes

Enforcement is meaningful only if failure is bounded. A PDP or PEP MUST behave as follows; in all cases the evidence record (Section 10) MUST be sufficient to reconstruct which path produced a refusal.¶

10. Runtime enforcement evidence

Every PDP decision on a consequential action MUST produce a runtime enforcement evidence record. A PEP refusal for a consequential action, whether before a PDP decision (for example, token validation failure or PDP unreachability) or after a PDP permit (for example, a parameter_digest mismatch), MUST likewise produce a runtime enforcement evidence record with the available fields and the failure condition. This document fixes the minimum record content and local integrity requirements. The concrete record schema, any interoperable canonical byte representation, separate Decision Evidence and Execution Evidence object schemas, and portable cross-domain receipts are out of scope (Section 12).¶

11. Example decision API binding: AuthZEN

The decision contract of Section 6 is abstract. One possible binding is the OpenID AuthZEN Authorization API [AUTHZEN]: the PEP issues an Access Evaluation request and the PDP returns a decision. This section is non-normative and does not define an AuthZEN profile.¶

A deployment using AuthZEN can carry Mission and actor inputs in AuthZEN's open-ended context object:¶

• context.mission: id, origin, authority_hash, and the current state.¶

• context.actor: client_id, client-instance identifier when present, and the act chain as an array ordered root to leaf.¶

The AuthZEN subject remains the principal the decision is requested for; the invoked capability is the action and the target resource is the resource. Note that AuthZEN's resource.type is a resource-kind identifier, not the issuance profile's authorization_details type ([I-D.draft-mcguinness-oauth-mission]): the example uses a deployment resource kind (mission_resource), and a deployment that needs to convey the mission_resource_access type carries it in resource.properties or context. An evaluation request might look like:¶

{
  "subject":  { "type": "user", "id": "user_3p2q8mN1a0kV7tR" },
  "action":   { "name": "journal-entries.write" },
  "resource": { "type": "mission_resource",
                "id": "https://erp.example.com" },
  "context": {
    "mission": {
      "id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-",
      "origin": "https://as.example.com",
      "authority_hash": "sha-256:l3KvZ4mP5x0wQrR6tY2nD9bM7sX1cF8gH2vJ4kE5pNQ",
      "state": "active"
    },
    "actor": {
      "client_id": "s6BhdRkqt3",
      "act": [ { "sub": "tool-runner-7" } ]
    }
  }
}

On permit, the AuthZEN response carries the policy-view version, a decision identifier, the parameter_digest for parameter-bound classes, and a short validity window, for example:¶

{
  "decision": true,
  "context": {
    "policy_view_version": "pv-2026-11-02-17",
    "decision_id": "dec_K9pV4nT2sR7mB1xQ",
    "parameter_digest": "sha-256:9XbVt2cF8gH2vJ4kE5pNQl3KvZ4mP5x0wQrR6tY2nD9",
    "expires_at": "2026-11-02T08:15:30Z"
  }
}

This profile's substance is the enforcement contract, action classification (Section 3.3), PEP placement (Section 3.4), parameter binding (Section 7), consumption metering (Section 8), and runtime enforcement evidence (Section 10), which is independent of the decision wire. The context.mission and context.actor example members above could be standardized separately as a Mission-bound AuthZEN binding without changing this contract.¶

12. Out of scope

The following compose with this profile but are deferred to future work and are not required to enforce it:¶

• mission expansion and the authority-expandable-denial escalation workflow (a deny here is terminal for the attempted action);¶

• a standardized enforcement-scope manifest format and discovery mechanism;¶

• cross-format capability-source binding beyond same-source digest drift (signed capability manifests, cross-catalog identity);¶

• portable, third-party-verifiable decision receipts (this profile fixes only the local runtime enforcement evidence record);¶

• separate Decision Evidence and Execution Evidence object schemas and media types;¶

• actor provenance beyond the act chain, attestation of the execution environment, and a purpose registry;¶

• compilation of the Mission into an engine-native policy artifact (Cedar, OpenFGA, or equivalent) and standardization of PDP deployment modes;¶

• action-hierarchy and resource-containment subset extensions (this profile uses the flat subset rule of [I-D.draft-mcguinness-oauth-mission]); and¶

• risk-signal inputs to the decision (deployment-defined).¶

Structured per-argument attenuation of tool grants ([I-D.draft-niyikiza-oauth-attenuating-agent-tokens]) is a related issuance/delegation-layer primitive, not part of this runtime profile.¶

13. Security Considerations

14. IANA Considerations

This document has no IANA actions. The non-normative context.mission and context.actor example members of Section 11 are not registered in an IETF registry. The Mission-bound token claims this profile consumes are registered by [I-D.draft-mcguinness-oauth-mission].¶

15. References

Acknowledgments

This document is the runtime companion to Mission-Bound Authorization for OAuth 2.0 and builds on the OpenID AuthZEN Authorization API and the OAuth 2.0 Rich Authorization Requests and JWT access token specifications.¶

Author's Address