Network Working Group K. McGuinness Internet-Draft Independent Intended status: Standards Track 23 June 2026 Expires: 25 December 2026 Mission-Bound Runtime Enforcement: AuthZEN Profile draft-mcguinness-oauth-mission-authzen-latest Abstract Mission-Bound Runtime Enforcement for OAuth 2.0 ([I-D.draft-mcguinness-oauth-mission-runtime]) specifies a substrate- independent decision contract: before each consequential action runs, a Policy Enforcement Point (PEP) obtains a permit from a Policy Decision Point (PDP) that evaluates the action against the Mission the acting token is bound to. That contract is independent of the decision wire format. This document is the concrete OpenID AuthZEN binding of that contract. It defines how a Mission is materialized into an evaluable policy view, how the abstract decision inputs map onto the AuthZEN Authorization API request and response, the Decision Evidence and Execution Evidence objects a deployment emits and their integrity, how runtime denials map onto AuthZEN decision context and optional error details, how requestable denials can compose with the AuthZEN Access Request and Approval Profile, and the AuthZEN representation of the runtime metering the base profile meters. It does not restate the enforcement semantics the base profile owns. 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-authzen.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft- mcguinness-oauth-mission-authzen/. 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 25 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. Requirements Language 2. Conventions and Definitions 3. Mission-to-Policy Materialization 3.1. Inputs 3.2. Properties 3.2.1. policy_view_id 3.3. Wire form 4. PDP Request 4.1. AuthZEN envelope binding 4.2. context.mission 4.3. context.actor 4.4. context.credential 4.5. context.parameters and context.parameter_digest 4.6. context.audience and context.freshness 4.7. context.capability_source 4.8. Worked PDP request 4.9. PDP-side consistency checks 5. Decision Evidence Object 5.1. Members 5.2. Integrity 5.3. Worked example 6. Execution Evidence Object 6.1. Members 6.2. Worked example 6.3. TOCTOU and parameter binding 6.4. Retention 7. Runtime Denial Classification 7.1. AuthZEN decision context 7.2. Permit response shape 7.3. Error response shape 8. Capability Source Binding 9. AuthZEN binding of consumption metering 10. Mission Status Composition 11. Security Considerations 11.1. Decision Evidence versus Execution Evidence 11.2. Evidence integrity and signing keys 11.3. Materialized view fidelity 11.4. Transport 12. Privacy Considerations 12.1. Evidence as PII sinks 12.2. Parameter exposure 12.3. Actor chain and Mission correlation 13. IANA Considerations 13.1. Media Type Registry 13.1.1. application/mission-decision-evidence+json 13.1.2. application/mission-execution-evidence+json 14. References 14.1. Normative References 14.2. Informative References Acknowledgments Author's Address 1. Introduction Mission-Bound Runtime Enforcement for OAuth 2.0 [I-D.draft-mcguinness-oauth-mission-runtime] (the "runtime profile") specifies the runtime enforcement layer for Mission-bound access tokens issued under Mission-Bound Authorization for OAuth 2.0 [I-D.draft-mcguinness-oauth-mission] (the "issuance profile"). The runtime profile is deliberately substrate-independent: it defines the decision contract, action classification, PEP placement, parameter binding and the time-of-check to time-of-use gap, consumption metering, failure modes, runtime enforcement evidence, and the runtime conformance scope, but it states that the decision API wire format is a deployment choice and that it is "not an AuthZEN profile". This document is that AuthZEN profile. It binds the runtime profile's abstract decision contract to the OpenID AuthZEN Authorization API [AUTHZEN]. It carries only the AuthZEN-binding deltas: * how a Mission becomes a materialized policy view the PDP evaluates (Section 3); * how the runtime profile's decision inputs map onto the AuthZEN subject/resource/action/context envelope, the worked PDP request, and the PDP-side consistency checks (Section 4); * the Decision Evidence and Execution Evidence objects, their integrity, and worked examples (Section 5, Section 6); * how runtime denials map onto AuthZEN decision context and optional error details (Section 7); * how requestable denials can compose with the AuthZEN Access Request and Approval Profile [ARAP]; * the binding of a Mission's approved authority to concrete, catalog-sourced capabilities (Section 8); and * the AuthZEN representation of the runtime metering the runtime profile meters (Section 9). This document does not restate the enforcement contract. It does not redefine which actions are consequential, where the PEP MUST sit, the semantics of parameter binding, the semantics of metering, the failure modes, or the runtime conformance scope; those are normatively defined in [I-D.draft-mcguinness-oauth-mission-runtime] and are referenced, not duplicated, here. 1.1. 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. Conventions and Definitions This document uses JSON [RFC8259] as the data model for all PDP requests, responses, and evidence objects. JCS canonicalization [RFC8785] applies wherever an integrity hash is computed, under the canonicalization rules of [I-D.draft-mcguinness-oauth-mission]; this document does not define a second canonicalization. "SHA-256" refers to [RFC6234]. A digest is encoded in the integrity- anchor encoded form of [I-D.draft-mcguinness-oauth-mission]: sha-256: followed by the base64url, no-padding encoding of the digest. The terms Policy Enforcement Point (PEP), Policy Decision Point (PDP), consequential action, Resource policy, decision, Mission state source, and enforcement scope are used as defined in [I-D.draft-mcguinness-oauth-mission-runtime]. The Mission claim (id, origin, authority_hash), the integrity anchors (intent_hash, authority_hash), and authorization_details entries of type mission_resource_access are used as defined in [I-D.draft-mcguinness-oauth-mission]. Additional terms specific to this binding: Materialized policy view: The reproducible, evaluable form of a Mission's approved authority produced by the issuing Authorization Server or a trusted compiler and consumed by the PDP (Section 3). Decision Evidence: The runtime enforcement evidence record emitted by the PDP, in the concrete object form of Section 5. Execution Evidence: The record emitted by the PEP or executor after the authorized action's outcome is determined (Section 6). HTTP message examples follow the AuthZEN specification [AUTHZEN] for the decision request and response, and [RFC9457] for problem-details error bodies where a deployment carries them outside the AuthZEN envelope. 3. Mission-to-Policy Materialization The PDP evaluates a Mission against an action. The issuing Authorization Server, or a trusted compiler, reproducibly materializes the Mission's approved authority as an evaluable policy view the PDP loads and addresses. 3.1. Inputs * The Mission's approved Authority Set (the authorization_details entries, including mission_resource_access entries with their resource, actions, and constraints), as committed by authority_hash ([I-D.draft-mcguinness-oauth-mission]). * The derivation policy_version recorded at the approval event. 3.2. Properties The materialized policy view MUST satisfy: * Reproducibility: the same inputs produce byte-identical materialized output under the canonicalization of [I-D.draft-mcguinness-oauth-mission]. * Identifiable: the materialized view carries a policy_view_id so PDP cache entries are addressable. * Bounded: materialization is faithful and does not enlarge the Authority Set's semantic bounds. A materialized view is an evaluation aid, never new authority. 3.2.1. policy_view_id policy_view_id is the integrity-anchor encoded form ([I-D.draft-mcguinness-oauth-mission]) of the SHA-256 of the JCS- canonical bytes of the materialized view envelope: SHA-256(JCS({ "typ": "mission-policy-view", "iss": , "value": })) The envelope reuses the domain-separated, issuer-bound integrity- anchor envelope of [I-D.draft-mcguinness-oauth-mission] with a new typ; this document defines no second canonicalization. Because policy_view_id is a content hash, it uniquely addresses the materialized form: any change to the view yields a new policy_view_id, so equality on policy_view_id is the cache identity and freshness test. 3.3. Wire form This profile does not pick a concrete policy-language wire form for the materialized view. Implementations MAY use canonical input bundles the AuthZEN PDP consumes directly, or an engine-native artifact. Compiling a Mission into an engine-native policy artifact and standardizing a policy-view carriage format are out of scope ([I-D.draft-mcguinness-oauth-mission-runtime]). 4. PDP Request The PDP request realizes the runtime profile's abstract decision contract over the OpenID AuthZEN Authorization API [AUTHZEN]. AuthZEN defines a top-level envelope with subject, resource, action, and context members. This profile binds the Mission-bound decision inputs into that envelope. It does not change which inputs MUST be evaluated; those are defined by the runtime profile. This binding is used after ordinary access-token validation under [I-D.draft-mcguinness-oauth-mission-runtime]: the PEP MUST NOT ask a PDP to authorize an action from unverified token claims, and the PEP- PDP channel MUST be integrity-protected and mutually authenticated as that profile requires. 4.1. AuthZEN envelope binding +==========+============================================+ | AuthZEN | Mission-bound binding | | member | | +==========+============================================+ | subject | The principal the decision is requested | | | for. | +----------+--------------------------------------------+ | resource | The target resource, with the canonical | | | resource identifier the PEP supplies. | +----------+--------------------------------------------+ | action | The requested action identifier (for | | | example, journal-entries.write), which the | | | PDP evaluates against the approved actions | | | per [I-D.draft-mcguinness-oauth-mission]. | +----------+--------------------------------------------+ | context | Carries the Mission-bound context object | | | defined below. | +----------+--------------------------------------------+ Table 1 4.2. context.mission The mission member identifies the governance record and its current materialized view: id: REQUIRED. A string. the Mission's id. origin: REQUIRED. A string containing a URI. the Mission's origin. authority_hash: REQUIRED. A string. the Authority Set integrity anchor, in the integrity-anchor encoded form ([I-D.draft-mcguinness-oauth-mission]). state: REQUIRED. A string. the current Mission lifecycle state the PEP established from its Mission state source ([I-D.draft-mcguinness-oauth-mission-runtime]). policy_version: REQUIRED. A string. the policy_version recorded at the approval event. policy_view_id: REQUIRED. A string. the materialized view identifier (Section 3). 4.3. context.actor The actor member carries the authenticated actor context when delegation is in effect, reconstructed from the access token's act claim and the token's authenticated client identity per [I-D.draft-mcguinness-oauth-mission]: client_id: REQUIRED when known. A string. the authenticated client identity. client_instance_id: OPTIONAL. A string. a deployment-defined client-instance correlator when the PEP can establish one. act: OPTIONAL. An array of objects. the delegation chain projection, ordered root to leaf. For a single actor, the array has one member. The actor member carries the delegation chain only. Provenance beyond the delegation chain -- the tool a request invoked, a named workflow step, a human approver -- MUST NOT be encoded inside the act chain; the PDP evaluates the act chain as defined by the runtime profile, and provenance is recorded in dedicated evidence fields where the deployment captures it. 4.4. context.credential The credential member carries token-derived facts the PEP has already validated and that the PDP needs to enforce the runtime decision's time, issuer, and sender-constraint checks: issuer: REQUIRED when known. A string containing a URI. The token issuer. expires_at: REQUIRED when the token carries an expiry. An RFC 3339 [RFC3339] timestamp corresponding to the token expiry. confirmation: OPTIONAL. An object. A sender-constraint confirmation value or digest of that value, included only after the PEP has verified the proof-of-possession check for the presented token. The PEP MUST NOT include unverified credential claims in this member. 4.5. context.parameters and context.parameter_digest When parameter binding is required for the requested action's class under [I-D.draft-mcguinness-oauth-mission-runtime], the PEP supplies: parameters: CONDITIONAL. An object. the action's parameters as a JSON object. The shape is action-specific. The PEP MAY omit parameters and supply only parameter_digest where the raw values are sensitive (Section 12), but only when the PDP can still enforce the applicable parameter policy from the digest, supplied derived attributes, or local state. If the PDP needs raw parameter values to evaluate an applicable constraint and they are not supplied through an equivalent privacy-preserving form, it MUST deny with parameter_violation. parameter_digest: REQUIRED for parameter-bound classes. A string. the parameter_digest defined by [I-D.draft-mcguinness-oauth-mission-runtime]. This profile carries that value on the wire; it does not define a second digest or canonicalization. The executing PEP recomputes and reverifies the digest immediately before acting, and the PDP recomputes it over any supplied parameters, both as that section requires. 4.6. context.audience and context.freshness audience: REQUIRED. A string. the PEP's audience or protected- resource identifier. freshness: REQUIRED. An object. the freshness of the Mission state the PEP relied on, conveying the runtime profile's freshness inputs on the wire. Members: mission_status_issued_at: An RFC 3339 [RFC3339] timestamp. mission_status_expires_at: An RFC 3339 timestamp. mode: A string. one of fresh, cached, or event_driven (Section 10). freshness_at: An RFC 3339 timestamp. when the PEP's view of the Mission state was current. The deployment's maximum staleness bound, and the rule that a consequential action MUST fail closed when the Mission cannot be established as active within that bound, are defined by the runtime profile ([I-D.draft-mcguinness-oauth-mission-runtime]); the freshness object is only their wire representation. 4.7. context.capability_source For catalog-sourced actions, the PEP supplies the capability-source binding in context.capability_source using the object defined in Section 8. For non-catalog actions, this member is absent. 4.8. Worked PDP request For a Q3 invoicing Mission: POST /pdp/access/v1/evaluation HTTP/1.1 Host: pdp.example.com Content-Type: application/json Authorization: ... { "subject": { "type": "user", "id": "user_3p2q8mN1a0kV7tR", "properties": { "iss": "https://idp.example.com" } }, "resource": { "type": "journal-entry", "id": "je_2026Q3_inv_8421" }, "action": { "name": "journal-entries.write" }, "context": { "mission": { "id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEd", "origin": "https://as.example.com", "authority_hash": "sha-256:l3KvZ4mP5x0wQrR6tY2nD9bM7sX1cF8gH2vJ4kE", "state": "active", "policy_version": "deploy-policy:v17", "policy_view_id": "sha-256:kP3xR9sQ7nM2vL4tY6bD1eF8jC5wH0pV2nR3kQ4" }, "actor": { "client_id": "client_erp-recon-agent", "client_instance_id": "inst_macbook_7f3a", "act": [ { "iss": "https://as.example.com", "sub": "client_erp-recon-agent" } ] }, "credential": { "issuer": "https://as.example.com", "expires_at": "2026-11-02T09:14:00Z" }, "parameters": { "amount_usd": 423.50, "source_invoice_id": "inv_2026Q3_842" }, "parameter_digest": "sha-256:t2Wq9pK7sR3mL6xT4bN1eY8jC5vH0nF2pV9zKqA", "audience": "https://erp.example.com", "freshness": { "mission_status_issued_at": "2026-11-02T08:14:00Z", "mission_status_expires_at": "2026-11-02T08:15:00Z", "mode": "cached", "freshness_at": "2026-11-02T08:14:00Z" } } } 4.9. PDP-side consistency checks In addition to evaluating the decision inputs the runtime profile requires, the PDP MUST verify that the AuthZEN-carried envelope is self-consistent: 1. The Mission state conveyed in context.mission.state is active; otherwise the PDP returns mission_inactive (Section 7). 2. authority_hash, policy_version, and policy_view_id carried in context.mission are consistent with the materialized policy view the PDP has loaded for this Mission; otherwise the PDP returns stale_state. 3. When context.credential.expires_at is present, it has not passed; otherwise the PDP returns credential_invalid. 4. The context.freshness the PEP supplied is within the deployment's staleness bound; otherwise the PDP returns stale_state, with the freshness-window violation in the denial reason. 5. When context.parameters is present, the PDP-recomputed digest matches context.parameter_digest; otherwise the PDP returns parameter_violation. 6. For catalog-sourced actions, context.capability_source is present and matches the approved source binding; otherwise the PDP returns capability_drift. 5. Decision Evidence Object The runtime profile requires a decision evidence record for every PDP decision on a consequential action and fixes the minimum content and local integrity requirements. This section gives the concrete object, canonicalization, and integrity envelope an AuthZEN deployment emits. 5.1. Members decision_id: REQUIRED. A string. unique decision identifier. ABNF: 1*64( ALPHA / DIGIT / "-" / "_" ). At least 128 bits of entropy. mission: REQUIRED. An object. the PDP request's context.mission object (id, origin, authority_hash, and, when known, policy_version and policy_view_id), extended with intent_hash and, when known, a consent-disclosure commitment, so the evidence chains back to the exact approved Mission. Within mission, id, origin, and authority_hash are required; the others are optional. These hashes are the issuing AS's commitments cited as anchors; the PDP does not recompute them. subject: REQUIRED. An object. PDP inputs as supplied, after PDP- side normalization. resource: REQUIRED. An object. PDP inputs as supplied, after PDP- side normalization. action: REQUIRED. An object. PDP inputs as supplied, after PDP- side normalization. audience: REQUIRED. A string. PDP inputs as supplied, after PDP- side normalization. actor: OPTIONAL. An object. PDP inputs as supplied, after PDP-side normalization. credential: OPTIONAL. An object. token-derived inputs as supplied, after PDP-side normalization. This member MUST contain only claims the PEP verified before invoking the PDP. parameter_digest: OPTIONAL. A string. PDP inputs as supplied, after PDP-side normalization. capability_source: OPTIONAL. An object. the catalog-source binding the PDP evaluated for catalog-sourced actions. decision: REQUIRED. A string. one of permit or deny. contributing_constraints: REQUIRED when the decision turned on one or more authority or constraint entries. An array of strings. the identifiers of the constraints the PDP evaluated (constraints keys, authorization_details entry types). For a permit this records what was checked; for a deny, what failed. sequence: REQUIRED. An integer. the per-Mission sequence indicator the runtime profile requires, so the decision stream has a verifiable order and gaps are detectable. MUST be zero or greater. denial_reason: CONDITIONAL. A string. present when decision is deny. A value from Section 7 or a constraints key. evaluated_at: REQUIRED. An RFC 3339 [RFC3339] timestamp. evidence_envelope: REQUIRED. An object. integrity protection (Section 5.2), carrying a format (string, required) and a value (string, required). A Decision Evidence Object is a closed object: it MUST NOT contain members other than those defined above. 5.2. Integrity The evidence_envelope carries the integrity protection over the Decision Evidence content. This AuthZEN profile defines the concrete serialization required by [I-D.draft-mcguinness-oauth-mission-runtime]: the Decision Evidence object is serialized as JCS [RFC8785] canonical JSON before integrity protection. The default format is jws-compact, a JWS Compact Serialization [RFC7515] whose payload is the JCS canonical bytes of the Decision Evidence object with the evidence_envelope member removed during signing. Verification re-removes evidence_envelope and verifies the JWS against the emitter's published signing key. For Decision Evidence emitted by a PDP, the emitter is the PDP. For Execution Evidence emitted by a PEP or executor, the emitter is that PEP or executor. { "evidence_envelope": { "format": "jws-compact", "value": "eyJhbGciOiJFUzI1NiIsImtpZCI6InBkcC1rZXkt..." } } This profile defines only the jws-compact format. Additional formats MAY be defined by future specifications; implementations MUST reject envelopes with unsupported formats. 5.3. Worked example { "decision_id": "dec_8K2nP4qV9rL3tY6sB1zN0eF7jB", "mission": { "id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEd", "origin": "https://as.example.com", "authority_hash": "sha-256:l3KvZ4mP5x0wQrR6tY2nD9bM7sX1cF8gH2vJ4kE", "intent_hash": "sha-256:wQ7p4LHnX9Md0LqJ6sZJ8b8mZ3rN2xT5pV4lE6s", "policy_version": "deploy-policy:v17", "policy_view_id": "sha-256:kP3xR9sQ7nM2vL4tY6bD1eF8jC5wH0pV2nR3kQ4" }, "subject": { "type": "user", "id": "user_3p2q8mN1a0kV7tR" }, "actor": { "client_id": "client_erp-recon-agent", "client_instance_id": "inst_macbook_7f3a", "act": [ { "iss": "https://as.example.com", "sub": "client_erp-recon-agent" } ] }, "credential": { "issuer": "https://as.example.com", "expires_at": "2026-11-02T09:14:00Z" }, "resource": { "type": "journal-entry", "id": "je_2026Q3_inv_8421" }, "action": { "name": "journal-entries.write" }, "parameter_digest": "sha-256:t2Wq9pK7sR3mL6xT4bN1eY8jC5vH0nF2pV9zKqA", "audience": "https://erp.example.com", "decision": "permit", "contributing_constraints": [ "mission_resource_access", "max_amount_usd" ], "sequence": 42, "evaluated_at": "2026-11-02T08:14:03Z", "evidence_envelope": { "format": "jws-compact", "value": "eyJhbGciOiJFUzI1NiIsImtpZCI6InBkcC1rZXkt..." } } Decision Evidence is durable and integrity-protected. It is the authoritative record of what the PDP evaluated, not proof that the action occurred. 6. Execution Evidence Object The PEP or executor emits an Execution Evidence Object after the authorized action's outcome is determined. It records whether the permitted action was attempted, completed, failed, or suppressed, linked to the Decision Evidence by decision_id. 6.1. Members execution_id: REQUIRED. A string. unique execution identifier. ABNF: 1*64( ALPHA / DIGIT / "-" / "_" ). At least 128 bits of entropy. decision_id: REQUIRED. A string. the linked Decision Evidence. mission_id: REQUIRED. A string. the Mission id, mirrored from the linked Decision Evidence for join-key convenience. parameter_digest: CONDITIONAL. A string. MUST be present when the linked Decision Evidence carries one, and MUST match it. outcome: REQUIRED. A string. one of attempted, completed, failed, or suppressed. suppressed means the action was permitted but the executor chose not to attempt it (for example, a kill-switch or a secondary deny). outcome_at: REQUIRED. An RFC 3339 [RFC3339] timestamp. error: CONDITIONAL. A string. error identifier when outcome is failed or suppressed. attempted_at: OPTIONAL. An RFC 3339 timestamp. timing context. completed_at: OPTIONAL. An RFC 3339 timestamp. timing context. result_summary: OPTIONAL. An object. minimal action result metadata (for example, affected resource counts). MUST NOT carry user- content payloads. evidence_envelope: REQUIRED. An object. integrity protection in the same form as Decision Evidence (Section 5.2), carrying a format (string, required) and a value (string, required). An Execution Evidence Object is a closed object: it MUST NOT contain members other than those defined above. 6.2. Worked example { "execution_id": "exe_4r9SqLm8tY2pXkV3nR0eF7jB1zN6cQ5w", "decision_id": "dec_8K2nP4qV9rL3tY6sB1zN0eF7jB", "mission_id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEd", "parameter_digest": "sha-256:t2Wq9pK7sR3mL6xT4bN1eY8jC5vH0nF2pV9zKqA", "outcome": "completed", "attempted_at": "2026-11-02T08:14:04Z", "completed_at": "2026-11-02T08:14:05Z", "outcome_at": "2026-11-02T08:14:05Z", "result_summary": { "rows_affected": 1 }, "evidence_envelope": { "format": "jws-compact", "value": "eyJhbGciOiJFUzI1NiIsImtpZCI6InBlcC1rZXkt..." } } Decision Evidence and Execution Evidence are linked but distinct. Authorization is not proof that an action occurred; a Decision Evidence record with no corresponding Execution Evidence record indicates the action was not attempted, or that the executor failed to emit evidence. 6.3. TOCTOU and parameter binding The semantics of parameter binding and the time-of-check to time-of- use gap are defined by the runtime profile ([I-D.draft-mcguinness-oauth-mission-runtime]). In this binding, the parameter_digest chain runs from the PDP request through Decision Evidence to Execution Evidence: if the executed action's effective parameters differ from those the PDP evaluated, the digest mismatch is detectable in audit. The PEP MUST NOT emit Execution Evidence that claims an attempted or completed execution under a parameter_digest that does not match the linked Decision Evidence. When the executing PEP detects a mismatch before acting, it MUST refuse the action and emit Execution Evidence with outcome set to suppressed and error set to parameter_mismatch, or emit an equivalent PEP-refusal evidence record under the deployment's runtime evidence mechanism. When values nonetheless diverge across the chain, the audit consumer MUST classify the action as parameter-mismatch and treat it as equivalent to an unauthorized action for compliance purposes. 6.4. Retention Decision Evidence and Execution Evidence MUST be retained for at least the deployment's audit retention window, which the runtime profile requires to be no shorter than the Mission's effective audit horizon. Regulated deployments MAY require longer retention. 7. Runtime Denial Classification When the PDP denies a consequential action, the failure condition is one defined by the runtime profile. This section binds those conditions to AuthZEN responses and gives the denial-reason identifiers carried in Decision Evidence: * out_of_authority: the action is not within the Authority Set. * acr_insufficient: the actor's acr does not satisfy the Mission's acr constraint. MAY be satisfied by [RFC9470] step-up authentication. * amr_insufficient: the actor's amr does not satisfy the Mission's amr constraint. MAY be satisfied by step-up authentication. * stale_state: the PEP-supplied freshness is stale or inconsistent with the materialized policy view. * mission_inactive: the Mission state is not active. * credential_invalid: token-derived credential facts supplied by the PEP are expired, inconsistent, or otherwise not usable for a runtime decision. * parameter_violation: parameters violate a constraint or the digest check fails. * resource_policy: Resource policy refuses the action independently of Mission authority. * quota_exceeded: a metered runtime bound is exhausted (Section 9). * capability_drift: a catalog-sourced action's current capability- source digest differs from the digest committed at derivation, or the presented tool_id is outside the approved set (Section 8). A deny is terminal for the attempted action. This profile does not define Mission expansion or an authority-expandable-denial workflow ([I-D.draft-mcguinness-oauth-mission-runtime]). When a deployment wants to route a denial through an approval workflow without treating the denial itself as access, it MAY compose this binding with the AuthZEN Access Request and Approval Profile [ARAP]. Approval through that workflow does not by itself authorize the action; the PEP MUST obtain a fresh AuthZEN decision, and any resulting permit and evidence remain subject to this profile. 7.1. AuthZEN decision context AuthZEN decisions use a boolean decision member and an optional context object. This profile defines the following AuthZEN response context members: decision_id: REQUIRED. A string. The Decision Evidence identifier for this decision. denial_reason: REQUIRED when decision is false. A string from Section 7 or a constraints key. parameter_digest: REQUIRED when the request was parameter-bound. A string. The digest bound to the decision. policy_view_id: REQUIRED when known. A string. The materialized policy view the PDP evaluated. permit_expires_at: REQUIRED when decision is true. An RFC 3339 timestamp after which the permit MUST NOT be used. single_use: OPTIONAL. A boolean. When true, the PEP MUST treat decision_id as a single-use decision identifier. insufficient_claims: OPTIONAL. An object. Present only for acr_insufficient or amr_insufficient denials. It MAY contain acr_values and amr_values members that identify authenticated claims that would lift the denial. access_request: OPTIONAL. An object. Present only when the deployment exposes the denial as requestable under [ARAP]. The object is the ARAP requestable-denial context. Its presence does not change the decision: false result and does not grant access. 7.2. Permit response shape When the PDP permits an action, it returns AuthZEN decision: true and the context needed by the PEP to enforce the permit lease. The decision_id, policy_view_id, and any parameter_digest bind the response to the Decision Evidence and to the request inputs the PDP evaluated. permit_expires_at and single_use express the permit lifetime controls required by the runtime profile. { "decision": true, "context": { "decision_id": "dec_8K2nP4qV9rL3tY6sB1zN0eF7jB", "parameter_digest": "sha-256:t2Wq9pK7sR3mL6xT4bN1eY8jC5vH0nF2pV9zKqA", "policy_view_id": "sha-256:kP3xR9sQ7nM2vL4tY6bD1eF8jC5wH0pV2nR3kQ4", "permit_expires_at": "2026-11-02T08:15:00Z", "single_use": true } } For an acr_insufficient or amr_insufficient denial, the PDP MAY include context.insufficient_claims, so the caller can satisfy the Mission's acr or amr constraint through OAuth step-up authentication challenge [RFC9470] at the protected resource and re-authenticate without a Mission expansion. 7.3. Error response shape The PDP returns its permit or denial in the AuthZEN response [AUTHZEN]. Runtime denials are successful evaluations and therefore are represented as decision: false with the context members above, not as transport errors. { "decision": false, "context": { "decision_id": "dec_8K2nP4qV9rL3tY6sB1zN0eF7jB", "denial_reason": "stale_state", "policy_view_id": "sha-256:kP3xR9sQ7nM2vL4tY6bD1eF8jC5wH0pV2nR3kQ4" } } Malformed requests, authentication failures, or PDP processing errors that prevent evaluation MAY be returned as AuthZEN or transport-level errors. A deployment MAY additionally carry [RFC9457] problem details for structured error information when the PDP is consumed over HTTP outside the AuthZEN envelope. 8. Capability Source Binding Consequential actions an agent discovers at runtime -- through a Model Context Protocol tool catalog, an OpenAPI document, a Protected Resource Metadata-linked catalog, or an equivalent capability source -- identify the source they came from, so a Mission's approved authority stays bound to concrete tools rather than to bare action names a later catalog revision could redefine. The runtime profile assigns capability identity to the approved actions and refuses an invoked identity outside them ([I-D.draft-mcguinness-oauth-mission-runtime]); this section gives the concrete binding an AuthZEN deployment presents for catalog- sourced actions. For MCP tools, this binding composes with the AuthZEN MCP profile's COAZ mapping [COAZ]. COAZ maps MCP tool definitions and invocation parameters into the AuthZEN Subject-Action-Resource-Context model; this profile adds Mission governance, source binding, Mission evidence, and runtime metering. A Mission-governed MCP deployment MAY use COAZ to construct the AuthZEN subject, resource, action, and parameter-bearing context members, but the Mission-specific context.mission, context.actor, freshness, permit binding, and evidence requirements in this document still apply. The minimum binding, committed by the validating server at derivation and presented by the executing component at request time in context.capability_source, is: { "tool_id": "mcp://docs.example.com/tools/write_document", "source_uri": "https://docs.example.com/.well-known/mcp", "source_digest": "sha-256:Qm0a...base64url-no-pad", "operation_ref": "tools/write_document" } tool_id: A string. a stable capability identifier the executing component asserts the action invokes. source_uri: A string. the discovery source the capability was resolved from. source_digest: A string. the integrity-anchor encoded form ([I-D.draft-mcguinness-oauth-mission]) over the exact retrieved source representation, recorded at derivation time. operation_ref: A string. the source-format-specific operation reference (MCP tool name, OpenAPI operationId, or equivalent). Rules: * The validating server records tool_id, source_uri, source_digest, and operation_ref for every consequential action sourced from a discovered catalog. These values are part of the approved Mission's derived authority and are therefore covered by authority_hash ([I-D.draft-mcguinness-oauth-mission]). * The PEP presents tool_id on consequential requests for catalog- sourced actions. The PDP MUST return capability_drift (Section 7) when the presented tool_id is outside the approved set. * When the current source digest differs from the digest recorded at derivation, the PDP MUST treat the change as drift: return capability_drift and refuse, per declared policy. * Actions not sourced from a discovered catalog (deployment- registered authorization_details types, first-party operations with stable identity) do not require this binding. Cross-format canonicalization, signed capability manifests, and media-type negotiation across catalog formats are out of scope ([I-D.draft-mcguinness-oauth-mission-runtime]); this binding requires only the stable identifier plus source evidence above. 9. AuthZEN binding of consumption metering The runtime profile owns consumption-metering semantics: it meters the Mission's max_budget, max_calls, and max_duration bounds, defines the atomic check-and-decrement, the single-versus-distributed-PDP consistency posture, retry and idempotency behavior, and the rule that an unmetered or unrecognized bound MUST cause refusal ([I-D.draft-mcguinness-oauth-mission-runtime]). This section adds only the AuthZEN wire representation; it defines no new metering semantics and no new constraint. A deployment that meters a per-action invocation cap evaluates the cap as part of the decision. When metering the cap would exceed it, the PDP MUST deny with quota_exceeded (Section 7) instead of returning a permit, and MUST record quota_exceeded as the denial_reason in Decision Evidence. Because the runtime profile counts a metered permit at decision time, the AuthZEN response surfaces the cap purely as the permit-or-quota_exceeded outcome; a permitted-but-failed action still counted, consistent with the runtime profile's metering rules. The exactness of the cap is the consistency bound the runtime profile's topology rules establish, not a property of this wire binding. 10. Mission Status Composition The PDP relies on Mission state to decide. The runtime profile defines the Mission state source, the maximum staleness bound, and the fail-closed rule ([I-D.draft-mcguinness-oauth-mission-runtime]). This binding conveys that state and its freshness on the wire through context.mission.state and context.freshness (Section 4), using a mode member with one of three values that describe how the PEP obtained the state: * fresh: the PEP consulted the Mission state source synchronously before the action. * cached: the PEP used cached Mission state within the deployment's staleness bound. * event_driven: the PEP relies on event-channel invalidation; cached state is valid until an event invalidates it. When freshness cannot be established within the bound, the PDP fails closed for consequential actions as the runtime profile requires; in this binding that surfaces as a stale_state denial (Section 7). 11. Security Considerations The runtime profile's Security Considerations ([I-D.draft-mcguinness-oauth-mission-runtime]) apply in full: placement and bypass, classification integrity, freshness and consumption honesty, Resource policy authority, TOCTOU and replay, and the limits of a compromised PEP or PDP. This section addresses only threats specific to the AuthZEN binding and the evidence objects. 11.1. Decision Evidence versus Execution Evidence Decision Evidence is not proof an action occurred. Implementations MUST emit Execution Evidence to record outcomes, and auditors MUST NOT treat Decision Evidence alone as evidence of action. An audit consumer MUST classify orphaned Decision Evidence (no matching Execution Evidence within the deployment's reconciliation window) as undetermined-outcome or, per deployment policy, as action-attempted; it MUST NOT treat it as proof of action. 11.2. Evidence integrity and signing keys The evidence_envelope binds each record to the emitting PDP or PEP. The PDP's jws-compact signing key MUST be resolvable in the PDP's published JWKS so a verifier can check Decision Evidence independently. The PEP or executor signing key used for Execution Evidence MUST be resolvable through a deployment-published key set or equivalent trust configuration. Implementations MUST reject evidence whose format is unsupported rather than accepting it unverified. 11.3. Materialized view fidelity A PDP that evaluates against a materialized view enlarging the Authority Set's bounds violates the bounded property of Section 3. authority_hash is the upper bound; policy_view_id lets the PDP detect that the view it loaded does not match the Mission the PEP referenced and deny with stale_state. 11.4. Transport The PDP endpoint and the audit channels carrying Decision Evidence and Execution Evidence MUST be served over TLS 1.2 or later (TLS 1.3 RECOMMENDED). PEP-to-PDP authentication MUST be mutual, satisfying the integrity and mutual-authentication requirement the runtime profile places on the PEP-PDP channel ([I-D.draft-mcguinness-oauth-mission-runtime]). Evidence at rest MUST be encrypted per the deployment's data-protection posture. 12. Privacy Considerations The runtime profile's evidence-privacy guidance ([I-D.draft-mcguinness-oauth-mission-runtime]) applies in full. This section addresses the concrete evidence objects. 12.1. Evidence as PII sinks Decision Evidence and Execution Evidence carry the authenticated subject, actor chain, resource and action identifiers, credential- derived correlators, capability-source identifiers, parameter_digest, and timing. These records are PII sinks and SHOULD be access- controlled to audit consumers with a legitimate need, encrypted at rest, and retained per the window of Section 6. 12.2. Parameter exposure The durable Decision Evidence record MUST NOT contain the raw parameters object; it carries only parameter_digest and, at most, parameter-class metadata, consistent with the runtime profile's rule that raw parameters never appear in the record. Where raw parameters must be retained for audit, they are held in a separately access- controlled store keyed by decision_id. When the parameters are themselves PII, the PEP SHOULD supply only context.parameter_digest to the PDP, omitting context.parameters, so the PDP evaluates against parameter-class policy without observing the raw values. The Execution Evidence result_summary MUST NOT carry user-content payloads. 12.3. Actor chain and Mission correlation The actor member carries the delegation chain, which MAY reveal service accounts, client instances, and organizational structure. Evidence carrying the same Mission id and authority_hash across resource boundaries can correlate a subject's activity; this is inherent to the Mission's role as a governance handle. Deployments that require unlinkability need an additional privacy design outside this profile. 13. IANA Considerations This document requests the following IANA actions. 13.1. Media Type Registry This document registers two media types per [RFC6838]. 13.1.1. application/mission-decision-evidence+json * Type name: application * Subtype name: mission-decision-evidence+json * Required parameters: none * Optional parameters: none * Encoding considerations: binary; JSON encoded in UTF-8 * Security considerations: see Section 11 * Interoperability considerations: see this document * Published specification: this document * Applications that use this media type: Mission-bound runtime enforcement deployments * Fragment identifier considerations: same as for application/json * Additional information: - Deprecated alias names for this type: none - Magic number(s): none - File extension(s): .json - Macintosh file type code(s): TEXT * Person & email address to contact for further information: Karl McGuinness public@karlmcguinness.com (mailto:public@karlmcguinness.com) * Intended usage: COMMON * Restrictions on usage: none * Author: IETF * Change controller: IETF 13.1.2. application/mission-execution-evidence+json * Type name: application * Subtype name: mission-execution-evidence+json * Required parameters: none * Optional parameters: none * Encoding considerations: binary; JSON encoded in UTF-8 * Security considerations: see Section 11 * Interoperability considerations: see this document * Published specification: this document * Applications that use this media type: Mission-bound runtime enforcement deployments * Fragment identifier considerations: same as for application/json * Additional information: - Deprecated alias names for this type: none - Magic number(s): none - File extension(s): .json - Macintosh file type code(s): TEXT * Person & email address to contact for further information: Karl McGuinness public@karlmcguinness.com (mailto:public@karlmcguinness.com) * Intended usage: COMMON * Restrictions on usage: none * Author: IETF * Change controller: IETF The context.mission, context.actor, context.credential, context.parameters, context.parameter_digest, context.audience, context.freshness, and context.capability_source members carried inside the AuthZEN request context object (Section 4) are AuthZEN extension data and are not registered in an IETF registry. The response context.decision_id, context.denial_reason, context.parameter_digest, context.policy_view_id, context.permit_expires_at, context.single_use, context.insufficient_claims, and context.access_request members (Section 7) are likewise AuthZEN extension data. The Mission-bound token claims this profile consumes are registered by [I-D.draft-mcguinness-oauth-mission]. 14. References 14.1. Normative References [AUTHZEN] OpenID Foundation, "OpenID AuthZEN Authorization API 1.0", 2026, . [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, . [I-D.draft-mcguinness-oauth-mission-runtime] McGuinness, K., "Mission-Bound Runtime Enforcement for OAuth 2.0", Work in Progress, Internet-Draft, draft- mcguinness-oauth-mission-runtime, 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, . [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, . [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, . [RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June 2020, . 14.2. Informative References [ARAP] McGuinness, K., "AuthZEN Access Request and Approval Profile - Draft 1", 2026, . [COAZ] OpenID Foundation, "AuthZen Profile for Model Context Protocol Tool Authorization - Draft 1", 2026, . [RFC9457] Nottingham, M., Wilde, E., and S. Dalal, "Problem Details for HTTP APIs", RFC 9457, DOI 10.17487/RFC9457, July 2023, . [RFC9470] Bertocci, V. and B. Campbell, "OAuth 2.0 Step Up Authentication Challenge Protocol", RFC 9470, DOI 10.17487/RFC9470, September 2023, . Acknowledgments This document is the AuthZEN binding of Mission-Bound Runtime Enforcement for OAuth 2.0 and builds on the OpenID AuthZEN Authorization API. The author thanks the OpenID AuthZEN community and the Mission-Bound Authorization implementer community for feedback. Author's Address Karl McGuinness Independent Email: public@karlmcguinness.com