Mission Approval Governance

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

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 and a typ of application/mission-approval-governance+json (Section 16); a verifier MUST reject a JWS whose protected typ is not this value. 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

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

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

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