Mission-Bound Runtime Enforcement: AuthZEN Profile

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 known (Section 2), 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.¶

issuer:

REQUIRED. A string containing a URI. The Mission's issuer.¶

authority_hash:

REQUIRED. A string. The Authority Set integrity anchor, in the integrity-anchor encoded form ([I-D.draft-mcguinness-oauth-mission]).¶

state:

CONDITIONAL. A string. The current Mission lifecycle state the PEP established from its Mission state source ([I-D.draft-mcguinness-mission-runtime]). REQUIRED where the deployment's declared state-source placement has the PEP supply state; absent where state establishment is placed with the PDP, whose obligation the PDP-side consistency checks state (Section 5).¶

version:

OPTIONAL. An integer. The Mission's state version as the status profile defines it ([I-D.draft-mcguinness-oauth-mission-status]), populated where the PEP holds it, under the same conditionality as state. It lets the PDP compare the PEP's observation against the state version committed in its loaded materialized policy view ([I-D.draft-mcguinness-mission-runtime]) and treat a mismatch as staleness.¶

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

This context anchors the Mission's approved Authority Set through authority_hash. Where a Mission participates in a companion that overlays evaluated authority on top of the approved set, for example Mission Containment's Effective Authority Set ([I-D.draft-mcguinness-oauth-mission-containment]), the PDP evaluates the request against that overlaid set, not the approved set alone, per the runtime profile's Authority decision input ([I-D.draft-mcguinness-mission-runtime]). This document defines no member carrying such an overlay's evaluated state. A companion profile MAY extend the mission context with the member it needs, by specification, mirroring the denial-reason extension rule (Section 6.4): an extension member name MUST be a collision-resistant name or a name coordinated within this document family, and a PDP that does not recognize an extension member evaluates the approved Authority Set unchanged. A denial produced against the overlaid set carries the overlay's own denial reason, not out_of_authority: the Containment profile's authority_contained denies capability the Approver granted and the issuer later removed, a distinct history from capability never approved ([I-D.draft-mcguinness-oauth-mission-containment]).¶

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

Where tokens carry instance identity ([I-D.draft-mcguinness-oauth-client-instance-assertion]), the act entry this projection already copies carries the instance identifier and, under the agent profile ([I-D.draft-mcguinness-oauth-ai-agent-instance]), issuer-minted provenance such as agent_instance_id and agent_model. Fleet deployments therefore get which-instance-acted attribution in Decision Evidence and, through the decision_id link, in Execution Evidence, without new members.¶

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 13), but only when the PDP can still enforce the applicable parameter policy from the digest, the supplied parameter_attributes, or local state. If the PDP needs raw parameter values to evaluate an applicable constraint and they are supplied through neither parameters nor the equivalent privacy-preserving parameter_attributes, 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.¶

idempotency_key:

CONDITIONAL. A string, distinct from parameters and parameter_digest. The idempotency key the Operation Profile requires for a non-idempotent action in the high-consequence classes ([I-D.draft-mcguinness-mission-runtime]); it identifies one intended execution of the normalized action, so a legitimate re-execution mints a new key. REQUIRED where the Operation Profile defines one for the action. When the key and the normalized parameters match a prior decision whose execution outcome is unresolved or completed within the reconciliation window, the PDP MUST deny with duplicate_suppressed, or route to action_approval_required (Section 6.4).¶

parameter_attributes:

OPTIONAL. An object. Privacy-preserving attributes derived from the action parameters that the PEP supplies for constraint evaluation when it withholds raw parameters (Section 13). It is the wire carriage of the derived attributes the runtime profile's privacy carve-out relies on ([I-D.draft-mcguinness-mission-runtime]); each member is a deployment-defined attribute the applicable constraints evaluate against. A constraint the PDP cannot evaluate from parameter_digest, parameter_attributes, or local state MUST fail closed (Section 5).¶

5.6. Audience and Freshness Context

audience:

REQUIRED. A string. The PEP's audience or protected-resource identifier.¶

freshness:

CONDITIONAL. An object, REQUIRED whenever state is present: 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 10).¶

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. External-Communication Context

The external-communication predicate is parameter-dependent: whether an action carries data outside the deployment's trust boundary depends on the concrete request parameters, not on the action class alone ([I-D.draft-mcguinness-mission-runtime]), so the PDP has no class-only way to recognize one. The PEP, at the last controllable boundary, computes the predicate from the request parameters and marks the action:¶

external_communication:

CONDITIONAL. A boolean. true when the PEP determines, from the request parameters at the last controllable boundary, that the action carries data to a recipient outside the deployment's trust boundary ([I-D.draft-mcguinness-mission-runtime]). REQUIRED for every action in a class for which the deployment declares PDP-enforced taint, so the taint requirement has a deterministic PDP-side trigger; OPTIONAL otherwise.¶

5.8. Taint Context

The OPTIONAL taint member carries the harness's untrusted-content determination ([I-D.draft-mcguinness-mission-harness]) for the requested action, when the deployment routes taint enforcement through the PDP, as the value of context.taint:¶

{
  "tainted": true,
  "granularity": "parameter",
  "source_class": "web_fetch"
}

tainted:

REQUIRED when taint is present. A boolean. Whether a bound parameter of the action derives from tainted content (under granularity parameter) or tainted content has entered the governed session (under granularity session).¶

granularity:

REQUIRED when taint is present. A string, parameter or session: the trigger granularity the harness established.¶

source_class:

OPTIONAL. A string. The deployment-defined class of the tainting source (for example, web_fetch, inbound_message, third_party_document), for policy and evidence.¶

Absence of taint means the harness did not route the determination through the decision request, not that the action is untainted; the harness's own egress rule then applies. That reading is confined to harness-enforced deployments. When the deployment's Enforcement Scope Statement declares PDP-enforced taint for an action class ([I-D.draft-mcguinness-mission-runtime]):¶

• The PDP MUST require context.taint on every decision in that class whose context.external_communication is true (Section 5.7) or whose action_class is external_commitment, and MUST deny with taint_context_missing when it is absent.¶

• When taint is present with tainted true on such an action, the PDP MUST deny or return action_approval_required (Section 6.4) unless a fresh action-bound approval bound to the action's parameters is present in the decision context.¶

• The PDP MUST record the presented taint context in Decision Evidence.¶

5.9. Action Approval Context

The OPTIONAL action_approval member carries an action-bound approval ([I-D.draft-mcguinness-mission-runtime]) the PEP obtained for the requested action, as the value of context.action_approval. The runtime profile owns the approval artifact; this member is only its wire carriage. Its members:¶

id:

REQUIRED when action_approval is present. A string. The approval identifier, for example ARAP's approval.id [ARAP].¶

state:

OPTIONAL. A string. The signed approval state, for example ARAP's signed approval.state [ARAP], when the deployment carries the approval by value rather than by reference.¶

approved_at:

REQUIRED when action_approval is present. An RFC 3339 [RFC3339] timestamp. When the approval was granted, so the PDP can enforce the deployment's maximum approval age ([I-D.draft-mcguinness-mission-runtime]).¶

approved_until:

REQUIRED when action_approval is present. An RFC 3339 [RFC3339] timestamp, ARAP's approval expiry [ARAP] (ARAP's approval.approved_until). The PDP MUST NOT accept the approval for re-evaluation after it, independent of the deployment's maximum approval age.¶

parameter_digest:

REQUIRED when action_approval is present. A string. The parameter_digest the approval is bound to. The PDP MUST match it against the request's parameter_digest; a mismatch means the approval does not cover these parameters.¶

When deployment or Resource policy requires an action-bound approval and context.action_approval is absent, is older than the deployment's maximum approval age ([I-D.draft-mcguinness-mission-runtime]), is past its approved_until, or is bound to a different parameter_digest, the PDP MUST deny with action_approval_required (Section 6.4). The PDP MUST record the presented approval id in Decision Evidence.¶

5.10. History Context

The OPTIONAL mission_history member carries the runtime profile's History decision input ([I-D.draft-mcguinness-mission-runtime]) on the wire, as the value of context.mission_history: an array of objects, each naming one predicate over the established Mission's prior evidence that the requested action depends on. Members of each entry:¶

predicate:

REQUIRED. A string. The predicate identifier. This document defines action_class_completed. An extension value MUST be either a collision-resistant name or a name coordinated within this document family, under the same rule as denial reasons (Section 6.4).¶

action_class:

REQUIRED when predicate is action_class_completed. A string. A runtime action class name, from the same value space as the Decision Evidence action_class member (Section 7).¶

action_class_completed is satisfied when the PDP's evidence store holds, for the established Mission, at least one Decision Evidence record with decision permit and the named action_class, and every such record has a linked Execution Evidence record (Section 8) whose outcome is completed. For a migration Mission whose copy steps are consequential writes, the delete step names its precondition:¶

[
  {
    "predicate": "action_class_completed",
    "action_class": "consequential_write"
  }
]

The PDP MUST evaluate each named predicate against its own evidence store. A caller-supplied history value is never evidence: an entry names the predicate the request depends on and carries no result member, and the PDP MUST NOT accept a predicate outcome asserted through any other context member.¶

The PDP MUST refuse the evaluation of an entry whose predicate value it does not recognize, treating the predicate as not establishable, consistent with this binding's unknown-value conventions (Section 6.4). Where deployment or Resource policy requires a history predicate that is unsatisfied or cannot be established, the PDP MUST deny with history_not_satisfied (Section 6.4); the runtime profile fixes the fail-closed posture and the evidence store's freshness discipline ([I-D.draft-mcguinness-mission-runtime]). The PDP MUST record the evaluated predicates and their outcomes in Decision Evidence (Section 7).¶

5.11. 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.12. Worked PDP request

The policy_view_id values in this document's examples (sha-256:kP3xR9sQ...) differ from the runtime profile's worked materialized-view value (sha-256:fuMqn6Nb...): this deployment's view payload includes the engine-evaluable form, so it hashes differently. Both are valid views of the same Mission.¶

For the ERP reconciliation 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-",
      "issuer": "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": "s6BhdRkqt3",
      "client_instance_id": "inst_macbook_7f3a",
      "act": [
        {
          "iss": "https://as.example.com",
          "sub": "s6BhdRkqt3"
        }
      ]
    },
    "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:WPVi6EnQ7H9Fh-qk9ADxmTg8zruOdVUX1esl-v3TfCI",
    "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.13. PDP-side consistency checks

A PDP that also serves non-Mission AuthZEN traffic MUST NOT downgrade: for an action within a runtime enforcement scope it mediates, a request whose context lacks the mission member (Section 5.2) is malformed under this binding, and the PDP MUST refuse it rather than evaluate it against non-Mission policy alone. A permit issued to an in-scope consequential action without Mission evaluation is an enforcement bypass, not a decision ([I-D.draft-mcguinness-mission-runtime]).¶

In addition to evaluating the decision inputs the runtime profile requires, the PDP MUST verify that the AuthZEN-carried envelope is self-consistent:¶

1. When present, 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 6.4). Where state establishment is placed with the PDP and the member is absent (Section 5.2), the PDP MUST establish state from its own source or deny with stale_state. 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 view_inconsistent on any inequality.¶

3. When context.mission.policy_view_id is present, it MUST equal the loaded view's policy_view_id, and the PDP returns view_inconsistent on inequality.¶

4. When context.mission.version is present, the PDP compares it against the state version committed in the loaded view ([I-D.draft-mcguinness-mission-runtime]) and treats a mismatch as staleness (stale_state): one side has missed a committed change.¶

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

6. When context.credential.expires_at is present, it has not passed; otherwise the PDP returns credential_invalid.¶

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

8. 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, the supplied context.parameter_attributes, or local state, and returns parameter_violation if it cannot. A parameter-bound action MUST NOT be permitted without a verified parameter_digest.¶

9. For a catalog-sourced action whose approved entry recorded a capability source binding at derivation (Section 9), context.capability_source MUST be present and match the approved binding: the presented source_digest, computed over the capability's current extracted definition (Section 9.1), MUST equal the recorded value, and, where a catalog_digest was recorded, the presented catalog_digest MUST equal it likewise; otherwise the PDP returns capability_drift. Whether an action is catalog-sourced, and which digests were recorded, are determined from the materialized policy view, not from the PEP's request; where no source binding was recorded, this check does not apply.¶

5.14. Clock skew

The time comparisons this binding performs (a permit's permit_expires_at at the PEP, the context.freshness window and context.credential.expires_at at the PDP, and the action-approval maximum age, Section 5.9) MAY allow a small leeway to absorb clock skew between the components. Any leeway MUST NOT exceed the deployment's maximum clock skew, and the deployment MUST publish that maximum-skew assumption in its Enforcement Scope Statement ([I-D.draft-mcguinness-mission-runtime]). A value outside its window by more than the published maximum skew MUST fail closed: an expired permit, a stale freshness window, or an expired credential is refused, and the leeway never extends a permit lease or freshness lease beyond its bound plus the published skew.¶

5.15. Batch evaluations

The AuthZEN evaluations (boxcar) endpoint MAY be used to submit several Mission-bound decisions in one request. Batching is a transport optimization and changes none of the per-item enforcement semantics: 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.¶

• Any metered bounds apply per item in request order ([I-D.draft-mcguinness-mission-metering]).¶

• Permits are per item, so a boxcar MAY return a mix of permits and denials.¶

• The AuthZEN options member MUST NOT request short-circuit or fail-fast semantics; a PDP MUST evaluate every item independently and MUST ignore any option that would suppress evaluation of a later item after an earlier denial.¶

A batch request for two journal-entry writes under the ERP reconciliation Mission, where the second exceeds the entry's max_amount ceiling of 500.00 USD. The shared subject is hoisted to the request's default members per [AUTHZEN]; each item carries its complete context:¶

POST /pdp/access/v1/evaluations HTTP/1.1
Host: pdp.example.com
Content-Type: application/json
Authorization: ...

{
  "subject": {
    "type": "user",
    "id": "user_3p2q8mN1a0kV7tR",
    "properties": {
      "iss": "https://idp.example.com"
    }
  },
  "evaluations": [
    {
      "resource": {
        "type": "journal-entry",
        "id": "je_2026Q3_inv_8421"
      },
      "action": { "name": "journal-entries.write" },
      "context": {
        "mission": {
          "id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-",
          "issuer": "https://as.example.com",
          "authority_hash":
            "sha-256:l3KvZ4mP5x0wQrR6tY2nD9bM7sX1cF8gH2vJ4kE5pNQ",
          "state": "active"
        },
        "actor": { "client_id": "s6BhdRkqt3" },
        "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:WPVi6EnQ7H9Fh-qk9ADxmTg8zruOdVUX1esl-v3TfCI",
        "audience": "https://erp.example.com",
        "freshness": {
          "mode": "fresh",
          "freshness_at": "2026-11-02T08:14:00Z"
        }
      }
    },
    {
      "resource": {
        "type": "journal-entry",
        "id": "je_2026Q3_inv_9310"
      },
      "action": { "name": "journal-entries.write" },
      "context": {
        "mission": {
          "id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-",
          "issuer": "https://as.example.com",
          "authority_hash":
            "sha-256:l3KvZ4mP5x0wQrR6tY2nD9bM7sX1cF8gH2vJ4kE5pNQ",
          "state": "active"
        },
        "actor": { "client_id": "s6BhdRkqt3" },
        "credential": {
          "issuer": "https://as.example.com",
          "expires_at": "2026-11-02T09:14:00Z"
        },
        "parameters": {
          "amount_usd": "780.00",
          "source_invoice_id": "inv_2026Q3_931"
        },
        "parameter_digest":
          "sha-256:mzFwtXAT6_hY0v8_NFHMDJG39HFuWY2fRcOCSFGDyyE",
        "audience": "https://erp.example.com",
        "freshness": {
          "mode": "fresh",
          "freshness_at": "2026-11-02T08:14:00Z"
        }
      }
    }
  ]
}

The response returns one decision per item, in request order; the first is a permit and the second a parameter_violation deny, whose failing max_amount key is listed in that item's Decision Evidence contributing_constraints:¶

{
  "evaluations": [
    {
      "decision": true,
      "context": {
        "decision_id": "dec_2FpQ8kV5nR1tX7mB4sJ9eL6wYc",
        "action_class": "irreversible_action",
        "class_source": "deployment",
        "parameter_digest":
          "sha-256:WPVi6EnQ7H9Fh-qk9ADxmTg8zruOdVUX1esl-v3TfCI",
        "policy_view_id":
          "sha-256:kP3xR9sQ7nM2vL4tY6bD1eF8jC5wH0pV2nR3kQ4mZ7t",
        "permit_expires_at": "2026-11-02T08:15:00Z",
        "single_use": true
      }
    },
    {
      "decision": false,
      "context": {
        "decision_id": "dec_6JwN3xT9rQ4mV8kP1sB5eZ2yLd",
        "denial_reason": "parameter_violation",
        "action_class": "irreversible_action",
        "class_source": "deployment",
        "parameter_digest":
          "sha-256:mzFwtXAT6_hY0v8_NFHMDJG39HFuWY2fRcOCSFGDyyE",
        "policy_view_id":
          "sha-256:kP3xR9sQ7nM2vL4tY6bD1eF8jC5wH0pV2nR3kQ4mZ7t"
      }
    }
  ]
}

5.16. Timeouts, Retries, and Overload

An evaluation exchange carries metered and single-use consequences, so its transport behavior is specified, not assumed:¶

• A PEP MUST bound each evaluation call with a timeout inside the action class's staleness budget and treat expiry as pdp_unreachable (Section 7.2): fail closed, never a permit.¶

• A PEP MAY retry an evaluation whose response was lost, carrying the same normalized parameters and idempotency key. The runtime profile's retransmission rule then returns the prior decision where its permit is unexpired and unconsumed ([I-D.draft-mcguinness-mission-runtime]), and metering MUST NOT charge the bound twice for the retried request ([I-D.draft-mcguinness-mission-metering]).¶

• A PDP under overload sheds load explicitly: HTTP 429 with Retry-After. The PEP treats it as pdp_unreachable for the action at hand and MUST NOT retry before Retry-After elapses.¶

• A PDP MAY publish a maximum batch size and refuse an oversized boxcar with HTTP 413; the PEP splits the batch rather than dropping items.¶

6.1. Response decision context

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 set of Section 6.4, including any specification-defined extension under that section's extensibility rule; a consumer MUST treat an unrecognized value as a deny and MUST NOT attach any other semantics to it. A constraint violation uses parameter_violation; the specific failing constraints keys are carried in the Decision Evidence contributing_constraints, not here.¶

action_class:

REQUIRED. A string. The runtime action class the PDP applied, from the value set of Section 7, so the PEP can verify it is enforcing that class's permit controls. When the PEP has itself established a stricter class for the action, from its deployment classification or a resource floor it knows ([I-D.draft-mcguinness-mission-runtime]), the PEP MUST enforce the stricter class's permit controls; for a high-consequence class that includes refusing a permit that lacks single_use.¶

class_source:

REQUIRED when action_class is present. A string. One of default, resource_floor, or deployment (Section 7).¶

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. The rules bounding its value follow this list.¶

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: the submission endpoint, the ARAP-required expires_at, and the denial binding that ties a later access request to this evaluation (denial_binding, this profile's name for ARAP's evaluation_id, with the PDP-signed binding_token). Its presence does not change the decision: false result and does not grant access.¶

No mode leaves the permit window unbounded on the wire. permit_expires_at MUST NOT be later than the freshness time or lease of the Mission state view the decision relied on ([I-D.draft-mcguinness-mission-runtime]); in particular, it MUST NOT be later than a supplied context.freshness.mission_status_expires_at. In fresh mode with no supplied mission_status_expires_at, the PDP derives the bound from its own state view: the view's freshness time or lease where the source reports one, otherwise the deployment's published staleness bound for the action's class.¶

6.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",
    "action_class": "irreversible_action",
    "class_source": "deployment",
    "parameter_digest":
      "sha-256:WPVi6EnQ7H9Fh-qk9ADxmTg8zruOdVUX1esl-v3TfCI",
    "policy_view_id":
      "sha-256:kP3xR9sQ7nM2vL4tY6bD1eF8jC5wH0pV2nR3kQ4mZ7t",
    "permit_expires_at": "2026-11-02T08:15:00Z",
    "single_use": true
  }
}

6.3. Denial response shape

A runtime denial is returned as decision: false with the context members above:¶

{
  "decision": false,
  "context": {
    "decision_id": "dec_5WcR2mT8xN4qV7kB1sJ6eL9yPd",
    "denial_reason": "stale_state",
    "action_class": "irreversible_action",
    "class_source": "deployment",
    "policy_view_id":
      "sha-256:kP3xR9sQ7nM2vL4tY6bD1eF8jC5wH0pV2nR3kQ4mZ7t"
  }
}

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

Malformed requests, authentication failures, or PDP processing errors that prevent evaluation MAY be returned as AuthZEN or transport-level errors; so is an in-scope request refused for missing Mission context (Section 5). A deployment MAY additionally carry [RFC9457] problem details for structured error information when the PDP is consumed over HTTP outside the AuthZEN envelope.¶

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

• step_up_required: Resource policy requires a stronger authentication context for this action than the actor presents, and MAY be satisfied by [RFC9470] step-up authentication (see the note after this list).¶

• action_approval_required: deployment or Resource policy requires an action-bound approval for this action ([I-D.draft-mcguinness-mission-runtime]) and a valid fresh approval bound to the action's parameters is not present, is older than the deployment's maximum approval age, or is bound to a different parameter_digest. The PEP carries any such approval in context.action_approval (Section 5.9); this profile does not define the approval artifact, which the runtime profile owns.¶

• taint_context_missing: the deployment declares PDP-enforced taint for the action's class and the decision request carries no context.taint (Section 5.8).¶

• stale_state: the PEP-supplied freshness is outside the deployment's staleness bound (a freshness-window violation).¶

• view_inconsistent: the request's Mission id, authority_hash, or policy_view_id does not equal the committed values in the materialized policy view the PDP loaded, so the request and the loaded view disagree on which Mission or view is in force. This is a view inconsistency, not staleness.¶

• mission_inactive: the Mission state is not active.¶

• mission_binding_failed: in externally-established Mission binding mode ([I-D.draft-mcguinness-mission-runtime]), the PDP could not verify the supplied Mission reference against the acting credential under the binding's join, so no Mission is established.¶

• actor_invalid: the required act chain is missing or malformed, so the PDP cannot establish the runtime actor context ([I-D.draft-mcguinness-mission-runtime]).¶

• 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 the PDP evaluated, the recomputed digest does not match, or a required parameter_digest is absent for a parameter-bound action.¶

• duplicate_suppressed: the request's idempotency_key and normalized parameters match a prior decision whose execution outcome is unresolved or completed within the reconciliation window, so the PDP suppresses a duplicate execution of the same normalized action ([I-D.draft-mcguinness-mission-runtime]). The PDP MAY instead route to action_approval_required.¶

• resource_policy: Resource policy refuses the action independently of Mission authority.¶

• quota_exceeded: a metered runtime bound is exhausted. The runtime profile fixes the fail-closed posture for consumption bounds ([I-D.draft-mcguinness-mission-runtime]); the metering semantics and settlement exchange are defined by the experimental metering companion ([I-D.draft-mcguinness-mission-metering]).¶

• capability_drift: for a catalog-sourced action whose approved entry recorded a capability source binding (Section 9), the digest of the action's current extracted capability definition differs from the source_digest committed at derivation, a recorded catalog_digest no longer matches the retrieved source, or the presented tool_id is outside the approved set (see the note after this list).¶

• unsupported_authorization_type: the action targets an authorization_details type the PDP does not understand or cannot enforce, so it refuses rather than guess the type's semantics ([I-D.draft-mcguinness-mission-runtime]).¶

• constraint_unsupported: an applicable constraint or consumption bound on the entry is unrecognized or unmetered, so the PDP cannot enforce it and refuses ([I-D.draft-mcguinness-mission-runtime]). This is distinct from parameter_violation, which is a constraint the PDP evaluated and found violated.¶

• history_not_satisfied: a deployment- or Resource-policy-required history predicate (Section 5.10) is not satisfied: the PDP established it false, could not establish it, could not consult its evidence store within the declared staleness bound, or does not recognize the presented predicate value. The per-predicate outcomes are in Decision Evidence (Section 7), so the unsatisfied and unavailable cases stay distinguishable after the fact.¶

step_up_required is a Resource-policy condition, not a Mission constraint: the issuance profile's acr is an approval-time requirement on the Approver, recorded on the Mission and neither carried on derived tokens nor evaluated per action ([I-D.draft-mcguinness-oauth-mission]), and the issuance profile defines no per-action amr constraint. It is a specialization of resource_policy that names the step-up affordance.¶

capability_drift applies only when a source binding was recorded and the digest comparison ran; an invoked identity outside the approved set for which no source binding was recorded is out_of_authority, not capability_drift.¶

This document defines no other denial-reason values. A companion profile MAY extend the set by specification; an extension value MUST be either a collision-resistant name (following the Collision-Resistant Name guidance of [RFC7519] Section 4.2) or a name coordinated within this document family, so values cannot collide. A consumer of a denial reason, wherever it is carried (the Decision Evidence denial_reason, Section 7, or the response context.denial_reason, Section 6.1), MUST treat an unrecognized value as a deny and MUST NOT attach any other semantics to it, mirroring the issuance profile's open lifecycle state space ([I-D.draft-mcguinness-oauth-mission]).¶

6.5. Requestable denials

A deny is terminal for the attempted action: the agent does not proceed on a denial. A deny need not end the task, however. For an out_of_authority or action_approval_required denial, the PDP MAY mark the denial requestable by including a context.access_request object, composing this binding with the AuthZEN Access Request and Approval Profile [ARAP]. The PEP then submits an ARAP access request bound to the denied evaluation, an independent approver or policy adjudicates it (synchronously when policy auto-approves, otherwise asynchronously through the portable ARAP task handle), and on approval the PEP re-evaluates against the PDP. This is the demand-driven, runtime-initiated counterpart to the pre-consented drawdown of the experimental progressive authorization companion ([I-D.draft-mcguinness-oauth-mission-progressive]): the agent starts narrow and requests the authority it discovers it needs, instead of holding it up front.¶

Auto-approval is bounded the same way in-ceiling drawdown is ([I-D.draft-mcguinness-oauth-mission-progressive]): a deployment SHOULD rate-limit and anomaly-check synchronous auto-approval, and MUST NOT auto-approve a request for an action_approval_required denial in the irreversible, external-commitment, or privileged-administration classes without an independent approver, so a compromised agent cannot drive the request loop to escalate itself unattended.¶

Two ARAP properties carry weight here and match this profile's stance. First, an ARAP approval is input context, not a bearer grant: the PDP remains authoritative at enforcement, so the PEP MUST obtain a fresh decision, and any resulting permit and evidence remain subject to this profile. The action-bound approval an action_approval_required denial calls for ([I-D.draft-mcguinness-mission-runtime]) is exactly such an approval, and ARAP's approval.id or signed approval.state is its carrier. Second, to persist authority beyond the single re-evaluated action rather than re-requesting it per call, an approved request MAY be realized as a Mission expansion ([I-D.draft-mcguinness-oauth-mission-expansion]): as the fresh human approval that creates the successor Mission or, where the experimental progressive authorization companion is deployed, as a policy-adjudicated in-ceiling expansion ([I-D.draft-mcguinness-oauth-mission-progressive]).¶

A requestable denial carries context.access_request alongside the denial members. Here deployment policy requires an action-bound approval for the journal-entry write, no valid fresh approval is present, and the PDP marks the denial requestable under [ARAP]:¶

{
  "decision": false,
  "context": {
    "decision_id": "dec_7YbK4nQ9tR2xV6mL1sP8eJ3wZc",
    "denial_reason": "action_approval_required",
    "action_class": "irreversible_action",
    "class_source": "deployment",
    "parameter_digest":
      "sha-256:WPVi6EnQ7H9Fh-qk9ADxmTg8zruOdVUX1esl-v3TfCI",
    "policy_view_id":
      "sha-256:kP3xR9sQ7nM2vL4tY6bD1eF8jC5wH0pV2nR3kQ4mZ7t",
    "access_request": {
      "endpoint": "https://requests.example.com/access-requests",
      "expires_at": "2026-11-02T09:14:00Z",
      "denial_binding": "dec_7YbK4nQ9tR2xV6mL1sP8eJ3wZc",
      "binding_token": "eyJhbGciOiJFUzI1NiIsInR5cCI6InBkcC1kZW5pYWwtYmluZGluZytqd3QifQ.eyJk..."
    }
  }
}

The access_request members compose the ARAP requestable-denial context [ARAP]: expires_at and the PDP-signed binding_token are ARAP's, and denial_binding is this profile's name for ARAP's evaluation reference. Its presence does not change the decision: false result: the PEP refuses the action, submits the access request, and re-evaluates only after approval.¶

Mapping to [ARAP]: this profile carries ARAP's context under mission names. context.action_approval (Section 5.9) is ARAP's context.approval; access_request.denial_binding is ARAP's evaluation_id and access_request.binding_token is ARAP's binding_token; the action_approval_required reason (Section 6.4) is ARAP's context.reason value approval_required. An ARAP implementer maps these names to drive an unmodified ARAP request and approval exchange.¶

6.6. Failure-condition coverage

Every runtime failure condition, whether named in the runtime profile's failure-mode table or in its other normative requirements ([I-D.draft-mcguinness-mission-runtime]), surfaces through exactly one of three carriers in this binding: a Refusal Record for a PEP refusal before any PDP decision (Section 7.2), a PDP denial (denial_reason in the decision context and Decision Evidence), or an Execution Evidence error for a failure after a permit (Section 8). The table below is the normative mapping for the conditions it names; extension identifiers remain governed by each carrier's extensibility rule.¶

6.7. 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 7) and verify the runtime's binding fields (the Mission reference and policy_view_id, audience, subject, client_id, actor context, action, resource, the authorizing entry or entry_digest, and parameter_digest) from it before acting, rather than trusting a relayed decision: true.¶

In such a split the executor is the enforcing component: it owns the consumed-identifier store and honors the permit lease (permit_expires_at and single_use, Section 6.1) under the runtime profile's consumed-identifier rules ([I-D.draft-mcguinness-mission-runtime]), so relayed Decision Evidence cannot be executed twice or after its lease. The requesting component's possession of a permit does not consume it; consumption is recorded where the action executes.¶

A PEP permit cache MUST key on the permit's bound fields (the Mission reference and policy_view_id, audience, subject, client_id, actor context, action, resource, the authorizing entry or entry_digest, and parameter_digest) and MUST NOT key on freshness telemetry (freshness_at, mission_status_issued_at, mission_status_expires_at), whose per-request variation would otherwise make the cache never hit. A cached permit cannot be reused for a request that differs in any bound field, and its reuse is bounded in time by permit_expires_at, not by the freshness telemetry.¶

The envelope rule fixes what a permit cache is for. A parameter-bound class keys on parameter_digest, and a high-consequence permit is single-use, so caching amortizes only repeat-identical, non-single-use actions: reads and idempotent re-checks. The steady state for consequential writes is one evaluation per action, and a deployment sizes PDP capacity and placement to that rate, not to a cache hit ratio ([I-D.draft-mcguinness-mission-runtime]).¶

6.8. Decision identifier propagation

In a split topology the resource request the permit authorizes is served by a Resource Server that did not see the PDP exchange. The PEP SHOULD propagate the permit's decision_id to the resource request in the Mission-Decision request header field (Section 14); the field value is the decision_id, whose ABNF (Section 7) is field-value-safe. The field is protected in transit per deployment: at minimum it rides the TLS channel this binding already requires (Section 12), and where the deployment signs resource requests the signature MUST cover it.¶

A Resource Server that logs the received decision_id with the access it serves closes the decision-to-access join: the Decision Evidence, the Execution Evidence, and the Resource Server's access log then share one identifier, so an access is joined to the decision that permitted it without timestamp correlation. This extends the issuance profile's recommendation that a Resource Server log the mission claim's id and the token jti with each decision ([I-D.draft-mcguinness-oauth-mission]): the decision identifier is this profile's addition to that correlation set.¶

The field is a correlation aid, not an authorization. Its presence or value grants nothing, the Resource Server's token validation and PEP obligations are unchanged, and a Resource Server MUST NOT treat it as a permit; the permit-binding rules above govern.¶

7.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, extended with the facts below, so the evidence chains back to the exact approved Mission. Sub-members:¶

id, issuer, authority_hash:

REQUIRED. From the request's context.mission.¶

policy_view_id:

REQUIRED. The PDP's own view identifier; the PDP always knows and populates it, whatever the request carried.¶

intent_hash:

OPTIONAL. It is carried in neither the mission claim nor introspection, so only a PDP with direct Mission-record access can record it.¶

policy_version:

OPTIONAL. From the request's context.mission, when known.¶

Consent-disclosure commitment:

OPTIONAL. Recorded when known.¶

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

action_class:

REQUIRED. A string. The runtime action class the PDP applied to the action: one of consequential_read, consequential_write, irreversible_action, external_commitment, or privileged_administration, naming the classes of [I-D.draft-mcguinness-mission-runtime]. Every decision this binding records is on a consequential action, so the member is always present.¶

class_source:

REQUIRED when action_class is present. A string. How the applied class was assigned: default (the runtime profile's default classification), resource_floor (the resource's published mission_action_class_floors floor set or raised it, [I-D.draft-mcguinness-mission-runtime]), or deployment (deployment policy assigned it).¶

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

permit_expires_at:

REQUIRED when decision is permit. An RFC 3339 [RFC3339] timestamp. The permit-lease expiry the PDP returned (Section 6.1), recorded so the durable evidence carries the permit-lease control the decision was bound to.¶

single_use:

CONDITIONAL. A boolean. The single-use control the PDP returned (Section 6.1), recorded on the decision. REQUIRED and true for a permit in the high-consequence classes.¶

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. The sequence is scoped to the emitter identified by emitter: each emitter maintains its own monotonically increasing per-Mission sequence, and a verifier detects gaps per (Mission, emitter) rather than expecting one ordering across emitters.¶

emitter:

REQUIRED. An object. The identity of the component that emitted and signed this record, with members id (REQUIRED, a string identifying the emitting component) and role (REQUIRED, one of pdp, pep, or executor). For Decision Evidence role is pdp. A companion profile MAY register coordinated additional roles (harness, egress) for records emitted under these conventions at other enforcement points. A verifier MUST bind the emitter's signing key to the enforcement scope and audience the record serves (Section 7.3).¶

denial_reason:

CONDITIONAL. A string. Present when decision is deny. A value from the set of Section 6.4, including any specification-defined extension under that section's extensibility rule; a consumer MUST treat an unrecognized value as a deny and MUST NOT attach any other semantics to it. 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.¶

authorizing_entry:

OPTIONAL. An object. The authorization_details entry the decision was evaluated against.¶

entry_digest:

OPTIONAL. A string. The integrity-anchor encoded digest ([I-D.draft-mcguinness-oauth-mission]) of that entry, for a deployment that does not record the entry in full. A record of a permit MUST carry authorizing_entry or entry_digest, per the runtime record requirements ([I-D.draft-mcguinness-mission-runtime]).¶

taint:

OPTIONAL. An object. The presented taint context (Section 5.8), recorded as supplied. REQUIRED when the decision request carried context.taint.¶

mission_history:

OPTIONAL. An array of objects. The presented history predicates (Section 5.10), each recorded as supplied and extended with an outcome member (REQUIRED, a string): satisfied, not_satisfied (established false), or unavailable (not establishable, including an unrecognized predicate value or an evidence store that could not be consulted within its bound). REQUIRED when the decision request carried context.mission_history.¶

evidence_envelope:

REQUIRED. An object. Integrity protection (Section 7.3), carrying a format (string, required) and a value (string, required).¶

A Decision Evidence Object is closed to uncoordinated extension: a companion profile of the runtime contract MAY add members with short names coordinated with this profile (for example, the metering companion's consumption and settlement members, or a discovery adjudication's resource_declaration_digest), any other extension MUST use a collision-resistant name, and a consumer MUST ignore members it does not understand and MUST NOT derive authority from any member.¶

7.2. Refusal Record

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 as a Refusal Record, carrying only facts the PEP verified:¶

refusal_id:

REQUIRED. A string. Unique refusal identifier. ABNF: 1*64( ALPHA / DIGIT / "-" / "_" ). At least 128 bits of entropy.¶

audience:

REQUIRED. A string. The PEP's audience or protected-resource identifier.¶

action:

REQUIRED. An object. The requested action descriptor, as the PEP established it.¶

resource:

OPTIONAL. An object. The target object identity, when the PEP established one.¶

decision:

REQUIRED. A string. Always deny.¶

denial_reason:

REQUIRED. A string. One of token_invalid, mission_claim_missing, channel_failure, pdp_unreachable, or state_unavailable (where the deployment's state-source placement has the PEP supply state, and it cannot establish it). These name PEP-side conditions and are disjoint from the PDP denial reasons of Section 6.4; a record that can populate the PDP-derived members is a Decision Evidence Object instead.¶

evaluated_at:

REQUIRED. An RFC 3339 [RFC3339] timestamp.¶

first_evaluated_at:

OPTIONAL. An RFC 3339 timestamp. Present on an aggregated record: the earliest refusal the record covers, with evaluated_at the latest.¶

attempt_count:

OPTIONAL. An integer. Present on an aggregated record: the number of refusals the record covers.¶

parameter_digest:

CONDITIONAL. A string. REQUIRED for a parameter-bound action class.¶

request_digest:

CONDITIONAL. A string. A privacy-preserving digest of the refused request, in the form of Section 7.5. REQUIRED when parameter_digest is absent, so the record meets the runtime profile's record minimum ([I-D.draft-mcguinness-mission-runtime]).¶

mission:

OPTIONAL. An object. The Mission reference (id, issuer, authority_hash), present only when the PEP verified the mission claim before the failure (for example, on pdp_unreachable).¶

subject, actor, credential:

OPTIONAL. Objects. Verified facts only, in the request forms of Section 5. For a token-validation failure, the record MUST NOT describe unverified token claims as authenticated facts ([I-D.draft-mcguinness-mission-runtime]).¶

sequence:

CONDITIONAL. An integer. REQUIRED when the record carries a verified mission reference, continuing that emitter's per-Mission sequence for that Mission (Section 7); absent when no Mission was established.¶

emitter:

REQUIRED. An object. The identity of the refusing PEP that emitted and signed this record, in the form Decision Evidence defines (Section 7), with role pep. A verifier MUST bind the emitter's signing key to the enforcement scope and audience the record serves (Section 7.3).¶

evidence_envelope:

REQUIRED. An object. Integrity protection in the form of Section 7.3, emitted by the refusing PEP, whose JWS protected typ is application/mission-refusal-record+json (Section 14).¶

A Refusal Record is closed to uncoordinated extension under the same rule as Decision Evidence.¶

A sustained failure condition with a retrying agent otherwise yields one signed record per attempt. A PEP MAY aggregate consecutive refusals sharing denial_reason, audience, action, and the parameter or request digest into one Refusal Record, carrying first_evaluated_at, evaluated_at, and attempt_count. Aggregation applies only to the PEP-side conditions of this section; PDP denials remain one Decision Evidence Object per evaluation.¶

When the deployment establishes the Mission binding externally under the runtime profile's binding-establishment step ([I-D.draft-mcguinness-mission-runtime]), absence of the mission claim is not a pre-decision refusal and mission_claim_missing does not apply; the external join's verification governs instead.¶

A PDP outage on the ERP reconciliation Mission, recorded by the PEP that failed closed:¶

{
  "refusal_id": "ref_3VtM9kQ2xN7rB4sL8eP1jY5wZc",
  "mission": {
    "id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-",
    "issuer": "https://as.example.com",
    "authority_hash":
      "sha-256:l3KvZ4mP5x0wQrR6tY2nD9bM7sX1cF8gH2vJ4kE5pNQ"
  },
  "audience": "https://erp.example.com",
  "action": { "name": "journal-entries.write" },
  "resource":
    { "type": "journal-entry", "id": "je_2026Q3_inv_8421" },
  "parameter_digest":
    "sha-256:WPVi6EnQ7H9Fh-qk9ADxmTg8zruOdVUX1esl-v3TfCI",
  "decision": "deny",
  "denial_reason": "pdp_unreachable",
  "sequence": 44,
  "emitter": { "id": "pep.example.com", "role": "pep" },
  "evaluated_at": "2026-11-02T08:16:11Z",
  "evidence_envelope": {
    "format": "jws-compact",
    "value": "eyJhbGciOiJFUzI1NiIsImtpZCI6InBlcC1rZXkt..."
  }
}

7.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. For a Refusal Record, the emitter is the refusing PEP.¶

A verifier MUST confirm that the signing key selected by the JWS kid is the published key of the component named in the record's emitter member, and that this key is bound to the enforcement scope and audience the record serves (Section 5.6, the record's audience). A verifier MUST reject a record whose signing key is not published for that scope, so one component's key cannot sign evidence for a resource, audience, or scope it does not serve.¶

The JWS protected header MUST carry:¶

• kid: a key identifier resolvable in the emitter's published JWKS (Section 12.5), 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, application/mission-refusal-record+json for Refusal Records, Section 14). A verifier MUST reject a JWS whose protected typ is not the media type of the object it is verifying, so signatures over one record kind cannot be cross-used for another.¶

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

7.4. Worked example

{
  "decision_id": "dec_8K2nP4qV9rL3tY6sB1zN0eF7jB",
  "mission": {
    "id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-",
    "issuer": "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": "s6BhdRkqt3",
    "client_instance_id": "inst_macbook_7f3a",
    "act": [
      {
        "iss": "https://as.example.com",
        "sub": "s6BhdRkqt3"
      }
    ]
  },
  "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:WPVi6EnQ7H9Fh-qk9ADxmTg8zruOdVUX1esl-v3TfCI",
  "audience": "https://erp.example.com",
  "action_class": "irreversible_action",
  "class_source": "deployment",
  "permit_expires_at": "2026-11-02T08:15:00Z",
  "single_use": true,
  "decision": "permit",
  "contributing_constraints": [
    "mission_resource_access", "max_amount"
  ],
  "sequence": 42,
  "emitter": { "id": "pdp.example.com", "role": "pdp" },
  "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.5. Request digest worked value

For a consequential action that is not parameter-bound (here a consequential read), the record carries request_digest in place of parameter_digest. The runtime profile does not standardize the digested request form, so the emitting deployment states the exact input; this non-normative example digests exactly the following evaluation-request summary object:¶

{
  "action": "journal-entries.read",
  "audience": "https://erp.example.com",
  "mission_id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-",
  "resource": "je_2026Q3_inv_8421",
  "subject": "user_3p2q8mN1a0kV7tR"
}

The value is the integrity-anchor encoded form of the SHA-256 of the JCS [RFC8785] canonical bytes of that object (one line, sorted member names, no whitespace, shown here wrapped for layout only; remove the layout line breaks, adding no characters, to recover the canonical form):¶

{"action":"journal-entries.read","audience":"https://erp.example.com
","mission_id":"msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-","resource":
"je_2026Q3_inv_8421","subject":"user_3p2q8mN1a0kV7tR"}

request_digest = sha-256:sK12VE_g01AHD2v-O1vsf1Gf_xT_htjX0UN0Oe0dDRU

8.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. It is scoped to emitter per (Mission, emitter) as Decision Evidence defines (Section 7).¶

emitter:

REQUIRED. An object. The identity of the PEP or executor that emitted and signed this record, in the form Decision Evidence defines (Section 7), with role pep or executor. A verifier MUST bind the emitter's signing key to the enforcement scope and audience the record serves (Section 7.3).¶

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 7.3), carrying a format (string, required) and a value (string, required).¶

An Execution Evidence Object is closed to uncoordinated extension under the same rule as Decision Evidence: coordinated companion members (for example, the metering companion's measured_duration) are permitted, any other extension MUST use a collision-resistant name, and a consumer MUST ignore members it does not understand.¶

8.2. Worked example

{
  "execution_id": "exe_4r9SqLm8tY2pXkV3nR0eF7jB1zN6cQ5w",
  "decision_id":  "dec_8K2nP4qV9rL3tY6sB1zN0eF7jB",
  "mission_id":   "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-",
  "parameter_digest":
    "sha-256:WPVi6EnQ7H9Fh-qk9ADxmTg8zruOdVUX1esl-v3TfCI",
  "outcome":      "completed",
  "sequence":     43,
  "emitter":      { "id": "pep.example.com", "role": "executor" },
  "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.¶

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

8.4. Retention

Decision Evidence, Execution Evidence, and Refusal Records 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.¶

9.1. Per-Capability Extraction

source_digest is computed over the extracted per-capability definition, not the whole retrieved source, so a revision elsewhere in a shared catalog does not invalidate a Mission's approved capabilities, while any mutation of an approved capability's own definition still refuses. The extraction rule is fixed per source format:¶

• For an MCP tool catalog, the extracted definition is the single tool's definition object as retrieved (the member of the catalog's tool list whose name is the capability's), JCS-canonicalized [RFC8785].¶

• For an OpenAPI document, the extracted definition is an object with two members: operation, the operation object operation_ref identifies, and components, an object carrying, under their component names, the components of the document the operation references by name, directly or transitively. The assembled object is JCS-canonicalized.¶

• For another source format, the binding profile in use defines the extraction rule. A capability whose format has no defined extraction rule cannot carry a source_digest; the whole-source catalog_digest remains available for it.¶

For the MCP tool of the minimum binding above, the extracted definition is the tool's definition object:¶

{
  "name": "write_document",
  "description": "Create or update a document",
  "inputSchema": {
    "type": "object",
    "properties": {
      "path": { "type": "string" },
      "content": { "type": "string" }
    },
    "required": ["path", "content"]
  }
}

The JCS canonical bytes are a single line with sorted member names and no whitespace, shown here wrapped for layout only; remove the layout line breaks, adding no characters, to recover the canonical form:¶

{"description":"Create or update a document","inputSchema":{"propert
ies":{"content":{"type":"string"},"path":{"type":"string"}},"require
d":["path","content"],"type":"object"},"name":"write_document"}

source_digest = sha-256:OAbEIh2DTYUVP7DjRhHct4aapsT8PybZq2ILdut9UP0

Adding, removing, or renaming another tool in the same catalog leaves this value unchanged; any byte change to this definition changes it.¶

Cross-format canonicalization, signed capability manifests, and media-type negotiation across catalog formats are out of scope ([I-D.draft-mcguinness-mission-runtime]); this binding requires only the stable identifier plus source evidence above.¶

12.1. Unbound-evaluation downgrade

A PDP that serves both Mission-bound and ordinary AuthZEN traffic has two policy surfaces, and the request selects between them by carrying context.mission. If an in-scope request that lost its Mission context (a PEP defect, or a path an attacker can influence) were evaluated against the non-Mission surface, a generic allow rule would stand in for the Mission evaluation this binding exists to force. The consistency requirement of Section 5 refuses such a request outright; deployments SHOULD additionally alert on in-scope requests arriving without Mission context, since each one is a PEP defect or a probe.¶

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

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

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

12.5. 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 and Refusal Records 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. The retired-key rule of the issuance profile's key management ([I-D.draft-mcguinness-oauth-mission]) extends to evidence signing keys: 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. The compromise exception carries over with it: a key known or suspected compromised is published as revoked or marked with a compromise time, per the core rule, and evidence signed under it after that time is unverifiable rather than verified.¶

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

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

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

13.1. Evidence as PII sinks

Decision Evidence, Execution Evidence, and Refusal Records 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 8.¶

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

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

14.1. Media Type Registry

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

14.2. HTTP Field Name Registration

This document registers the following in the "Hypertext Transfer Protocol (HTTP) Field Name" registry ([RFC9110]):¶

• Field Name: Mission-Decision¶

• Status: permanent¶

• Reference: this document, Section 6.8¶

• Comments: none¶

The context.mission, context.actor, context.credential, context.parameters, context.parameter_digest, context.idempotency_key, context.parameter_attributes, context.audience, context.freshness, context.external_communication, context.taint, context.action_approval, and context.capability_source members carried inside the AuthZEN request context object (Section 5) are AuthZEN extension data and are not registered in an IETF registry. The response context.decision_id, context.denial_reason, context.action_class, context.class_source, context.parameter_digest, context.policy_view_id, context.permit_expires_at, context.single_use, context.insufficient_claims, and context.access_request members (Section 6.1) are likewise AuthZEN extension data. The Mission-bound token claims this profile consumes are registered by [I-D.draft-mcguinness-oauth-mission].¶

15.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", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-runtime.html>.

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

McGuinness, K., "Mission-Bound Authorization for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission.html>.

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

McGuinness, K., "Mission Status and Lifecycle for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-status.html>.

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

[RFC9110]

Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, <https://www.rfc-editor.org/rfc/rfc9110>.

15.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-mission-harness]

McGuinness, K., "Mission-Aware Agent Harnesses", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-harness.html>.

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

McGuinness, K., "Mission Consumption Metering", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-metering.html>.

[I-D.draft-mcguinness-oauth-ai-agent-instance]

McGuinness, K., "OAuth 2.0 AI Agent Instance Profile", Work in Progress, Internet-Draft, draft-mcguinness-oauth-ai-agent-instance-00, 4 July 2026, <https://datatracker.ietf.org/doc/html/draft-mcguinness-oauth-ai-agent-instance-00>.

[I-D.draft-mcguinness-oauth-client-instance-assertion]

McGuinness, K., "OAuth 2.0 Client Instance Assertion", Work in Progress, Internet-Draft, draft-mcguinness-oauth-client-instance-assertion-01, 24 June 2026, <https://datatracker.ietf.org/doc/html/draft-mcguinness-oauth-client-instance-assertion-01>.

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

McGuinness, K., "Mission Containment for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-containment.html>.

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

McGuinness, K., "Mission Expansion for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-expansion.html>.

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

McGuinness, K., "Mission Progressive Authorization for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-progressive.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>.