Skip to content

Proof bundle format

A proof bundle is one JSON file with the evidence that an ISCC-ID is in its hub's log. It is the authoritative way to check an ISCC-ID. A client verifies it on its own, without trusting the monitor.

Get it from GET /inclusion/<iscc_id>.bundle, or with the "Download proof bundle" button on a certificate. Verify a proof bundle shows how to check one. Example: MEIGKV5N6NTVF4AB.bundle.json.

Members

iscc_id
The ISCC-ID, in its canonical ISCC: form.
hub
The hub whose log has the record: its domain and its did:web identifier did. The hub publishes its key at https://<domain>/.well-known/did.json.
checkpoint
The latest checkpoint the monitor accepted for the hub, as the hub signed it. It is a signed note: the log's origin, size and base64 Merkle root, then a blank line and the signature line.
inclusion

The inclusion proof of the record against checkpoint, in the hub's IsccLogInclusionProof shape:

Member Content
type "IsccLogInclusionProof"
checkpoint The same signed checkpoint
treeSize The checkpoint's size
leafIndex The record's position in the log, counted from 0
inclusionProof The RFC 6962 sibling hashes, base64, from the leaf upward
record
The record exactly as the hub logged it, base64-encoded. Its RFC 6962 leaf hash is the SHA-256 of a zero byte followed by these bytes.
key
The key that signed checkpoint. id is its 4-byte signed-note key hash in hex. multibase is the Ed25519 public key as the hub's did:web document lists it (publicKeyMultibase).
anchor (optional)

Present when a confirmed Bitcoin anchor covers the record. It has the evidence for the earliest such anchor.

Member Content
checkpoint The hub-signed checkpoint at the anchored size
inclusion The record's inclusion proof against that checkpoint
key The key that signed that checkpoint
ots The OpenTimestamps proof of that checkpoint's root, base64

How the parts fit

  1. Hash record to a leaf. inclusion.inclusionProof rebuilds the root of a tree of treeSize from that leaf at leafIndex.
  2. The rebuilt root must equal the root in checkpoint.
  3. checkpoint must have a valid signature by key.
  4. key must be in the hub's did:web document. Check this yourself, because the bundle's copy comes from the monitor.
  5. For anchor, repeat steps 1 to 4 with its checkpoint, inclusion and key. Then ots verify -d <root in hex> checks its ots proof against Bitcoin.

No bundle

If the monitor cannot certify an ISCC-ID, the route returns 200 with:

{"error": "no proof bundle available for this id", "iscc_id": "..."}

The monitor offers a bundle only after it has verified the inclusion proof against its accepted root. It never returns a partial bundle.