Network Working Group K. McGuinness Internet-Draft Independent Intended status: Standards Track 22 June 2026 Expires: 24 December 2026 Mission-Bound Runtime Enforcement for OAuth 2.0 draft-mcguinness-oauth-mission-runtime-latest Abstract The Mission-Bound Authorization for OAuth 2.0 profile binds issued authority to a durable, approved Mission, but it governs issuance and derivation only: it does not evaluate individual runtime actions, so an active Mission can become ambient authority for the actions an agent takes within a token's lifetime. This document specifies the companion runtime layer for deployments that claim runtime Mission enforcement. Within a declared enforcement scope, each consequential action is evaluated, before it executes, against the Mission the acting credential is bound to: the action and its parameters against the Mission's approved authority and constraints, the actor against the delegation chain, and the Mission against its current state. It defines where enforcement MUST sit, how a permit is bound to concrete parameters to close the time-of-check to time-of-use gap, how carried consumption bounds (budget, call counts) are metered, and the runtime evidence each consequential action MUST produce. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://mcguinness.github.io/draft-mcguinness-oauth-mission/draft- mcguinness-oauth-mission-runtime.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft- mcguinness-oauth-mission-runtime/. Source for this draft and an issue tracker can be found at https://github.com/mcguinness/draft-mcguinness-oauth-mission. 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 24 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 1.1. Relationship to the issuance profile 1.2. Runtime conformance 1.3. Requirements Language 2. Overview 2.1. Terminology 2.2. Enforcement flow 3. Action classification 4. PEP placement 5. Token presentation and validation 6. The decision 6.1. Mission state and freshness 7. Parameter binding and time-of-check to time-of-use 8. Consumption metering 9. Failure modes 10. Runtime enforcement evidence 11. Example decision API binding: AuthZEN 12. Out of scope 13. Security Considerations 13.1. What this layer adds, and its limits 13.2. Placement and bypass 13.3. Classification integrity 13.4. Freshness and consumption honesty 13.5. Resource policy remains authoritative 13.6. TOCTOU and replay 13.7. Evidence privacy and correlation 14. IANA Considerations 15. References 15.1. Normative References 15.2. Informative References Acknowledgments Author's Address 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. Issuance is governance; this is enforcement. 1.1. Relationship to the issuance profile This document depends normatively on the issuance profile and is not implementable alone: it consumes Mission-bound access tokens that profile defines. It does not place any new requirement back on the issuance profile; it reads only fields that profile already defines: * the mission claim (id, origin, authority_hash); * the token's authorization_details, including entries of type mission_resource_access (resource, actions, constraints, and any delegation member) and any other entry type the deployment supports under the issuance profile's rules; * the act chain, when delegation is in effect; * the standard iss, aud, sub, client_id, and exp claims, when present in the token format; and * any cnf sender-constraint binding. Where this document needs a value the token does not carry (the current Mission lifecycle state, or a materialized policy-view version), it obtains it at runtime as described below, never by requiring the issuance profile to add a field. 1.2. Runtime conformance This profile is implemented by a runtime deployment, not by an OAuth Authorization Server alone. A deployment that claims conformance to this profile MUST document its enforcement scope, including: * the protected resources, action classes, and execution paths it mediates; * the PEP locations that can prevent those actions; * the PDP or PDPs that evaluate Mission-bound decisions; * the authorization_details types, action identifiers, and constraint vocabularies it supports; * the Mission state source and maximum staleness bound used for each action class (Section 6.1); * the runtime enforcement evidence mechanism and retention window (Section 10); and * any consumption-metering consistency bound it advertises (Section 8). A deployment MUST NOT claim runtime enforcement for a resource, action class, authorization_details type, or execution path outside that declared scope. A Mission Issuer conforms to the issuance profile; it does not become a runtime-conforming deployment merely by issuing Mission-bound tokens. The enforcement scope is a deployment conformance statement, not an OAuth Authorization Server metadata extension. This document defines no discovery mechanism, registry, or wire format for publishing it. Different deployments can document scope through configuration, operational policy, resource-server metadata defined elsewhere, or a contractual profile. 1.3. Requirements Language 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. 2. Overview 2.1. Terminology 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). Decision: A PDP's permit-or-deny result for one action, bound to the inputs it evaluated (Section 6). 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. 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. 2.2. Enforcement flow 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-| | The PEP first validates the token as described in Section 5. On permit the PEP reverifies the parameter binding, then executes; on deny it refuses. The PDP evaluates the action against the Mission's authority, the entry constraints, the actor chain, the Mission's current state, and Resource policy, as defined in Section 6. 3. Action classification The boundary between consequential and non-consequential actions is deployment policy, but a deployment MUST NOT define it so loosely that nothing is enforced. This document defines a default classification a deployment SHOULD adopt, and a floor it MUST observe. +===================+==================+==========+================+ | Class | Examples | PDP gate | Parameter | | | | | binding | +===================+==================+==========+================+ | Non-consequential | internal | not | n/a | | | reasoning, cache | required | | | | reads, planning | | | +-------------------+------------------+----------+----------------+ | Consequential | reading user | MUST | not required | | read | data, querying | | | | | logged APIs | | | +-------------------+------------------+----------+----------------+ | Consequential | updating | MUST | MUST | | write | records, posting | | | | | messages | | | +-------------------+------------------+----------+----------------+ | Irreversible | sending mail, | MUST | MUST, with | | action | payment, | | TOCTOU | | | deletion | | reverification | +-------------------+------------------+----------+----------------+ | External | signing, | MUST | MUST, with | | commitment | accepting terms | | TOCTOU | | | for the user | | reverification | | | | | and evidence | +-------------------+------------------+----------+----------------+ | Privileged | granting access, | MUST | MUST, with | | administration | changing policy | | TOCTOU and | | | | | evidence | +-------------------+------------------+----------+----------------+ Table 1 *Classification floor.* Actions in the *irreversible*, *external commitment*, and *privileged administration* classes MUST be treated as consequential and gated. A Mission's purpose, or deployment policy, MAY raise an action to a stricter class; it MUST NOT lower an action below the resource owner's minimum classification, and MUST NOT classify an irreversible, external-commitment, or privileged- administration action as non-consequential. A deployment that leaves such an action ungated does not enforce this profile for that action's class (Section 4). A deployment policy can require human confirmation, step-up authentication, or another local signal for privileged administration or external commitments. This profile does not define such a signal. 4. PEP placement Enforcement only works at the component that can actually stop the action. A deployment claiming this profile MUST observe these rules: * The PEP MUST sit at the last controllable boundary before the action. A permit checked further upstream does not survive parameter changes, retries, or routing that happen after the check. * A token-issuance decision does not replace execution-time authorization. A token-only Resource Server cannot claim runtime enforcement; the issuance gate is governance, the runtime gate is enforcement. * A tool-catalog filter does not replace per-call authorization. Filtering a tool list by the caller's authority is exposure control; every consequential tool call MUST still pass the runtime gate. * An orchestrator's internal check does not replace a Resource Server's PEP. Defense in depth is permitted; substitution is not. * If no PEP can prevent the action for a given class, the deployment MUST NOT claim runtime enforcement for that class, and MUST name the action classes and execution paths it does mediate. The boundary varies by action: an OAuth-protected API call is gated at the Resource Server; a consequential MCP tools/call at the MCP server; a local tool invocation, file write, or payment at the orchestrator or whatever component drives the call; external egress at an egress proxy. Where an action can be reached by an unmediated path (a debug shell, an unsanctioned egress route, a direct connector), the profile is not enforced for the classes that path reaches. 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) according to the proof-of-possession profile in use. 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. 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, and the PDP MUST evaluate: * *Authority.* The action MUST be authorized by an applicable authorization_details entry in the token. 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. Richer capability- source binding (source digests, cross-format identity) is out of scope (Section 12). * *Resource policy.* The PDP MUST evaluate 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. The PDP MUST refuse when Resource policy, object-level authorization, tenant configuration, legal holds, service invariants, or risk policy prohibit the action, even if the action is otherwise within the Mission authority. * *Parameters.* Every machine-enforceable constraints value on the applicable entry MUST be evaluated against the concrete action parameters. A constraint the PDP does not understand or cannot meter MUST cause refusal; it MUST NOT be ignored. * *Actor.* When delegation is in effect, the PDP MUST evaluate the authenticated act chain and refuse a chain that is missing, malformed, or references an actor not permitted for the entry. 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 or the requested action would execute outside the permit validity window. If its Mission state source reports that the Mission has expired, or reports a mission_expiry value that has passed, the PDP MUST refuse independent of the token's own exp. * *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. 6.1. Mission state and freshness A Mission-aware decision needs the Mission's current state, which a token alone does not convey. A runtime deployment MUST define the Mission state source it trusts for each enforcement scope. Examples include origin AS token introspection, a local Mission database, an authenticated status or event feed from the Mission origin, a materialized policy view, or a short-lived cross-domain credential whose lifetime is the deployment's accepted state lease. * The PDP MUST refuse a consequential action when it cannot establish, within the deployment's published staleness bound, that the Mission is active. * A state source MUST either report the Mission state with a freshness time, or define a lease interval over which a previously established active state remains acceptable for the relevant action class. * When the credential issuer also holds the Mission, the PDP can learn state through token introspection ([RFC7662]) at the issuer per [I-D.draft-mcguinness-oauth-mission]. A non-origin Resource AS introspecting a local token cannot report current Mission state under the issuance profile; it can establish local token validity, but not origin Mission freshness. * This document defines no cross-issuer by-Mission status query. Deployments that need tighter freshness than the token or cross- domain grant lifetime provides need an out-of-band trusted status feed or a future standardized Mission Status surface. * Each deployment profile MUST publish its maximum staleness bound per action class and state source. This document does not impose one universal value. 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 either a short validity window or a single-use decision identifier. * 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. Consequential reads do not require a parameter digest; the evaluation request still appears in the evidence record, by digest where the parameters are sensitive (Section 10). 8. Consumption metering Consumption bounds the Mission carries as constraints, such as a call count, a spend budget, or a duration, are enforced here, not at issuance. 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. +============================+================================+ | Condition | Required behavior | +============================+================================+ | Token validation fails, | Refuse before runtime Mission | | including sender- | evaluation | | constraint verification | | +----------------------------+--------------------------------+ | Mission governance is | Refuse before runtime Mission | | required but the token | evaluation | | lacks a mission claim | | +----------------------------+--------------------------------+ | PEP-PDP channel | Fail closed | | authentication or | | | integrity protection fails | | +----------------------------+--------------------------------+ | Mission state cannot be | Fail closed for consequential | | established within the | actions | | staleness bound | | +----------------------------+--------------------------------+ | PDP unreachable | Fail closed for consequential | | | actions; do not proceed on | | | cached permits past the window | +----------------------------+--------------------------------+ | Mission not active | Refuse | +----------------------------+--------------------------------+ | mission_expiry passed | Refuse | +----------------------------+--------------------------------+ | Unsupported | Refuse | | authorization_details type | | | for the action | | +----------------------------+--------------------------------+ | Unknown or unmetered | Refuse | | constraint on the | | | applicable entry | | +----------------------------+--------------------------------+ | Consumption bound would be | Refuse | | exceeded | | +----------------------------+--------------------------------+ | parameter_digest mismatch | Refuse | | at the executing PEP | | +----------------------------+--------------------------------+ | act chain missing, | Refuse | | malformed, or naming a | | | disallowed actor | | +----------------------------+--------------------------------+ | Invoked capability | Refuse | | identity outside the | | | approved actions | | +----------------------------+--------------------------------+ | Resource policy refuses | Refuse | | the action | | +----------------------------+--------------------------------+ | Request would broaden the | Refuse (expansion is out of | | Mission's authority | scope) | +----------------------------+--------------------------------+ Table 2 10. Runtime enforcement evidence Every PDP decision on a consequential action MUST produce a decision evidence record. A PEP refusal for a consequential action that occurs before a PDP decision (for example, token validation failure or PDP unreachability) or after a PDP permit (for example, parameter_digest mismatch) MUST also produce an enforcement evidence record with the available fields and the failure condition. This document fixes the record's content, its canonical form, and its local integrity; portable cross-domain receipts are out of scope (Section 12). A record MUST contain: * the decision or refusal result and, on refusal, the failure condition from Section 9; * the request time (RFC 3339 [RFC3339]); and * the parameter_digest for parameter-bound classes, or a privacy- preserving digest of the evaluation request otherwise. A record MUST also contain the following fields when they are available and trusted for the refusal or decision path: * the Mission reference (mission.id, mission.origin) and the authority_hash (and proposal_hash when known) it operated under; * the token issuer and audience or protected-resource identifier when available; * the authenticated sub, client_id, client-instance identifier when present, sender-constraint confirmation key when present, and the act chain projection when delegation applies; * the action and resource identifiers (and the asserted capability identity when applicable); * the authorization_details type and authorizing entry, or a digest of that entry when recording the full entry would disclose excess authority or sensitive policy; * the decision identifier, when the PDP produced one; and * the PDP's policy-view version. For a token-validation failure, the record MUST NOT describe unverified token claims as authenticated facts. It MAY include a digest of the presented token or rejected claim set for correlation and forensics, subject to the privacy requirements below. The authority_hash and proposal_hash in a record are the originating AS's commitments, cited as anchors; the PDP does not recompute them and is not required to hold the full Authority Set to record them, consistent with [I-D.draft-mcguinness-oauth-mission]. Requirements on the record: * It MUST be serialized with JCS [RFC8785] before storage and integrity protection, under the issuance profile's canonicalization rules, so identical inputs from one PDP produce identical bytes. * It MUST be append-only and integrity-protected; the deployment profile MUST name the mechanism (a hash-linked log, signed segments, a transparency anchor, or equivalent). * Raw parameters MUST NOT appear in the record; when retained for forensics they MUST be in separately access-controlled storage referenced by an opaque identifier, with only the parameter_digest in the record. * Records for one Mission MUST carry a deployment-defined sequence indicator so decision order can be reconstructed without relying on wall-clock time alone. * The deployment profile MUST publish a retention window no shorter than the Mission's effective audit horizon. 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. On permit, the response carries the policy-view version, a decision identifier, the parameter_digest for parameter-bound classes, and a short validity window. This profile's substance is the enforcement contract, action classification (Section 3), PEP placement (Section 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 (signed capability manifests, source-digest drift handling, 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 13.1. What this layer adds, and its limits Gating every consequential action against the current Mission prevents an active Mission from acting as ambient authority: authority is checked at the point of use, parameters are bound to the permit, consumption is metered, and each decision or refusal path is recorded. This closes the approval-to-execution gap the issuance profile leaves open. It does not make a compromised enforcement component safe. A compromised PEP can decline to consult the PDP or ignore its decision; a compromised PDP can return whatever decisions it chooses. Decision and enforcement evidence make such behavior auditable after the fact; they do not prevent it in the moment. Signed, externally verifiable decisions are future work (Section 12). 13.2. Placement and bypass The strongest decision logic is void if the PEP is not at the last controllable boundary, or if an unmediated path can reach the action (Section 4). A deployment's claim is only as strong as the set of execution paths it actually mediates; it MUST name that set. 13.3. Classification integrity Because "consequential" is partly deployment-defined, the classification floor of Section 3 is load-bearing: a deployment cannot evade enforcement by classifying an irreversible, external- commitment, or privileged-administration action as non-consequential. A purpose may raise a class but never lower it below the resource owner's floor. 13.4. Freshness and consumption honesty A permit is a lease, not a standing grant: stale Mission state MUST fail closed for consequential actions within the published bound (Section 6.1). Consumption bounds are exact only under a single serializing PDP; a deployment MUST NOT advertise exactness it cannot meet across distributed decision points (Section 8). 13.5. Resource policy remains authoritative Mission authority is a maximum authority envelope. It does not force a Resource Server to perform an action, bypass local authorization, or override object ACLs, tenant configuration, legal holds, service invariants, or risk policy. A runtime deployment that treats a Mission-bound permit as sufficient without Resource policy evaluation can perform actions that the resource owner or service would otherwise forbid. 13.6. TOCTOU and replay Parameter binding (Section 7) ties a permit to specific normalized parameters and a short window or single use, so a permit cannot be replayed for a different request or survive a parameter change between check and use. The executing PEP, not an upstream component, MUST perform the reverification. 13.7. Evidence privacy and correlation Runtime enforcement evidence is intentionally durable and therefore sensitive. It can reveal a subject's resources, action timing, delegated actors, and Mission correlation identifier even when raw action parameters are not stored. Deployments SHOULD minimize recorded authority entries, store entry and parameter digests where full values are not needed for audit, restrict access to evidence by role, and document the retention window declared under Section 10. Evidence shared across resource boundaries can also correlate activity by mission.id and authority_hash; deployments that require unlinkability need an additional privacy design outside this profile. General OAuth security guidance [RFC9700] applies to the underlying credentials. 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 15.1. Normative References [I-D.draft-mcguinness-oauth-mission] McGuinness, K., "Mission-Bound Authorization for OAuth 2.0", Work in Progress, Internet-Draft, draft-mcguinness- oauth-mission, 2026, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, . [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June 2020, . [RFC9068] Bertocci, V., "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens", RFC 9068, DOI 10.17487/RFC9068, October 2021, . 15.2. Informative References [AUTHZEN] OpenID Foundation, "OpenID AuthZEN Authorization API 1.0", 2025, . [I-D.draft-niyikiza-oauth-attenuating-agent-tokens] Aimable, N., "Attenuating Authorization Tokens for Agentic Delegation Chains", Work in Progress, Internet-Draft, draft-niyikiza-oauth-attenuating-agent-tokens-01, 15 June 2026, . [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization Framework: Bearer Token Usage", RFC 6750, DOI 10.17487/RFC6750, October 2012, . [RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection", RFC 7662, DOI 10.17487/RFC7662, October 2015, . [RFC9700] Lodderstedt, T., Bradley, J., Labunets, A., and D. Fett, "Best Current Practice for OAuth 2.0 Security", BCP 240, RFC 9700, DOI 10.17487/RFC9700, January 2025, . 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 Karl McGuinness Independent Email: public@karlmcguinness.com