Verifiable Data Structures: RFC 9162 vs CCF
A verifiable data structure (VDS) is the mechanism a transparency log uses to prove that an entry is included and that the log has only ever grown. A SCITT receipt records which VDS it speaks — and the same signed statement can be carried by more than one.
The VDS field
SCITT receipts carry a vds identifier so a verifier knows how to interpret the proof. Two are implemented here:
| vds=1 — RFC9162_SHA256 | vds=2 — CCF (ccf.v1) | |
|---|---|---|
| Basis | RFC 9162 (Certificate Transparency 2.0) Merkle trees, SHA-256 | CCF (Confidential Consortium Framework) ledger receipts |
| Proof shape | Merkle inclusion path + signed tree head | CCF ledger inclusion proof signed by the service identity |
| Verify with | the log's public key + the leaf digest | the CCF service certificate / identity |
| Published status | RFC 9162 is a published RFC; the SCITT Architecture is RFC 9943 | CCF is an open-source framework; the SCITT mapping is a draft |
Why two?
Different operators run different ledger technologies. The same Agent Action Capsule was registered to both an RFC 9162 log (vds=1) and a real CCF node (vds=2), and both receipts check out — evidence that the statement layer is structure-independent. (The reference verifier scitt-cose verifies both: its Python verify_receipt and its Go verifier accept vds=1 and vds=2; its Rust crate accepts vds=1 only and rejects anything else. The CCF receipt came from a CCF development node, not a production service.)
What stays constant
The signed statement — the capsule itself — does not change between vds=1 and vds=2. Only the receipt differs. That is the whole point of separating the statement layer from the transparency layer.
RFC9162_SHA256 are published in the SCITT working group's examples repository: ietf-wg-scitt/examples.capsule-emit: Going deeper ↗