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
- hyper-spec:artifactKind
- 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 no transparency receipt reference is present in the case record. 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 a reference to it as an entry in externalReferences with type 'attestation', marked hyper-spec:role = transparencyReceiptRef. The reference MUST address the Transparency Service and log in its url, MUST carry the registration entry hash in hashes[] as a labelled digest, and MUST carry hyper-spec:logId and hyper-spec:scittProfile as properties. Receipt bytes MUST NOT be embedded or re-encoded inside any BOM or attestation. In the sovereign default no such reference is present, and its absence MUST NOT be treated as non-conformance.
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. Each fact the reference carries has its own field: the url addresses the log, the entry hash is a labelled digest beside it, and the log identifier and profile are named properties. Presence or absence of the reference is what distinguishes a cross-org matter from the sovereign default; the document schema is identical either way.
- reference-role
- transparencyReceiptRef
- reference-field
- url
- reference-field
- hashes
- reference-field
- hyper-spec:logId
- reference-field
- hyper-spec:scittProfile
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
- 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
- RFC9943
- specifications
- RFC9942
- 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