Mission-Bound Runtime Enforcement: OAuth 2.0 Profile

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 9 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

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

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

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

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

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

11. References

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