Canonical Payload Binding: A Signed Statement Construction Profile

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

Systems that anchor structured content to a SCITT Transparency Service [RFC9943] face a common sub-problem: how does a producer turn a JSON or CBOR object into a content-addressed Signed Statement whose identifier survives serialization, and how does a verifier check that the identifier in hand matches the bytes in hand? Each answer involves the same four moves — canonicalize, derive an identifier, bind a receipt, cite externals by digest — but they have been restated independently in every profile that needed them, with small variations that defeat interoperability.¶

This document extracts those four moves into a single reusable profile called the Canonical Payload Binding (CPB). CPB is the missing piece the COSE Hash Envelope mechanism [RFC9995] deliberately leaves open: RFC 9995 defines how a Signed Statement signals that its payload field carries a hash rather than the content itself, but it does not say how that hash is computed from structured content so that two independently written implementations arrive at the same bytes. CPB fills that gap and stops there — it defines the canonicalization algorithm, the derived identifier it produces, the binding of that identifier to a Signed Statement and its Receipt, and a typed reference mechanism for citing other digests, and it defines nothing about what the hashed content means. CPB is derived from [I-D.mih-scitt-agent-action-capsule] (§Conventions, §envelope, §registration, §identity), which first stated the construction in a SCITT context, and generalized at the IETF 126 hackathon in Vienna, where seven parties participated in the public interop program. The public record reports four codebases demonstrating byte agreement in specific shared, declared contexts. Other frozen artifacts retained separately declared digest contexts. ORPRG retained its CP-JSON-2 context and was represented in the interop design through a typed reference rather than through an assertion of cross-profile digest equality. Digests remain governed by their original contexts; CPB does not relabel an ORPRG CP-JSON-2 commitment as a CPB canonicalization algorithm's output. The provenance is stated here once and not repeated in subsequent sections.¶

For generic citation-binding verification, a CPB verifier can process a typed reference to any artifact type whose digest context it can resolve. Whether a particular citation slot permits that artifact type is determined by the consuming profile. Artifact-specific appraisal, authorization semantics, and application integration remain separate.¶

Supporting a new artifact type requires no change to this document's citation-binding algorithm. Declaring the type, its digest context, and its meaning is a matter for the payload profile that defines it; it may also require consuming-profile integration and artifact-specific appraisal.¶

2. Changes from -01

The most consequential correction since -01 is registry-level: the registry was re-derived from what the field actually built, not from what -01 originally specified. jcs-n, live and Registered in -01, is withdrawn; jcs — the construction every independent implementation actually converged on — is registered in its place. The rest of this revision consolidates registry, canonicalization, and conformance-checker work landed since -01 was posted, and rescopes the document to its charter.¶

Charter rescope. This document no longer normatively defines the Artifact Type Registry or any artifact-type-specific payload-shape rule. What changes is governance ownership, not location: REGISTRY.md does not move, and stays in this repository as the shared home for both registries this document's ecosystem uses. The Canonicalization Algorithm Registry (Section 14.1) remains CPB-normative. The Artifact Type Registry — its registration template, the purpose-label vocabulary, and both live entries (agent-action-capsule, machine-mandate) — is governed separately, by its own Designated Expert checklist and registration rungs already stated in REGISTRY.md, and this document references that registry rather than defining it. It is a single shared registry, not a per-profile one: [I-D.mih-scitt-agent-action-capsule] registers artifact types there alongside any other payload profile that wants to, each citing a CPB algorithm for its canonicalization; no one profile owns the registry. The worked walkthrough of Artifact-Type-Registry governance (Specification Required / Designated Expert / third-party registration) that -01 carried as an appendix is removed from this document, not moved — it belongs beside the registry it documents, in REGISTRY.md, where it already lives. This document now anchors [RFC9995] and keeps only the canonicalization algorithm(s), the derived identifier, Signed-Statement and Receipt binding, and the typed digest-reference container; the Abstract's former claim that this document governs "the artifact types" is corrected.¶

Registry.¶

• A machine-readable registry.json is now generated by CI from REGISTRY.md; releases pin a snapshot. A lookup against an identifier absent from the pinned snapshot but potentially valid in a later snapshot now returns a distinct verdict, id-unknown-to-snapshot, rather than being indistinguishable from a genuinely unknown identifier.¶

• REGISTRY.md gained an onboarding ladder and a controlled entry-status vocabulary (owner-confirmed, third-party-documented, provisional, standards-referenced), a three-rung registration path (owner-authored / third-party-documented / provisional) with a template, lifecycle, and removal/correction path, and Designated Expert review stated explicitly as a precondition of merging an entry rather than a status a merged entry can still assert. This infrastructure is shared by every registry this file hosts, including the shared Artifact Type Registry, which [I-D.mih-scitt-agent-action-capsule] registers into alongside every other payload profile that does — no single profile owns it.¶

• The registry generator and validator now source legal status values from REGISTRY.md itself instead of a hardcoded list, and reject a malformed table row (mismatched cell/header count) closed instead of silently mis-assigning columns; a small number of rows that predate the controlled vocabulary are named explicitly as the only ones permitted a legacy status spelling.¶

• A Reserved placeholder token no longer reads as Verified: registry lookups previously returned a "verified" verdict on entry presence alone; a distinct VERDICT_RESERVED verdict now applies to any entry present but not in Registered status.¶

• The required-fields table, the "immutable" language, and the upgrade-acknowledgment gate were corrected: the required-fields table is scoped to new entries; "immutable" is stated consistently as "immutable in behavior"; and the acknowledgment gate now requires the same consuming-profile acknowledgment for an upgrade to owner-confirmed that it already required for initial admission, closing a path where an owner could file without an acknowledgment and self-acknowledge afterward.¶

Canonicalization algorithms. jcs — plain RFC 8785 JCS, no normalization pass — is registered (Section 4.1), with a named consuming profile and a discriminating vector against jcs-n: one payload carrying a null member and an empty array (jcs preserves both, jcs-n stripped them) plus a float member (jcs admits it, jcs-n rejected it), failing loudly in both directions. jcs-n is withdrawn (Section 4.2) — the same terminal-marking disposition cde-n already carried in -01 — following an implementer census (the reference implementation was the only implementer of the normalization step it added), a byte audit showing 191 of 203 evaluated records were byte-identical under plain jcs without that step, the 12 divergent records being proof-of-concept artefacts retained by vintage, and the admission bar this revision applies to every entry: a named consuming profile. Separately, a cross-language conformance harness (vectors/CANONICALIZATION_DECLARATION.md) versions jcs-n's construction precisely enough for an independent implementation to conform against without reading the reference library; it stands as part of the permanent historical record for the now-withdrawn algorithm. The lowercase-\u string-escaping rule and the corresponding control-character sort order — properties of RFC 8785 JCS itself, and therefore shared by jcs and the withdrawn jcs-n alike — are now stated in prose and cross-linked from REGISTRY.md. The shared JCS serialization helper also now rejects non-finite numeric values (Infinity, -Infinity, NaN) before serialization, consistent with RFC 8785 Section 3.2.2.3 admitting finite values only.¶

Digest determinism and typed references. Two paragraphs now state explicitly what -01 only implied: each algorithm entry and each artifact type's digest-context declaration names exactly one hash algorithm, so digest_alg is fully determined by type (together with purpose where needed) for any registered reference, and a verifier encountering a digest_alg inconsistent with the resolved context MUST treat it as a failure and MUST NOT attempt to reconcile it (Section 8.1). A MUST-FAIL/PASS vector pair pins that an assembled pre-image — one built from selected source fields rather than the payload minus an exclusion set — is under-determined by algorithm and field set alone; producer-chosen member naming and nesting are part of the bytes. Two conformance-checker categories exercise this: recomputing both pinned pre-images and asserting they diverge for exactly the demonstrated reason, and applying a declared member_mapping to assert it reproduces the vector's own input. Contributed by Rul1an as an external submission, reproduced independently against the reference canonicalizer.¶

Conformance checker. A grammar/wire-layer conformance checker (cpb-check) validates a record against its declared profile grammar — a presence-and-number-form walk and duplicate-key rejection — built around a duplicate-preserving raw-bytes lexer, since a standard JSON parser silently drops duplicate keys before any rule can see them; digest recomputation and canonicalization_id resolution remain out of scope pending a later gate. Vector-harness fixes landed alongside it: the lexer now rejects trailing bytes after a JSON document ends and NFC-normalizes before duplicate-key detection, and an inverted must-fail assertion and a -0/duplicate-key gap that could previously let the harness certify a vector as passing for the wrong reason are both closed.¶

3. Conventions and Definitions

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

Payload Class:

A named category of structured content that has declared a canonicalization algorithm (from the registry in Section 14.1) and an exclusion set of fields that are omitted from the canonical form before the derived identifier is computed. A payload class is declared by the payload profile that defines it; this document does not maintain a registry of payload classes or artifact types.¶

Derived Identifier:

The content-address of a payload: the output of CANONICAL-DIGEST applied to the canonical form of the payload with the exclusion set removed. Verifiers MUST recompute the derived identifier from the payload bytes; a carried derived-identifier value is advisory only and a mismatch is a defect.¶

Digest Context:

The complete set of parameters that determine how a digest was computed: the field set selected, the exclusion set applied, the canonicalization algorithm applied, any domain separation, the encoding of the pre-image, and the representation of the output. Two digest values are comparable only when their full digest contexts are established as compatible. A payload class or artifact type MAY declare more than one digest context over the same payload, each serving a distinct purpose declared by the payload profile that defines the class or type; the contexts are independent and MUST NOT be conflated.¶

CANONICAL-DIGEST:

A function parameterized by a canonicalization algorithm A: for any such algorithm A and payload v, CANONICAL-DIGEST(A, v) = ENCODE_A(H_A(A(v))), where H_A is the digest function and ENCODE_A the output encoding declared by A's entry in the Canonicalization Algorithm Registry (Section 14.1). Every entry registered by this document declares SHA-256 and 64-character lowercase hexadecimal; an entry registered by a later document MAY declare another digest function or encoding, and a verifier MUST read both from the entry rather than assuming them. A(v) is the octet string produced by the algorithm applied to v; the specific pre-image construction — field selection, normalization, and encoding — is part of A's definition and is registered per Section 14.1.¶

Signed Statement:

A COSE_Sign1 object [RFC9052] that carries a payload, a protected header, and an optional unprotected header; defined in [RFC9943].¶

Receipt:

A COSE structure produced by a Transparency Service that provides verifiable evidence that a Signed Statement was registered; defined in [RFC9943] and format-governed by the Verifiable Data Structure of the service.¶

Transparent Statement:

A Signed Statement to whose unprotected header one or more Receipts have been attached.¶

Verifier:

Any party that validates a record from its bytes, without trusting the producer.¶

4. Payload Canonicalization Algorithms

A canonicalization algorithm specifies how to produce a canonical octet string from a structured value. The canonical octet string is the pre-image to CANONICAL-DIGEST. A payload class declares exactly one canonicalization algorithm; verifiers MUST NOT guess the algorithm from the payload shape.¶

The algorithms defined in this document and registered in the Canonicalization Algorithm Registry (Section 14.1) are:¶

Entries in the Canonicalization Algorithm Registry are immutable: new behavior requires a new entry, never a retroactive edit to an existing one. A reserved entry binds its token only; its summary is provisional until the entry is defined, at which point the full entry becomes immutable. A reserved entry may instead be withdrawn (Section 4.3, Section 4.2), which is terminal: the token stays bound, no definition is ever assigned (or, for an entry that was already defined, no further definition ever attaches to it), and the name is not reassigned. The hash function is part of each algorithm's definition; migration to a different hash (for example, a future post-quantum function) is performed by registering a new algorithm entry, never by reinterpreting an existing one.¶

CANONICAL-DIGEST(jcs, P) =
    lowercase_hex(SHA-256(JCS(P)))

CANONICAL-DIGEST(as-transmitted, B) = lowercase_hex(SHA-256(B))

5. The Derived Identifier

The derived identifier of a record is computed as:¶

id = CANONICAL-DIGEST(A, payload minus exclusion_set)

where A is the canonicalization algorithm declared by the payload class and the exclusion set is the set of fields declared by the payload class as self-referential or chain-linkage fields. The derived identifier is a 64-character lowercase hex string for every algorithm this document registers; for an algorithm registered elsewhere, its representation is the one that algorithm's registry entry declares.¶

The exclusion set MUST be declared by the payload class in its specification. Fields excluded are those that either contain the derived identifier itself (they cannot be inside the pre-image they help compute) or that reference other records in a chain (to keep the content-address stable regardless of what later chains to this record). The exclusion set is normative for the payload class; a verifier MUST apply the same exclusion set as the producer.¶

A producer MAY carry the derived identifier as a field in the payload. A verifier MUST recompute the identifier from the payload bytes and the declared exclusion set. If the recomputed value does not match the carried value, the verifier MUST treat this as a defect in the record.¶

When selective disclosure is in use, the derived identifier MUST be computed over the SD-encoded form of the payload, not the plaintext payload. A payload profile MUST declare non-eligible for selective disclosure any field that the profile's own verifier requires in order to evaluate the binding.¶

6. Envelope Conventions

A Signed Statement carrying a CPB-bound payload MUST be a COSE_Sign1 [RFC9052] structure. The protected header MUST carry:¶

• alg: the signing algorithm.¶

• kid or x5chain: the signing key identifier or certificate chain.¶

• content_type: the media type of the payload, as application/CLASS+json or application/CLASS+cbor according to the serialization the payload class declares, where CLASS is the payload class name as declared by the payload class's own defining specification.¶

A field belongs in the protected header only if a SCITT-generic party — a Transparency Service registration policy or a profile-unaware verifier — must act on it without understanding the payload class. Everything semantically specific to the payload class stays in the payload.¶

Protected-header claims are a closed set per payload class: extensions are payload-only. A Transparency Service that does not understand a protected-header extension MUST be able to register the Signed Statement and verify the envelope without it.¶

The closed-claim principle does not prevent payload-class-specific protected-header fields from existing; it requires that such fields be defined by the payload class specification, not added ad-hoc by producers.¶

7. Statement-to-Receipt Binding

A producer makes a record transparent by registering its Signed Statement with a SCITT Transparency Service per [RFC9943] and attaching the returned Receipt to the unprotected header, forming a Transparent Statement.¶

This profile is VDS-agnostic at the statement layer. Receipt format and proof verification are governed by the Verifiable Data Structure (VDS) of the Transparency Service; this profile imposes no VDS requirement.¶

A verifier MUST NOT report receipt-backed status without having verified a Receipt from a Transparency Service under a key the verifier trusts.¶

A verifier determining which VDS to apply when verifying a Receipt MUST read the VDS identifier from the protected header of the Receipt. The verifier MUST NOT infer the VDS from the COSE structure of the receipt alone. Unknown VDS identifiers MUST be rejected.¶

leaf_input = bytes.fromhex(D)    -- correct: 32 raw bytes

leaf_input = D.encode("utf-8")  -- WRONG: 64 ASCII bytes

8. Typed Digest References

A typed digest reference is the mechanism by which one record cites an external artifact — another record, an authorization document, a configuration object, or any other verifiable item — by its content-address without embedding it.¶

A typed digest reference is a JSON object with the following fields:¶

Additional fields MAY be present and MUST be ignored by verifiers that do not understand them.¶

9. Profile Independence

A payload profile MUST NOT impose requirements on the internal structure or field values of another payload profile. Relationships between artifacts of different types are expressed solely through typed references (Section 8) that resolve against each artifact type's own digest-context declaration.¶

This constraint keeps verification of a multi-artifact chain decomposable: a verifier evaluates each binding under each profile's own semantics independently and never needs to evaluate a pair of profiles jointly. Implementations therefore need not implement, or be aware of, profiles they neither produce nor consume, and a new profile may declare its own artifact types without revalidating existing profiles or implementations.¶

10. Discovery Mirror

This section is informative.¶

A producer MAY place an unprotected COSE header parameter that mirrors the derived identifier of the record. This parameter is advisory only: it allows log tooling, registration policies, and cross-grain citation to locate a record's content-address without parsing the payload, but it carries no binding guarantee.¶

A verifier MUST recompute the derived identifier from the payload. A mismatch between the advisory mirror value and the recomputed value is a defect in the record and MUST be reported.¶

The discovery mirror parameter is aligned with the trace-metadata convention in draft-birkholz-verifiable-agent-conversations §7.4 [I-D.birkholz-verifiable-agent-conversations], which defines a similar unprotected-header mechanism for conversation-grain records. A record using CPB at the action grain and a conversation container using that convention can share one discovery layer.¶

11. Extensibility and Cross-Cutting Facilities

This section is informative.¶

Several concerns are common to all payload profiles and, if defined independently per profile, would undermine decomposable verification or fragment the interoperability surface: selective disclosure, countersignature and multi-party attestation, record relations (supersedes, confirms, corrects), erasure tombstones, producer timestamps and validity periods, batch aggregation, and profile versioning.¶

This specification does not define these facilities in this document. Each will be addressed in a companion document that payload profiles MUST reference rather than developing an incompatible per-profile variant. Defining any of these facilities per-profile would violate the constraint established in Section 9.¶

12. Security Considerations

13. Privacy Considerations

A record bound under this profile carries digests of content rather than the content itself. The derived identifier and any typed digest references commit to the content without disclosing it; the record is therefore payload-blind to any verifier that does not independently possess the referenced artifacts.¶

Payload privacy is the responsibility of the payload class. A payload class that includes fields identifying persons, sessions, or request content SHOULD document the privacy properties of those fields, including whether they can be inferred from their digests given knowledge of the value space. Low-entropy fields are not confidential even when digested (Section 12).¶

An anchored record cannot be retracted: a Transparency Service's log is append-only and a registered record persists. Payload classes SHOULD specify which fields, if any, must not be present in a record that is intended to be anchored.¶

14. IANA Considerations

This document requests the creation of one new IANA registry, the Canonicalization Algorithm Registry (Section 14.1), under a "Canonical Payload Binding" heading. The registry uses the Specification Required policy ([RFC8126], Section 4.6); a Designated Expert is required for each registration. This document does not define an Artifact Type registry: artifact types are registered in the shared Artifact Type Registry in REGISTRY.md, governed separately from this document under its own Designated Expert checklist and registration rungs; this document references that registry (see Section 1.1) but does not define it. This revision's Canonicalization Algorithm Registry entries reflect a deliberate correction over -01's: the registry was re-derived from what the field actually built, rather than restated from what -01 originally specified (Section 2).¶

Registry entries are immutable. A registered entry defines a specific algorithm. If a behavior change is needed, a new entry MUST be registered; existing entries MUST NOT be modified retroactively. Maintainer is IANA per standard process; no other governance body is defined.¶

Until this registry comes into existence at RFC publication, the table below serves as the provisional living registry, maintained in this document's source repository. If the document is adopted, the provisional registry moves with the document to a repository of the working group's choosing.¶

15. Related Work

COSE Hash Envelope ([RFC9995]) is the hash-side sibling: it defines how to carry a content-addressed reference to an opaque payload in a COSE structure. CPB is the statement-side complement: it defines how the payload content is canonicalized and identified so that the content-address is reproducible across implementations.¶

The CCF Receipt Profile ([I-D.ietf-scitt-receipts-ccf-profile]) and COSE Receipts ([RFC9942]) are the receipt-side twins: they define the Verifiable Data Structure formats that may appear in the unprotected headers of Transparent Statements whose binding layer is defined here.¶

In-toto and DSSE represent an industry two-layer precedent: a content-addressed artifact layer combined with an attestation layer over the artifact's identifier. CPB formalizes the same pattern for the SCITT statement context.¶

[I-D.hillier-scitt-arp] independently derives a similar canonical claim construction in its §2. Its Canonical Claim defines its own key-sort, NFC, number-rendering, and undefined-stripping rules, plus a Claim Hash join key. The construction is near-jcs but not byte-compatible. The independent re-derivation is evidence that this layer is consistently re-invented when it is not standardized; CPB exists to stop the re-invention. Implementations must not assume byte compatibility; ARP's Canonical Claim carries an explicit construction identifier by which a consumer can determine compatibility.¶

[I-D.birkholz-verifiable-agent-conversations] defines trace-metadata conventions at the conversation grain (§7.4). The discovery mirror in Section 10 is designed to be compatible with that convention so that action-grain records and conversation-grain containers share one discovery layer. The alignment is informative; CPB does not normatively depend on that document.¶

[I-D.sokolov-rats-aep-composition] addresses the complementary problem in the RATS domain: composing application-layer action evidence with remote attestation. [I-D.mih-sato-agent-accountability-composition] defines composition and conformance rules for multi-agent accountability chains. Together these documents demonstrate that the canonicalize-and-derive-identifier construction is a recurring primitive across independent use cases — one shared binding layer serving SCITT-anchored agent records, RATS attestation composition, and multi-agent accountability chains.¶

16. References

Appendix A. Synthetic Registration Walkthrough

This appendix illustrates the mechanics of Section 5, Section 6, and Section 7 using a non-domain-specific payload class. No domain vocabulary from any specific profile is used.¶

Payload class: temperature-record. Fields: station_id (string), timestamp (string), celsius (exact decimal string), record_id (string). Exclusion set: {record_id}. Algorithm: jcs. Representation: bare 64-char lowercase hex.¶

Step 1 — Construct the payload:¶

{
  "station_id": "WS-42",
  "timestamp": "2026-07-24T00:00:00Z",
  "celsius": "21.3",
  "record_id": null
}

Step 2 — Apply the exclusion set:¶

Remove record_id (it is in the exclusion set). The resulting object is:¶

{
  "station_id": "WS-42",
  "timestamp": "2026-07-24T00:00:00Z",
  "celsius": "21.3"
}

Step 3 — Compute the derived identifier:¶

Apply JCS [RFC8785] to produce the canonical octet string. Compute SHA-256 and encode as lowercase hex. The result is the record_id value to be placed back into the payload for transport.¶

Step 4 — Construct the Signed Statement:¶

Wrap the complete payload (including the now-populated record_id) in a COSE_Sign1 with:¶

• content_type: application/temperature-record+json¶

• alg and kid: producer's signing algorithm and key identifier¶

Step 5 — Register and receive a Receipt:¶

Submit the Signed Statement to a SCITT Transparency Service. Attach the returned Receipt to the unprotected header. The Transparent Statement is now suitable for distribution to verifiers.¶

Step 6 — Verify:¶

A verifier extracts the payload, strips record_id, applies JCS, recomputes SHA-256, and compares to the carried record_id. The verifier then verifies the envelope signature and, if present, the Receipt under a trusted service key. All three checks must pass for the record to be considered fully verified.¶

Appendix B. Synthetic Two-Slot Composition

This appendix illustrates Section 8 using two cooperating payload classes. No domain vocabulary is used.¶

Scenario: a decision-record payload class cites an authorization-doc using a typed digest reference.¶

Authorization doc (payload class authorization-doc; algorithm jcs):¶

{
  "doc_id": "...",
  "subject": "WS-42",
  "scope": "temperature-write",
  "issued_at": "2026-07-24T00:00:00Z"
}

Its derived identifier is computed with doc_id in the exclusion set. Suppose the result is "ab12cd34...".¶

Decision record (payload class decision-record; algorithm jcs):¶

{
  "record_id": null,
  "action": "write",
  "authorization": {
    "type": "authorization-doc",
    "digest_alg": "SHA-256",
    "digest": "ab12cd34..."
  }
}

The typed reference authorization cites the authorization doc by its artifact type and derived identifier. A verifier can confirm the doc was cited by resolving the authorization-doc artifact type's digest context from its governing specification, recomputing "ab12cd34..." from the doc's bytes, and matching.¶

Composability: the verifier needs only the authorization-doc digest context — it does not need to understand the decision-record format to verify the citation binding. For generic citation-binding verification, a CPB verifier can process a typed reference to any artifact type whose digest context it can resolve. Whether a particular citation slot permits that artifact type is determined by the consuming profile. Artifact-specific appraisal, authorization semantics, and application integration remain separate.¶

Appendix C. Field-Verified Instances

The instances in this appendix were chosen to illustrate the mechanisms of Section 4, Section 7, and Section 8. They are not a ranking. Two parties appear in every instance: the implementing system and the verification counterparty. The common counterparty in each case is the AAC reference implementation, which is present as a verifier, not as the subject. This is a historical record and is not edited retroactively: the instances below report what ran at the time, under algorithm jcs-n, which is withdrawn as of this revision (Section 4.2). The byte-agreement result each instance reports is a property of applying RFC 8785 JCS consistently, which jcs (Section 4.1) also provides going forward.¶

Owner consent status: Anton Sokolov (Tyche Institute) — confirmed 2026-07-24. Tom Sato (GAR/SOOS) — confirmed 2026-07-25. Tymofii Pidlisnyi (Agent Passport System) — confirmed 2026-07-24 (on-issue).¶

Acknowledgments

The following individuals contributed findings from the IETF 126 hackathon in Vienna that directly shaped the rules in this document. All attributions cite public artifacts.¶

Contributors [all named attributions and contributor acknowledgments individually confirmed: Anton Sokolov (confirmed 2026-07-24), Iman Schrock (confirmed 2026-07-24), Tom Sato (confirmed 2026-07-25), Yong Bok Lee (Scott Lee) (contributor attribution confirmed 2026-07-27), Tymofii Pidlisnyi (Agent Passport System, confirmed 2026-07-24, on-issue), Karthik Rampalli (Glyphzero, confirmed 2026-07-25, email, with corrections)]:¶

• Anton Sokolov (Tyche Institute) — assurance-boundary discipline; the A2A boundary-seal instance in Appendix C.¶

• Yong Bok Lee (Scott Lee), Meridian Verity Group — ORPRG-derived cross-profile digest-context discipline: equal-looking digest text alone is not a valid join; a typed reference is verified by recomputing the referenced artifact under its established digest context and comparing that result with the digest carried in the reference, not with the citing record's own derived identifier. Also contributed the representation-boundary distinction among raw digest bytes, bare lowercase hexadecimal text, and prefixed text, and the verification-scope boundary separating typed-reference content binding from artifact-specific appraisal and authorization. See [I-D.lee-orprg-permit-receipts].¶

• Tymofii Pidlisnyi (Agent Passport System) — the content-derived action reference pattern (NFC + code-point sort + JCS) demonstrating that jcs-n generalizes across canonicalization styles; bidirectional cross-runs with confirmed byte-agreement.¶

• Tom Sato (GAR/SOOS) — the leaf-bytes-not-hex finding documented in Section 7.1: the log leaf hashes the raw bytes of the derived identifier, not the hex-string encoding.¶

• Karthik Rampalli (Glyphzero) — independent JCS implementation byte-agreement on subject_digest 0b4da06b..., demonstrating that RFC 8785 JCS is reproducible across separately written implementations.¶

• Iman Schrock (EMILIA/EP) — confirmed 2026-07-24 — the three-computation single-digest instance (8cf0c36e...) demonstrating byte-agreement across three independent codebases.¶

Acknowledged [Amaury Chamayou confirmed 2026-07-24 (email)]:¶

• Amaury Chamayou (Microsoft) — two-TS single-statement demonstration; the vds-from-protected-header finding subsequently mirrored in microsoft/scitt-ccf-ledger #424.¶

Authors' Addresses