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 | Microsoft 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 | 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 — proving the statement layer really is structure-independent. (The reference verifier scitt-cose implements vds=1; the CCF receipt was cross-checked against a CCF node.)
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 ↗