Mission Audit Transparency for OAuth 2.0

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 28 December 2026.¶

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

The issuance profile [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 [I-D.draft-ietf-scitt-architecture] (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 is one feed an auditor retrieves and replays as a single narrative.¶

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

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

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

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-oauth-mission-runtime]).¶

5. 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 ([I-D.draft-ietf-scitt-architecture]). 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 6.¶

The content_type identifies the evidence object's media type.¶

A Signed Statement MUST commit to the evidence by hash, with a detached payload, rather than carry the evidence itself ([I-D.draft-ietf-scitt-architecture]). The committed value is the evidence's existing integrity anchor or evidence-envelope digest ([I-D.draft-mcguinness-oauth-mission]); where the evidence has no such anchor, the producer computes one over the evidence's canonical bytes. This keeps sensitive task data out of the log (Section 12): the log proves a specific record was registered at a time, and the record is retrieved separately, under access control, and checked against the committed hash.¶

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

6. 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 origin and id. All evidence about one Mission shares one sub and forms one Transparency Service feed. An auditor retrieves 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 feed.¶

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 origin:¶

<origin>/missions/<id>

The origin 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 mission_id 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]).¶

7. Receipts and Transparent Statements

On registration the Transparency Service returns a Receipt, a signed inclusion proof ([I-D.draft-ietf-scitt-architecture]). 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 6); and¶

5. retrieve the referenced evidence under access control and verify it against the committed detached hash.¶

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

8. 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 detached and whose content_type names the evidence, committing to the evidence by its consent_rendering_hash. The sub is the Mission feed, derived from the Mission origin and id; the iss is the Mission Issuer. Protected header, in COSE EDN ([RFC9052]):¶

{
  / alg /          1: -7,             / ES256 /
  / content_type / 3: "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 signed payload is detached; the committed value is the evidence's consent_rendering_hash, sha-256:CnS3nT9sQ7nM2vL4tY6bD1eF8jC5wH0pV2nR3kQ4xVz. 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 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. Querying the Transparency Service for that one sub returns 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  decision-evidence     iss=pdp.example.com   t0+6h
  #4  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 checks it against the committed consent_rendering_hash. 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 7.1). If the retrieved Consent Evidence hashes to a value other than the committed consent_rendering_hash, 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.¶

9. 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 ([I-D.draft-ietf-scitt-architecture]). 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.¶

10. Conformance

A producer conforming to this profile MUST:¶

• register Mission evidence as Signed Statements with a detached hash commitment, never the evidence in the clear (Section 5);¶

• set sub to the Mission feed by the fixed construction of Section 6;¶

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

A relying party conforming to this profile MUST:¶

• perform verification steps 1 through 5 of Section 7 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; and¶

• treat unretrievable evidence as an audit failure, not as evidence of tampering (Section 7.1).¶

11. 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 9).¶

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

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

12. 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 a hash commitment with a detached payload (Section 5), 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. A deployment SHOULD derive sub so it does not expose the Subject or task in the clear, and SHOULD weigh whether a Mission's mere existence and cadence are sensitive before registering its evidence in a shared log.¶

13. IANA Considerations

This document makes no IANA request. It reuses the Signed Statement and Receipt media types of the transparency substrate ([I-D.draft-ietf-scitt-architecture]) and the evidence media types of the suite, and derives the sub by profile rather than registering a new identifier.¶

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