Network Working Group K. McGuinness Internet-Draft Independent Intended status: Standards Track 23 August 2026 Expires: 24 February 2027 Mission Approval Governance draft-mcguinness-mission-approval-governance-latest Abstract Mission-Bound Authorization records exactly one accountable Approver per Mission and defers approval-authority provenance to a governance layer. This document defines that layer's record: the Approval Governance Record, an issuer-retained, issuer-signed record of the policy, assertions, and evaluation standing behind an approval event. It gives an estate first-class, auditable answers to who approved, under which authority, and why the decision satisfied governance, without adding any wire artifact. The record never appears on tokens, protocol messages, or enforcement projections, and the Mission record's single accountable Approver is unchanged. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://mcguinness.github.io/mission-bound-authorization/draft- mcguinness-mission-approval-governance.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft- mcguinness-mission-approval-governance/. Source for this draft and an issue tracker can be found at https://github.com/mcguinness/mission-bound-authorization. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 24 February 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction 2. Status: An Optional Extension 3. Conventions and Definitions 4. Relationship to the Issuance Profile 5. The Approval Governance Record 6. Assertion Requirements 7. Evaluation and Atomic Commitment 8. Policy-Approval Recency 9. Envelope and Verification 10. Recording Triggers 11. Consent Evidence Relationship 12. Boundaries 13. Mission Evidence 14. Security Considerations 14.1. Forged or Padded Assertions 14.2. Policy Substitution 14.3. Manufactured Accountability 14.4. Stale Policy Approval 14.5. Immutability Witness 14.6. Issuer Key Compromise 15. Privacy Considerations 16. IANA Considerations 16.1. Media Type Registration 16.1.1. application/mission-approval-governance+jws 16.1.2. application/mission-approval-governance+json 17. Conformance 18. References 18.1. Normative References 18.2. Informative References Acknowledgments Author's Address 1. Introduction An authority-bearing binding of the Mission model records one accountable Approver and defers multi-party approval and approval- authority provenance to a governance layer ([I-D.draft-mcguinness-oauth-mission] states the rule for the OAuth binding, whose record members this document's binding rules consume). An enterprise review surface is often that governance layer: a decision may involve several principals, a threshold or separation- of-duty rule, and a delegation-of-authority policy, and an auditor later needs to prove not only who approved but under which authority the approval was valid. This document defines the Approval Governance Record (AGR) as governance evidence with teeth: where it is recorded, it participates in whether the Mission activates, so its assertions carry authentication and binding requirements, and its committed form is signed and immutable. Before commitment, the record is part of the approval decision itself: an assertion that fails authentication, event binding, or policy authorization MUST NOT contribute, and a record that cannot be evaluated or persisted MUST prevent activation. After commitment, the record is evidence: immutable, signed, and consumed by audit, never by enforcement. 2. Status: An Optional Extension This document is optional. A deployment that records nothing beyond the Mission record's accountable approver is fully conformant to its Mission binding and unaffected by this document. Profiles MAY require this record; the Enterprise Mission Authority Profile does so under its recording triggers ([I-D.draft-mcguinness-mission-authority-server]). This document is ceremony-independent: it applies to synchronous approval, deferred approval ([I-D.draft-mcguinness-oauth-mission-approval]), and the standalone Mission Authority Server's native asynchronous approval alike, and depends on no deferral substrate. 3. Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. This document uses JSON [RFC8259] as the data model for the Approval Governance Record. JCS canonicalization [RFC8785] applies wherever this document computes a digest or a signing input, under the canonicalization rules of [I-D.draft-mcguinness-oauth-mission]; this document does not define a second canonicalization. A digest is encoded in the integrity-anchor encoded form of [I-D.draft-mcguinness-oauth-mission]: the sha-256: prefix followed by the base64url, no-padding encoding of the digest. This document defines no digest algorithm of its own. Its two digests are classified under the substrate's default commitment construction, which this document imports normatively ([I-D.draft-mcguinness-mission-substrate]): approval_policy.digest is an envelope anchor, and the record digest (Section 9) is a canonical- object digest. The terms Mission, Mission Issuer, Approver, approval event, Mission Intent, approval_event_id, intent_hash, authority_hash, and controls are used as defined in [I-D.draft-mcguinness-oauth-mission]. Approval Governance Record (AGR): The record this document defines: the policy, assertions, and evaluation standing behind one approval event (Section 5). Assertion: One principal's authenticated decision statement carried in an AGR (Section 5). Evaluation: The issuer's determination of whether the recorded assertions satisfy the referenced approval policy (Section 5). Recording trigger: A condition under which a profile requires this record for an approval event (Section 10). 4. Relationship to the Issuance Profile The Mission record carries exactly one accountable approver, and this document does not change that: the accountable Approver remains the only principal any downstream projection, token, or enforcement point consumes. The record captures the standing behind that approval, never a second authorization surface visible outside the issuer. approval_event_id joins the record to the approval event and to the Mission record it governs ([I-D.draft-mcguinness-oauth-mission]). The record never appears on tokens or in any protocol message; it is issuer-retained control-plane state. 5. The Approval Governance Record An Approval Governance Record is a JSON object with these members, plus the integrity envelope Section 9 defines. approval_event_id: REQUIRED. A string. The approval event's identifier, equal to the Mission record's approval_event_id ([I-D.draft-mcguinness-oauth-mission]). mission: REQUIRED. An object binding the record to the approved Mission: issuer (the Mission Issuer), intent_hash, and authority_hash, each equal to the committed Mission record member of the same name. A record whose binding does not match the Mission record it is retained with is invalid. approval_policy: REQUIRED. An object identifying the governing delegation-of-authority policy: id (an identifier), version (a string), and digest (an integrity anchor over the retained policy snapshot, in the encoded form Section 3 fixes). The digest preimage is the issuance profile's integrity-anchor envelope ([I-D.draft-mcguinness-oauth-mission]) with typ mission-approval- policy, iss the Mission issuer, and value an object of content_type (the snapshot's media type) and content (the base64url, no-padding encoding of the snapshot bytes), canonicalized with JCS [RFC8785]: the typ domain-separates this anchor from every other anchor in the family, and the issuer binding prevents cross-issuer replay. The snapshot bytes and their media type, or the referenced policy version they represent, MUST be retained for the Mission's audit horizon ([I-D.draft-mcguinness-oauth-mission]), so an independent auditor reproduces the digest exactly and re-checks the evaluation against the policy that governed it. Threshold, quorum, veto, and separation-of-duty semantics live in the referenced policy; any human-readable summary of them in deployment tooling is advisory and carries no semantics in this record. assertions: REQUIRED. An array of one or more decision assertions. Each carries: assertion_id: REQUIRED. A string, unique within the record. principal: REQUIRED. An object with iss and sub. kind: REQUIRED. A string, one of human, service, or policy. decision: REQUIRED. A string, one of approve or deny. decided_at: REQUIRED. An RFC 3339 [RFC3339] timestamp. authority: REQUIRED. A reference to the provenance under which this principal was authorized to decide. For a human assertion, the authentication context of the assertion. For a policy assertion, the deciding policy's identifier and version, and approved_at: the family's provenance chain for non-human approval, in which the policy approves the instance because a human approved the policy. approved_at is an RFC 3339 timestamp: the human approval instant of that exact policy version, not the assertion instant. decided_at records when the policy asserted; approved_at records when a human approved the version it asserts under. The issuer MUST verify approved_at from retained, authenticated governance state for the named policy_id and version; it MUST NOT accept approved_at as the assertion's own uncorroborated clock value (Section 8). reason: OPTIONAL. A string. evaluation: REQUIRED. An object recording the outcome: decision (a string, approved, the only value a committed record carries, since a record exists only for an approval that committed, Section 7), evaluated_at (an RFC 3339 timestamp), and contributing (an array of the assertion_id values the evaluation relied on). envelope: REQUIRED. An object. Integrity protection over the members above, in the form Section 9 defines. { "approval_event_id": "ape_8K2nP4qV9rL3tY6sB1z", "mission": { "issuer": "https://as.example.com", "intent_hash": "sha-256:wQ7p4LHnX9Md0LqJ6sZJ8b8mZ3rN2xT5pV4lE6sQqYY", "authority_hash": "sha-256:l3KvZ4mP5x0wQrR6tY2nD9bM7sX1cF8gH2vJ4kE5pNQ" }, "approval_policy": { "id": "dlg-matrix", "version": "v7", "digest": "sha-256:OAbEIh2DTYUVP7DjRhHct4aapsT8PybZq2ILdut9UP0" }, "assertions": [ { "assertion_id": "ast_1", "principal": { "iss": "https://login.example.com", "sub": "manager@example.com" }, "kind": "human", "decision": "approve", "decided_at": "2026-09-30T16:58:11Z", "authority": { "role": "finance-manager" } }, { "assertion_id": "ast_2", "principal": { "iss": "https://as.example.com", "sub": "policy:finance-charter" }, "kind": "policy", "decision": "approve", "decided_at": "2026-09-30T16:58:12Z", "authority": { "policy_id": "dlg-matrix", "version": "v7", "approved_by": { "iss": "https://login.example.com", "sub": "cfo@example.com" }, "approved_at": "2026-09-15T09:00:00Z" } } ], "evaluation": { "decision": "approved", "evaluated_at": "2026-09-30T16:58:13Z", "contributing": ["ast_1", "ast_2"] }, "envelope": { "format": "jws-compact", "value": "eyJhbGciOiJFUzI1NiIsImtpZCI6ImFzLWtleS0y..." } } The Mission record's accountable approver in this example is manager@example.com; ast_1 is that principal's own approve assertion, satisfying the accountable-approver rule of Section 6 directly. ast_2 is a policy assertion carrying its own provenance chain, recorded alongside rather than in place of the accountable approver's assertion. The envelope member's value is the JWS whose payload is the JCS canonical bytes of this object with envelope itself removed (Section 9). 6. Assertion Requirements These rules are the record's security core. * Every assertion that contributes to the evaluation MUST be authenticated: a human assertion with the authentication the issuance profile requires of an Approver at an approval event, a service or policy assertion through an integrity-protected channel or signature the issuer verifies. * Every assertion MUST be bound to this approval event: an assertion is made against this approval_event_id and this authority_hash, and an assertion captured for one event MUST NOT be replayed into another. * Every contributing assertion MUST be policy-authorized: the issuer verifies the asserting principal was eligible to assert under the referenced approval_policy version before counting it. * Denials and vetoes MUST be recorded: an assertion set that omits a negative assertion misrepresents the decision. * Exactly one assertion MUST match the Mission record's accountable approver and carry an approve decision; the record supports the approval it claims to govern or it does not commit. A policy- authority Approver satisfies this with a policy assertion carrying its provenance chain, subject to the high-risk-class restriction of Section 8. * An assertion that fails authentication, event binding, or policy authorization MUST NOT contribute to the evaluation and MUST NOT be counted toward any policy rule. 7. Evaluation and Atomic Commitment Where a deployment records the Approval Governance Record for an approval, the record and the Mission are one commit: the issuer evaluates the assertions under the referenced policy, and the Mission record MUST NOT be created active unless the evaluation's decision is approved and the signed record persists atomically with the Mission's creation. Failure to authenticate the contributing assertions, to complete the evaluation, or to persist the record MUST prevent activation; there is no Mission whose governance record was meant to exist and does not. A governance evaluation that denies creates no Mission and no committed record: negative assertions retained inside a committed record document dissent (Section 6), and a wholly declined approval's evidence surface is consent evidence's declined outcome ([I-D.draft-mcguinness-oauth-mission-consent-evidence]), which exists without a Mission record. The issuer signs the evaluated record (Section 9) and persists the signed form in the same commit as the Mission's creation; signing follows evaluation and precedes persistence, never the reverse. A committed record is immutable. A subsequent governance action, a re-review or an incident finding, is a new record about a new event, never an edit. 8. Policy-Approval Recency This section bounds staleness on the AGR policy assertion path: it governs a policy assertion's authority.approved_at and the kind of the accountable-approver's assertion. It does not apply to a human assertion, whose decided_at is the approval instant itself. A Recording Issuer that admits policy assertions MUST declare a maximum policy-approval age per consequence class (a *recency ceiling*) and a bounded clock-skew allowance, and MAY declare, per class, an *exception* admitting a policy assertion as the accountable approver's assertion for that class, each exception carrying its own maximum age. The ceiling, the skew allowance, and any exception MUST be part of the retained approval_policy snapshot that approval_policy.digest commits (Section 5), or a separately versioned declaration committed from that snapshot. A mutable, out-of-band deployment statement MUST NOT serve this role: it would make the evaluation impossible to reproduce, contrary to the promise of Section 5 that the retained policy lets an auditor re-run the decision. At evaluation, the issuer MUST classify the committed Mission's consequence classes from the derived Authority Set and from any consumption bound Mission Intent controls carries ([I-D.draft-mcguinness-mission-metering]). The issuer MUST select, across every class either source carries, the strictest maximum age that applies, accounting for any declared exception. This is a property of the whole committed Mission the record's mission.authority_hash and mission.intent_hash bind to (Section 5), never of one assertion or entry in isolation. For each policy assertion the evaluation would count toward the applicable maximum, the issuer: * MUST verify authority.approved_at from retained, authenticated governance state for the exact policy_id and version the assertion names; * MUST measure the assertion's age as evaluation.evaluated_at minus authority.approved_at, using the atomic-commitment instant (Section 7); * MUST enforce authority.approved_at <= decided_at <= evaluation.evaluated_at, subject to the declared clock-skew allowance; and * MUST reject the assertion if authority.approved_at or decided_at is later than the issuer's own clock at evaluation, beyond that allowance. A policy assertion whose age exceeds the applicable maximum, or whose ordering the previous paragraph does not admit, fails policy- authorization under Section 6: the issuer MUST NOT count it toward the evaluation, and by Section 7 the Mission MUST NOT be created active on an evaluation that depended on it. An evaluation.evaluated_at later than the issuer's own clock, beyond the declared allowance, is a defect of the record rather than of one assertion: the evaluation MUST NOT be treated as complete, and by Section 7 the Mission MUST NOT be created active on it. This is issuance-time eligibility. It determines whether a Mission activates and does not reach back into a Mission already active: that Mission's governing policy approval was measured fresh at its own approval event, and a later change to the ceiling, the exception, or the policy's freshness does not narrow or terminate it. Four conditions are the high-risk classes the issuance profile defines: irreversible action, external commitment, privileged administration, and a consumption bound ([I-D.draft-mcguinness-oauth-mission]). Where the committed Mission's derived Authority Set or Mission Intent controls ([I-D.draft-mcguinness-mission-metering]) carries one, the assertion satisfying the accountable-approver rule of Section 6 MUST be kind: human, unless a committed, class-named exception under this section admits kind: policy for that class. Approval Governance is an optional extension (Section 2); the rules of this section are a conservative default of that profile, not a family-wide guarantee, and a deployment that records no Approval Governance Record is unbounded by them. kind: human is not by itself an assurance property: the authentication-strength, rendering, and accountable-principal requirements the issuance profile and Section 6 otherwise impose still carry that property; this section only decides which assertion kind MUST be present. 9. Envelope and Verification An Approval Governance Record carries its integrity protection in an envelope member: REQUIRED, an object with format (a string, required) and value (a string, required). The default format is jws-compact, a JWS Compact Serialization [RFC7515] over the JCS [RFC8785] canonical bytes of the record with the envelope member removed, signed by the Mission Issuer under a key resolvable in its published key material. The signed record, envelope included, is the retained, registrable form. A verifier MUST perform the following steps, in order, and MUST NOT treat a record as verified if any step fails: 1. Resolve the Mission Issuer's signing key from the JWS protected kid in its published key material. 2. Verify the JWS signature and protected header against that key. 3. Compute the JCS canonical bytes of the outer record with the envelope member removed. 4. Require byte-for-byte equality between the decoded JWS payload and the canonical bytes of step 3, rejecting the record on any difference. The signature authenticates only its own embedded payload; a record that differs from that payload is unauthenticated regardless of whether the signature itself verifies. 5. Validate the mission binding of Section 5 against the Mission record it is retained with. The JWS protected header MUST carry a kid resolvable in the Mission Issuer's published key material, a typ of application/mission- approval-governance+jws, and a cty of application/mission-approval- governance+json (Section 16); a verifier MUST reject a JWS whose protected typ and cty are not exactly this pair ([RFC7515], Sections 4.1.9 and 4.1.10). This document defines only the jws-compact format; an implementation MUST reject an envelope whose format is unsupported rather than accepting it unverified. The *record digest* is the digest, in the encoded form Section 3 fixes, over the JCS [RFC8785] canonical bytes of the complete record, envelope included. It is the one byte sequence every external binding names: audit registration hashes exactly these bytes (Section 13), and consent evidence's approval_governance_digest equals exactly this value (Section 11). 10. Recording Triggers Defined here so a profile cites one list. The record is REQUIRED for an approval event when any of the following holds: * the Mission record's approver differs from its subject; * more than one principal contributes to the decision; * a non-human assertion contributes to the decision; * a threshold, veto, or separation-of-duty rule is evaluated; or * validating any assertion requires authority standing outside the Mission record. Direct self-approval by one authenticated human is the degenerate case: the Mission record already carries it completely, and no record is required. 11. Consent Evidence Relationship Where both are recorded, the AGR is authoritative for approval- governance facts, and consent evidence presents a deliberately partial view of it ([I-D.draft-mcguinness-oauth-mission-consent-evidence]). Agreement is testable, member by member: * Each co_approvals entry MUST correspond to exactly one human assertion in the record with the same principal, the entry's decision equal to the assertion's decision, and the entry's timestamp equal to the assertion's decided_at. Omitting an assertion is permitted; an entry with no corresponding assertion, or one that alters a decision or time, is an integrity failure. service and policy assertions are governance inputs, never consent events, and are never presented as co-approvals. * The consent evidence approver MUST equal the principal of the record's accountable assertion (Section 6). * approval_authority, when present, MUST equal approval_policy.id; approval_policy_version, when present, MUST equal approval_policy.version. * approval_governance_digest, when present, MUST equal the record digest (Section 9). The AGR governs on any disagreement. Where a deferred approval revises under Mission Approval Revision ([I-D.draft-mcguinness-oauth-mission-approval-revision]) and the deployment records consent evidence, each revision_required outcome produces a narrowed consent-evidence decision with no corresponding record: no Mission yet exists for the atomic commitment rule (Section 7) to attach to. Where consent evidence is recorded, it owns the narrowing history, through its narrowed entries and predecessor_intent_hashes. Where an AGR is recorded for the final approval, it owns the final approval-governance facts. This is a deliberate artifact separation, not an authority conflict. 12. Boundaries The record governs the Mission approval event; an action-time approval under the runtime profile's re-evaluation surfaces ([I-D.draft-mcguinness-mission-runtime]) is a different layer and never joins this record. OAuth standardizes the requested and granted authorization data, not an organization's internal approval provenance ([RFC9396] takes the same boundary for rich authorization requests); this record therefore stays off protocol messages and out of enforcement projections, matching the issuance profile's control-plane discipline. Section 8 bounds only the AGR policy assertion path. The issuance profile's standing-consent authority bases and their related provenance carry no equivalent human-approval instant and trace only through a consent principal and a commitment; that gap is a distinct, tracked concern outside this document's assertions, for the issuance profile or whichever companion defines those standing-consent types to close. 13. Mission Evidence The AGR is registrable Mission evidence under the audit transparency profile's evidence-type pattern ([I-D.draft-mcguinness-mission-audit]): canonical bytes are the JCS canonical bytes of the complete record, envelope included, the record-digest preimage (Section 9); payload-preimage-content-type is application/mission-approval-governance+json; the authoritative producer is the Mission issuer. Registration is optional transparency hardening; retention and immutability do not depend on it. 14. Security Considerations 14.1. Forged or Padded Assertions A forged or padded assertion is an authorization attack before commitment, not an audit defect: the assertion requirements of Section 6 are the control, and a deployment that records assertions without authenticating them has built an approval bypass rather than an evidence trail. 14.2. Policy Substitution Without approval_policy.digest and its retention, a later reading cannot prove which policy governed the evaluation. The digest and the audit-horizon retention of Section 5 are the control. 14.3. Manufactured Accountability The accountable-approver assertion rule of Section 6 prevents a set of service and policy assertions from claiming a Mission whose named Approver never asserted anything. 14.4. Stale Policy Approval Without Section 8, a policy assertion could rely on a human approval far in the past, or stand in for the accountable approver on a high- risk consequence with no human assertion at all. The recency ceiling, its ordering checks, and the human-by-default consequence- class rule are the control. 14.5. Immutability Witness The issuer-signed envelope of Section 9 makes post-commit tampering detectable. Audit registration (Section 13) additionally bounds issuer-side substitution, since a registered record's later alteration diverges from its receipt. 14.6. Issuer Key Compromise This document inherits the issuance profile's key-material considerations. A compromised Mission Issuer signing key can mint a plausible record; audit registration ([I-D.draft-mcguinness-mission-audit]) is the existence bound, not a substitute for key custody. 15. Privacy Considerations Assertion principals and decision times are PII about reviewers. The record is control-plane state retained by the issuer, never disclosed on wire surfaces, and access to a retained record follows the issuer's audit-log discipline for approval-event records ([I-D.draft-mcguinness-oauth-mission]). 16. IANA Considerations 16.1. Media Type Registration IANA is requested to register two media types per [RFC6838]: the Approval Governance Record object, and the JWS-secured representation its envelope carries (using the +jws structured syntax suffix already registered with IANA). 16.1.1. application/mission-approval-governance+jws * Type name: application * Subtype name: mission-approval-governance+jws * Required parameters: none * Optional parameters: none * Encoding considerations: binary; a JWS Compact Serialization: base64url-encoded values separated by period characters. The secured payload's media type travels in the JWS protected cty (Section 9). * Security considerations: see Section 14 * Interoperability considerations: see this document (Section 9) * Published specification: this document * Applications that use this media type: Mission-Bound Authorization approval governance * Fragment identifier considerations: N/A * Additional information: - Deprecated alias names for this type: none - Magic number(s): none - File extension(s): none - Macintosh file type code(s): N/A * Person & email address to contact for further information: Karl McGuinness public@karlmcguinness.com (mailto:public@karlmcguinness.com) * Intended usage: COMMON * Restrictions on usage: none * Author: IETF * Change controller: IETF 16.1.2. application/mission-approval-governance+json * Type name: application * Subtype name: mission-approval-governance+json * Required parameters: none * Optional parameters: none * Encoding considerations: binary; JSON encoded in UTF-8 * Security considerations: see Section 14 * Interoperability considerations: see this document * Published specification: this document * Applications that use this media type: Mission-Bound Authorization issuers and audit deployments * Fragment identifier considerations: same as for application/json * Additional information: - Deprecated alias names for this type: none - Magic number(s): none - File extension(s): .json - Macintosh file type code(s): TEXT * Person & email address to contact for further information: Karl McGuinness public@karlmcguinness.com (mailto:public@karlmcguinness.com) * Intended usage: COMMON * Restrictions on usage: none * Author: IETF * Change controller: IETF 17. Conformance A *Recording Issuer* MUST: * authenticate, event-bind, and policy-authorize every contributing assertion (Section 6); * record denials; * include the accountable-approver assertion; * evaluate under the retained policy version; * enforce the strictest applicable policy-approval maximum age across the consequence classes the committed Mission's derived Authority Set and Mission Intent controls carry, from a committed ceiling and any committed exception (Section 8); * require kind: human for the accountable-approver assertion where the committed Mission's derived Authority Set or Mission Intent controls carries a high-risk class, unless a committed class-named exception applies (Section 8); * commit the record atomically with Mission creation and let failure prevent activation (Section 7); * sign the committed record and keep it immutable (Section 9); and * retain the record and the referenced policy for the Mission's audit horizon ([I-D.draft-mcguinness-oauth-mission]). A *Relying Auditor* MUST verify the envelope by byte equality, MUST validate the mission binding, and MUST obtain the retained policy version before treating the evaluation as re-checked (Section 9). 18. References 18.1. Normative References [I-D.draft-mcguinness-mission-substrate] McGuinness, K., "Mission Substrate Requirements", 2026, . [I-D.draft-mcguinness-oauth-mission] McGuinness, K., "Mission-Bound Authorization for OAuth 2.0", 2026, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, . [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, . [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, . [RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June 2020, . 18.2. Informative References [I-D.draft-mcguinness-mission-audit] McGuinness, K., "Mission Audit Transparency", 2026, . [I-D.draft-mcguinness-mission-authority-server] McGuinness, K., "Mission Authority Server", 2026, . [I-D.draft-mcguinness-mission-metering] McGuinness, K., "Mission Consumption Metering", 2026, . [I-D.draft-mcguinness-mission-runtime] McGuinness, K., "Mission-Bound Runtime Enforcement", 2026, . [I-D.draft-mcguinness-oauth-mission-approval] McGuinness, K., "Mission Deferred Approval for OAuth 2.0", 2026, . [I-D.draft-mcguinness-oauth-mission-approval-revision] McGuinness, K., "Mission Approval Revision for OAuth 2.0", 2026, . [I-D.draft-mcguinness-oauth-mission-consent-evidence] McGuinness, K., "Mission Consent Evidence for OAuth 2.0", 2026, . [RFC9396] Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0 Rich Authorization Requests", RFC 9396, DOI 10.17487/RFC9396, May 2023, . Acknowledgments This document extracts the experimental approval-provenance record that Mission Deferred Approval first sketched into a standalone companion, and reshapes it so its assertions carry the authentication, binding, and policy-authorization requirements that governance evidence with teeth requires. The author thanks the Mission-Bound Authorization implementer community for feedback. Author's Address Karl McGuinness Independent Email: public@karlmcguinness.com