Network Working Group K. McGuinness Internet-Draft Independent Intended status: Standards Track 13 August 2026 Expires: 14 February 2027 Mission Audit Transparency draft-mcguinness-mission-audit-latest 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 14 February 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction 2. Conventions and Terminology 3. Status: An Optional Extension 4. Relationship to the Issuance Profile 5. Mission Substrate 6. Registering Mission Evidence 6.1. Hash Commitment 6.2. The Mission Evidence Base 6.3. Evidence Types 6.3.1. The Lifecycle Transition Object 6.3.2. The Derivation Record 6.3.3. The Erasure Record 6.4. Registration Policy and Authoritative Producers 6.5. Registration Availability 6.6. Retrieval 6.7. What to Register 7. Cross-Producer Correlation 8. The Mission as Subject 9. Receipts and Transparent Statements 9.1. Verification Failures 10. Worked Example 11. What Transparency Adds, and Does Not 12. Conformance 13. Security Considerations 14. Privacy Considerations 14.1. Evidence Minimization 15. IANA Considerations 16. References 16.1. Normative References 16.2. Informative References Acknowledgments Author's Address 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: * the issuance profile's mission claim and integrity anchors; * the evidence objects defined across the suite; and * the transparency substrate's Signed Statement, Receipt, Transparent Statement, and subject (feed) constructs and COSE_Sign1 [RFC9052] format. 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 an action taken 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; the receipt-chaining alternative, each Mission Receipt binding its predecessor's digest, is for a deployment without a Transparency Service. 5. Mission Substrate This profile is defined against the Mission model rather than against OAuth 2.0 mechanics. It consumes these substrate primitives: * the Mission identifier and issuer, from which the statement subject is constructed; * the evidence types and their canonical bytes; * the integrity-anchor envelope; * each producer's published key material; and * the audit horizon, the retention window the registered evidence must survive. The issuance profile [I-D.draft-mcguinness-oauth-mission] is this version's normative substrate. 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: * iss: the producing component's issuer identifier, bound to the key the record is signed with; and * sub: the Mission, as defined in Section 8. 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 object that is already signed, those bytes are the retained object as issued, hashed as-is; for an object this profile canonicalizes, they are its JCS canonical bytes. The protected header carries: * payload-hash-alg (label 258): the COSE algorithm of the hash, -16 for SHA-256 [I-D.draft-ietf-cose-hash-envelope]; and * payload-preimage-content-type (label 259): the media type of the evidence that was hashed, from Section 6.3. 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). 6.3. Evidence Types Each registrable evidence type fixes the exact bytes that are hashed, the media type carried in payload-preimage-content-type, 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. +============+=================+====================+==========+ | Evidence | Canonical bytes | payload-preimage- | Producer | | type | (hashed) | content-type | | +============+=================+====================+==========+ | Approval | Mission record | application/ | issuer | | event | at creation, | mission-approval- | | | | state excluded, | record+json | | | | canonicalized | | | +------------+-----------------+--------------------+----------+ | Lifecycle | Signals SET as | application/ | issuer | | transition | issued; else | secevent+jwt, else | | | | Section 6.3.1 | application/ | | | | (JCS) | mission-lifecycle- | | | | | transition+json | | +------------+-----------------+--------------------+----------+ | Derivation | Section 6.3.2 | application/ | issuer | | record | (JCS) | mission- | | | | | derivation- | | | | | record+json | | +------------+-----------------+--------------------+----------+ | Consent | retained signed | application/ | issuer | | evidence | object, as | mission-consent- | | | | issued | evidence+json | | +------------+-----------------+--------------------+----------+ | Decision | Decision | application/ | PDP key | | evidence | Evidence | mission-decision- | | | | object, as | evidence+json | | | | issued | | | +------------+-----------------+--------------------+----------+ | Execution | Execution | application/ | PEP key | | evidence | Evidence | mission-execution- | | | | object, as | evidence+json | | | | issued | | | +------------+-----------------+--------------------+----------+ | Refusal | Refusal Record | application/ | PEP key | | Record | object, as | mission-refusal- | | | | issued | record+json | | +------------+-----------------+--------------------+----------+ | Mission | JWS Compact | application/ | issuer | | Mandate | Serialization, | mission- | | | | as issued | mandate+jwt | | +------------+-----------------+--------------------+----------+ | Child | Child Evidence | application/ | issuer | | Evidence | object (JCS), | mission-child- | | | | as the child- | evidence+json | | | | delegation | | | | | profile fixes | | | +------------+-----------------+--------------------+----------+ | Discovery | Discovery | application/ | issuer | | Evidence | Evidence object | mission-discovery- | | | | (JCS), as the | evidence+json | | | | discovery | | | | | profile fixes | | | +------------+-----------------+--------------------+----------+ | Harness | Harness | application/ | harness | | Evidence | Evidence object | mission-harness- | key | | | (JCS), as the | evidence+json | | | | harness profile | | | | | fixes | | | +------------+-----------------+--------------------+----------+ | Erasure | Section 6.3.3 | application/ | producer | | record | (JCS) | mission-erasure- | of the | | | | record+json | erased | | | | | record's | | | | | type | +------------+-----------------+--------------------+----------+ Table 1 The table is extensible by specification: a profile MAY define an additional evidence type by fixing its canonical bytes, its payload- preimage-content-type, 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. 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 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 already-signed object (the consent, decision, execution, and refusal evidence, the Signals SET, and the Mandate) is hashed as issued, not re-canonicalized. The media types and type identifiers are defined as follows: * the approval-event, lifecycle-transition, and derivation-record media types are defined by this profile (Section 15); * the consent, decision, execution, and refusal evidence types are registered by the profiles that define those objects ([I-D.draft-mcguinness-oauth-mission-consent-evidence], [I-D.draft-mcguinness-mission-runtime-evidence]); * the Signals SET media type by the Signals profile it is carried in ([I-D.draft-mcguinness-oauth-mission-signals]); * the Mandate media type by the Mandate profile ([I-D.draft-mcguinness-mission-mandate]); * the Child Evidence canonical bytes and type identifier by the child-delegation profile ([I-D.draft-mcguinness-oauth-mission-child-delegation]); and * the Discovery Evidence canonical bytes and type identifier by the discovery profile ([I-D.draft-mcguinness-mission-discovery]). 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 row) stays on that profile's maturity: this document keeps that reference informative, and a deployment not running the Experimental profile omits the row. 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. 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.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: * the Authorization Server's metadata jwks_uri in the OAuth binding ([I-D.draft-mcguinness-oauth-mission]); * the Mission Authority Server's discovery jwks_uri in the standalone binding ([I-D.draft-mcguinness-mission-authority-server]); or * the AAuth Person Server's existing jwks_uri in the AAuth binding ([I-D.draft-mcguinness-mission-aauth]). A PDP, PEP, or harness 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 that registers its evidence ([I-D.draft-mcguinness-mission-harness]). 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: * mission_id, or the nested Mission reference an object carries: the join's outer key, present on every record. * event_id: correlates a containment-plane ingestion decision to the Containment Evidence it produced when the outcome was applied ([I-D.draft-mcguinness-oauth-mission-containment]). * hop_reference: correlates an action's evidence to the continuation hop that authorized it (Section 6.2). * entry_digest: correlates records across producers and decisions that concern the same Authority Set entry. * trace_id: a deployment-supplied telemetry correlation identifier threading every record one task run produced, when the deployment's evidence-emitting components share one. This document does not define its form or require it. 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: /missions/ 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 retained Consent Evidence object as issued (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: * register Mission evidence as Signed Statements that commit to the evidence by an inline hash, never the evidence in the clear (Section 6); * set sub to the Mission feed by the fixed construction of Section 8; * set iss to its own issuer identifier, bound to the signing key; and * register at least the approval event and every Mission lifecycle transition (Section 6). A relying party conforming to this profile MUST: * perform verification steps 1 through 5 of Section 9 before relying on a record as transparent; * treat a signature, Receipt, inclusion-proof, or committed-hash mismatch as an integrity failure and reject the record; * treat unretrievable evidence as an audit failure, not as evidence of tampering (Section 9.1); and * treat a producer or Transparency Service key it cannot verify against a trust anchor as an audit failure, and not treat the record as transparent (Section 9.1). 13. Security Considerations The transparency substrate's security considerations apply. This profile adds: * Accountability, not prevention. Transparency detects and attributes tampering and omission after the fact; it does not stop a producer from registering a false record (Section 11). * Transparency Service trust. A single service is trusted not to equivocate; a deployment that needs that property checked SHOULD register with multiple independent services (Section 9). * Operator independence. The Transparency Service SHOULD be operated independently of the authoritative producers for the feeds it holds. The cross-domain value of transparency is verification without trust in the producer's own infrastructure (Section 11); a service operated by the producer whose records it holds returns the auditor to exactly that trust. Where producer and service share an operator, registration with a second, independent service is the compensating control. A deployment without one MUST NOT claim cross-domain verifiability for the affected records. A deployment states its service topology (self- run, vendor-shared, or third-party) and each operator's relationship to the producers in its Mission Deployment Profile ([I-D.draft-mcguinness-mission-architecture]). * Completeness. Transparency proves what was registered, not that everything was registered. A producer that omits a record cannot forge inclusion, but the gap is visible only if an auditor expects the record; a deployment SHOULD register evidence on a predictable schedule so omissions stand out in the feed. * Receipt and key management. A Receipt is only as trustworthy as the Transparency Service key that signs it; relying parties manage those trust anchors as they do the producers'. * Log lifecycle. Transparency Service key rotation, log retirement, and migration of a Mission's feed between services are deferred to future work, and a deployment whose Missions outlive a single log instance handles them by local arrangement until then. One interim rule holds now: the core's retired-key rule ([I-D.draft-mcguinness-oauth-mission]) applies to the Transparency Service's own keys, with the audit horizon of the feeds a key covers as the retention bound. * Receipt verification keys. A deployment MUST pin and retain the Transparency Service verification keys that validate its retained Receipts, for the audit horizon of the feeds each key covers. A Receipt is the longest-lived artifact this profile produces and is the compensating control for issuer key compromise ([I-D.draft-mcguinness-mission-mandate]); a Receipt whose signing key is no longer resolvable cannot be verified offline, and the compensating control is lost. 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: * application/mission-approval-record+json for the approval-event record; * application/mission-lifecycle-transition+json for the minimal lifecycle-transition object (Section 6.3.1); * application/mission-derivation-record+json for the derivation record (Section 6.3.2); and * application/mission-erasure-record+json for the erasure record (Section 6.3.3). 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 runtime decision, execution, and refusal evidence types by the runtime evidence companion ([I-D.draft-mcguinness-mission-runtime-evidence]); * the consent evidence type by the consent evidence profile ([I-D.draft-mcguinness-oauth-mission-consent-evidence]); * the Mission Mandate media type by the Mandate profile ([I-D.draft-mcguinness-mission-mandate]); * the Child Evidence type identifier by the child-delegation profile ([I-D.draft-mcguinness-oauth-mission-child-delegation]); * the Harness Evidence type identifier by the harness profile ([I-D.draft-mcguinness-mission-harness]); and * the Signals SET media type application/secevent+jwt by RFC 8417, which the Signals profile carries the event in ([I-D.draft-mcguinness-oauth-mission-signals]). 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, 15 November 2025, . [I-D.draft-mcguinness-mission-runtime-evidence] McGuinness, K., "Mission Runtime Evidence", 2026, . [I-D.draft-mcguinness-oauth-mission] McGuinness, K., "Mission-Bound Authorization for OAuth 2.0", 2026, . [I-D.draft-mcguinness-oauth-mission-child-delegation] McGuinness, K., "Mission Child Delegation for OAuth 2.0", 2026, . [I-D.draft-mcguinness-oauth-mission-consent-evidence] McGuinness, K., "Mission Consent Evidence for OAuth 2.0", 2026, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, . [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June 2020, . [RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, DOI 10.17487/RFC9052, August 2022, . [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, June 2026, . 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, 26 June 2026, . [I-D.draft-mcguinness-mission-aauth] McGuinness, K., "Mission Context Binding for AAuth", 2026, . [I-D.draft-mcguinness-mission-architecture] McGuinness, K., "An Architecture for Mission-Bound Authorization", 2026, . [I-D.draft-mcguinness-mission-authority-server] McGuinness, K., "Mission Authority Server", 2026, . [I-D.draft-mcguinness-mission-discovery] McGuinness, K., "Mission Open-World Discovery", 2026, . [I-D.draft-mcguinness-mission-harness] McGuinness, K., "Mission-Aware Agent Harnesses", 2026, . [I-D.draft-mcguinness-mission-mandate] McGuinness, K., "Mission Mandate", 2026, . [I-D.draft-mcguinness-mission-runtime] McGuinness, K., "Mission-Bound Runtime Enforcement", 2026, . [I-D.draft-mcguinness-oauth-mission-containment] McGuinness, K., "Mission Containment for OAuth 2.0", 2026, . [I-D.draft-mcguinness-oauth-mission-expansion] McGuinness, K., "Mission Expansion for OAuth 2.0", 2026, . [I-D.draft-mcguinness-oauth-mission-signals] McGuinness, K., "Mission Lifecycle Signals for OAuth 2.0", 2026, . [I-D.draft-mcguinness-oauth-mission-template] McGuinness, K., "Mission Template for OAuth 2.0", 2026, . [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, June 2019, . 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 Email: public@karlmcguinness.com