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

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

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

{"issuer":"https://as.example.com","mission_id":"msn_8RfX2Lqv9TqMv
4z7sA2bN1k0YpEdHc9-","salt":"q7hJ2mXv9pTzR4kW5nB8dQ","state":"revo
ked","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",
  "token_digest_kind": "jti",
  "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","token_digest_kind":"jti"}

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

<issuer>/missions/<id>

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

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

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

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

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

9. Receipts and Transparent Statements

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

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

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

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

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

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

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

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

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

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

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 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]);¶

• 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

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