Mission-Bound Runtime Enforcement: AuthZEN Profile

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

5.1. AuthZEN envelope binding

The runtime profile requires the PDP to confirm that the action falls within an approved Authority Set entry by matching the action's resource and action identity against that entry's resource and actions ([I-D.draft-mcguinness-mission-runtime]). In this binding, the approved entry's resource (the protected-resource or audience URI, for example https://erp.example.com) is matched against context.audience, not against the AuthZEN resource member. The AuthZEN resource carries the finer-grained object identity used only for Resource-policy evaluation. A PDP MUST perform the entry match against context.audience; matching it against the AuthZEN resource member is non-conforming and will diverge across deployments.¶

The AuthZEN subject is the token's authenticated sub: the Subject the Mission's authority is exercised for ([I-D.draft-mcguinness-oauth-mission]). It does not change under delegation. The acting agent's client_id and any act delegation chain are carried in context.actor, never in subject. The PDP binds the permit to subject together with the actor context, and the confused-deputy check ([I-D.draft-mcguinness-mission-runtime]) re-verifies that the action is for the same Subject it was authorized for.¶

subject.type is user unless the deployment profiles another value. subject.id is the token's authenticated sub. subject.properties.iss is REQUIRED when the Subject's issuer is known, carrying the issuer that authenticated the Subject, so a sub is disambiguated across issuers; a PEP that cannot establish the Subject's issuer omits it.¶

5.2. Mission Decision Context

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-mission-runtime]).¶

policy_version:

REQUIRED when known. A string. the policy_version recorded at the approval event. It is a Mission-record field ([I-D.draft-mcguinness-oauth-mission]) and is not carried on the mission claim or the introspection projection, so a PEP that is not co-located with the Mission record may not have it; such a PEP omits it and relies on policy_view_id for view correlation. A PEP that can obtain it (for example, co-located with the origin) includes it.¶

policy_view_id:

OPTIONAL. A string. the materialized view identifier (Section 4). The PDP is authoritative for the current view, so a PEP need not supply it; a PEP that has the value supplies it and the PDP uses it as a content-addressed correlator. When present it is checked as in Section 5.¶

5.3. Actor Decision Context

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

5.4. Credential Decision Context

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

5.5. Action Parameters and Parameter Digest

When parameter binding is required for the requested action's class under [I-D.draft-mcguinness-mission-runtime], the PEP supplies:¶

parameters:

CONDITIONAL. An object. When present, it MUST be the operation-profile-normalized parameter object ([I-D.draft-mcguinness-mission-runtime]): the same bytes the parameter_digest is computed over, so the PDP's recomputation matches. The shape is action-specific. The PEP MAY omit parameters and supply only parameter_digest where the raw values are sensitive (Section 14), 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-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.¶

5.6. Audience and Freshness Context

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

mode:

REQUIRED. A string. one of fresh, cached, or event_driven (Section 11).¶

freshness_at:

REQUIRED in every mode. An RFC 3339 [RFC3339] timestamp. when the PEP's view of the Mission state was current.¶

mission_status_issued_at:

REQUIRED for cached and event_driven, OPTIONAL for fresh. An RFC 3339 timestamp. when the relied-on Mission state was issued.¶

mission_status_expires_at:

REQUIRED for cached and event_driven, OPTIONAL for fresh. An RFC 3339 timestamp. when the relied-on Mission state (or its lease) expires.¶

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-mission-runtime]); the freshness object is only their wire representation.¶

5.7. Capability Source Context

For catalog-sourced actions, the PEP supplies the capability-source binding in context.capability_source using the object defined in Section 9. For non-catalog actions, this member is absent.¶

5.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_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-",
      "origin": "https://as.example.com",
      "authority_hash":
        "sha-256:l3KvZ4mP5x0wQrR6tY2nD9bM7sX1cF8gH2vJ4kE5pNQ",
      "state": "active",
      "policy_version": "deploy-policy:v17",
      "policy_view_id":
        "sha-256:kP3xR9sQ7nM2vL4tY6bD1eF8jC5wH0pV2nR3kQ4mZ7t"
    },
    "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:t2Wq9pK7sR3mL6xT4bN1eY8jC5vH0nF2pV9zKqA8dRn",
    "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"
    }
  }
}

5.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 exactly active; every other value, recognized or not, is non-active per the issuance profile's forward-compatibility rule ([I-D.draft-mcguinness-oauth-mission]) and the PDP returns mission_inactive (Section 8). A PDP with direct access to a Mission state source MUST prefer its own fresher view over context.mission.state, and MUST return mission_inactive when its view disagrees with the PEP-supplied state. PEP-supplied state is a floor, never a substitute for a state source the PDP can itself consult.¶

2. The id and authority_hash in context.mission equal the mission_id and authority_hash committed in the materialized policy view the PDP has loaded for this Mission ([I-D.draft-mcguinness-mission-runtime]); the PDP returns stale_state on any inequality. When context.mission.policy_view_id is present, it MUST equal the loaded view's policy_view_id, and the PDP returns stale_state on inequality. A PDP MUST NOT fail a decision solely because the optional policy_view_id or policy_version was omitted; the view the PDP loaded is authoritative.¶

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. For an action whose class requires parameter binding ([I-D.draft-mcguinness-mission-runtime]), context.parameter_digest MUST be present; if it is absent the PDP returns parameter_violation. When context.parameters is also present, the PDP-recomputed digest MUST match context.parameter_digest, otherwise parameter_violation. When parameters is omitted under the privacy carve-out (Section 5.5), the PDP MUST still be able to evaluate every applicable parameter constraint from the digest, supplied derived attributes, or local state, and returns parameter_violation if it cannot. A parameter-bound action MUST NOT be permitted without a verified parameter_digest.¶

6. For a catalog-sourced action whose approved entry recorded a capability source digest at derivation (Section 9), context.capability_source MUST be present and match the approved source binding; otherwise the PDP returns capability_drift. Whether an action is catalog-sourced, and whether a source digest was recorded, are determined from the materialized policy view, not from the PEP's request; where no source digest was recorded, this check does not apply.¶

5.10. Batch evaluations

The AuthZEN evaluations (boxcar) endpoint MAY be used to submit several Mission-bound decisions in one request. Each item is evaluated independently and on the same terms as a single request: each item yields its own Decision Evidence Object with its own decision_id and sequence, assigned in request order; consumption metering applies per item in request order (Section 10); and permits are per item, so a boxcar MAY return a mix of permits and denials. Batching is a transport optimization and changes none of the per-item enforcement semantics.¶

6.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; intent_hash is OPTIONAL (it is carried in neither the mission claim nor introspection, so only a PDP with direct Mission-record access can record it), and the remaining members 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.¶

request_digest:

CONDITIONAL. A string. a privacy-preserving digest of the evaluation request, in the integrity-anchor encoded form ([I-D.draft-mcguinness-oauth-mission]). REQUIRED when parameter_digest is absent for a consequential action, so the closed object still carries the request digest the runtime profile requires of every decision record ([I-D.draft-mcguinness-mission-runtime]).¶

capability_source:

OPTIONAL. An object. the catalog-source binding the PDP evaluated for catalog-sourced actions.¶

compensates_decision_id:

OPTIONAL. A string. the decision_id of the action this decision compensates, carrying the runtime profile's compensation link ([I-D.draft-mcguinness-mission-runtime]) so a compensating action reconciles against the action it reverses.¶

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 and entries the PDP evaluated (constraints keys, authorization_details entry types). For a permit it records every constraint key and entry type the decision relied on; for a deny it MUST list every entry that failed. Omitting an entry the decision turned on is non-conforming, so the array can be relied on to reconstruct the decision basis.¶

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 the closed set in Section 8. When the denial is a constraint violation, the value is parameter_violation and the specific failing constraints keys are carried in contributing_constraints, not in denial_reason, so the reason enum and the open constraint-key space never mix in one field.¶

evaluated_at:

REQUIRED. An RFC 3339 [RFC3339] timestamp.¶

evidence_envelope:

REQUIRED. An object. integrity protection (Section 6.3), 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.¶

6.2. Pre-decision refusal records

The Decision Evidence Object records a PDP decision, which is why its PDP-derived members are REQUIRED. The runtime profile also requires an evidence record for a PEP refusal that occurs before any PDP decision: token validation failure, a missing mission claim, PEP-PDP channel failure, PDP unreachability, or the PEP being unable to establish Mission state ([I-D.draft-mcguinness-mission-runtime]). Such a refusal has no PDP decision and cannot populate the PDP-derived members above. An AuthZEN deployment records it not as a Decision Evidence Object but as a refusal record carrying only the fields the PEP verified, at least audience, an action descriptor, evaluated_at, decision of deny, and a denial_reason from this pre-decision set: token_invalid, mission_claim_missing, channel_failure, pdp_unreachable, or state_unavailable (the PEP cannot establish Mission state to send to the PDP). These name PEP-side conditions and are disjoint from the PDP denial reasons of Section 8; a record that can populate the PDP-derived members is a Decision Evidence Object instead.¶

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

The JWS protected header MUST carry:¶

• kid: a key identifier resolvable in the emitter's published JWKS (Section 13.4), so a verifier can select the emitter's signing key independently.¶

• alg: ES256 [RFC7518] is mandatory to implement; an implementation MAY offer other JOSE algorithms but MUST implement ES256.¶

• typ: the registered media type of the evidence object being signed (application/mission-decision-evidence+json for Decision Evidence, application/mission-execution-evidence+json for Execution Evidence, Section 15). A verifier MUST reject a JWS whose protected typ is not the media type of the object it is verifying, so Decision Evidence and Execution Evidence signatures cannot be cross-used.¶

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

6.4. Worked example

{
  "decision_id": "dec_8K2nP4qV9rL3tY6sB1zN0eF7jB",
  "mission": {
    "id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-",
    "origin": "https://as.example.com",
    "authority_hash":
      "sha-256:l3KvZ4mP5x0wQrR6tY2nD9bM7sX1cF8gH2vJ4kE5pNQ",
    "intent_hash":
      "sha-256:wQ7p4LHnX9Md0LqJ6sZJ8b8mZ3rN2xT5pV4lE6sQqYY",
    "policy_version": "deploy-policy:v17",
    "policy_view_id":
      "sha-256:kP3xR9sQ7nM2vL4tY6bD1eF8jC5wH0pV2nR3kQ4mZ7t"
  },
  "subject": {
    "type": "user",
    "id": "user_3p2q8mN1a0kV7tR",
    "properties": {
      "iss": "https://idp.example.com"
    }
  },
  "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:t2Wq9pK7sR3mL6xT4bN1eY8jC5vH0nF2pV9zKqA8dRn",
  "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.¶

7.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, from this closed set: parameter_mismatch (the executing PEP found the effective parameters differ from those the permit bound), permit_expired (the permit's validity window had passed at execution), permit_consumed (re-presentation of an already-consumed single-use decision identifier), and kill_switch (execution suppressed by an operator or safety control). A deployment MAY define additional values, which MUST be collision-resistant names (a short name within a namespace the deployment controls, following the Collision-Resistant Name guidance of [RFC7519] Section 4.2) so they cannot collide with this set or another deployment's.¶

sequence:

REQUIRED. An integer. the per-Mission sequence indicator the runtime profile requires of every record, so the execution stream has a verifiable order and gaps are detectable. MUST be zero or greater.¶

measured_duration:

CONDITIONAL. A string. REQUIRED for a duration-metered action, otherwise absent. An ISO 8601 duration (the duration rule in Appendix A of [RFC3339]): the PEP's measured duration, the PDP's commit-or-release input for max_duration (Section 10).¶

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 6.3), 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.¶

7.2. Worked example

{
  "execution_id": "exe_4r9SqLm8tY2pXkV3nR0eF7jB1zN6cQ5w",
  "decision_id":  "dec_8K2nP4qV9rL3tY6sB1zN0eF7jB",
  "mission_id":   "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-",
  "parameter_digest":
    "sha-256:t2Wq9pK7sR3mL6xT4bN1eY8jC5vH0nF2pV9zKqA8dRn",
  "outcome":      "completed",
  "sequence":     43,
  "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.¶

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

7.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 audit horizon, the term defined in the Mission Record section of [I-D.draft-mcguinness-oauth-mission]. Regulated deployments MAY require longer retention.¶

8.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 the closed set in Section 8. A constraint violation uses parameter_violation; the specific failing constraints keys are carried in the Decision Evidence contributing_constraints, not here.¶

parameter_digest:

REQUIRED when the request was parameter-bound. A string. The digest bound to the decision.¶

policy_view_id:

REQUIRED. A string. The materialized policy view the PDP evaluated. The PDP is authoritative for the view, so it always knows and returns this value.¶

permit_expires_at:

REQUIRED when decision is true. An RFC 3339 timestamp after which the permit MUST NOT be used.¶

single_use:

CONDITIONAL. A boolean. When true, the PEP MUST treat decision_id as a single-use decision identifier. Absent, the permit is not single-use. For an action in the high-consequence classes ([I-D.draft-mcguinness-mission-runtime]) the PDP MUST include single_use: true, and the PEP MUST treat a high-consequence permit lacking it as invalid.¶

insufficient_claims:

OPTIONAL. An object. Present only for a step_up_required denial. It MAY contain acr_values and amr_values members that identify the authentication context Resource policy requires to lift the denial.¶

access_request:

OPTIONAL. An object. Present on an out_of_authority or action_approval_required denial when the deployment exposes it as requestable under [ARAP]. It is the ARAP requestable-denial context, carrying the submission endpoint and the denial binding that ties a later access request to this evaluation. Its presence does not change the decision: false result and does not grant access.¶

8.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:t2Wq9pK7sR3mL6xT4bN1eY8jC5vH0nF2pV9zKqA8dRn",
    "policy_view_id":
      "sha-256:kP3xR9sQ7nM2vL4tY6bD1eF8jC5wH0pV2nR3kQ4mZ7t",
    "permit_expires_at": "2026-11-02T08:15:00Z",
    "single_use": true
  }
}

For a step_up_required denial, the PDP MAY include context.insufficient_claims, so the caller can satisfy the Resource-policy authentication requirement through an OAuth step-up authentication challenge [RFC9470] at the protected resource and re-authenticate, without a Mission expansion. Because the requirement is Resource policy and not a Mission constraint, satisfying it changes the actor's authentication context, not the Mission or its Authority Set.¶

8.3. Permit binding in split topologies

A permit is valid only on the mutually authenticated channel and PEP identity that requested it, and MUST NOT be relayed to another component as a bearer grant. Where the requesting component and the executing PEP differ, the executor MUST receive the signed Decision Evidence (Section 6) and verify the runtime's binding fields (the Mission reference, audience, subject, client_id, actor context, action, resource, and parameter_digest) from it before acting, rather than trusting a relayed decision: true. A PEP permit cache MUST key on the complete request envelope, so a cached permit cannot be reused for a request whose envelope differs in any bound field.¶

8.4. 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:kP3xR9sQ7nM2vL4tY6bD1eF8jC5wH0pV2nR3kQ4mZ7t"
  }
}

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

10.1. Settlement exchange

The runtime profile requires the PEP to signal actual use so the PDP commits consumption and releases any reservation. In this binding, delivery of the Execution Evidence Object (Section 7) to the PDP is that commit-or-release signal: on receipt the PDP commits the consumption the linked action used and releases any reserved excess, keyed to the Execution Evidence's decision_id.¶

For a duration-metered action the PEP reports the measured duration in the Execution Evidence measured_duration member, and the PDP commits that duration against max_duration. A duration-lease renewal is a new re-evaluation request that carries the prior permit's decision_id in context.prior_decision_id, so the PDP continues the same metered activity rather than opening a new reservation. This exchange requires one request member and one evidence member:¶

context.prior_decision_id:

OPTIONAL. A string. Present on a duration-lease renewal request, carrying the decision_id of the permit being renewed. Absent on an initial request.¶

measured_duration (Execution Evidence):

REQUIRED for a duration-metered action, otherwise absent. A string containing an ISO 8601 duration (the duration rule in Appendix A of [RFC3339]): the PEP's measured duration for the executed action (Section 7).¶

13.1. Access Request Service in the trusted base

A deployment that composes with ARAP adds the Access Request Service to its trusted base: it adjudicates requestable denials and issues the approvals the PDP consumes as input. A compromised or misconfigured Access Request Service can auto-approve escalations, so it MUST be trusted, authenticated, and access-controlled like the PDP, and its auto-approval is bounded as above.¶

13.2. Denial oracle

The denial-reason identifiers and any contributing_constraints are a decision oracle: an agent can probe them to map authority it does not hold. The PEP SHOULD minimize the denial detail it relays to the agent; a generic refusal suffices to stop the action, and the full reason and contributing constraints belong in evidence, not in the agent-facing response. To bound probing through the request loop, deployments SHOULD rate-limit access requests per Mission and surface request provenance to Approvers, so a compromised agent driving repeated requestable denials is visible to the humans adjudicating them.¶

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

13.4. 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, by the JWS protected kid, 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 the same way through a deployment-published key set.¶

This profile fixes one concrete discovery convention: the PDP publishes its JWKS at a deployment-published location named in the enforcement scope statement ([I-D.draft-mcguinness-mission-runtime]), and the PEP or executor key set is published and named there likewise. A retired signing key MUST remain resolvable in the published key set for at least the evidence retention window, so records signed before a rotation stay verifiable after it.¶

Implementations MUST reject evidence whose format is unsupported rather than accepting it unverified.¶

13.5. Materialized view fidelity

A PDP that evaluates against a materialized view enlarging the Authority Set's bounds violates the bounded property of Section 4. 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.¶

13.6. 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-mission-runtime]). Evidence at rest MUST be encrypted per the deployment's data-protection posture.¶

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

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

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

15.1. Media Type Registry

This document registers two media types per [RFC6838].¶

16.1. Normative References

[AUTHZEN]

OpenID Foundation, "OpenID AuthZEN Authorization API 1.0", 2026, <https://openid.net/specs/authorization-api-1_0-final.html>.

[I-D.draft-mcguinness-mission-runtime]

McGuinness, K., "Mission-Bound Runtime Enforcement", Work in Progress, Internet-Draft, draft-mcguinness-mission-runtime, 2026, <https://datatracker.ietf.org/doc/html/draft-mcguinness-mission-runtime>.

[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, <https://datatracker.ietf.org/doc/html/draft-mcguinness-oauth-mission>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC3339]

Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, <https://www.rfc-editor.org/rfc/rfc3339>.

[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, <https://www.rfc-editor.org/rfc/rfc6234>.

[RFC6838]

Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, <https://www.rfc-editor.org/rfc/rfc6838>.

[RFC7515]

Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, <https://www.rfc-editor.org/rfc/rfc7515>.

[RFC7518]

Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, DOI 10.17487/RFC7518, May 2015, <https://www.rfc-editor.org/rfc/rfc7518>.

[RFC7519]

Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, <https://www.rfc-editor.org/rfc/rfc7519>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC8259]

Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/rfc/rfc8259>.

[RFC8785]

Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June 2020, <https://www.rfc-editor.org/rfc/rfc8785>.

16.2. Informative References

[ARAP]

McGuinness, K., "AuthZEN Access Request and Approval Profile - Draft 1", 2026, <https://openid.github.io/authzen/authzen-access-request-approval-profile-1_0.html>.

[COAZ]

OpenID Foundation, "AuthZEN Profile for Model Context Protocol Tool Authorization - Draft 1", 2026, <https://openid.github.io/authzen/authzen-mcp-profile-1_0.html>.

[I-D.draft-mcguinness-oauth-mission-expansion]

McGuinness, K., "Mission Expansion for OAuth 2.0", Work in Progress, Internet-Draft, draft-mcguinness-oauth-mission-expansion, 2026, <https://datatracker.ietf.org/doc/html/draft-mcguinness-oauth-mission-expansion>.

[RFC9457]

Nottingham, M., Wilde, E., and S. Dalal, "Problem Details for HTTP APIs", RFC 9457, DOI 10.17487/RFC9457, July 2023, <https://www.rfc-editor.org/rfc/rfc9457>.

[RFC9470]

Bertocci, V. and B. Campbell, "OAuth 2.0 Step Up Authentication Challenge Protocol", RFC 9470, DOI 10.17487/RFC9470, September 2023, <https://www.rfc-editor.org/rfc/rfc9470>.