Network Working Group K. McGuinness Internet-Draft Independent Intended status: Standards Track 5 October 2026 Expires: 8 April 2027 Mission-Bound Runtime Enforcement: OAuth 2.0 Profile draft-mcguinness-mission-runtime-oauth-latest Abstract This document profiles Mission-Bound Runtime Enforcement for OAuth 2.0 access tokens. It specifies how validated token claims and token introspection results supply the runtime decision inputs, how OAuth mechanisms provide Mission state observations, and how protected resource metadata conveys runtime classification floors. Enforcement semantics are defined by Mission-Bound Runtime Enforcement; token semantics are defined by Mission-Bound Authorization for OAuth 2.0. 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/mission-bound-authorization/draft- mcguinness-mission-runtime-oauth.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft- mcguinness-mission-runtime-oauth/. Source for this draft and an issue tracker can be found at https://github.com/mcguinness/mission-bound-authorization. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 8 April 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction 2. Conventions and Terminology 3. Establishing Validated Credential Context 4. Runtime Input Mapping 4.1. Required Instance Attribution 5. Authority and State Sources 5.1. Credential Authority and Current Effective Authority 5.2. Mission State Sources 6. Resource-Owner Class Floors 7. Conformance 8. Security Considerations 9. Privacy Considerations 10. IANA Considerations 10.1. OAuth Protected Resource Metadata Registration 11. References 11.1. Normative References 11.2. Informative References Appendix A. Document History Acknowledgments Author's Address 1. Introduction Mission-Bound Runtime Enforcement [I-D.draft-mcguinness-mission-runtime] (the "runtime core") defines a binding-neutral decision contract: an established Mission reference, an effective-authority source, an active predicate and freshness bound, a subject and actor, an action and resource with normalized parameters, local-policy intersection, an authenticated permit or deny, an execution boundary, and fail-closed behavior on anything the deployment does not understand. It names these as abstract roles, so a non-OAuth binding can implement it without importing OAuth semantics. Mission-Bound Authorization for OAuth 2.0 [I-D.draft-mcguinness-oauth-mission] (the "issuance profile") defines the Mission-bound access token: its claims, its issuance and delegation, and the validation a Resource Server applies to it. Neither says which validated token values supply which runtime inputs, which OAuth mechanisms observe Mission state, or how a protected resource publishes its classification floor. This document answers those three questions for a deployment whose Mission-bound credential is an OAuth access token. Three specifications divide the work: +========================================+==========================+ | Specification | Owns | +========================================+==========================+ | Issuance profile | Token claims, | | [I-D.draft-mcguinness-oauth-mission] | issuance, delegation, | | | and baseline Resource | | | Server validation | +----------------------------------------+--------------------------+ | Runtime core | Decision inputs, | | [I-D.draft-mcguinness-mission-runtime] | enforcement, freshness | | | requirements, permits, | | | and evidence | | | obligations | +----------------------------------------+--------------------------+ | This document | The mapping between | | | them, OAuth state- | | | source integration, | | | and classification | | | metadata | +----------------------------------------+--------------------------+ Table 1 This document defines the processing rules that mapping needs and one protected resource metadata member (Section 6). It cites the runtime core's invariants, failure modes, and evidence requirements and the issuance profile's token validation rather than restating them. A decision API is a separate choice. The AuthZEN profile ([I-D.draft-mcguinness-mission-authzen]) carries the runtime core's decision between a PEP and a PDP whatever credential supplied its inputs, and a deployment using this document does not need it. A deployment on a different Mission substrate supplies its own credential profile and uses the runtime core unchanged ([I-D.draft-mcguinness-mission-substrate]). 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 uses Policy Enforcement Point (PEP), Policy Decision Point (PDP), established Mission, decision, Resource policy, consequential action, high- consequence class, Enforcement Scope Statement, and the action-class names as defined by the runtime core ([I-D.draft-mcguinness-mission-runtime]). Validated credential context: The values a PEP has established for a presented access token under Section 3: the claims of a validated JWT access token, or the members of the introspection response for a presented opaque token. Credential authority: The authority the presented token itself carries: for a Mission-bound token, the authorization_details in the validated credential context; for an ordinary token joined to a Mission under an externally established reference, the authority it carries as issued (Section 5.1). Current effective authority: The Mission's approved Authority Set narrowed by whatever narrowing mechanism the deployment runs, as the runtime core's authority input defines it; the issuance profile's Status companion names it the Effective Authority Set ([I-D.draft-mcguinness-oauth-mission-status]). 3. Establishing Validated Credential Context 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, including its audience and, for a sender- constrained token, proof of possession of the confirmation key. The issuance profile defines that validation for both of its token forms; this document adds no validation step of its own: * A JWT access token is validated under the issuance profile's Resource Server rules, which apply [RFC9068] and verify any sender-constraint binding ([I-D.draft-mcguinness-oauth-mission], Section "Resource Server Enforcement"). * An opaque access token is resolved under the issuance profile's introspected token consumption mode: introspection before each use, an active response, the Resource Server's own identity in aud, and a sender-constraint binding verified locally ([I-D.draft-mcguinness-oauth-mission], Section "Introspected Token Consumption"). Each value the runtime decision uses is read from the resulting validated credential context (Section 4). For an action in a high-consequence class, the runtime core requires a sender-constrained acting credential ([I-D.draft-mcguinness-mission-runtime], Section "Credential Custody and Mediated Execution"). The cnf claim of a validated JWT, or the cnf member of the introspection response for an opaque token (Section 6.2 of [RFC9449], Section 3.2 of [RFC8705]), supplies the sender-constraint binding: a DPoP key (jkt), proved with a DPoP proof checked per Section 7.1 of [RFC9449], or a client certificate thumbprint (x5t#S256), proved over mutual TLS per Section 3 of [RFC8705]. Proof over mutual TLS means the certificate authenticated on the request's own TLS connection matches the bound thumbprint; a certificate merely received with the request, or a thumbprint match against a certificate the connection did not authenticate, establishes no possession. An access token whose validated credential context carries no such binding is a bearer token and does not meet that requirement, and a binding whose proof the PEP has not verified for the request supplies no confirmation key to the decision. The requirement attaches to the action's class, not to issuance: the issuance profile's level for the primary access token is unchanged ([I-D.draft-mcguinness-oauth-mission], Section "Mission- Bound Access Tokens"). Under the issuance profile alone, introspection freshness is per use: each response is an observation for one decision, not a cacheable state assertion ([I-D.draft-mcguinness-oauth-mission], Section "Mission State via Token Introspection"). A deployment that runs the Mission Status profile can have the Mission issuer's introspection projection carry fresh_until, until which the reported Mission state can be relied on without re-checking ([I-D.draft-mcguinness-oauth-mission-status]). That caches Mission state only. Token validation and the credential authority are not cached: an opaque token is resolved by introspection before each use, and each response remains one observation, never a cacheable authority record ([I-D.draft-mcguinness-oauth-mission], Section "Introspected Token Consumption"). A PEP MUST NOT ask a PDP to authorize an action from unverified token claims. If token validation fails, 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 document defines no new OAuth error code. A Mission reference reaches the decision in one of two ways. A credential-carried reference is the mission claim of a validated JWT, or the mission member of the introspection response for an opaque token. An externally established reference is supplied outside the token and verified against the acting credential under a join a binding profile defines, as the runtime core's Mission Binding Establishment requires ([I-D.draft-mcguinness-mission-runtime]): the Mission Authority Server's Mission Join is one ([I-D.draft-mcguinness-mission-authority-server]), and this document defines none of its own. If the deployment requires Mission governance for the protected operation and neither reference is established, the PEP MUST refuse. An external reference never substitutes for the claim where the protected resource requires Mission-bound tokens: a resource that advertises mission_bound_authorization_required rejects a token that lacks the mission claim ([I-D.draft-mcguinness-oauth-mission], Section "Protected Resource Metadata"), whatever reference the deployment could establish externally. 4. Runtime Input Mapping The runtime core states its decision inputs, permit binding, and required evidence fields as abstract roles ([I-D.draft-mcguinness-mission-runtime]). This section is their complete, normative realization on this profile. Each value is read from the validated credential context (Section 3): a JWT claim, or the introspection response member of the same name. +=======================+==================================================+ |Runtime-core role or |OAuth realization | |input | | +=======================+==================================================+ |Established Mission |The mission claim's id and issuer | |reference |[I-D.draft-mcguinness-oauth-mission], or an | | |externally established reference (Section 3) | +-----------------------+--------------------------------------------------+ |Authenticated subject |sub | +-----------------------+--------------------------------------------------+ |Client identity |client_id | +-----------------------+--------------------------------------------------+ |Immediate actor |The current actor in act when act is present; | | |otherwise the client client_id names | +-----------------------+--------------------------------------------------+ |Actor-delegation chain |act, when delegation is in effect | +-----------------------+--------------------------------------------------+ |Attester-verified actor|Instance Context: the client_instance claim or | |context |introspection member | | |([I-D.draft-mcguinness-oauth-client-instance-id]),| | |validated as that profile's Context Consumer | | |requires; it identifies the instance that obtained| | |the token and grants no authority, and attributing| | |a presentation to it requires the presenter | | |association of | | |[I-D.draft-mcguinness-oauth-client-instance-id], | | |Section 7.5: an instance-unique key under direct | | |Client Attestation validation, and authenticated | | |provenance for context preserved from an input | | |token | +-----------------------+--------------------------------------------------+ |Sender-constraint |cnf, verified during validation (Section 3) | |confirmation | | +-----------------------+--------------------------------------------------+ |Credential audience or |The protected resource the PEP guards; validation | |protected resource |has established that aud names it | +-----------------------+--------------------------------------------------+ |Authority entry |The applicable entry of the credential authority | | |for a Mission-bound token; under a join, the | | |applicable entry of the Mission's authority | | |(Section 5.1) | +-----------------------+--------------------------------------------------+ |Current effective |The approved Authority Set as narrowed, from a | |authority |source that reports the narrowing (Section 5.1) | +-----------------------+--------------------------------------------------+ |Credential issuer |iss | +-----------------------+--------------------------------------------------+ |Credential expiry |exp | +-----------------------+--------------------------------------------------+ |The Mission's |The mission claim's expires_at member where | |expires_at (time input)|present, or a Mission state source that reports | | |the Mission's expiry | +-----------------------+--------------------------------------------------+ |Mission state version |The Mission Status version member, the Mission's | |(mission_state_version)|state version | | |([I-D.draft-mcguinness-oauth-mission-status]) | +-----------------------+--------------------------------------------------+ Table 2 Four pairs in the table are related but distinct inputs: * client_id and act. The issuance profile gives client_id its ordinary meaning, the OAuth client that requested the token, and carries delegation in act ([I-D.draft-mcguinness-oauth-mission], Section "Resource Server Enforcement"). When delegation is in effect, the PDP MUST evaluate the authenticated act claim as part of the runtime actor context and refuse a chain that is missing or malformed; when an act claim is present, the PDP MUST NOT treat client_id alone as the immediate actor. * aud and the protected resource. Validation establishes that aud names the protected resource the PEP guards; the decision, the permit binding, and the evidence then identify that protected resource, the target of the action. * The credential authority and the current effective authority. The action falls within both (Section 5.1). * Credential expiry and Mission expiry. The PDP MUST refuse if the decision context indicates the token is expired (exp). Where the validated mission claim carries the expires_at member, the PEP or PDP MAY refuse actions past that instant without consulting a state source: the value is an immutable commitment and a ceiling only, carrying no liveness, so the runtime core's only-active rule and freshness requirements apply unchanged. Where a Mission state source separately reports the Mission expired, or exposes the Mission's expires_at, the PDP MUST refuse on it independent of the token's own exp: the baseline mission claim need not carry expires_at, and OAuth token introspection [RFC7662] does not itself surface it. The issuance profile caps the exp of every token the Mission Issuer derives at the Mission's expires_at ([I-D.draft-mcguinness-oauth-mission], Section "Mission-Bound Access Tokens"), so the exp check enforces the Mission's expiry transitively, as the runtime core's time input expects. A profile that makes the expires_at member REQUIRED for the credentials it governs, such as the Issuance Grant profile ([I-D.draft-mcguinness-oauth-mission-issuance-grant]), lets a validator check that cap directly. These realize the runtime core's decision inputs ([I-D.draft-mcguinness-mission-runtime]); the requirements themselves, including that no runtime input expands authority beyond the issued authority, are the runtime core's. The Mission reference is id and issuer. Neither authority_hash nor intent_hash is carried on the baseline mission claim or the default introspection projection, so a PDP has them for the runtime core's evidence only with direct Mission-record access, introspection's authority_hash disclosure privilege ([I-D.draft-mcguinness-oauth-mission]), or the Local Approved-Set Verification profile ([I-D.draft-mcguinness-oauth-mission-approved-set-verification], Section "Local Approved-Set Verification"). A deployment that needs authority_hash as a commitment proof rather than an audit correlator obtains it from the Mission issuer under the last of these. The runtime core's permit binding and required decision evidence record the roles above; their serialization is defined by the runtime core and the decision-API profile in use, for example [I-D.draft-mcguinness-mission-authzen]. 4.1. Required Instance Attribution The instance specification defines how to validate context and associate it with a presenter; this profile selects that association when Resource policy or the Enforcement Scope Statement requires instance attribution. The PEP validates the credential, Instance Context, and current proof under [I-D.draft-mcguinness-oauth-client-instance-id], Sections 7.3 and 7.5, before supplying the resulting identity to the PDP. The PDP relies on that PEP only under the decision API's authenticated trust boundary. A policy match on the resulting identity still grants no authority beyond the decision's other bounds. Where the path requires instance attribution, the PEP MUST refuse the request if context is absent or invalid, or if its association with the current presenter cannot be established. This is a credential- validation failure, using the instance specification's Section 7.6 invalid_token response and the runtime profile's pre-decision refusal evidence. An instance-unique key alone does not establish the association for upstream context. Optional context that establishes only participation can inform provenance evidence, but does not identify the current actor instance. This requirement is conditional on the path's policy, not a requirement that every Mission deployment use instance attribution. 5. Authority and State Sources The runtime decision needs two kinds of input that OAuth supplies separately: the authority an action is checked against, and observations of Mission state. 5.1. Credential Authority and Current Effective Authority The runtime core requires that the action fall within both the credential authority and the current effective authority, that the PDP never substitute the second for the first, and that the PDP fail closed on an authority-entry type it does not understand ([I-D.draft-mcguinness-mission-runtime]). On this profile the two bounds are: * the credential authority: for a Mission-bound token, the authorization_details of the validated JWT or, for an opaque token, of its introspection response; for an ordinary token joined to a Mission under an externally established reference (Section 3), the authority that token carries as issued, established and enforced as the join profile defines (the Mission Authority Server enforces it at the Resource Server or gateway, [I-D.draft-mcguinness-mission-authority-server]); and * the current effective authority: the approved Authority Set, narrowed by any narrowing mechanism the deployment runs. For a Mission-bound token with no narrowing mechanism running, the approved set already bounds the credential authority, so this bound needs no lookup. Otherwise it is established from a source that reports it (Section 5.2), and under a join the join profile draws it from the Mission. A token narrowed below its Mission's approved Authority Set is therefore evaluated at its own narrower entry. Each entry is enforced under its type's own specification, as the issuance profile requires of a Resource Server ([I-D.draft-mcguinness-oauth-mission], Section "Resource Server Enforcement"). 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-resource-access]. The PEP asserts the capability identity (for example, the tool or function name) it will invoke, and 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, the runtime core's fail-closed rule governing what it does not understand or cannot enforce. 5.2. Mission State Sources The runtime core defines an abstract freshness dial running from credential-lifetime expiry to a queried or event-driven active source, and requires a deployment to declare its position per action class ([I-D.draft-mcguinness-mission-runtime]). On this profile the dial has two parts that bound different things. Token validity bounds how long a credential stays usable with no state check at action time: +================+===============+============+=====================+ | Mechanism | Revocation | Per-action | Cannot provide | | | latency | cost | | | | floor | | | +================+===============+============+=====================+ | Token-lifetime | maximum | local | suspend, complete, | | expiry | token | clock | or any revocation | | | lifetime | check | inside the lifetime | +----------------+---------------+------------+---------------------+ | Refresh gated | the token | none at | anything between | | on active | lifetime | action | refreshes | | | | time | | +----------------+---------------+------------+---------------------+ Table 3 Where derivation and refresh of a Mission-bound token are gated on active ([I-D.draft-mcguinness-oauth-mission]), token-lifetime expiry conforms to the runtime core's Credential-lifetime freshness rule, and the refresh cycle to its rule for a refresh cycle gated on live Mission state, each at the token lifetime as its revocation latency floor. Mission freshness bounds how stale an observation of Mission state can be. The sources are token introspection [RFC7662] at the Mission issuer, the Mission Status profile ([I-D.draft-mcguinness-oauth-mission-status]), the Mission Status List ([I-D.draft-mcguinness-oauth-mission-status-list]), and Mission Lifecycle Signals ([I-D.draft-mcguinness-oauth-mission-signals]): +=============+===========+==============+============+=============+ |State source |Exposure | Per-action |Depends on |Cannot | | |bound | cost | |provide | +=============+===========+==============+============+=============+ |Issuer |the | one lookup |issuer |reuse of one | |introspection|interval | per use |availability|response | | |from the | | |across | | |lookup to | | |decisions | | |the action | | | | | |it serves | | | | +-------------+-----------+--------------+------------+-------------+ |Issuer |published | one lookup |issuer |revocation | |introspection|staleness | within the |availability|inside the | |with Status |bound, to | bound for | |bound | |fresh_until |fresh_until| Mission | | | | | | state; an | | | | | | opaque token | | | | | | is still | | | | | | introspected | | | | | | per use for | | | | | | its claims | | | +-------------+-----------+--------------+------------+-------------+ |Mission |published | one lookup |status |revocation | |Status |staleness | within the |surface |inside the | | |bound | bound, |availability|bound | | | | cacheable to | | | | | | fresh_until | | | +-------------+-----------+--------------+------------+-------------+ |Status List |Status List| local bit |list |terminal- | | |Token TTL | read, plus |publisher |state detail;| | | | one list |availability|a non-VALID | | | | fetch per | |bit sends the| | | | window | |consumer to | | | | | |the | | | | | |authoritative| | | | | |surface | +-------------+-----------+--------------+------------+-------------+ |Lifecycle |delivery | none (event- |stream |the pull | |Signals |latency | driven) |liveness |floor; a dead| | |within the | | |stream is | | |verified | | |stale state | | |stream | | | | +-------------+-----------+--------------+------------+-------------+ Table 4 Each Mission-freshness source is a separate mechanism whose requirements its own specification defines. A deployment adopts the sources its Enforcement Scope Statement declares; a normative reference here does not require a deployment to implement every source. A lifecycle observation is not by itself a source for the current effective authority. A contained Mission stays active, so an active observation, including an unchanged Mission Status List bit, says nothing about contained capability. On this profile the sources that do report it are full Mission Status or introspection carrying containment_version, and Mission Lifecycle Signals carrying the overlay change ([I-D.draft-mcguinness-oauth-mission-containment], Section "Visibility"); each is a containment-aware source in the runtime core's sense ([I-D.draft-mcguinness-mission-runtime]). Only the Mission issuer reports Mission state through introspection ([I-D.draft-mcguinness-oauth-mission]). A non-issuer Resource AS introspecting a local token ([I-D.draft-mcguinness-oauth-mission-cross-domain]) can establish local token validity, but not issuer-side Mission freshness. For the high-consequence classes, the runtime core requires an active freshness mechanism that reflects a revocation within the staleness bound ([I-D.draft-mcguinness-mission-runtime]); on this profile, that is token introspection at the Mission issuer, the Mission Status profile, a Mission Status List whose Status List Token TTL is within the bound (the Status List companion's swarm-scale pull floor, [I-D.draft-mcguinness-oauth-mission-status-list]), or Mission Lifecycle Signals. 6. Resource-Owner Class Floors A resource owner can carry its classification minimums to any PDP through its protected resource metadata [RFC9728], the OAuth realization of the runtime core's classification-floor rule ([I-D.draft-mcguinness-mission-runtime]): mission_action_class_floors: OPTIONAL JSON object. Each member name is an action identifier from the resource's actions vocabulary ([I-D.draft-mcguinness-oauth-mission-resource-access]); an action- family identifier, in that profile's action-family form, sets the floor for every action in the family. Each value is the minimum runtime action class for the mapped action: one of consequential_read, consequential_write, irreversible_action, external_commitment, or privileged_administration: this document's identifiers for the runtime core's Consequential read, Consequential write, Irreversible action, External commitment, and Privileged administration classes. A PDP with access to the resource's metadata MUST NOT classify a mapped action below its floor. The member is the interoperable carriage of the Resource-policy minimum the runtime core's classification floor already binds; it raises, and never lowers, an action's class. A PDP that does not recognize a mapped value MUST treat it as naming a high-consequence class. For the ERP resource of the runtime core's worked examples: { "resource": "https://erp.example.com", "mission_action_class_floors": { "journal-entries.read": "consequential_read", "journal-entries.write": "irreversible_action" } } 7. Conformance A deployment conforms to this profile where, for its declared enforcement scope, it: 1. establishes the validated credential context before any credential-derived value becomes a decision input (Section 3); 2. realizes each runtime-core role as Section 4 maps it; 3. evaluates each action against both the credential authority and the current effective authority (Section 5.1); 4. establishes the Mission reference from the credential, or verifies an externally established one where no resource requirement for Mission-bound tokens applies (Section 3); 5. observes Mission state through sources from Section 5.2 that satisfy the runtime core's freshness requirements it adopts for each action class; and 6. honors any classification floor it holds from protected resource metadata (Section 6). It also conforms to the runtime core ([I-D.draft-mcguinness-mission-runtime]) and the issuance profile ([I-D.draft-mcguinness-oauth-mission]) for the same enforcement scope. This profile adds no separate conformance tier: adopting it is what makes "the Mission-bound credential is an OAuth access token" a true statement of the deployment's Enforcement Scope Statement, rather than a second scope to declare separately. 8. Security Considerations The runtime core's Security Considerations ([I-D.draft-mcguinness-mission-runtime]) apply in full, including the remote decision-channel requirement on a PEP/PDP boundary that is not co-resident. General OAuth security guidance [RFC9700] applies to the credentials this profile validates. A PDP that accepts an access token directly, rather than the minimum credential-derived claims a PEP needs to convey, MUST treat it as a credential, protect it against disclosure, and MUST NOT use it outside the declared enforcement scope. Evaluating an action against the approved Authority Set in place of the credential authority would let a narrowed token act with its Mission's broader authority, undoing the narrowing the issuance profile applied; Section 5.1 requires both bounds for that reason. 9. Privacy Considerations This document defines no evidence content of its own; the runtime core's privacy guidance governs the claims this profile maps into decision inputs and evidence records ([I-D.draft-mcguinness-mission-runtime]). 10. IANA Considerations 10.1. OAuth Protected Resource Metadata Registration This document registers the following in the "OAuth Protected Resource Metadata" registry ([RFC9728]): * Metadata Name: mission_action_class_floors * Metadata Description: JSON object mapping a protected resource's action identifiers to minimum runtime action classes. * Change Controller: IETF * Reference: this document, Section 6 The Mission-bound token claims this document maps are registered by [I-D.draft-mcguinness-oauth-mission]. 11. References 11.1. Normative References [I-D.draft-mcguinness-mission-runtime] McGuinness, K., "Mission-Bound Runtime Enforcement", 2026, . [I-D.draft-mcguinness-mission-substrate] McGuinness, K., "Mission Substrate Requirements", 2026, . [I-D.draft-mcguinness-oauth-client-instance-id] McGuinness, K., "Client Instance Identification for Attestation-Based Client Authentication", Work in Progress, Internet-Draft, draft-mcguinness-oauth-client- instance-id-00, 28 September 2026, . [I-D.draft-mcguinness-oauth-mission] McGuinness, K., "Mission-Bound Authorization for OAuth 2.0", 2026, . [I-D.draft-mcguinness-oauth-mission-resource-access] McGuinness, K., "Mission Resource Access Profile for OAuth 2.0", 2026, . [I-D.draft-mcguinness-oauth-mission-signals] McGuinness, K., "Mission Lifecycle Signals for OAuth 2.0", 2026, . [I-D.draft-mcguinness-oauth-mission-status] McGuinness, K., "Mission Status and Lifecycle for OAuth 2.0", 2026, . [I-D.draft-mcguinness-oauth-mission-status-list] McGuinness, K., "Mission Status List for OAuth 2.0", 2026, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, . [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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8705] Campbell, B., Bradley, J., Sakimura, N., and T. Lodderstedt, "OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens", RFC 8705, DOI 10.17487/RFC8705, February 2020, . [RFC9068] Bertocci, V., "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens", RFC 9068, DOI 10.17487/RFC9068, October 2021, . [RFC9449] Fett, D., Campbell, B., Bradley, J., Lodderstedt, T., Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449, September 2023, . [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, . [RFC9728] Jones, M.B., Hunt, P., and A. Parecki, "OAuth 2.0 Protected Resource Metadata", RFC 9728, DOI 10.17487/RFC9728, April 2025, . 11.2. Informative References [I-D.draft-mcguinness-mission-authority-server] McGuinness, K., "Mission Authority Server", 2026, . [I-D.draft-mcguinness-mission-authzen] McGuinness, K., "Mission-Bound Runtime Enforcement: AuthZEN Profile", 2026, . [I-D.draft-mcguinness-oauth-mission-approved-set-verification] McGuinness, K., "Mission Approved-Set Verification for OAuth 2.0", 2026, . [I-D.draft-mcguinness-oauth-mission-containment] McGuinness, K., "Mission Containment for OAuth 2.0", 2026, . [I-D.draft-mcguinness-oauth-mission-cross-domain] McGuinness, K., "Mission Cross-Domain Projection for OAuth 2.0", 2026, . [I-D.draft-mcguinness-oauth-mission-issuance-grant] McGuinness, K., "Mission Issuance Grant for OAuth 2.0", 2026, . Appendix A. Document History [[ To be removed from the final specification ]] * Establishing Validated Credential Context: the OAuth realization of the runtime core's sender-constraint requirement for high- consequence actions: the cnf binding of the validated credential context (a JWT's claim, or an opaque token's introspection response), with a proof the PEP verified; a context with no binding is a bearer token. Adds RFC 8705 and RFC 9449 as normative references. Acknowledgments This document extracts the OAuth-specific realization of Mission- Bound Runtime Enforcement so that document can state a binding- neutral contract. The author thanks reviewers of the runtime core for pressing on the substrate-neutrality claim until it was true. It builds on the OAuth 2.0 Rich Authorization Requests and JWT access token specifications. Author's Address Karl McGuinness Independent Email: public@karlmcguinness.com