Hypermedia Security: Transparency Receipt Specification
v1.0.0Hypermedia Au
Transparency Receipt (SCITT Transparent Statement, cross-org non-equivocation)
The transparency receipt as used by CyberBench: an OPTIONAL, cross-org-only referenced artifact. The sovereign default ships NO transparency log — non-equivocation is a guarantee produced only by external mutually-distrusting witnesses, which a single-authority sovereign enclave does not have; a witness-less private log would give log structure without the guarantee. The in-enclave append-only ledger is the git case-repo commit DAG, and independent time is the external RFC 3161 seal token (timestamp-token/v1). When a genuine cross-org matter requires non-equivocation across a trust boundary, a SCITT Transparency Service (RFC 9943) slots in behind the TransparencyLog port and its Receipts (RFC 9942) are referenced — never embedded — from the case record.
Relationships
References
- sovereign-time →Hypermedia Security: Timestamp Token Specification
- target-standard →Hypermedia Security: Evidence Record Specification
Referenced by
- Hypermedia Security: Case Provenance BOM Specification(target-standard)
- Hypermedia Security: Case Provenance BOM Specification(references)
- Hypermedia Security: Evidence Record Specification(references)
About this standard
- artifact-kind
- referenced-artifact (optional; cross-org only; not a BOM)
Sources
- www.rfc-editor.org
- RFC 9943 (June 2026, Standards Track) — SCITT architecture: Signed Statement, Transparency Service, Receipt, Transparent Statement. Ratified from draft-ietf-scitt-architecture
- www.rfc-editor.org
- RFC 9942 (June 2026, Proposed Standard) — COSE Receipts: header parameters receipts (394), vds (395), vdp (396); inclusion and consistency proofs; RFC9162_SHA256 verifiable data structure
- www.rfc-editor.org
- RFC 3161 — the independent-time anchor the sovereign default uses instead of a transparency log
- sec.hypermedia.au
- website
TREC-001 Sovereign Default Ships No Transparency Log MUST NOT
The sovereign default deployment MUST NOT operate a transparency log, and the transparency receipt reference in the case record MUST be empty. A verifier operating under the sovereign profile MUST NOT treat the absence of transparency receipts as non-conformance. An in-enclave private transparency log MUST NOT be presented as providing non-equivocation.
Non-equivocation — the guarantee that no one was shown a different version of the log — is produced only by external mutually-distrusting witnesses. A single-authority sovereign enclave has none, so a private log would add structure without the guarantee. The enclave's append-only ledger is the git case-repo commit DAG; independent time comes from the external RFC 3161 seal token. This requirement exists so the posture is citable: an assessor asking where the transparency log is gets a requirement URI stating the reasoned absence.
- sovereign-ledger
- git-commit-DAG
- sovereign-time
- https://sec.hypermedia.au/standards/timestamp-token/v1
TREC-002 Receipts Are Referenced, Never Embedded MUST NOT
When a transparency receipt exists, the case record MUST carry only a reference to it — service identity, log identifier, entry hash, and the scittProfile marker — via the cyberbench:transparencyReceiptRef property. Receipt bytes MUST NOT be embedded or re-encoded inside any BOM or attestation. BOM shapes MUST be identical whether receipts exist or not.
The receipt is a COSE/CBOR artifact belonging to its own ecosystem; the JSON case record points at it by hash, the same pattern as timestamp tokens and the Evidence Record. Keeping the shapes identical with and without receipts is what makes transparency a slot-in rather than a fork of the record format.
- reference-property
- cyberbench:transparencyReceiptRef
- reference-fields
- servicelogIdentryHashscittProfile
TREC-003 Cross-Org Trigger MUST
Transparency receipts MUST be produced only for a cross-org matter: one where non-equivocation must be demonstrated across a trust boundary between mutually-distrusting organisations. The capability MUST be implemented behind the TransparencyLog port so that enabling it changes configuration, not the record format.
The trigger is a property of the matter, not of the deployment: the same enclave runs sovereign matters with no log and a cross-org matter with a Transparency Service, distinguished only by which TransparencyLog implementation is wired.
- seam
- TransparencyLog-port
TREC-004 Receipt Model MUST
When transparency is wired, each registered seal or custody event MUST follow the SCITT model (RFC 9943): a Signed Statement whose detached payload is the CycloneDX document, identified by hash; registration with a Transparency Service; a Receipt returned as proof of registration. The stored artifact MUST be the Transparent Statement (the Signed Statement with its Receipt attached), verifiable offline by a relying party without a live call to the Transparency Service.
Only hashes and signatures are registered — the BOM payload is detached, so no case content reaches the Transparency Service, preserving the same privacy posture as the TSA relationship. Offline verifiability matters because the relying party in a cross-org matter is by definition outside the enclave.
- payload
- detached (BOM referenced by hash)
- stored-artifact
- Transparent Statement
TREC-005 Specification Basis MUST NOT
Receipts MUST conform to RFC 9943 (SCITT architecture) and RFC 9942 (COSE Receipts: header parameters 394/395/396, inclusion proofs). The scittProfile field of the receipt reference MUST record the profile in use (e.g. rfc9943). Encodings from pre-RFC Internet-Drafts MUST NOT be used or accepted.
Both specifications ratified in June 2026. Earlier CyberBench design material treated SCITT as an unstable draft and marked the seam scittProfile:pending; with the RFCs published, the profile marker now names the ratified specification, and the seam's job becomes recording which profile a receipt conforms to rather than guarding against draft churn.
- specifications
- RFC9943RFC9942
- profile-marker
- scittProfile
TREC-006 Receipt Storage MUST
When transparency is wired, Transparent Statements MUST be stored under Receipts/seals/ (per-seal registrations) and Receipts/events/ (per-event registrations, where used) in the case repository. The Receipts/ tree MUST be absent in the sovereign default. Receipts present at finalisation MUST be included as leaves of the Evidence Record (evidence-record/v1#leaf-completeness).
The receipt tree is the only optional tree in the case repo layout — its very absence is meaningful (sovereign profile) and its presence marks a cross-org matter. Feeding receipts into the Evidence Record puts them under the same renewal protection as every other proof artifact.
- seal-receipts
- Receipts/seals/
- event-receipts
- Receipts/events/
- target-standard
- https://sec.hypermedia.au/standards/evidence-record/v1#leaf-completeness