Mission Audit Transparency

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 8 January 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

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 a verifiable, non-equivocating 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, in a log that cannot later drop or reorder it. 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.5).¶

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

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

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

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

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

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

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

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

{
  / 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-"
  }
}

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

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

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

7. 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.5), an auditor collects a Mission's complete, ordered, append-only evidence by that sub, and the substrate's non-equivocation guarantee means the auditor and the deployment see the same records.¶

For that to hold, every producer MUST compute the identical sub. This profile fixes a single construction; a producer MUST use it and 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, and 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.¶

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 8); an auditor that needs the Mission's whole history reconciles it across those services, and a deployment that wants a single coherent feed SHOULD have its cross-domain producers register with one shared service.¶

8. 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 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 7); and¶

5. retrieve the referenced evidence under access control, rehash the evidence bytes as Section 6.2 fixes them for its type (with the retained salt, where one was used, Section 13), 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. 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.2), 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.2.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.5) 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 and has not since been altered, dropped, or reordered, without trusting the Mission Issuer's own records.¶

Two failures are distinct (Section 8.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 not reordered, but cannot confirm its content: an audit failure, not proof of tampering.¶

10. What Transparency Adds, and Does Not

Transparency makes the evidence set tamper-evident and independently verifiable: a registered record cannot be silently backdated, dropped, or reordered, the feed is the same for every auditor, 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]).¶

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

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

• 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 8 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 8.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 8.1).¶

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

• 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 8).¶

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

13. 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. 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 7) and does not expose the Subject directly, so the concern is not Subject leakage but that the Mission's durable identifier, its existence, and its registration cadence are visible in the log. A deployment SHOULD weigh whether those 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.¶

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

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

14. IANA Considerations

This document defines three media types for the evidence types of Section 6.2 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.2.1), and application/mission-derivation-record+json for the derivation record (Section 6.2.2). 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 and execution evidence types by the AuthZEN profile ([I-D.draft-mcguinness-mission-authzen]), 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]), 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.¶

15. References

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