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

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

SHA-256(JCS({
  "typ":   "mission-policy-view",
  "iss":   <mission.origin>,
  "value": <materialized view payload>
}))

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

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

REQUIRED. A string. the materialized view identifier (Section 3). It is content- addressed and self-sourcing (Section 3), so it is the authoritative view correlator the PDP relies on.¶

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_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"
    }
  }
}

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

2. authority_hash and policy_view_id carried in context.mission, and policy_version when present, are consistent with the materialized policy view the PDP has loaded for this Mission; otherwise the PDP returns stale_state. policy_view_id is the authoritative correlator; a PDP MUST NOT fail a decision solely because the optional policy_version was omitted.¶

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.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 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 7. 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 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_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"
  },
  "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.¶

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_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-",
  "parameter_digest":
    "sha-256:t2Wq9pK7sR3mL6xT4bN1eY8jC5vH0nF2pV9zKqA8dRn",
  "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.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 7. 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 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 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 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: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.¶

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

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.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.1. Media Type Registry

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

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

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

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

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

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

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