Mission Runtime Evidence

4.1. Members

evidence_id:

REQUIRED. A string. Unique record identifier for this Decision Evidence Object. ABNF: 1*64( ALPHA / DIGIT / "-" / "_" ). At least 128 bits of entropy.¶

evaluation_id:

REQUIRED. A string. The correlation identifier for the evaluation this record documents: the abstract evaluation identifier of the runtime profile's Decision Output ([I-D.draft-mcguinness-mission-runtime]), as carried by the deployment's decision-API binding (for example, the AuthZEN binding carries this as the decision-API response's evaluation identifier, [I-D.draft-mcguinness-mission-authzen]). Distinct from evidence_id: evaluation_id correlates this record with the evaluation and with every other record and wire artifact of the same evaluation; evidence_id names this evidence record alone.¶

mission:

REQUIRED. An object. The decision request's Mission reference 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 Mission reference.¶

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 Mission reference, 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. Subject identifiers and assurance metadata, never a raw claim set, minimized per the deployment's audit policy.¶

resource:

REQUIRED. An object. The resource identifier and type; any further resource properties are minimized to what the deployment's audit policy declares.¶

action:

REQUIRED. An object. The action's name or identifier and non-sensitive classification metadata only. It MUST NOT contain the request's properties.parameters, under any name: the parameter binding this record carries is parameter_digest alone, an evidence projection of the decision request rather than a pass-through of it.¶

audience:

REQUIRED. A string. The audience the PDP evaluated: the runtime profile's audience input to the Decision Output ([I-D.draft-mcguinness-mission-runtime]), as carried by the deployment's decision-API binding (for example, the AuthZEN binding's decision-API request's audience member, [I-D.draft-mcguinness-mission-authzen]).¶

mission_state_version:

OPTIONAL. An integer. The Mission lifecycle-state version the decision consulted, when the PDP tracks one: the mutable-state counterpart of the compiled-authority policy_view_id ([I-D.draft-mcguinness-mission-runtime]). The PDP computes and records it directly; no decision-API wire echo is required.¶

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 document 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. Actor-chain identifiers and assurance metadata, never a raw claim set, minimized per the deployment's audit policy.¶

credential:

OPTIONAL. An object. Credential-derived identifiers and assurance metadata, never a raw claim set, minimized per the deployment's audit policy. This member MUST contain only claims the PEP verified before invoking the PDP.¶

parameter_digest:

OPTIONAL. A string. The parameter digest the decision was bound to ([I-D.draft-mcguinness-mission-runtime]); REQUIRED for a parameter-bound action.¶

obligations:

REQUIRED whenever the decision response contained obligations, on either decision. An array of obligation objects, recorded as returned to the PEP (for example, as carried by the AuthZEN binding, [I-D.draft-mcguinness-mission-authzen]).¶

conditions:

REQUIRED when decision is permit for a consequential action. An object recording the permit's decision conditions in this document's normalized form: valid_until (the validity bound) and use_limit (the consumption bound on evaluation_id; the PDP MUST set use_limit: 1 for a permit in the high-consequence classes). The parameter binding is recorded once, in this record's parameter_digest member; the producer MUST ensure that value equals the binding carried by the wire conditions. A binding maps its wire members onto this form (for example the AuthZEN binding's conditions response member, [I-D.draft-mcguinness-mission-authzen]).¶

evaluation_request_digest:

CONDITIONAL. A string. A privacy-preserving digest of the whole 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]). Distinct from parameter_digest: that member records the parameter binding the decision was bound to; evaluation_request_digest is this record's fallback digest of the whole evaluation request, present whether the decision was a permit or a deny.¶

compensates_evaluation_id:

OPTIONAL. A string. The evaluation_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. The identifiers support correlation and targeted reconstruction of the decision, given access to the policy content and inputs those identifiers name; the array alone, without that access, does not reconstruct the decision basis.¶

sequence:

REQUIRED. An integer. The per-Mission sequence indicator the runtime profile requires, so one emitter's 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 and orders records within (Mission, emitter). It does not reconstruct Mission-wide decision order across emitters: cross-emitter ordering is best-effort, established, where the deployment's evidence supports it, from the correlation members (evaluation_id, mission.id, hop_reference) together with each record's timestamps, not from sequence alone.¶

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, issuer) for records emitted under these conventions at other enforcement points, or by the Mission Issuer's own retained producers (for example, protected-event ingestion, [I-D.draft-mcguinness-oauth-mission-containment]). A verifier MUST bind the emitter's signing key to the enforcement scope and audience the record serves (Section 4.3).¶

denial_reason:

CONDITIONAL. A string. Present when decision is deny. A value naming the runtime profile's failure-condition classification ([I-D.draft-mcguinness-mission-runtime]), as carried by the deployment's decision-API binding, including any specification-defined extension under that binding's extensibility rule; a consumer MUST treat an unrecognized value as a deny and MUST NOT attach any other semantics to it. For example, the AuthZEN binding carries this as its wire denial-reason strings ([I-D.draft-mcguinness-mission-authzen]). 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. The runtime profile's decision timestamp ([I-D.draft-mcguinness-mission-runtime]), as carried by the deployment's decision-API binding.¶

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. It is the issuance profile's Authority Set entry commitment ([I-D.draft-mcguinness-oauth-mission]). A record of a permit MUST carry authorizing_entry or entry_digest, per the runtime record requirements ([I-D.draft-mcguinness-mission-runtime]).¶

evidence_envelope:

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

A Decision Evidence Object is closed to uncoordinated extension; see Section 8 for the extension rule and the coordinated extension members a deployment following the AuthZEN binding commonly carries (taint, mission_history, capability_source, hop_reference).¶

4.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 refusal that occurs before any PDP decision, whether the refusing component is the PEP or the PDP: a PEP refusal for 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]); or a PDP refusal of an in-scope request that reaches it without the Mission decision context a runtime enforcement scope requires, per the AuthZEN binding ([I-D.draft-mcguinness-mission-authzen]). Such a refusal has no PDP decision and cannot populate the PDP-derived members above. A deployment records it as a Refusal Record, carrying only facts the refusing role verified: a PEP populates the members it can attest from token validation and its own state establishment; a PDP populates the members it can attest from the request it received. Neither role attests facts only the other could verify: the PDP cannot attest PEP-side token checks, and the PEP cannot attest the PDP's own context-completeness check. The boundary is the PDP decision: a Refusal Record is exclusively pre-decision, and once a PDP has decided, every final disposition of a consequential permit, whether completed, failed, or suppressed before release, is Execution Evidence (Section 5), never a Refusal Record:¶

refusal_id:

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

audience:

REQUIRED. A string. The audience or protected-resource identifier, as the refusing component established it.¶

action:

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

resource:

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

decision:

REQUIRED. A string. Always deny.¶

denial_reason:

REQUIRED. A string. For a PEP refusal, 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). For a PDP refusal of an in-scope request that reaches it without the Mission decision context a runtime enforcement scope requires, mission_context_missing. These name pre-evaluation conditions, PEP-side or PDP-side, and are disjoint from the runtime profile's PDP denial reasons for an evaluated decision (for example, as carried by the AuthZEN binding, [I-D.draft-mcguinness-mission-authzen]); a record that can populate the PDP-derived members of an evaluated decision is a Decision Evidence Object instead.¶

evaluated_at:

REQUIRED. An RFC 3339 [RFC3339] timestamp.¶

parameter_digest:

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

evaluation_request_digest:

CONDITIONAL. A string. A privacy-preserving digest of the whole refused request, in the form of Section 4.5. REQUIRED when parameter_digest is absent, so the record meets the runtime profile's record minimum ([I-D.draft-mcguinness-mission-runtime]). Distinct from a granted permit's parameter_digest condition (Section 4): a Refusal Record has no PDP decision and no permit.¶

mission:

OPTIONAL. An object. The Mission reference (id, issuer, authority_hash), present only when the refusing component established it before the failure: for a PEP, for example, on pdp_unreachable; for a PDP refusing on mission_context_missing, the reference is typically absent, since that is exactly what the request lacked.¶

subject, actor, credential:

OPTIONAL. Objects. Verified facts only, in the projected forms Section 4 defines (for example, as carried in the AuthZEN binding's decision-API request, [I-D.draft-mcguinness-mission-authzen]). A PEP populates them from its own token validation; a PDP populates them from the request context it received, never asserting a check only the other role can perform. 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 4); absent when no Mission was established.¶

emitter:

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

hop_reference:

OPTIONAL. An object, in the coordinated extension form Section 8 defines. Present only when the refusing component verified enough of the presented credential, before the failure, to establish it was a continued credential.¶

evidence_envelope:

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

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

Refusal Records are per-attempt, immutable, and append-only: a sustained failure condition with a retrying agent yields one signed record per attempt, never a record amended or replaced in place. A deployment MAY maintain a separate derived summary over a series of Refusal Records for reporting purposes (for example, a count of refusals sharing denial_reason, audience, and action over a window). That summary is not a Refusal Record, is not signed as one, and adds no evidentiary standing beyond the inputs it summarizes.¶

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

A PDP-side refusal, recorded by the PDP itself: an in-scope request reached it without the Mission decision context the AuthZEN binding requires, so no Mission reference is established and the PDP populates only what it can attest from the request it received:¶

{
  "refusal_id": "ref_9NcT4wQ1xM6rB3sK7eV0jY2wLz",
  "audience": "https://erp.example.com",
  "action": { "name": "journal-entries.write" },
  "parameter_digest":
    "sha-256:WPVi6EnQ7H9Fh-qk9ADxmTg8zruOdVUX1esl-v3TfCI",
  "decision": "deny",
  "denial_reason": "mission_context_missing",
  "emitter": { "id": "pdp.example.com", "role": "pdp" },
  "evaluated_at": "2026-11-02T08:17:02Z",
  "evidence_envelope": {
    "format": "jws-compact",
    "value": "eyJhbGciOiJFUzI1NiIsImtpZCI6InBkcC1rZXkt..."
  }
}

4.3. Integrity

The evidence_envelope carries the integrity protection over the Decision Evidence content. This document 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.¶

A verifier MUST perform the following steps, in order, and MUST NOT treat a record as verified if any step fails:¶

1. Decode the JWS payload.¶

2. Compute the JCS [RFC8785] canonical bytes of the outer record with the evidence_envelope member removed.¶

3. Require byte-for-byte equality between the decoded payload of step 1 and the canonical bytes of step 2, rejecting the record on any difference. The signature authenticates only its own embedded payload; an outer object that differs from that payload is unauthenticated, regardless of whether the signature itself verifies.¶

4. Verify the JWS signature and protected header 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. This procedure applies wherever verification of the evidence_envelope is described in this document, including for Execution Evidence and Refusal Records.¶

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: the record's own audience member, present directly on Decision Evidence, Execution Evidence, and Refusal Records alike (for Decision Evidence, mirroring the decision-API request's audience member, [I-D.draft-mcguinness-mission-authzen]). 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.¶

Where the selected signing key is identified as compromised by the deployment-defined key-status mechanism, the verifier MUST apply the compromise-boundary rule of Section 10.2 before treating the signature as verified: only an independently trusted existence proof over the complete signed artifact, or its unambiguous typed digest, establishing existence before the authenticated boundary permits the remaining steps to continue, and the record's own asserted timestamps never satisfy it.¶

The JWS protected header MUST carry:¶

• kid: a key identifier resolvable in the emitter's published JWKS (Section 10.2), 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, application/mission-receipt+json for Mission Receipts, Section 12). 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.¶

This rule is unaffected by the members Decision Evidence, Execution Evidence, and Refusal Records share with each other and with other evidence types, named once as a base shape ([I-D.draft-mcguinness-mission-audit]). Shared member names describe a common shape for readability; they carry no exemption, and the typ check above remains the sole authority for which kind a signature covers.¶

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

This document defines only the jws-compact format. Additional formats MAY be defined by future specifications; implementations MUST reject envelopes with unsupported formats.¶

4.4. Worked example

{
  "evidence_id": "evd_9Nq3TmR6xL2vP8kY4sD1eB7jH0wC5uA",
  "evaluation_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",
  "conditions": {
    "valid_until": "2026-11-02T08:15:00Z",
    "use_limit": 1
  },
  "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",
  "entry_digest":
    "sha-256:dPCNLHsZuzPXuhco_s21VTvDI4cagI_LMhPQsqfNJKQ",
  "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.¶

4.5. Evaluation request digest worked value

For a consequential action that is not parameter-bound (here a consequential read), the record carries evaluation_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"}

evaluation_request_digest =
  sha-256:sK12VE_g01AHD2v-O1vsf1Gf_xT_htjX0UN0Oe0dDRU

5.1. Members

execution_id:

REQUIRED. A string. Unique execution identifier, stable across delivery retries of this record: exactly one Execution Evidence Object exists per final disposition of a permit, and delivery of that record is at-least-once, so a consumer MUST deduplicate on execution_id rather than assume single delivery. ABNF: 1*64( ALPHA / DIGIT / "-" / "_" ). At least 128 bits of entropy.¶

evaluation_id:

REQUIRED. A string. Correlates this record with the linked Decision Evidence's own evaluation_id (Section 4), and with every other record and wire artifact of the same evaluation.¶

mission_id:

REQUIRED. A string. The Mission id, mirrored from the linked Decision Evidence for join-key convenience.¶

audience:

REQUIRED. A string. The audience the linked Decision Evidence recorded, mirrored for join-key convenience and so a verifier's key-to-audience binding (Section 4.3) has its input.¶

authorized_parameter_digest:

CONDITIONAL. A string. REQUIRED when the linked Decision Evidence carries parameter_digest; MUST equal it. The link to what the permit authorized.¶

effective_parameter_digest:

CONDITIONAL. A string. REQUIRED whenever authorized_parameter_digest is present. The digest, in the same form, over the normalized parameters actually attempted or executed. Equality with authorized_parameter_digest is the binding-held case. Inequality is a parameter deviation, and the record REMAINS VALID: evidence of an unauthorized execution is still evidence, never grounds to discard the record. A deviation recorded against outcome suppressed carries error parameter_mismatch. A deviation recorded against outcome completed or failed, a buggy or compromised executor having gone ahead despite the mismatch, is equally representable, and a consumer MUST flag it as an unauthorized execution.¶

outcome:

REQUIRED. A string. One of completed, failed, or suppressed; a final outcome, recorded once one exists. 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 evaluation identifier), obligation_unfulfilled (a permit suppressed before release because an attached obligation could not be fulfilled; the failing entry is named in obligation_outcomes), 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.¶

obligation_outcomes:

CONDITIONAL. An array of objects. REQUIRED when the linked Decision Evidence carried obligations and a permit disposition exists. One object per attached obligation, with id (REQUIRED, a string, the obligation's identifier as returned by the decision), type (REQUIRED, a string, the obligation type), outcome (REQUIRED, a string, one of fulfilled, failed, or unsupported), and error (OPTIONAL, a string, an implementation-specific detail on a non-fulfilled outcome).¶

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

emitter:

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

hop_reference:

OPTIONAL. An object, in the coordinated extension form Section 8 defines. Present when the linked Decision Evidence carries one.¶

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 4.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 (Section 8): 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.¶

5.2. Worked example

{
  "execution_id":  "exe_4r9SqLm8tY2pXkV3nR0eF7jB1zN6cQ5w",
  "evaluation_id": "dec_8K2nP4qV9rL3tY6sB1zN0eF7jB",
  "mission_id":    "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-",
  "audience":      "https://erp.example.com",
  "authorized_parameter_digest":
    "sha-256:WPVi6EnQ7H9Fh-qk9ADxmTg8zruOdVUX1esl-v3TfCI",
  "effective_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. Here the two Execution Evidence digests are equal: the binding-held case, the executed parameters are the ones the permit authorized.¶

5.3. Worked example: parameter deviation

A later attempt on the same operation, a different permit (evaluation_id dec_9HtV3wN6xQ1rB8mP5kS2eL7jY4zA) bound to the same 423.50 journal entry the runtime profile's parameter-digest example digests ([I-D.draft-mcguinness-mission-runtime]). Between check and use the parameters became {"amount_usd":"780.00","source_invoice_id":"inv_2026Q3_842"}. The executing PEP recomputed the digest over the parameters it was about to use, found it differed from the authorized digest, and suppressed the release before acting:¶

{
  "execution_id":  "exe_7QsK2wR4xN9mV3pB6tY8eJ1zH5uD0cA",
  "evaluation_id": "dec_9HtV3wN6xQ1rB8mP5kS2eL7jY4zA",
  "mission_id":    "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-",
  "audience":      "https://erp.example.com",
  "authorized_parameter_digest":
    "sha-256:WPVi6EnQ7H9Fh-qk9ADxmTg8zruOdVUX1esl-v3TfCI",
  "effective_parameter_digest":
    "sha-256:UdG-TiebDHTiKRXUVURs1Jeq_vDJp_Ro8jWbBAD8hgM",
  "outcome":      "suppressed",
  "error":        "parameter_mismatch",
  "sequence":     44,
  "emitter":      { "id": "pep.example.com", "role": "executor" },
  "attempted_at": "2026-11-02T09:03:28Z",
  "outcome_at":   "2026-11-02T09:03:29Z",
  "evidence_envelope": {
    "format": "jws-compact",
    "value": "eyJhbGciOiJFUzI1NiIsImtpZCI6InBlcC1rZXkt..."
  }
}

The two digests differ: a parameter deviation. The record REMAINS VALID; it is evidence that the executing PEP caught the deviation and suppressed the release, never an invalid record to be discarded. Had the executor instead gone ahead with the 780.00 parameters despite the mismatch, the same two-digest divergence would appear against outcome completed or failed, and a consumer MUST flag that record as an unauthorized execution regardless of the recorded outcome.¶

5.4. 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]). The parameter-digest chain runs from the decision-API request through Decision Evidence's parameter_digest to Execution Evidence's authorized_parameter_digest (REQUIRED to equal it) and effective_parameter_digest (the digest over what the executing PEP actually attempted or executed).¶

Equality between the two Execution Evidence digests is the binding-held case. Inequality is a parameter deviation, and the record REMAINS VALID: evidence of an unauthorized execution is still evidence, never an invalid record to discard. When the executing PEP detects the deviation before acting, it MUST refuse the action and emit Execution Evidence with outcome suppressed and error parameter_mismatch (Section 5.3). A deviation recorded against an outcome of completed or failed, a buggy or compromised executor having gone ahead despite the mismatch, is equally representable and is never grounds to reject the record. Whatever the recorded outcome, when the two digests diverge the audit consumer MUST classify the execution as a parameter deviation and treat it as equivalent to an unauthorized action for compliance purposes.¶

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

6.1. Receipt Kinds

A kind member fixes what a receipt may claim, with exactly three values and the required evidence combination for each:¶

decision:

The receipt projects a Decision Evidence record alone. It claims an authorization decision was rendered; it claims nothing about execution, and a verifier MUST NOT treat it as evidence that an action occurred.¶

execution:

The receipt projects a permit Decision Evidence record and the final Execution Evidence record of the same action. Its outcome is copied from the Execution Evidence and carries that document's semantics unchanged; an action whose outcome is not yet terminal has no execution receipt, and an unresolved action MUST NOT be rewritten as terminal to issue one.¶

refusal:

The receipt projects a Refusal Record alone. A refusal is exclusively pre-decision (Section 4.2), so there is no Decision Evidence for the same evaluation to project beside it. A refusal receipt exists only for a Refusal Record whose own mission member carries the verified Mission reference the receipt's REQUIRED mission member repeats; a pre-decision refusal without an established Mission (a mission_context_missing refusal) remains a Refusal Record and never becomes a Mission Receipt.¶

6.2. Members

A Mission Receipt is a JSON object. REQUIRED members:¶

evidence_envelope:

REQUIRED. An object. Integrity protection in the same form as Decision Evidence (Section 4.3), carrying a format (string, required) and a value (string, required). The default format is jws-compact; the JWS protected typ is application/mission-receipt+json (Section 12).¶

kind:

REQUIRED. A string. One of decision, execution, or refusal (Section 6.1).¶

mission:

REQUIRED. An object, with id (REQUIRED) and issuer (REQUIRED), plus authority_hash (OPTIONAL). The member is this exact object, never a union with another projection. A cross-domain grant or a Mandate that proves the tuple travels beside the receipt at its carriage layer, outside the closed evidence-reference type set of Section 6.3, which a future profile MAY extend.¶

emitter:

REQUIRED. An object, in the form Decision Evidence's emitter member defines (Section 4): id (a string identifying the receipt issuer) and role (a string; receipt_issuer, a role this document registers under that member's extensibility rule). Receipt issuance is limited to components the deployment's enforcement scope statement already names (the PDP, or an executing PEP), and the statement declares which of them issue receipts; the verifier resolves the signing key through that statement's published key sets (Section 10.2) and rejects an emitter the statement does not name as a receipt issuer. A self-published key presenting role receipt_issuer establishes nothing (Section 6.5).¶

evidence:

REQUIRED. An array of evidence references (Section 6.3).¶

issued_at:

REQUIRED. An RFC 3339 [RFC3339] timestamp.¶

outcome:

REQUIRED when kind is execution; absent otherwise. A string, copied from the projected Execution Evidence's outcome (Section 5), carrying that member's semantics unchanged: one of completed, failed, or suppressed.¶

Everything beyond the join and integrity core is optional and selected, never defaulted: a projection profile or a recipient agreement names the optional members a receipt carries, and an issuer minimizes to that selection. Actor chains, policy versions, target detail, and custody topology are correlation surfaces; a receipt carries them when its recipient needs them, not because the underlying evidence has them. A Mission Receipt is evidence, never reusable authorization, and confers no authority on its holder.¶

OPTIONAL members, each a projection from the evidence a receipt of that content already carries:¶

decision:

OPTIONAL. An object, with id (the projected Decision Evidence's own evidence_id) and result (its decision member, permit or deny) (Section 4).¶

policy:

OPTIONAL. An object, with pdp_policy_view (the projected Decision Evidence's mission.policy_view_id) and mission_policy_version (its mission.policy_version, when the Decision Evidence carries it) (Section 4).¶

executor:

OPTIONAL. An object, the projected Decision Evidence's actor member: the authenticated actor and any act chain (Section 4).¶

target:

OPTIONAL. An object, with resource (the projected Decision Evidence's resource member) and audience (its audience member) (Section 4).¶

profile:

OPTIONAL. A string, a URI naming the projection profile in force: the profile that selected the optional members this receipt carries and defines the semantics of any issuer_assertions members. REQUIRED when issuer_assertions is present.¶

issuer_assertions:

OPTIONAL. An object. Facts the receipt issuer asserts on its own authority, structurally separate from the projections above: every member's name and semantics come from the profile, and relying on any of them takes the trust model's explicit-policy path, never the verified-projection path. The credential custody mode (whether a mediating PEP held the credential, [I-D.draft-mcguinness-mission-runtime]) is the motivating member: no Decision or Execution Evidence record carries it, so a profile that needs it defines it here.¶

chain:

OPTIONAL. An object (Section 6.4).¶

6.3. Evidence References

Each evidence entry is an object. All members REQUIRED:¶

type:

REQUIRED. A string. The referenced record's registered media type: application/mission-decision-evidence+json, application/mission-execution-evidence+json, or application/mission-refusal-record+json (Section 12, Section 4, Section 5, Section 4.2).¶

digest:

REQUIRED. A string. A sha-256: prefixed digest, classified under the substrate's default commitment construction ([I-D.draft-mcguinness-mission-substrate]) as a canonical-object digest for a JSON evidence record and a raw-octet digest for a JWS- or JWT-shaped artifact. For a JSON evidence record the digest input is the exact canonical bytes the convention fixes for that record: the complete object, evidence_envelope included, JCS [RFC8785] canonicalized (Section 4.3). For a compact-serialized artifact the digest input is the exact serialization octets, as issued.¶

evidence_id:

REQUIRED. A string. The referenced record's own identifier member: evidence_id for a Decision Evidence record (Section 4), execution_id for an Execution Evidence record (Section 5), or refusal_id for a Refusal Record (Section 4.2).¶

emitter:

REQUIRED. An object, in the form Decision Evidence's emitter member defines (Section 4): id and role. Enough to select the emitting component's published key set before the referenced record is resolved; the specific signing key is selected, once resolved, by that record's own JWS kid.¶

An evidence array carries the combination Section 6.1 fixes for the receipt's kind: one Decision Evidence reference alone for decision; a permit Decision Evidence reference and the final Execution Evidence reference of the same action for execution; one Refusal Record reference alone for refusal. A reference to a record type the verifier does not implement fails verification; it is not skipped.¶

6.4. Receipt Chaining

Chaining is OPTIONAL, orthogonal to transparency, and never a substitute for it: a signer-controlled hash chain can be truncated, forked, or presented differently to different verifiers, so it gives tamper-evident linkage within the view a verifier is shown, never global ordering or inclusion. A deployment that needs those properties runs the audit transparency profile or anchors the chain head independently; a deployment without either still MAY chain, or MAY not.¶

A chain is scoped to one (Mission, receipt issuer, stream): the chain member carries stream (an issuer-chosen identifier), sequence (an integer, strictly increasing per stream), and previous (an array of one or more digests of predecessor receipts in the same scope, present on every receipt after the stream's first). Concurrent issuance either serializes per stream or records multiple predecessors; a verifier treats the result as a DAG and checks only linkage and sequence monotonicity, never completeness. The scope's receipt issuer is the emitter the predecessor and successor receipts carry (Section 6.5).¶

A predecessor digest is a canonical-object digest (Section 6.3): the complete predecessor Mission Receipt object, evidence_envelope included, JCS canonicalized, the same construction an evidence reference's digest uses over a Decision, Execution, or Refusal record, so this digest too covers the signature rather than only the unsigned payload. The predecessor object is itself a Mission Receipt, typed application/mission-receipt+json, so the digest cannot be read as committing to any other record type.¶

6.5. Receipt Verification

A verifier MUST perform the following steps, in order, and MUST NOT rely on a receipt if any step fails. Where the receipt issuer's signing key is identified as compromised, these steps are additionally governed by the compromise-boundary rule of Section 10.2:¶

1. Verify the receipt's evidence_envelope: decode the JWS payload, compute the JCS canonical bytes of the receipt with evidence_envelope removed, and require byte-for-byte equality, rejecting on any difference (Section 4.3). Confirm the JWS protected typ is application/mission-receipt+json and verify the signature against the published key resolved by the JWS kid for the party named in emitter, through the enforcement scope statement's published key sets (Section 10.2). Confirm that statement names the emitter as a receipt issuer; the receipt's Mission binding is established by the verified records and the joins of step 4, never by key publication alone.¶

2. Confirm the kind's required evidence combination is present (Section 6.1, Section 6.3).¶

3. Resolve each evidence reference. Verify each resolved record under its own rules (Section 4.3). Recompute each digest over the defined bytes (Section 6.3) and require equality. Require the resolved record's own identifier to equal evidence_id and its emitter and key to match emitter.¶

4. Join the records: the same mission.id and mission.issuer as the receipt's mission; the Execution Evidence joins the Decision Evidence on evaluation_id (Section 4, Section 5); audience and target, and the authorized and effective parameter digests, are consistent across the records per the runtime's rules ([I-D.draft-mcguinness-mission-runtime]); for execution, the receipt's outcome equals the Execution Evidence's terminal outcome.¶

5. Require every copied optional member to equal the corresponding member of the record it projects.¶

6. When chain is present (Section 6.4): resolve each previous digest to a predecessor receipt, verify the predecessor's own envelope, require the same mission, emitter, and chain.stream as this receipt, recompute the predecessor digest over its complete canonical bytes and require equality, and require each predecessor's chain.sequence to be strictly less than this receipt's. Monotonicity is relative to the receipt's predecessors, never a claim of a globally serialized stream. A predecessor unresolvable within the retention obligations of Section 6.6 fails chain verification.¶

7. Reject on: a missing required record, a record of an unimplemented type, digest mismatch, emitter or key mismatch, join failure, a chain-linkage failure, or a copied field that differs. A verifier MUST NOT treat the receipt as verified if any step fails (Section 4.3).¶

6.6. Retention

A Mission Receipt inherits the runtime's record-integrity and retention floor (Section 5). A receipt is retained at least as long as the records it projects; conversely, the referenced evidence and the historical verification keys MUST remain retained or resolvable for as long as verifiers are expected to validate the receipt ([I-D.draft-mcguinness-mission-runtime]).¶

6.7. Worked example

A complete execution receipt, projecting records carrying the identifiers of Section 4 and Section 5's worked examples; Section 6.8 fixes the exact bytes verified for the execution reference:¶

{
  "kind": "execution",
  "mission": {
    "id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-",
    "issuer": "https://as.example.com",
    "authority_hash":
      "sha-256:l3KvZ4mP5x0wQrR6tY2nD9bM7sX1cF8gH2vJ4kE5pNQ"
  },
  "emitter": { "id": "receipts.example.com", "role": "receipt_issuer" },
  "evidence": [
    {
      "type": "application/mission-decision-evidence+json",
      "digest":
        "sha-256:fS_yB6-Yit7Gsz-6vw73q7YphoiRm3VwC-3Pk8xW9J0",
      "evidence_id": "evd_9Nq3TmR6xL2vP8kY4sD1eB7jH0wC5uA",
      "emitter": { "id": "pdp.example.com", "role": "pdp" }
    },
    {
      "type": "application/mission-execution-evidence+json",
      "digest":
        "sha-256:Ims1Xx5FAPYfFB6c6Y2gbqybB-Z2PxCi93yWPcIHmC8",
      "evidence_id": "exe_4r9SqLm8tY2pXkV3nR0eF7jB1zN6cQ5w",
      "emitter": { "id": "pep.example.com", "role": "executor" }
    }
  ],
  "issued_at": "2026-11-02T08:14:06Z",
  "outcome": "completed",
  "decision": {
    "id": "evd_9Nq3TmR6xL2vP8kY4sD1eB7jH0wC5uA",
    "result": "permit"
  },
  "policy": {
    "pdp_policy_view":
      "sha-256:kP3xR9sQ7nM2vL4tY6bD1eF8jC5wH0pV2nR3kQ4mZ7t",
    "mission_policy_version": "deploy-policy:v17"
  },
  "executor": {
    "client_id": "s6BhdRkqt3",
    "client_instance_id": "inst_macbook_7f3a",
    "act": [
      { "iss": "https://as.example.com", "sub": "s6BhdRkqt3" }
    ]
  },
  "target": {
    "resource": {
      "type": "journal-entry",
      "id": "je_2026Q3_inv_8421"
    },
    "audience": "https://erp.example.com"
  },
  "evidence_envelope": {
    "format": "jws-compact",
    "value": "eyJhbGciOiJFUzI1NiIsImtpZCI6InJlY2VpcHQta2V5..."
  }
}

6.8. Digest vector

A reproducible digest for the execution evidence reference above. The referenced record is a minimal Execution Evidence stand-in carrying only the members Section 5 requires, consistent with that section's worked example's identifiers. This is a digest-only vector: the stand-in's evidence_envelope.value is an illustrative placeholder, not a signature over these bytes, so the object fixes digest computation alone and would fail the byte-equality verification of Section 4.3 by design:¶

{
  "audience": "https://erp.example.com",
  "emitter": { "id": "pep.example.com", "role": "executor" },
  "evaluation_id": "dec_8K2nP4qV9rL3tY6sB1zN0eF7jB",
  "evidence_envelope": {
    "format": "jws-compact",
    "value":
      "eyJhbGciOiJFUzI1NiIsImtpZCI6InBlcC1rZXktMSJ9.dGhlLXNpZ25lZC1wYXlsb2FkLWJ5dGVzLWFib3Zl.RVMyNTZfc2lnbmF0dXJlX2J5dGVzX2lsbHVzdHJhdGl2ZQ"
  },
  "execution_id": "exe_4r9SqLm8tY2pXkV3nR0eF7jB1zN6cQ5w",
  "mission_id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-",
  "outcome": "completed",
  "outcome_at": "2026-11-02T08:14:05Z",
  "sequence": 43
}

The digest input is the JCS [RFC8785] canonical bytes of that object, member names sorted, no whitespace (one line, 506 bytes, shown here wrapped for layout only; remove the layout line breaks, adding no characters, to recover the canonical form):¶

{"audience":"https://erp.example.com","emitter":{"id":"pep.example.
com","role":"executor"},"evaluation_id":"dec_8K2nP4qV9rL3tY6sB1zN0e
F7jB","evidence_envelope":{"format":"jws-compact","value":"eyJhbGci
OiJFUzI1NiIsImtpZCI6InBlcC1rZXktMSJ9.dGhlLXNpZ25lZC1wYXlsb2FkLWJ5dG
VzLWFib3Zl.RVMyNTZfc2lnbmF0dXJlX2J5dGVzX2lsbHVzdHJhdGl2ZQ"},"execut
ion_id":"exe_4r9SqLm8tY2pXkV3nR0eF7jB1zN6cQ5w","mission_id":"msn_8R
fX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-","outcome":"completed","outcome_at":
"2026-11-02T08:14:05Z","sequence":43}

digest = sha-256:Ims1Xx5FAPYfFB6c6Y2gbqybB-Z2PxCi93yWPcIHmC8

9.1. Compromise-Boundary Outcomes

A VERIFIER and a RECEIPT VERIFIER conform to the compromise-boundary rule (Section 10.2) when each of the following holds:¶

• a self-asserted pre-boundary timestamp does not rescue a record signed under a compromised key;¶

• a key identified as compromised with no authenticated boundary available yields not-verified, with no boundary inferred from artifact timestamps, the verifier's clock, or a default;¶

• a verified independent proof over the complete signed artifact or its unambiguous typed digest, with an authenticated time before the boundary, permits the ordinary verification algorithm to continue;¶

• a proof whose authenticated time is at or after the boundary does not;¶

• the underlying record stays not-verified in every failure case: a missing, unavailable, or unresolvable proof is an audit failure, a presented proof failing its own cryptographic or commitment verification is an integrity failure of the proof, and neither is a finding of tampering against the underlying evidence;¶

• a proof authenticated by a key itself identified as compromised qualifies only through a distinct independent pre-boundary anchor; and¶

• the same outcomes hold for Mission Receipts and for harness evidence.¶

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

10.2. Evidence integrity and signing keys

The evidence_envelope binds each record to the emitting PDP or PEP. The PDP's jws-compact signing key MUST be resolvable, 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 document 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 key's compromise status, and the authenticated compromise boundary, come from the deployment-defined key-status mechanism. Once the signing key is identified as compromised, the compromise-boundary rule applies. A verifier MUST NOT use a timestamp asserted by the target artifact, or authenticated only by the target artifact's compromised signing key, to place that artifact before the boundary; it MAY use the authenticated time of an independently trusted recovery proof after verifying that proof under the proof's own non-compromised trust path. It MUST NOT treat an artifact under a compromised key as verified unless such a proof commits to the complete signed artifact, or to its unambiguous typed digest, and establishes its existence before that boundary. Where the key is identified as compromised but no authenticated boundary is available, the artifact is not verified: the verifier MUST NOT infer a boundary from artifact timestamps, its own clock, or an implementation default. Such a proof establishes only that those bytes existed by the proof time; it does not establish the truth of the artifact, the actual signature time, or that the key was not compromised earlier. This rule applies whether or not the deployment adopted the audit profile: registration under the audit profile ([I-D.draft-mcguinness-mission-audit]) or a trusted timestamp is the optional recovery mechanism, and without one, a record under the compromised key is not verified merely because it claims a pre-boundary time. For a Receipt-based proof, the verifier completes the audit profile's Receipt verification in full, including the Transparency Service signature, the authenticated registration time, the inclusion proof, the type binding, and the digest linkage to the complete evidence bytes; a bare inclusion path or a payload timestamp is insufficient. Independently trusted requires a valid, non-compromised proof-verification path: where a key authenticating the proof is itself identified as compromised, the proof is subject to this same rule for that key and qualifies only through a distinct independent pre-boundary anchor; otherwise it cannot rescue the artifact. An artifact refused under this rule is not verified in every case. A missing, unavailable, or unresolvable proof is an audit failure; a presented proof that fails its own cryptographic or commitment verification is an integrity failure of the proof. Neither outcome by itself establishes that the underlying evidence was altered.¶

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

Verification under this section is anchored in the Enforcement Scope Statement's published keys: a party with access to that statement can verify a record independently of the deployment that emitted it. Portability beyond that, to a party without access to the deployment's own published keys, is not a property this document provides; it requires the transparency mechanisms of the audit profile ([I-D.draft-mcguinness-mission-audit]), where a deployment adopts them.¶

10.3. Transport

Audit channels carrying Decision Evidence and Execution Evidence MUST be served over TLS 1.2 or later (TLS 1.3 RECOMMENDED). Evidence at rest MUST be encrypted per the deployment's data-protection posture.¶

10.4. Mission Receipt

A Mission Receipt that copies fields from its underlying evidence invites a verifier to treat the receipt signer as authoritative for those facts; the trust model (Section 6) and the verification algorithm (Section 6.5) are the control, not the receipt's signature alone.¶

Chaining gives view-local linkage only: a signer-controlled chain can be truncated, forked, or presented differently to different verifiers (Section 6.4); a deployment that needs global ordering or inclusion runs the audit transparency profile or anchors the chain head independently.¶

A compromised receipt-issuer signing key is governed by the compromise-boundary rule of Section 10.2, applied during Receipt verification (Section 6.5): timestamps asserted by the receipt itself never establish that its signature predates the boundary.¶

11.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 (or, on Execution Evidence, authorized_parameter_digest and effective_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 5.¶

Where the cross-domain Origin Principal profile is in use ([I-D.draft-mcguinness-oauth-mission-cross-domain]), retained records SHOULD carry the composed principal_mapping extension member (Section 8) with protected subject references, not raw identities, unless the raw identity is necessary for the stated audit purpose. A protected subject reference is one of: an audit-domain-scoped keyed pseudonym (an HMAC under an audit key, carried with a method identifier, a key identifier, and rotation semantics); a random opaque mapping reference resolvable by authorized auditors; or, only where cross-record correlation is explicitly intended, the deterministic public digest of the family anchor idiom ([I-D.draft-mcguinness-oauth-mission]) with typ mission-origin-subject over the closed {iss, sub} object. A deterministic digest of an enumerable identifier is dictionary-attackable: it is correlation infrastructure, not concealment, and a deployment using it MUST disclose that limitation.¶

11.2. Parameter exposure

This restates, for the privacy reader, the action member's rule (Section 4): the durable Decision Evidence record MUST NOT contain the raw properties.parameters object under any name; it carries only parameter_digest and, at most, non-sensitive action classification 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 evaluation_id. When the parameters are themselves PII, the PEP SHOULD supply only a parameter digest to the PDP, omitting the raw 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.¶

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

11.4. Mission Receipt

The Mission Receipt's optional members (Section 6) are correlation surfaces, the same as the evidence they project from. Minimization to the selection a projection profile or recipient agreement names is the rule, not a default. A receipt crosses a trust boundary by design, so an issuer carries only the members its recipient needs.¶

12.1. Media Type Registry

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

13.1. Normative References

[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-mission-substrate]

McGuinness, K., "Mission Substrate Requirements", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-substrate.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-cross-domain]

McGuinness, K., "Mission Cross-Domain Projection for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-cross-domain.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>.

13.2. Informative References

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

McGuinness, K., "Mission Audit Transparency", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-audit.html>.

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

McGuinness, K., "Mission-Bound Runtime Enforcement: AuthZEN Profile", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-authzen.html>.

[I-D.draft-mcguinness-mission-capability-binding]

McGuinness, K., "Mission Capability Binding", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-capability-binding.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-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-continuation]

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