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 (Section 12 of [I-D.draft-mcguinness-oauth-mission-runtime]).¶

4.1. AuthZEN envelope binding

4.2. context.mission

The mission member identifies the governance record and its current materialized view:¶

• id (string, required): the Mission's id.¶

• origin (string, required, URI): the Mission's origin.¶

• authority_hash (string, required): the Authority Set integrity anchor, in the integrity-anchor encoded form ([I-D.draft-mcguinness-oauth-mission]).¶

• state (string, required): the current Mission lifecycle state the PEP established from its Mission state source (Section 6.1 of [I-D.draft-mcguinness-oauth-mission-runtime]).¶

• policy_version (string, required): the policy_version recorded at the approval event.¶

• policy_view_id (string, required): 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 (string): the authenticated client identity.¶

• a client-instance identifier when present.¶

• act (object or array): the delegation chain, ordered root to leaf.¶

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.parameters and context.parameter_digest

When parameter binding is required for the requested action's class (Section 3 of [I-D.draft-mcguinness-oauth-mission-runtime]), the PEP supplies:¶

• parameters (object, conditional): 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).¶

• parameter_digest (string, required for parameter-bound classes): the parameter_digest defined by Section 7 of [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.5. context.audience and context.freshness

• audience (string, required): the PEP's audience or protected-resource identifier.¶

• freshness (object, required): the freshness of the Mission state the PEP relied on, conveying the runtime profile's freshness inputs (Section 6.1 of [I-D.draft-mcguinness-oauth-mission-runtime]) on the wire. Members:¶

  • mission_status_issued_at (RFC 3339 [RFC3339] timestamp)¶

  • mission_status_expires_at (RFC 3339 timestamp)¶

  • mode (string): one of fresh, cached, or event_driven (Section 10)¶

  • freshness_at (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 (Section 6.1 of [I-D.draft-mcguinness-oauth-mission-runtime]); the freshness object is only their wire representation.¶

4.6. 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",
      "act": {
        "iss": "https://as.example.com",
        "sub": "client_erp-recon-agent"
      }
    },
    "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.7. PDP-side consistency checks

In addition to evaluating the decision inputs the runtime profile requires (Section 6 of [I-D.draft-mcguinness-oauth-mission-runtime]), 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. The context.freshness the PEP supplied is within the deployment's staleness bound (Section 6.1 of [I-D.draft-mcguinness-oauth-mission-runtime]); otherwise the PDP returns stale_state, with the freshness-window violation in the denial reason.¶

4. When context.parameters is present, the PDP-recomputed digest matches context.parameter_digest; otherwise the PDP returns parameter_violation.¶

5.1. Members

• decision_id (string, required): unique decision identifier. ABNF: 1*64( ALPHA / DIGIT / "-" / "_" ). At least 128 bits of entropy.¶

• mission (object, required): the PDP request's context.mission object (id, origin, authority_hash, and, when known, policy_version and policy_view_id), extended with proposal_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 (Section 10 of [I-D.draft-mcguinness-oauth-mission-runtime]).¶

• subject (object, required), resource (object, required), action (object, required), audience (string, required): PDP inputs as supplied, after PDP-side normalization.¶

• actor (object, optional), parameter_digest (string, optional): PDP inputs as supplied, after PDP-side normalization.¶

• decision (string, required): one of permit or deny.¶

• contributing_constraints (array of string, required when the decision turned on one or more authority or constraint entries): 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 (integer, required): the per-Mission sequence indicator the runtime profile requires (Section 10 of [I-D.draft-mcguinness-oauth-mission-runtime]), so the decision stream has a verifiable order and gaps are detectable. MUST be zero or greater.¶

• denial_reason (string, conditional): present when decision is deny. A value from Section 7 or a constraints key.¶

• evaluated_at (RFC 3339 [RFC3339] timestamp, required).¶

• evidence_envelope (object, required): 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; it satisfies the runtime profile's requirement that the record be serialized with JCS and integrity-protected (Section 10 of [I-D.draft-mcguinness-oauth-mission-runtime]). The default format is jws-compact, a JWS Compact Serialization [RFC7515] whose payload is the JCS [RFC8785] 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 PDP's published signing key.¶

{
  "evidence_envelope": {
    "format": "jws-compact",
    "value": "eyJhbGciOiJFUzI1NiIsImtpZCI6InBkcC1rZXkt..."
  }
}

Profiles MAY register additional formats (for example, jws-flattened). Implementations MUST reject envelopes with unregistered formats.¶

5.3. Worked example

{
  "decision_id": "dec_8K2nP4qV9rL3tY6sB1zN0eF7jB",
  "mission": {
    "id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEd",
    "origin": "https://as.example.com",
    "authority_hash":
      "sha-256:l3KvZ4mP5x0wQrR6tY2nD9bM7sX1cF8gH2vJ4kE",
    "proposal_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",
    "act": {
      "iss": "https://as.example.com",
      "sub": "client_erp-recon-agent"
    }
  },
  "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.1. Members

• execution_id (string, required): unique execution identifier. ABNF: 1*64( ALPHA / DIGIT / "-" / "_" ). At least 128 bits of entropy.¶

• decision_id (string, required): the linked Decision Evidence.¶

• mission_id (string, required): the Mission id, mirrored from the linked Decision Evidence for join-key convenience.¶

• parameter_digest (string, conditional): MUST be present when the linked Decision Evidence carries one, and MUST match it.¶

• outcome (string, required): 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 (RFC 3339 [RFC3339] timestamp, required).¶

• error (string, conditional): error identifier when outcome is failed.¶

• attempted_at, completed_at (RFC 3339 timestamps, optional): timing context.¶

• result_summary (object, optional): minimal action result metadata (for example, affected resource counts). MUST NOT carry user-content payloads.¶

• evidence_envelope (object, required): 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 (Section 7 of [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 refuse to emit Execution Evidence with a parameter_digest that does not match the linked Decision Evidence. When the 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 (Section 10 of [I-D.draft-mcguinness-oauth-mission-runtime]). Regulated deployments MAY require longer retention.¶

7.1. Insufficient Claims composition

For an acr_insufficient or amr_insufficient denial, the PDP MAY signal which authenticated claims would lift the denial, 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.2. Error response shape

The PDP returns its decision and any denial reason in the AuthZEN response [AUTHZEN]. 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 PDP 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. Implementations MUST reject evidence whose format is unregistered 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 (Section 5 of [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, 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", 2025, <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

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