Internet-Draft Mission Audit Transparency August 2026
McGuinness Expires 22 February 2027 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-mcguinness-mission-audit-latest
Published:
Intended Status:
Standards Track
Expires:
Author:
K. McGuinness
Independent

Mission Audit Transparency

Abstract

Mission-Bound Authorization for OAuth 2.0 and its companions produce many evidence records: the approval event, lifecycle transitions, consent evidence, runtime decision and execution evidence, and further evidence types profiles define. Each is signed, but signed is not the same as tamper-evident, append-only, or independently verifiable: a holder of the signing key can still backdate, drop, or reorder records, and a cross-domain party cannot confirm what was recorded without trusting the issuer's own logs. This document defines an optional Mission Audit Transparency profile. It registers Mission evidence into a SCITT Transparency Service as Signed Statements, with the Mission as the statement subject so a Mission's records form one coherent, append-only feed, and binds the resulting Receipt back so any party, in any domain, can verify offline that a record was registered and not altered. To keep sensitive task data out of the log, statements commit to the evidence by hash rather than carrying it.

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-audit.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-mcguinness-mission-audit/.

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 22 February 2027.

▲

Table of Contents

1. Introduction

Mission-Bound Authorization for OAuth 2.0 [I-D.draft-mcguinness-oauth-mission] (the "issuance profile") and its companions record evidence at every governance and enforcement point. The evidence is signed, which makes a single record attributable and tamper-evident in isolation. It does not make the record set as a whole trustworthy: the party that holds the signing key can backdate a record, omit an inconvenient one, or present different histories to different auditors, and nothing a relying party holds detects it. A cross-domain auditor is worse off still, with only the issuer's assertion that its logs are complete.

This document closes that gap by profiling the SCITT architecture [RFC9943] (the "transparency substrate"). A Mission evidence record is registered with a Transparency Service as a Signed Statement; the service appends it to an append-only log and returns a Receipt proving inclusion. The Signed Statement plus its Receipt is a Transparent Statement that any party can verify offline: the record was registered, at a committed time, and is included in a signed log tree head. Detecting whether the service later drops or reorders a record, or shows different auditors different heads, rests on trusting that single service or on registering with more than one (Section 11, Section 13). The Mission is the statement subject, so all of a Mission's evidence shares one subject and forms one feed an auditor can assemble and replay as a single narrative (Section 6.6).

This adds transparency to evidence the suite already defines; it defines no new evidence object. It is optional, and what it proves is bounded: transparency makes misbehavior detectable and attributable, it does not make a dishonest issuer honest (Section 11).

2. Conventions and Terminology

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.

Mission evidence:

Any evidence record the suite defines, including the approval event, lifecycle transitions, consent evidence ([I-D.draft-mcguinness-oauth-mission-consent-evidence]), and runtime decision and execution evidence ([I-D.draft-mcguinness-mission-runtime]).

3. Status: An Optional Extension

This document is optional. A deployment that retains evidence without a Transparency Service is fully conformant to the issuance profile and its companions and is unaffected by this document. It places no new requirement on them and defines no new evidence; it registers the records they already produce.

A deployment claims this profile only when it registers Mission evidence with a Transparency Service.

The transparency substrate this profile builds on is ratified: it depends normatively on the SCITT architecture [RFC9943], a published standard. Its hash commitment uses the COSE hash-envelope headers ([I-D.draft-ietf-cose-hash-envelope]), approved and in the RFC Editor queue. The profile itself is newer than the substrate and less exercised in deployment, so an implementer treats its interfaces as still settling and validates them against real audits before relying on them. The signed evidence the suite produces without a Transparency Service ([I-D.draft-mcguinness-oauth-mission]) does not depend on this profile.

4. Relationship to the Issuance Profile

This document depends normatively on the issuance profile and the transparency substrate, and is not implementable alone. It reuses:

It uses Mission, Mission Issuer, and the evidence objects as the suite defines them, and Transparency Service, Signed Statement, Receipt, and Transparent Statement as the transparency substrate defines them.

The transparency substrate's Receipt, the Transparency Service's proof of inclusion, is distinct from the runtime profile's Mission Receipt, portable evidence of a decision, an executed action's outcome, or a refusal under a Mission ([I-D.draft-mcguinness-mission-runtime]); this document uses Receipt in the SCITT sense only. Registering a Mission Receipt's underlying evidence on the Mission's feed provides tamper-evident ordering and inclusion; receipt chaining ([I-D.draft-mcguinness-mission-runtime-evidence]) is OPTIONAL, gives view-local tamper evidence within one issuer's stream, and is never a substitute for those properties.

5. Mission Substrate

This profile is defined against the Mission model rather than against OAuth 2.0 mechanics. It consumes these substrate primitives:

The issuance profile [I-D.draft-mcguinness-oauth-mission] is this version's reference host. Evidence produced under another Mission substrate registers and verifies the same way once its types and canonical bytes are defined as in the evidence-type table (Section 6.3).

6. Registering Mission Evidence

A producer of Mission evidence (the Mission Issuer, a Policy Decision Point, a harness, or another component the deployment trusts to record) MAY register a record with a Transparency Service as a Signed Statement ([RFC9943]). The Signed Statement's protected header carries, in its CWT Claims:

6.1. Hash Commitment

A Signed Statement MUST commit to the evidence by hash rather than carry the evidence itself, so sensitive task data stays out of the log (Section 14). The commitment uses the COSE hash-envelope mechanism [I-D.draft-ietf-cose-hash-envelope]: the COSE_Sign1 payload is the hash of the evidence, carried inline, and the protected header signals how the hash was produced. The payload is not detached, and it is not the sha-256:... display string an integrity anchor uses ([I-D.draft-mcguinness-oauth-mission]); it is the digest bytes themselves.

The committed value is the SHA-256 [RFC6234] digest of the evidence bytes that Section 6.3 fixes for the evidence type. For an artifact whose retained form is itself a compact serialization (a JWS, JWT, SET, or SD-JWT component), those bytes are the artifact as issued, hashed as-is; for a JSON object, including one that carries a nested signature envelope, they are the JCS [RFC8785] canonical bytes of the complete retained object, envelope included, unless its row fixes different bytes. The protected header carries:

The log then proves a specific record was registered at a time; the evidence is retrieved separately, under access control, and its canonical bytes are rehashed and checked against the committed digest (Section 9).

6.2. The Mission Evidence Base

Several registrable evidence types, defined across the runtime evidence, harness, and containment profiles, record an enforcement or issuer decision under a shared shape: a reference to the Mission the record concerns, an emitter object naming the component that produced it (id, a string; role, one of pdp, pep, executor, harness, egress, or issuer), and, where the defining profile fixes it, an entry_digest naming the Authority Set entry the record concerns ([I-D.draft-mcguinness-mission-runtime-evidence]). Two further members carry correlation a record MAY need: hop_reference, attributing a record to the continuation hop that authorized it, defined as a coordinated Decision Evidence member by the runtime evidence companion ([I-D.draft-mcguinness-mission-runtime-evidence]), and scope_statement_digest, binding a record to the published Enforcement Scope Statement in effect when it was made, defined by the harness profile ([I-D.draft-mcguinness-mission-harness]).

This is a naming convention this document names once, not a wire object every evidence type carries verbatim. Each type's defining profile fixes the concrete form of the Mission reference (a nested mission object or a flat mission_id/issuer pair), its own record identifier, and its own timestamp member, and adds its own kind-specific members on top; no member named here is required across every type, and a defining profile states which of them it carries and whether each is required, optional, or absent for that type.

The shared naming does not weaken, and is not a substitute for, the per-type separation Section 6.3 fixes. Each evidence type keeps its own registered payload-preimage-content-type or JWS typ, and a signature or hash commitment produced over one type's canonical bytes remains verifiable only as that type: domain separation comes from the signed content-type or typ value (Section 6.1), never from members a record happens to share with another type. A relying party that recognizes these member names by convention still MUST check a record's registered type identifier against the exact type it expects before treating the record as that type (Section 6.4).

A registrable evidence type is named at up to three layers, and the layers are distinct identifiers with distinct purposes, not spellings of one string. The media type, or local-use type identifier, identifies the retained representation: the payload schema for a +json object, the compact artifact itself for a +jwt, +sd-jwt, or SET form. The protected typ of an operational signature envelope, where the defining profile fixes one, names the signed object as that profile scopes it: either the payload, as the runtime evidence types do, or the secured representation itself, as Consent Evidence's mission-consent-evidence+jws names the JWS over the application/mission-consent-evidence+json payload. The payload-preimage-content-type identifies the media type of the preimage committed at the transparency boundary; the exact bytes are what the canonical-bytes column fixes (Section 6.3, Section 6.1). The evidence-type table fixes each type's operational typ explicitly; the identifiers are not derivable from one another in every case, and a consumer checks the identifier of the layer it is verifying. A new type that fixes an operational envelope SHOULD set its typ to its registered media type, the application/ prefix retained or omitted (equivalent under JWS [RFC7515]); that equivalence never overrides a defining profile's exact-value rule, so a verifier of the runtime evidence types still rejects the omitted-prefix forms that profile does not permit. A typ naming the secured representation instead is a per-type mapping the table documents, not a divergent spelling of the media type.

The layering is deliberate, and the layers compose rather than compete. The operational signature authenticates producer origin and record integrity to any verifier that resolves the producer's key; it is not inherently deployment-local. The Signed Statement is a typed hash commitment the producer submits for registration, itself a producer assertion over a digest (Section 6.1). What makes verification independent of the producer is neither of these but the Transparency Service's Receipt and inclusion proof, under a service key trusted and retained separately: they add registration and inclusion at a committed time and remove reliance on the producer's live records (Section 9). Operator independence, or the second-service control of Section 11, is what carries the cross-domain claim; verification still requires the producer and service trust anchors, the Receipt, and the retrievable evidence, and proves neither that a record is true nor that a feed is complete (Section 9.1). The anti-cross-use rule above depends on keeping the identifiers' roles and checks distinct, not their string values: the runtime evidence rows deliberately carry the same media type string as operational typ and as payload-preimage-content-type. Collapsing the types into one envelope, one media type, or a shared typ list would relocate domain separation from the registered identifier into a payload member.

6.3. Evidence Types

Each registrable evidence type fixes the exact bytes that are hashed, the media type carried in payload-preimage-content-type, the operational typ its retained form carries (none where the retained object is unsigned), and the producer authoritative for it. A producer MUST commit to the canonical bytes named here. A relying party MUST verify the producer is authoritative for the type (Section 6.4) before treating a record as part of the Mission's feed. The table is a normative catalog of evidence types, not a registry: a row registers nothing, and its identifier is defined, and registered where it is, by the profile the row cites.

Table 1
Evidence type Canonical bytes (hashed) payload-preimage-content-type Operational typ Producer
Approval event Mission record at creation, state excluded, canonicalized application/mission-approval-record+json none issuer
Lifecycle transition Signals SET as issued, as the signals profile fixes; else Section 6.3.1 (JCS) application/secevent+jwt, else application/mission-lifecycle-transition+json secevent+jwt, else none issuer
Derivation record Section 6.3.2 (JCS) application/mission-derivation-record+json none issuer
Consent evidence complete retained object, evidence_envelope included (JCS) application/mission-consent-evidence+json mission-consent-evidence+jws issuer
Approval governance complete record including envelope (JCS), the record-digest preimage application/mission-approval-governance+json application/mission-approval-governance+json issuer
Decision evidence complete object, evidence_envelope included (JCS) application/mission-decision-evidence+json application/mission-decision-evidence+json PDP key
Execution evidence complete object, evidence_envelope included (JCS) application/mission-execution-evidence+json application/mission-execution-evidence+json PEP key
Refusal Record complete object, evidence_envelope included (JCS) application/mission-refusal-record+json application/mission-refusal-record+json PEP key
Mission Receipt complete object, evidence_envelope included (JCS) application/mission-receipt+json application/mission-receipt+json receipt issuer key
Mission Mandate plain form: JWS Compact Serialization, as issued; SD-JWT form: issuer-signed JWT component, as issued application/mission-mandate+jwt, else application/mission-mandate+sd-jwt mission-mandate+jwt, else mission-mandate+sd-jwt issuer
Work Product Binding JWS Compact Serialization, as issued application/mission-work-product-binding+jwt mission-work-product-binding+jwt signing mediator principal
Child Evidence Child Evidence object (JCS), as the child-delegation profile fixes application/mission-child-evidence+json none issuer
Discovery Evidence Discovery Evidence object (JCS), as the discovery profile fixes application/mission-discovery-evidence+json mission-discovery-evidence+json issuer
Harness Evidence Harness Evidence object (JCS), as the harness profile fixes application/mission-harness-evidence+json none fixed harness key
Egress evidence Egress Evidence object (JCS), as the harness profile fixes application/mission-egress-evidence+json none fixed egress key
Containment evidence Containment Evidence object (JCS), as the containment profile fixes application/mission-containment-evidence+json none issuer
Protected event receipt Protected Event Receipt object (JCS), as the containment profile fixes application/mission-protected-event-receipt+json none issuer
Erasure record Section 6.3.3 (JCS) application/mission-erasure-record+json none producer of the erased record's type

The table is extensible by specification: a profile MAY define an additional evidence type by fixing its canonical bytes, its payload-preimage-content-type, its operational typ together with the envelope that carries it, where its retained form has one, or an explicit none, and its authoritative producer, as the Mandate profile does for the Mission Mandate ([I-D.draft-mcguinness-mission-mandate]). A relying party admits an extension type it implements; it ignores records of a type it does not implement, and they are not audit failures.

Two evidence producers stay outside the table by design. Shaping Evidence fixes no schema or media type; its commitment mechanism is the shaping_evidence_hash integrity anchor, the issuance profile's domain-separated {typ, iss, value} envelope with committed-object typ mission-shaping-evidence ([I-D.draft-mcguinness-mission-shaping]), and the underlying record gains a row only when a profile fixes its canonical bytes and type identifier. Orchestration Evidence registers no media type and keeps mission-orchestration-evidence as a local-use identifier ([I-D.draft-mcguinness-mission-orchestration]); a deployment MAY register it under deployment policy by fixing the values a row requires.

The producer identifiers are principals the suite already names. For every record whose producer is the Mission issuer, the Signed Statement's iss MUST equal that issuer ([I-D.draft-mcguinness-oauth-mission]). The PDP and PEP keys are those in the deployment-published key sets the runtime profile and its runtime evidence companion require ([I-D.draft-mcguinness-mission-runtime], [I-D.draft-mcguinness-mission-runtime-evidence]); the harness and egress keys publish in the same deployment key sets under the harness profile's conventions ([I-D.draft-mcguinness-mission-harness]). The producer of a Work Product Binding is the mediator principal that signed it, projected onto these paths as Section 6.4 fixes ([I-D.draft-mcguinness-oauth-mission-work-products]).

The approval event, the lifecycle-transition object, and the derivation record are canonicalized under the issuance profile's canonicalization rules ([I-D.draft-mcguinness-oauth-mission]). An artifact whose retained form is itself a compact serialization (the Signals SET, the Mandate, the Work Product Binding) is hashed as issued, not re-canonicalized. A JSON object that carries a nested signature envelope (the consent, decision, execution, refusal, and receipt evidence) is hashed as the JCS canonical bytes of the complete retained object, envelope included, the same shape as the approval-governance record digest: hashing received octets instead would let a reserialization outside the envelope change the audit digest while the operational signature stayed valid.

The operational typ column records the protected typ of the signature envelope a type's retained form carries, none where the type is retained unsigned. It is the per-type mapping named in Section 6.2, checked when verifying the operational signature, never in place of payload-preimage-content-type. Harness and Egress Evidence fix none: their defining profile fixes the raw object's JCS bytes under integrity protection by a named mechanism, not a JWS envelope, and a deployment-local signature creates no portable mapping in this catalog. A harness revision that defines a JWS representation fixes, in that profile, the envelope and retained form, the protected typ, byte-equality verification, and whether transparency commits the JSON payload, the complete nested object, or the compact JWS.

The media types and type identifiers are defined as follows:

The approval event's canonical bytes are the whole Mission record at creation with state excluded, canonicalized (Section 6.3): every committed member is included, the record's own optional members where present (for example, proposed_authority and proposal_hash, [I-D.draft-mcguinness-oauth-mission]), and members companion profiles add to the record under its extensibility rules, so the commitment covers the record as approved and not a fixed subset. These bytes carry no typ/iss integrity-anchor envelope, unlike the derivation record's entries_digest and token_digest (Section 6.3.2); domain separation instead comes from the signed payload-preimage-content-type in the COSE hash-envelope protected header (Section 6.1), which binds the committed hash to application/mission-approval-record+json and keeps a digest of one evidence type from being read as another.

Each companion-defined row binds only a deployment that produces that evidence, so the reference is consulted only where the profile is adopted. A row whose defining profile is Experimental (the Discovery Evidence, Containment evidence, Protected event receipt, and Work Product Binding rows) stays on that profile's maturity: its reference is a conditional normative down-reference, binding only a deployment that produces that row's evidence, and a deployment not running an Experimental profile omits its rows. A deployment that does not run the Signals profile commits lifecycle transitions as the transition object (Section 6.3.1) instead of the Signals SET.

A Child Evidence record registers on the Parent Mission's feed: the sub is the parent's (Section 8), its producer is the issuer, and the child Mission's id inside the evidence makes the delegation navigable from parent to child.

6.3.1. The Lifecycle Transition Object

A deployment that does not run the Signals profile commits a lifecycle transition as a minimal JSON object with these members, JCS-canonicalized [RFC8785]:

  • mission_id (string, required): the Mission id.

  • issuer (string, required): the Mission issuer.

  • state (string, required): the new lifecycle state.

  • prior_state (string, optional): the state immediately before the transition.

  • transitioned_at (string, required): an RFC 3339 [RFC3339] date-time at which the transition was committed.

  • salt (string, required): a random salt of at least 128 bits, base64url-encoded, retained with the evidence. The object's other members are drawn from an enumerable space, so an unsalted commitment is confirmable by dictionary (Section 14).

Its media type is application/mission-lifecycle-transition+json (Section 15).

6.3.1.1. Computed Example

A minimal transition object recording the revocation of Mission msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-; the salt is a fixed illustrative 16-byte value, where a producer generates a fresh random one per record:

{
  "mission_id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-",
  "issuer": "https://as.example.com",
  "salt": "q7hJ2mXv9pTzR4kW5nB8dQ",
  "state": "revoked",
  "transitioned_at": "2026-11-02T08:30:00Z"
}

Its JCS canonical bytes (one line; breaks are for display only):

{"issuer":"https://as.example.com","mission_id":"msn_8RfX2Lqv9TqMv
4z7sA2bN1k0YpEdHc9-","salt":"q7hJ2mXv9pTzR4kW5nB8dQ","state":"revo
ked","transitioned_at":"2026-11-02T08:30:00Z"}

The committed digest is the SHA-256 of those bytes; its base64url form is SD3SCb7vm3b_Ivsm19ENQAGAv7pjLS-mNWGcaXqslmc. The Signed Statement carries the digest bytes inline as its payload, with this protected header (Section 6.1, Section 8):

{
  / alg /                    1: -7,   / ES256 /
  / payload-hash-alg /     258: -16,  / SHA-256 /
  / payload-preimage-content-type / 259:
      "application/mission-lifecycle-transition+json",
  / kid /                    4: h'61732d6b65792d323032362d7133',
  / CWT Claims /            15: {
    / iss / 1: "https://as.example.com",
    / sub / 2: "https://as.example.com/missions/
                msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-"
  }
}

6.3.2. The Derivation Record

The family's evidence runs from the approval to the enforced action, but the derivation event between them, the issuer issuing a token under the Mission ([I-D.draft-mcguinness-oauth-mission]), is otherwise visible only in Authorization Server logs no profile mandates. A derivation record closes that gap: it commits which token was issued, to which audience, carrying which entries, under which Mission.

A derivation record is a JSON object with these members, JCS-canonicalized [RFC8785]:

  • mission_id (string, required): the Mission id.

  • issuer (string, required): the Mission issuer.

  • token_digest (string, required): a digest in the issuance profile's encoded form ([I-D.draft-mcguinness-oauth-mission]), over the UTF-8 bytes of the issued token's JWS Compact Serialization, or of the token's jti where the deployment retains no token bytes.

  • token_digest_kind (string, required): which preimage token_digest was taken over, so a verifier need not guess: jws for the token's JWS Compact Serialization, or jti for the token's jti.

  • aud (string, required): the audience the token was issued for.

  • entries_digest (string, required): the integrity-anchor envelope digest ([I-D.draft-mcguinness-oauth-mission]) over the issued authorization_details array, with typ mission-derivation-entries and iss the issuer.

  • actor (string, optional): the delegate's sub, present when the derivation was a delegation.

  • issued_at (string, required): an RFC 3339 [RFC3339] date-time at which the token was issued.

entries_digest is an envelope anchor and token_digest a raw-octet digest under the substrate's default commitment construction, which this document imports normatively ([I-D.draft-mcguinness-mission-substrate]).

Its media type is application/mission-derivation-record+json (Section 15), and its authoritative producer is the issuer: the Signed Statement's iss MUST equal the Mission issuer (Section 6.3).

6.3.2.1. Computed Example

For Mission msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-, the Mission Issuer issues a token for audience https://erp.example.com, narrowed to the write entry, with jti at_5v9Kq2mR7xW4nP8sL1zT6. The issued authorization_details:

[
  { "type": "mission_resource_access",
    "resource": "https://erp.example.com",
    "actions": ["journal-entries.write"],
    "constraints":
      { "max_amount": { "amount": "500.00", "currency": "USD" } } }
]

entries_digest is the integrity-anchor envelope digest over that array with typ mission-derivation-entries and iss https://as.example.com; token_digest is over the UTF-8 bytes of the jti, so token_digest_kind is jti. The derivation was not a delegation, so actor is absent. The record:

{
  "mission_id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-",
  "issuer": "https://as.example.com",
  "token_digest":
    "sha-256:V1Wbh4Z3wK39B_YmzHlvkGr7hEA1rUoJMuj00y0q-eE",
  "token_digest_kind": "jti",
  "aud": "https://erp.example.com",
  "entries_digest":
    "sha-256:Hilv4npLEWlcp2y5z7xcACgXxRhx-LO6dqs5AX0xL8o",
  "issued_at": "2026-10-15T14:32:12Z"
}

Its JCS canonical bytes (one line; breaks are for display only):

{"aud":"https://erp.example.com","entries_digest":"sha-256:Hilv4np
LEWlcp2y5z7xcACgXxRhx-LO6dqs5AX0xL8o","issued_at":"2026-10-15T14:3
2:12Z","issuer":"https://as.example.com","mission_id":"msn_8RfX2Lq
v9TqMv4z7sA2bN1k0YpEdHc9-","token_digest":"sha-256:V1Wbh4Z3wK39B_Y
mzHlvkGr7hEA1rUoJMuj00y0q-eE","token_digest_kind":"jti"}

The committed digest is the SHA-256 of those bytes; its base64url form is ilGnfpu7hz4kMZeqXWuxwNi0i_fO2vzjWGOY_i9yt4s. The Signed Statement carries the digest bytes inline as its payload, with payload-preimage-content-type application/mission-derivation-record+json and the same iss and sub as Section 6.3.1.1.

6.3.3. The Erasure Record

When retained evidence is destroyed inside its retention window, under a data-subject request or a retention limit, the erasure itself is registered, so the resulting audit failure is explained on the feed rather than indistinguishable from convenient loss (Section 14). The canonical bytes are the JCS serialization of a JSON object with:

  • erased (string, required): the committed digest, from the Signed Statement's payload, of the record whose evidence was erased.

  • basis (string, required): the erasure basis: data_subject_request, retention_limit, or a deployment-defined value.

  • erased_at (string, required): an RFC 3339 [RFC3339] date-time.

  • salt (string, required): a random salt of at least 128 bits, base64url encoded, per the enumerable-shape rule of Section 14.

The record's producer is the authoritative producer of the erased record's type, and it registers on the same Mission feed. A relying party that finds an erasure record covering an unretrievable commitment treats the audit failure as explained (recorded-basis erasure, still not content-verified); an unexplained gap, in a deployment that registers erasures, remains worth recording (Section 9.1).

6.3.4. Computed Nested-Envelope Example

The consent, decision, execution, and refusal rows commit the JCS canonical bytes of the complete retained object, evidence_envelope included. This example fixes that rule against the two divergent readings, hashing the received JSON octets and hashing the object with the nested envelope stripped; an implementation that reproduces this digest has applied the row correctly. The retained Decision Evidence object ([I-D.draft-mcguinness-mission-runtime-evidence]) is the following. Its evidence_envelope.value is a fixed illustrative JWS whose protected header and payload decode as that profile fixes and whose signature third segment is a fixed illustrative 64-byte value; every string is shown wrapped for layout only, so remove the layout line breaks within a string, adding no characters, to recover the exact value:

{
  "evidence_id": "evd_9Nq3TmR6xL2vP8kY4sD1eB7jH0wC5uA",
  "evaluation_id": "dec_8K2nP4qV9rL3tY6sB1zN0eF7jB",
  "mission": {
    "id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-",
    "issuer": "https://as.example.com",
    "authority_hash":
      "sha-256:l3KvZ4mP5x0wQrR6tY2nD9bM7sX1cF8gH2vJ4kE5pNQ",
    "policy_view_id":
      "sha-256:kP3xR9sQ7nM2vL4tY6bD1eF8jC5wH0pV2nR3kQ4mZ7t"
  },
  "subject": { "type": "user", "id": "user_3p2q8mN1a0kV7tR" },
  "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":
      "eyJhbGciOiJFUzI1NiIsImtpZCI6InBkcC1rZXktMjAyNiIsInR5cCI6ImFw
      cGxpY2F0aW9uL21pc3Npb24tZGVjaXNpb24tZXZpZGVuY2UranNvbiJ9.eyJ
      hY3Rpb24iOnsibmFtZSI6ImpvdXJuYWwtZW50cmllcy53cml0ZSJ9LCJhY3R
      pb25fY2xhc3MiOiJpcnJldmVyc2libGVfYWN0aW9uIiwiYXVkaWVuY2UiOiJ
      odHRwczovL2VycC5leGFtcGxlLmNvbSIsImNsYXNzX3NvdXJjZSI6ImRlcGx
      veW1lbnQiLCJjb25kaXRpb25zIjp7InVzZV9saW1pdCI6MSwidmFsaWRfdW5
      0aWwiOiIyMDI2LTExLTAyVDA4OjE1OjAwWiJ9LCJjb250cmlidXRpbmdfY29
      uc3RyYWludHMiOlsibWlzc2lvbl9yZXNvdXJjZV9hY2Nlc3MiLCJtYXhfYW1
      vdW50Il0sImRlY2lzaW9uIjoicGVybWl0IiwiZW1pdHRlciI6eyJpZCI6InB
      kcC5leGFtcGxlLmNvbSIsInJvbGUiOiJwZHAifSwiZW50cnlfZGlnZXN0Ijo
      ic2hhLTI1NjpkUENOTEhzWnV6UFh1aGNvX3MyMVZUdkRJNGNhZ0lfTE1oUFF
      zcWZOSktRIiwiZXZhbHVhdGVkX2F0IjoiMjAyNi0xMS0wMlQwODoxNDowM1o
      iLCJldmFsdWF0aW9uX2lkIjoiZGVjXzhLMm5QNHFWOXJMM3RZNnNCMXpOMGV
      GN2pCIiwiZXZpZGVuY2VfaWQiOiJldmRfOU5xM1RtUjZ4TDJ2UDhrWTRzRDF
      lQjdqSDB3QzV1QSIsIm1pc3Npb24iOnsiYXV0aG9yaXR5X2hhc2giOiJzaGE
      tMjU2OmwzS3ZaNG1QNXgwd1FyUjZ0WTJuRDliTTdzWDFjRjhnSDJ2SjRrRTV
      wTlEiLCJpZCI6Im1zbl84UmZYMkxxdjlUcU12NHo3c0EyYk4xazBZcEVkSGM
      5LSIsImlzc3VlciI6Imh0dHBzOi8vYXMuZXhhbXBsZS5jb20iLCJwb2xpY3l
      fdmlld19pZCI6InNoYS0yNTY6a1AzeFI5c1E3bk0ydkw0dFk2YkQxZUY4akM
      1d0gwcFYyblIza1E0bVo3dCJ9LCJwYXJhbWV0ZXJfZGlnZXN0Ijoic2hhLTI
      1NjpXUFZpNkVuUTdIOUZoLXFrOUFEeG1UZzh6cnVPZFZVWDFlc2wtdjNUZkN
      JIiwicmVzb3VyY2UiOnsiaWQiOiJqZV8yMDI2UTNfaW52Xzg0MjEiLCJ0eXB
      lIjoiam91cm5hbC1lbnRyeSJ9LCJzZXF1ZW5jZSI6NDIsInN1YmplY3QiOns
      iaWQiOiJ1c2VyXzNwMnE4bU4xYTBrVjd0UiIsInR5cGUiOiJ1c2VyIn19.fo
      eBPar5Zq5LGp7rFVQB5YBYaIJ3HeV0Mysvhkwe9Lx-
      4z5KuH6nIgB9chzIMoCu1IBtmPq0eCi5YKa5OfccHg"
  }
}

The decoded protected header of the evidence_envelope value:

{
  "alg": "ES256",
  "kid": "pdp-key-2026",
  "typ": "application/mission-decision-evidence+json"
}

The evidence bytes are the JCS canonical bytes of that complete retained object, evidence_envelope included (one line; breaks are for display only):

{"action":{"name":"journal-entries.write"},"action_class":"irrever
sible_action","audience":"https://erp.example.com","class_source":
"deployment","conditions":{"use_limit":1,"valid_until":"2026-11-
02T08:15:00Z"},"contributing_constraints":["mission_resource_acces
s","max_amount"],"decision":"permit","emitter":{"id":"pdp.example.
com","role":"pdp"},"entry_digest":"sha-
256:dPCNLHsZuzPXuhco_s21VTvDI4cagI_LMhPQsqfNJKQ","evaluated_at":"2
026-11-
02T08:14:03Z","evaluation_id":"dec_8K2nP4qV9rL3tY6sB1zN0eF7jB","ev
idence_envelope":{"format":"jws-compact","value":"eyJhbGciOiJFUzI1
NiIsImtpZCI6InBkcC1rZXktMjAyNiIsInR5cCI6ImFwcGxpY2F0aW9uL21pc3Npb2
4tZGVjaXNpb24tZXZpZGVuY2UranNvbiJ9.eyJhY3Rpb24iOnsibmFtZSI6ImpvdXJ
uYWwtZW50cmllcy53cml0ZSJ9LCJhY3Rpb25fY2xhc3MiOiJpcnJldmVyc2libGVfY
WN0aW9uIiwiYXVkaWVuY2UiOiJodHRwczovL2VycC5leGFtcGxlLmNvbSIsImNsYXN
zX3NvdXJjZSI6ImRlcGxveW1lbnQiLCJjb25kaXRpb25zIjp7InVzZV9saW1pdCI6M
SwidmFsaWRfdW50aWwiOiIyMDI2LTExLTAyVDA4OjE1OjAwWiJ9LCJjb250cmlidXR
pbmdfY29uc3RyYWludHMiOlsibWlzc2lvbl9yZXNvdXJjZV9hY2Nlc3MiLCJtYXhfY
W1vdW50Il0sImRlY2lzaW9uIjoicGVybWl0IiwiZW1pdHRlciI6eyJpZCI6InBkcC5
leGFtcGxlLmNvbSIsInJvbGUiOiJwZHAifSwiZW50cnlfZGlnZXN0Ijoic2hhLTI1N
jpkUENOTEhzWnV6UFh1aGNvX3MyMVZUdkRJNGNhZ0lfTE1oUFFzcWZOSktRIiwiZXZ
hbHVhdGVkX2F0IjoiMjAyNi0xMS0wMlQwODoxNDowM1oiLCJldmFsdWF0aW9uX2lkI
joiZGVjXzhLMm5QNHFWOXJMM3RZNnNCMXpOMGVGN2pCIiwiZXZpZGVuY2VfaWQiOiJ
ldmRfOU5xM1RtUjZ4TDJ2UDhrWTRzRDFlQjdqSDB3QzV1QSIsIm1pc3Npb24iOnsiY
XV0aG9yaXR5X2hhc2giOiJzaGEtMjU2OmwzS3ZaNG1QNXgwd1FyUjZ0WTJuRDliTTd
zWDFjRjhnSDJ2SjRrRTVwTlEiLCJpZCI6Im1zbl84UmZYMkxxdjlUcU12NHo3c0EyY
k4xazBZcEVkSGM5LSIsImlzc3VlciI6Imh0dHBzOi8vYXMuZXhhbXBsZS5jb20iLCJ
wb2xpY3lfdmlld19pZCI6InNoYS0yNTY6a1AzeFI5c1E3bk0ydkw0dFk2YkQxZUY4a
kM1d0gwcFYyblIza1E0bVo3dCJ9LCJwYXJhbWV0ZXJfZGlnZXN0Ijoic2hhLTI1Njp
XUFZpNkVuUTdIOUZoLXFrOUFEeG1UZzh6cnVPZFZVWDFlc2wtdjNUZkNJIiwicmVzb
3VyY2UiOnsiaWQiOiJqZV8yMDI2UTNfaW52Xzg0MjEiLCJ0eXBlIjoiam91cm5hbC1
lbnRyeSJ9LCJzZXF1ZW5jZSI6NDIsInN1YmplY3QiOnsiaWQiOiJ1c2VyXzNwMnE4b
U4xYTBrVjd0UiIsInR5cGUiOiJ1c2VyIn19.foeBPar5Zq5LGp7rFVQB5YBYaIJ3He
V0Mysvhkwe9Lx-
4z5KuH6nIgB9chzIMoCu1IBtmPq0eCi5YKa5OfccHg"},"evidence_id":"evd_9N
q3TmR6xL2vP8kY4sD1eB7jH0wC5uA","mission":{"authority_hash":"sha-
256:l3KvZ4mP5x0wQrR6tY2nD9bM7sX1cF8gH2vJ4kE5pNQ","id":"msn_8RfX2Lq
v9TqMv4z7sA2bN1k0YpEdHc9-
","issuer":"https://as.example.com","policy_view_id":"sha-
256:kP3xR9sQ7nM2vL4tY6bD1eF8jC5wH0pV2nR3kQ4mZ7t"},"parameter_diges
t":"sha-256:WPVi6EnQ7H9Fh-qk9ADxmTg8zruOdVUX1esl-
v3TfCI","resource":{"id":"je_2026Q3_inv_8421","type":"journal-entr
y"},"sequence":42,"subject":{"id":"user_3p2q8mN1a0kV7tR","type":"u
ser"}}

The committed digest is the SHA-256 of those bytes; its base64url form is 0qiDkwVoXwySxY32mS1NF_arp20x28leBo65z5PE5CQ. The Signed Statement carries the digest bytes inline as its payload, with payload-preimage-content-type application/mission-decision-evidence+json in its protected header (Section 6.1). A verifier that recomputes a different digest from the retrieved object has either re-serialized the object outside the envelope without recanonicalizing, or hashed the object with evidence_envelope removed, the signing preimage rather than the registered evidence bytes.

6.4. Registration Policy and Authoritative Producers

Each evidence type has one authoritative producer (Section 6.3). A relying party MUST verify that a record's iss is the authoritative producer for the record's type before treating the record as part of the Mission's feed; a record from any other producer is not part of the feed, whatever its sub.

The deployment's Transparency Service registration policy SHOULD restrict who may register Signed Statements for a Mission subject to those authoritative producers, so the log does not accumulate records from components that are not entitled to write to a Mission's feed.

A relying party discovers a producer's key by the producer's role. The issuer's key is resolved through its published key material:

A PDP, PEP, harness, or egress key is resolved through the deployment-published key sets the runtime profile and its runtime evidence companion require ([I-D.draft-mcguinness-mission-runtime], [I-D.draft-mcguinness-mission-runtime-evidence]); the harness profile requires the same publication of a harness or egress gate that registers its evidence ([I-D.draft-mcguinness-mission-harness]). A Work Product Binding projects onto the producer rule rather than meeting it literally ([I-D.draft-mcguinness-oauth-mission-work-products]). Its evidence producer is the mediator principal that signed the inner binding; the binding's own iss is the key-set authority that locates the mediator's key, not the mediator identity. A relying party verifies the inner JWS first, including that mediator.id and mediator.role correspond to the key its kid resolves; the Signed Statement's iss MUST equal the binding's iss, and the Signed Statement's signing key MUST be authorized for that same mediator principal and role under the deployment's published key material. The Mission Issuer does not register a harness-mediated binding as its own production: the producer stays the mediator principal, whichever component performs the registration.

6.5. Registration Availability

Registration is asynchronous to the events it records. A producer MUST NOT block approval, issuance, or a lifecycle transition on a Transparency Service being reachable or on a Receipt being returned; the governed operation proceeds and the record is registered out of band.

A conforming deployment MUST register each record within a documented time bound. It MUST record its registration backlog, so a gap between an event and its registration is visible rather than silent. The deployment publishes, with its registration schedule, in its Mission Deployment Profile ([I-D.draft-mcguinness-mission-architecture]):

  • the time bound;

  • the backlog metric; and

  • the component that alerts when the bound is exceeded.

This mirrors the runtime profile's orphaned-evidence obligations ([I-D.draft-mcguinness-mission-runtime]).

A record registered late is transparent only from its registration time: the Receipt proves inclusion from when the log received the Signed Statement, not from when the event occurred. A deployment that needs the event time itself attested relies on the timestamps the evidence carries, which the record's hash commits.

6.6. Retrieval

The transparency substrate registers Signed Statements and resolves a Receipt by its entry identifier; the SCITT reference APIs [I-D.draft-ietf-scitt-scrapi] give a concrete interface for registration, Receipt resolution, and Transparency Service key discovery where a deployment runs them. Neither the substrate nor those APIs defines a query that enumerates a subject's whole feed.

A deployment that wants an auditor to retrieve all of a Mission's records by sub provides that enumeration itself, out of band, over the records it registered; this profile fixes the sub so those records share one correlator (Section 8), not a standardized feed query.

Out of band is not undocumented. A deployment claiming this profile MUST document its feed-enumeration mechanism:

  • how an authorized auditor retrieves every record registered for a sub;

  • in what order;

  • with what completeness relative to Section 6.7; and

  • under what auditor authentication.

The mechanism is deployment-chosen (a SCRAPI extension, a log export, a query surface over retained Transparent Statements); an undocumented one leaves the feed assembled only by the deployment itself, which is the trust this profile exists to remove.

6.7. What to Register

A deployment claiming this profile MUST register at least the governance-critical records: the approval event and every Mission lifecycle transition. It SHOULD also register the runtime decision and execution evidence for the action classes it enforces, so the action trail is transparent and not only the governance trail.

A Mission Issuer deploying this profile SHOULD register a derivation record (Section 6.3.2) for each derivation event. The derivation is where approval becomes an issued token, and the family's evidence otherwise leaves that step to Authorization Server logs no profile mandates; registering it closes the approval-to-action gap.

7. Cross-Producer Correlation

This section is non-normative reference-architecture guidance. It describes how a deployment builds an activity view across evidence its separate producers retain; it defines no wire member and imposes no requirement of this profile.

Registration (Section 6) commits evidence by hash to one Mission-keyed transparency feed (Section 8); it does not itself join records into a timeline. Independently of registration, evidence is producer-retained (each PDP, PEP, executor, egress gate, harness, and the Mission Issuer keeps its own store, [I-D.draft-mcguinness-mission-runtime]), and a deployment builds a per-Mission activity view by joining those retained records at query time, over correlation members the evidence conventions already carry:

Each key joins only where the producing profile's evidence carries it: a record with no hop_reference was not taken under a continuation, and Containment Evidence carries no trace_id.

A Mission's lineage members thread a whole task-run graph, one Mission at a time, into a tree: the parent member a Child Mission's record carries ([I-D.draft-mcguinness-oauth-mission-child-delegation]), the template member a template-dispatched Mission carries ([I-D.draft-mcguinness-oauth-mission-template]), and the predecessor member an expansion successor carries ([I-D.draft-mcguinness-oauth-mission-expansion]). A template's dispatched instances, a dispatched Mission's Child Missions, and the continuation hops carried on their evidence, form the branches; an expansion successor's predecessor is lineage metadata pointing back to the Mission it succeeds, not a branch of the same run, because a successor's authority comes only from its own approval ([I-D.draft-mcguinness-oauth-mission-expansion]).

A reference realization of this guidance is a console activity log: a read-model view joining Decision Evidence, Execution Evidence, Refusal Records, egress evidence, issuer ingestion records, and Containment Evidence across their producers into a per-Mission task-run timeline, by the keys and the lineage tree above, without registering, moving, or duplicating any producer's evidence of record.

8. The Mission as Subject

The sub of every Signed Statement about a Mission is a stable identifier of that Mission, derived from the mission claim's issuer and id. All evidence about one Mission shares one sub and forms one Transparency Service feed. Where the deployment provides feed retrieval (Section 6.6), an auditor collects a Mission's registered evidence by that sub, ordered and append-only within what the retrieval returns.

That retrieval is out-of-band enumeration the deployment provides (Section 6.6), not a standardized subject query the substrate defines: the substrate's non-equivocation guarantee binds the log and its Receipts, not the completeness of an enumeration the audited deployment itself assembles. A deployment can therefore present different auditors different subject listings, and such a per-auditor split view is not detectable from a single service without a standardized listing or registration with more than one service (Section 9, Section 13).

The feed is complete only relative to what the deployment is expected to register and to enumerate (Section 6.7); an omitted or withheld record is visible only against that expectation (Section 13).

For that to hold, every producer MUST compute the identical sub. This profile fixes a single construction; a producer MUST use it. A producer MUST NOT use any other. The sub is the URI formed by appending the literal path segment missions and the Mission id to the issuer:

<issuer>/missions/<id>

The issuer is used exactly as it appears in the mission claim, with any single trailing slash removed, and the id is appended without transformation; the issuance profile constrains the Mission Identifier to the URL-safe characters [A-Za-z0-9_-] ([I-D.draft-mcguinness-oauth-mission]), so no percent-encoding is required. Because the construction is fixed, independent producers writing evidence about the same Mission (the Mission Issuer, a PDP, a harness) compute the same sub and write to one feed.

The sub is a correlator, not a credential; presenting it authorizes nothing ([I-D.draft-mcguinness-oauth-mission]).

A Child Mission ([I-D.draft-mcguinness-oauth-mission-child-delegation]) is its own Mission with its own id and issuer, so its evidence forms its own feed; its lifecycle events, including a cascaded transition, appear in that feed. The event that triggered the cascade is in the parent's feed. Lineage is navigable in both directions: the child's lineage to the parent is the parent member of its mission claim, which an auditor follows to the parent's sub to see that trigger, and the parent's children are enumerated by the Child Evidence records on the parent's feed (Section 6.3), each carrying the child's id.

Across trust domains a Mission's issuer and id are unchanged ([I-D.draft-mcguinness-oauth-mission]), so every producer in every domain computes the same sub. They share one feed only when they register with the same Transparency Service.

Where domains register with different services, each service holds a partial feed and its non-equivocation guarantee is per-service (Section 9); an auditor that needs the Mission's whole history reconciles it across those services. A deployment that wants a single coherent feed SHOULD have its cross-domain producers register with one shared service.

9. Receipts and Transparent Statements

On registration the Transparency Service returns a Receipt, a signed inclusion proof ([RFC9943]).

The producer SHOULD retain the Receipt with the evidence, or on the Mission record, as a Transparent Statement (the Signed Statement augmented with its Receipt). A producer that claims offline verifiability for a record MUST retain its Receipt, or an entry identifier the service guarantees resolvable for the audit horizon; a registered record with neither is verifiable only against the live service.

A relying party verifies a Transparent Statement offline, without contacting the producer or the service:

  1. verify the Signed Statement signature against the producing component's (iss) trust anchor;

  2. verify the Receipt signature against the Transparency Service's published key or configured trust anchor;

  3. verify the inclusion proof binds the Signed Statement to the log;

  4. when auditing a specific Mission, confirm sub is that Mission's feed (Section 8); and

  5. retrieve the referenced evidence under access control, rehash the evidence bytes as Section 6.3 fixes them for its type (with the retained salt, where one was used, Section 14), and compare the result against the committed digest.

A relying party MUST complete steps 1 through 5 before relying on a record as transparent.

9.1. Verification Failures

This profile distinguishes an integrity failure, where the transparency claim is false, from an audit failure, where the claim cannot be fully checked but is not refuted, as the consent evidence profile does ([I-D.draft-mcguinness-oauth-mission-consent-evidence]):

  • A failed Signed Statement signature, Receipt signature, or inclusion proof (steps 1 through 3), or a committed hash that does not match the retrieved evidence (step 5), is an integrity failure. The relying party MUST reject the Transparent Statement. It MUST NOT treat the record as transparent.

  • Evidence that cannot be retrieved within the retention window (step 5 incomplete) is an audit failure, not an integrity failure. Steps 1 through 3 still establish that the record was registered, at a committed time, in a non-equivocating log; only the content check is incomplete. The relying party MUST NOT treat the record as content-verified. It MUST NOT treat unretrievable evidence as evidence of tampering. An erasure record on the feed (Section 6.3.3) explains the gap as recorded-basis erasure; a gap without one, in a deployment that registers erasures, is itself worth recording, though still not proof of tampering.

  • A producer or Transparency Service key that the relying party cannot verify against a trust anchor (step 1 or step 2 unresolved) is an audit failure, not an integrity failure. The relying party cannot attribute the Signed Statement or the Receipt to a known key, so it MUST NOT treat the record as transparent. It is not evidence of tampering, and the relying party MUST NOT treat it as such.

A deployment MAY register the same evidence with more than one Transparency Service and retain multiple Receipts.

A relying party detects equivocation by comparing two things across services: the Receipts issued for the same Signed Statement, which must prove inclusion of the identical statement, and the records listed for the same sub, which must not differ in ways the append-only property forbids. A service that presents inconsistent Receipts for one statement, or a subject listing that diverges from another service's, is equivocating, and the relying party can rely on the others.

Detection is a duty, not a side effect. A deployment claiming this profile MUST designate the party that periodically re-verifies feed consistency (retained Receipts and the sub listing, against each service it registers with) and that party's alerting obligation on failure. A deployment with a single service and no designated monitor MUST NOT claim non-equivocation: it obtains tamper evidence only against alteration after registration, not against a split view.

10. Worked Example

At the approval event for Mission msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-, the Mission Issuer records Consent Evidence and registers it. It does not put the disclosure in the log; it signs a Signed Statement whose payload is the hash of the Consent Evidence, carried inline, with the hash algorithm and the evidence media type in the protected header (Section 6.1). The sub is the Mission feed, derived from the Mission issuer and id; the iss is the Mission Issuer. Protected header, in CBOR extended diagnostic notation ([RFC8610], Appendix G):

{
  / alg /                    1: -7,   / ES256 /
  / payload-hash-alg /     258: -16,  / SHA-256 /
  / payload-preimage-content-type / 259:
      "application/mission-consent-evidence+json",
  / kid /                    4: h'61732d6b65792d323032362d7133',
  / CWT Claims /            15: {
    / iss / 1: "https://as.example.com",
    / sub / 2: "https://as.example.com/missions/
                msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-"
  }
}

The payload is the SHA-256 digest of the JCS canonical bytes of the retained Consent Evidence object, evidence_envelope included (Section 6.3), carried inline as the raw digest whose base64url form is CnS3nT9sQ7nM2vL4tY6bD1eF8jC5wH0pV2nR3kQ4xVz, not that display string. The Transparency Service appends the statement and returns a Receipt, a COSE_Sign1 with an inclusion proof in its unprotected header, which the Mission Issuer keeps with the evidence as a Transparent Statement.

As the Mission proceeds, its other producers write to the same sub: the Mission Issuer registers a derivation record when it derives the agent's token (Section 6.3.2), the PDP registers a decision-evidence commitment when it permits the journal-entries.write, and the Mission Issuer registers a lifecycle-change commitment when alice later completes the Mission. Collecting the records registered under that one sub (Section 6.6) gives the Mission's whole history, in order, append-only:

sub =
https://as.example.com/missions/msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-

  #1  approval-event        iss=as.example.com    t0
  #2  consent-evidence      iss=as.example.com    t0
  #3  derivation-record     iss=as.example.com    t0
  #4  decision-evidence     iss=pdp.example.com   t0+6h
  #5  lifecycle: completed  iss=as.example.com    t0+6h

A compliance auditor in another domain, holding none of these deployments' logs, takes the Transparent Statement for #2, verifies the Receipt against the Transparency Service's published key and the inclusion proof, retrieves the Consent Evidence under access control, and rehashes the retained object to compare against the committed digest. The auditor now knows that exact disclosure was registered at t0, included in the service's signed tree head, and unaltered since, without trusting the Mission Issuer's own records. Detecting a later drop or reorder by the service rests on trusting that single service or reconciling across several (Section 11).

Two failures are distinct (Section 9.1). If the retrieved Consent Evidence hashes to a value other than the committed digest, the retained record was altered after registration: an integrity failure, and the auditor rejects it. If the record cannot be retrieved at all, the auditor still knows from the Receipt that record #2 was registered at t0 and included in a signed tree head, but cannot confirm its content: an audit failure, not proof of tampering.

11. What Transparency Adds, and Does Not

Transparency makes the evidence set tamper-evident and independently verifiable: a registered record's inclusion is provable from its Receipt against a signed tree head, and a cross-domain party verifies a record without trusting the producer's logs, which a bare signature over a narrowed token cannot give it ([I-D.draft-mcguinness-oauth-mission]). Against a single Transparency Service, that a record is not later silently dropped or reordered and that the feed is the same for every auditor are trusted properties of that service, not ones a Receipt proves: this profile defines no consistency proofs or gossip, so checking them rests on registering with more than one service (Section 9, Section 13).

It does not make a dishonest producer honest. A producer can register a false record; transparency makes the false record permanent, attributable, and visible to every auditor, which is accountability, not prevention, the transparency substrate's own model ([RFC9943]). It also proves only that a record was registered, not that the action the record describes occurred or was authorized; that is the evidence's own semantics. And because statements commit by hash, a Receipt without the retrievable evidence proves only that some record was logged, not what it said.

12. Conformance

A producer conforming to this profile MUST:

A relying party conforming to this profile MUST:

13. Security Considerations

The transparency substrate's security considerations apply. This profile adds:

14. Privacy Considerations

A Transparency Service log is append-only and may be widely readable, so nothing registered can be redacted later. A producer MUST NOT register Mission evidence in the clear; it registers an inline hash commitment (Section 6), and the evidence, which can carry task descriptions, principals, and high-risk authority, is retained separately under access control.

A deployment SHOULD weigh whether the Mission's durable identifier, its existence, and its registration cadence are sensitive, and whether the issuer and id that compose the sub reveal more than intended, before registering a Mission's evidence in a shared or widely readable log. Even the committed metadata leaks information: the sub is a durable per-Mission correlator and the registration times reveal a Mission's activity pattern. The sub construction is fixed (Section 8) and does not expose the Subject directly, so the concern is not Subject leakage but that the identifier, existence, and cadence are visible in the log.

Evidence whose canonical bytes are low-entropy or drawn from an enumerable space MUST be committed with a random salt, retained alongside the evidence and hashed together with the evidence's canonical bytes. Without a salt, a party that can guess the evidence can confirm the commitment by dictionary; the salt makes the committed digest unguessable while still reproducible at verification, where the salt is retrieved with the evidence (Section 9).

The lifecycle-transition object carries the salt as a required member of its canonical bytes for exactly this reason (Section 6.3.1), and any other profile-fixed low-entropy shape MUST do the same.

Deleting retained evidence has a consequence the log makes permanent. The Receipt, the sub, and the registration cadence stay in the log, but the evidence they commit to is gone, so every record over the erased evidence becomes a permanent audit failure (Section 9.1): its content can never again be checked against the commitment. A deployment that may need to erase evidence, for a data-subject request or a retention limit, weighs this before registering. Registration does not prevent erasure; it converts an erased record into a permanent, visible gap rather than a silent one.

A deployment that erases committed evidence MUST register an erasure record (Section 6.3.3) on the same feed, so the gap carries its basis: lawful erasure and convenient loss are otherwise indistinguishable, and the verification taxonomy forbids reading the gap as tampering.

14.1. Evidence Minimization

The evidence layer is an accountability substrate, and unbounded it becomes a surveillance substrate. A deployment SHOULD apply these minimizations to the evidence it produces and registers, across this profile and the runtime and consent-evidence records it aggregates:

  • Data minimization. Record the action class, resource, and bound parameters a decision turned on, not full user content or model input, unless the content is itself the audited artifact.

  • Field classification. Classify evidence fields by sensitivity when the record is produced, so access, export, and retention key on the class rather than on later review; the Mission Deployment Profile names the scheme in use ([I-D.draft-mcguinness-mission-architecture]).

  • Separation. Keep operational logs distinct from audit-grade evidence, so verbose debugging data is not retained at the audit horizon or committed to a transparency log.

  • Access control. Evidence access is itself policy-governed; reading a Mission's evidence is a privileged operation, not a byproduct of holding a Mission reference, and a deployment SHOULD record evidence reads as it records the actions the evidence describes: access to the audit trail is part of the audit trail.

  • Retention. Retain for the declared audit horizon and no longer; the horizon is per-Mission, not indefinite.

  • Identifier strategy. The durable per-Mission sub is a cross-audience correlator; a deployment that needs to limit correlation adopts the directed or audience-pairwise Mission references named as future work by the issuance profile and the AAuth binding, when available ([I-D.draft-mcguinness-oauth-mission], [I-D.draft-mcguinness-mission-aauth]).

  • Export. An evidence export preserves integrity (the commitments and their salts) without over-sharing the raw committed content beyond the recipient's need.

15. IANA Considerations

This document defines four media types for the evidence types of Section 6.3 that no other profile defines:

This document makes no registration request for them yet; registration is deferred pending a demonstrated cross-domain interoperability need, and deployments using these media types do so by local agreement until then.

The other evidence media types this profile registers into a Transparency Service are defined elsewhere:

The Signed Statement and Receipt media types are the transparency substrate's ([RFC9943]). This profile derives the sub by profile rather than registering a new identifier.

16. References

16.1. Normative References

[I-D.draft-ietf-cose-hash-envelope]
Steele, O., Lasker, S., and H. Birkholz, "COSE Hash Envelope", Work in Progress, Internet-Draft, draft-ietf-cose-hash-envelope-10, , <https://datatracker.ietf.org/doc/html/draft-ietf-cose-hash-envelope-10>.
[I-D.draft-mcguinness-mission-approval-governance]
McGuinness, K., "Mission Approval Governance", , <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-approval-governance.html>.
[I-D.draft-mcguinness-mission-discovery]
McGuinness, K., "Mission Open-World Discovery", , <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-discovery.html>.
[I-D.draft-mcguinness-mission-harness]
McGuinness, K., "Mission-Aware Agent Harnesses", , <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-harness.html>.
[I-D.draft-mcguinness-mission-mandate]
McGuinness, K., "Mission Mandate", , <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-mandate.html>.
[I-D.draft-mcguinness-mission-runtime-evidence]
McGuinness, K., "Mission Runtime Evidence", , <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-runtime-evidence.html>.
[I-D.draft-mcguinness-mission-substrate]
McGuinness, K., "Mission Substrate Requirements", , <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", , <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission.html>.
[I-D.draft-mcguinness-oauth-mission-child-delegation]
McGuinness, K., "Mission Child Delegation for OAuth 2.0", , <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-child-delegation.html>.
McGuinness, K., "Mission Consent Evidence for OAuth 2.0", , <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-consent-evidence.html>.
[I-D.draft-mcguinness-oauth-mission-containment]
McGuinness, K., "Mission Containment for OAuth 2.0", , <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-containment.html>.
[I-D.draft-mcguinness-oauth-mission-signals]
McGuinness, K., "Mission Lifecycle Signals for OAuth 2.0", , <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-signals.html>.
[I-D.draft-mcguinness-oauth-mission-work-products]
McGuinness, K., "Mission Work Products", , <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-work-products.html>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <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, , <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, , <https://www.rfc-editor.org/rfc/rfc6234>.
[RFC7515]
Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, , <https://www.rfc-editor.org/rfc/rfc7515>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8785]
Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, , <https://www.rfc-editor.org/rfc/rfc8785>.
[RFC9052]
Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, DOI 10.17487/RFC9052, , <https://www.rfc-editor.org/rfc/rfc9052>.
[RFC9943]
Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande, Y., and S. Lasker, "An Architecture for Trustworthy and Transparent Digital Supply Chains", RFC 9943, DOI 10.17487/RFC9943, , <https://www.rfc-editor.org/rfc/rfc9943>.

16.2. Informative References

[I-D.draft-ietf-scitt-scrapi]
Birkholz, H., Geater, J., and A. Delignat-Lavaud, "Supply Chain Integrity, Transparency, and Trust (SCITT) Reference APIs", Work in Progress, Internet-Draft, draft-ietf-scitt-scrapi-11, , <https://datatracker.ietf.org/doc/html/draft-ietf-scitt-scrapi-11>.
[I-D.draft-mcguinness-mission-aauth]
McGuinness, K., "Mission Context Binding for AAuth", , <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-aauth.html>.
[I-D.draft-mcguinness-mission-architecture]
McGuinness, K., "An Architecture for Mission-Bound Authorization", , <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-architecture.html>.
[I-D.draft-mcguinness-mission-authority-server]
McGuinness, K., "Mission Authority Server", , <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-authority-server.html>.
[I-D.draft-mcguinness-mission-orchestration]
McGuinness, K., "Mission Orchestration and Unwinding", , <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-orchestration.html>.
[I-D.draft-mcguinness-mission-runtime]
McGuinness, K., "Mission-Bound Runtime Enforcement", , <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-runtime.html>.
[I-D.draft-mcguinness-mission-shaping]
McGuinness, K., "Mission Intent Shaping", , <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-shaping.html>.
[I-D.draft-mcguinness-oauth-mission-expansion]
McGuinness, K., "Mission Expansion for OAuth 2.0", , <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-expansion.html>.
[I-D.draft-mcguinness-oauth-mission-template]
McGuinness, K., "Mission Template for OAuth 2.0", , <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-template.html>.
[RFC8610]
Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, , <https://www.rfc-editor.org/rfc/rfc8610>.

Acknowledgments

This document is part of the Mission-Bound Authorization for OAuth 2.0 work and profiles the SCITT architecture to make Mission evidence transparent and independently verifiable.

Author's Address

Karl McGuinness
Independent