The reference implementation of the Data Fidelity Register verification procedure (specification §15).
It verifies a published register without trusting the entity, the builder, the signer, or the publisher. It shares no code with any register-producing engine, so agreement between the two is genuine cross-implementation evidence rather than one system agreeing with itself.
Licence: MIT. Run it, read it, fork it, reimplement it.
pip install -r requirements.txtrfc8785 is required. cryptography is required to verify signatures; without it the verifier still checks seals, commitments, file hashes and the release digest, and reports the signature as unchecked.
# a published register
python verify_register.py https://ledger.derappar.at
# a local directory of register files
python verify_register.py ./register/Exit code 0 if every fatal check passes, 1 otherwise.
| Step | Check | On failure |
|---|---|---|
| 2 | Every entry seal recomputes (RFC 8785 over the six sealed fields) | FAIL |
| 3 | The release commitment recomputes (RFC 6962 Merkle root) | FAIL |
| 4 | Every file listed in file_hashes hashes to its listed digest |
FAIL |
| 5 | The release digest recomputes | FAIL |
| 6 | key_id matches the published key, and the signature verifies over the digest |
FAIL |
| 7 | The transparency-log entry commits to the same digest | FAIL |
| 8 | The chain to the prior release | WARN if unretrievable |
| 10 | Freshness | WARN if unestablished |
A single failing entry fails the register. A register is verified as a whole, and partial integrity is not a meaningful assurance.
A WARN means an assurance is absent, not that it has failed. A register with warnings passes its fatal checks but is not reported as fully verified.
A passing verification proves the release is internally consistent, signed and anchored. It does not prove the release is current.
An old release remains permanently valid: its seals verify, its signature verifies, its anchor is genuinely in the log. A publisher wishing to conceal a later disclosure can serve an earlier release, and this verifier will report PASS. No property internal to a single release can detect that.
The verifier therefore always warns that freshness is unestablished. To establish it, query the transparency log for the most recent entry under the signer's key_id and confirm the presented digest is the latest. See specification §15.3.
test_vectors.json carries the conformance vectors of specification §16. An independent implementation is conformant with respect to the primitives if it reproduces every expected value exactly.
It includes the negative cases, which are the ones that catch silent divergence: the string "null" must be rejected rather than sealed; a missing required field must be rejected; the NO_HASH_FOUND sentinel is filtered; the commitment is order-independent; and duplicate seals are not deduplicated, so multiplicity changes the root.
canonical.py— the six-field seal. Calls an RFC 8785 library directly, so the reference code is the canonicalisation standard rather than an approximation of it.merkle.py— the RFC 6962 release commitment. No duplicate-last-node step, which closes the CVE-2012-2459 ambiguity.release_digest.py— the signed structure binding the entity, both commitments, the timestamp, the row count and the file hashes.verify_register.py— the verification procedure and its error model.