proofbundle 2.1.0__tar.gz → 3.0.1__tar.gz

{proofbundle-2.1.0/src/proofbundle.egg-info → proofbundle-3.0.1}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: proofbundle
-Version: 2.1.0
+Version: 3.0.1
 Summary: Emit and verify portable cryptographic evidence bundles, offline: Ed25519 + RFC 6962 Merkle + optional SD-JWT.
 Author: Konrad Gruszka
 License: MIT
@@ -75,12 +75,28 @@ Merkle, one file, no server, no network.
 [![DOI](https://zenodo.org/badge/DOI/10.5281/zenodo.21230467.svg)](https://doi.org/10.5281/zenodo.21230467)
 [![Ruff](https://img.shields.io/endpoint?url=https://raw.githubusercontent.com/astral-sh/ruff/main/assets/badge/v2.json)](https://github.com/astral-sh/ruff)
 [![Mutation tested](https://img.shields.io/badge/tests-mutation_gated-D6248A.svg)](https://github.com/b7n0de/proofbundle/blob/main/scripts/mutation_check.py)
-<!-- SLSA / PEP 740 attestation badges follow once the first attested release lands, see RELEASE.md. -->
+[![PyPI attestations](https://img.shields.io/badge/PyPI-PEP_740_attested-D6248A.svg)](https://pypi.org/project/proofbundle/#files)
+[![SLSA provenance](https://img.shields.io/badge/SLSA-build_provenance-D6248A.svg)](https://slsa.dev/spec/v1.0/provenance)
 
 **Reviewing this for adoption?** Start with the 30-minute adversarial audit path: **[docs/REVIEWERS.md](https://github.com/b7n0de/proofbundle/blob/main/docs/REVIEWERS.md)**.
 
 </div>
 
+## Contents
+
+- [60-second try](#60-second-try-offline)
+- [Inspect-native?](#inspect-native-metr-task-standard-uk-aisi-ecosystem)
+- [The problem](#the-problem)
+- [What a receipt proves, and what it doesn't](#what-a-receipt-proves-and-what-it-doesnt)
+- [How it fits together](#how-it-fits-together)
+- [Post-quantum posture](#post-quantum-posture-honest-two-layers)
+- [What's in the box](#whats-in-the-box)
+- [Docs](#docs)
+- [Install](#install)
+- [Status, scope and roadmap](#status-scope-and-roadmap)
+- [Contributing](#contributing)
+- [License](#license)
+
 ## 60-second try (offline)
 
 ```bash
@@ -91,21 +107,9 @@ git clone https://github.com/b7n0de/proofbundle && cd proofbundle
 pip install -e ".[eval,inspect]" && make demo   # or `make full-demo` for log -> receipt -> verify
 ```
 
-## The problem
-
-Every AI eval number you read — a safety benchmark, a capability score, a leaderboard entry — is an
-**unverifiable claim**. You trust the lab. There's no portable way to check, offline, that a result
-was signed by a stated party, hasn't been altered, and covers the samples it claims.
-
-proofbundle is that check. It's a small MIT-licensed Python tool (a compact, auditable trusted core,
-depends only on [`cryptography`](https://cryptography.io)) that turns a result into a signed
-receipt anyone can verify from a single file — and it's honest about the line it does not cross.
-
-## What the demo shows
-
-You'll see an honest receipt verify `=> OK`, then six independent tampers each verify `FAILED`, then
-a swapped sample get caught — all in memory. `proofbundle demo` exits non-zero if any tamper slips through,
-so it's also a self-test. Full walkthrough: **[docs/DEMO.md](https://github.com/b7n0de/proofbundle/blob/main/docs/DEMO.md)**.
+The demo runs entirely in memory: an honest receipt verifies `=> OK`, six independent tampers each
+verify `FAILED`, and a swapped sample gets caught. `proofbundle demo` exits non-zero if any tamper
+slips through, so it doubles as a self-test. Full walkthrough: **[docs/DEMO.md](https://github.com/b7n0de/proofbundle/blob/main/docs/DEMO.md)**.
 
 ```bash
 # verify a real hosted receipt without writing any code:
@@ -120,7 +124,7 @@ proofbundle verify receipt.json        # exit 0 = crypto OK, 1 = crypto/verifica
 proofbundle verify receipt.json --policy trust_policy.json   # POLICY: OK | FAIL (exit 3) | NOT_EVALUATED
 ```
 
-## Inspect-native? (METR Task Standard / UK-AISI ecosystem)
+## Inspect-native? (METR Task Standard, UK-AISI ecosystem)
 
 The receipt layer runs directly on [Inspect AI](https://inspect.aisi.org.uk/) — and the proof is
 reproducible offline in minutes:
@@ -135,7 +139,22 @@ In your own pipeline the end-of-task hook signs every run automatically. Walkthr
 **[docs/INSPECT_HAPPY_PATH.md](https://github.com/b7n0de/proofbundle/blob/main/docs/INSPECT_HAPPY_PATH.md)** · worked example:
 **[examples/inspect_receipt.py](https://github.com/b7n0de/proofbundle/blob/main/examples/inspect_receipt.py)**.
 
-## What a receipt proves — and what it doesn't
+## The problem
+
+Every AI eval number you read — a safety benchmark, a capability score, a leaderboard entry — is an
+**unverifiable claim**. You trust the lab. There's no portable way to check, offline, that a result
+was signed by a stated party, hasn't been altered, and covers the samples it claims.
+
+proofbundle is that check. It's a small MIT-licensed Python tool (a compact, auditable trusted core,
+depends only on [`cryptography`](https://cryptography.io)) that turns a result into a signed
+receipt anyone can verify from a single file — and it's honest about the line it does not cross.
+
+In plain language: a proofbundle receipt is the cash-register receipt of an AI test result. It shows
+who claimed the number and that nobody quietly changed it afterwards. It does not show the test was
+good — the way a cash-register receipt does not show the meal was good — but without a receipt there
+is nothing to check at all.
+
+## What a receipt proves, and what it doesn't
 
 | ✅ It proves | ❌ It does **not** prove |
 |---|---|
@@ -149,6 +168,21 @@ This boundary is the point, not a weakness. A receipt makes a claim **attributab
 and — with pre-registration and per-sample auditing — bounded and spot-checkable**. Full detail:
 **[THREAT_MODEL.md](https://github.com/b7n0de/proofbundle/blob/main/THREAT_MODEL.md)**.
 
+## How it fits together
+
+*(diagram renders on GitHub — [view it there](https://github.com/b7n0de/proofbundle#how-it-fits-together); PyPI shows the source)*
+
+```mermaid
+flowchart LR
+    H["eval harness<br/>inspect_ai · lm-eval · promptfoo · pytest"] --> A["adapter → signed claim<br/>salted commitments · provenance · samples root"]
+    A --> R["receipt<br/>one portable file"]
+    R --> V{{"proofbundle verify — offline"}}
+    V --> C["signature · Merkle inclusion · SD-JWT/KB ·<br/>witness quorum · status list · sample openings"]
+    C --> OK(["CRYPTO: OK / FAILED"])
+    style V fill:#D6248A,stroke:#D6248A,color:#fff
+    style OK fill:#D6248A,stroke:#D6248A,color:#fff
+```
+
 ## Post-quantum posture (honest, two layers)
 
 proofbundle is **not** "quantum-proof" or "quantum-safe" as a whole. It combines two cryptographic layers
@@ -173,28 +207,6 @@ On the witness side, C2SP checkpoints already carry post-quantum **ML-DSA-44** (
 (`proofbundle[pq]`); a post-quantum *payload* signature — crypto-agility for the receipt itself — is on the
 roadmap.
 
-## In plain language
-
-A proofbundle receipt is the cash-register receipt of an AI test result: it shows who claimed the
-number and that nobody quietly changed it afterwards. It does not show the test was good — the way a
-cash-register receipt does not show the meal was good — but without a receipt there is nothing to
-check at all.
-
-## How it fits together
-
-*(diagram renders on GitHub — [view it there](https://github.com/b7n0de/proofbundle#how-it-fits-together); PyPI shows the source)*
-
-```mermaid
-flowchart LR
-    H["eval harness<br/>inspect_ai · lm-eval · promptfoo · pytest"] --> A["adapter → signed claim<br/>salted commitments · provenance · samples root"]
-    A --> R["receipt<br/>one portable file"]
-    R --> V{{"proofbundle verify — offline"}}
-    V --> C["signature · Merkle inclusion · SD-JWT/KB ·<br/>witness quorum · status list · sample openings"]
-    C --> OK(["CRYPTO: OK / FAILED"])
-    style V fill:#D6248A,stroke:#D6248A,color:#fff
-    style OK fill:#D6248A,stroke:#D6248A,color:#fff
-```
-
 ## What's in the box
 
 - **Core** — Ed25519 signature + RFC 6962 / 9162 Merkle inclusion, verified fully offline. Checks a
@@ -202,7 +214,8 @@ flowchart LR
 - **Eval receipts** — a signed claim (`metric ⋈ threshold`, `n`, salted model/dataset commitments,
   assurance level, provenance) from your run. See [EVAL_CLAIM.md](https://github.com/b7n0de/proofbundle/blob/main/EVAL_CLAIM.md).
 - **Selective disclosure** — SD-JWT ([RFC 9901](https://datatracker.ietf.org/doc/rfc9901/)) with Key
-  Binding: prove a threshold while withholding the exact score.
+  Binding: prove a threshold while withholding the exact score. Secure-by-default in 3.0.0 (breaking): an
+  unsigned SD-JWT, or one whose disclosures do not bind this bundle, now fails verification (was warn-only).
 - **Transparency-log interop** — C2SP `tlog-checkpoint` / cosignature / `.tlog-proof`, with
   post-quantum **ML-DSA-44** witness cosignatures. Optional Token-Status-List revocation snapshots.
 - **Per-sample audit** — commit to every sample; an auditor challenges random indices (with a fresh
@@ -218,12 +231,34 @@ flowchart LR
   [docs/INSPECT_HAPPY_PATH.md](https://github.com/b7n0de/proofbundle/blob/main/docs/INSPECT_HAPPY_PATH.md) — run an eval, get a receipt, verify it offline.
 - **External time anchors** *(v2.0 beta, the `[anchors]` extra)* — an optional `anchors[]` layer that
   attaches external evidence of *when* a commitment or receipt existed, from a party the producer does not
-  control. Two built-in types verify offline: **RFC 3161** TSA tokens (against a frozen cert chain) and
-  **OpenTimestamps** Bitcoin proofs (honest pending → confirmed lifecycle). A `register_anchor_type`
+  control. Two built-in types verify offline: **RFC 3161** TSA tokens (against a relying-party-supplied TSA
+  root, see the 3.0.0 trust note below) and **OpenTimestamps** Bitcoin proofs (honest pending → confirmed lifecycle). A `register_anchor_type`
   extension interface lets a third party ship its own fail-closed type; two worked examples ship — a
   first-party **`chia-datalayer/v1`** (offline Merkle inclusion of a canonical root under a published Chia
   DataLayer root) and a third-party **`markovian-provenance/v1`** (a wallet-attributable, Bitcoin-anchored
-  stamp). See [docs/ANCHORS.md](https://github.com/b7n0de/proofbundle/blob/main/docs/ANCHORS.md).
+  stamp). **Since 2.1:** a `verify --require-anchor` relying-party gate (optionally narrowed by
+  `--anchor-type`) turns "no verifying anchor of that type" into a failure layered over the crypto result
+  (exit 3, like `--policy`); a pending anchor does not satisfy it unless `--allow-pending`. Plus RFC 3161
+  hardening — the frozen cert chain is validated at the token's own `gen_time`, with optional `policyOid`
+  pinning. **Breaking in 3.0.0:** an anchor's TRUST now comes only from the relying party — supply a TSA
+  root (`--trusted-tsa-root`) or a Bitcoin block header (`--bitcoin-header`), or the equivalent `anchors`
+  policy keys; the bundle's producer-controlled `frozen` block is evidence, never a trust source, so
+  `--require-anchor` without relying-party trust material is unmet (exit 3). An anchor stays detached from
+  the content root, and the `statement` target is RESERVED for decision receipts.
+  See [docs/ANCHORS.md](https://github.com/b7n0de/proofbundle/blob/main/docs/ANCHORS.md).
+- **Universal content root** *(2.1, `jcs-sha256-v1`, [ADR 0002](https://github.com/b7n0de/proofbundle/blob/main/docs/adr/0002-universal-content-root.md))* — one shared primitive now underlies both the
+  decision-receipt path and the in-toto eval-result / test-result / SVR exports: SHA-256 over the RFC 8785
+  (JCS) canonical bytes of the full pre-signature Statement, so a content root survives counter-signing and
+  key rotation. The algorithm is a versioned id signed inside the payload (`contentRootAlg`, default
+  `jcs-sha256-v1`); a verifier re-serializes with exactly the declared algorithm, never falls back, and an
+  unknown algorithm fails closed. Migration is a compatible evolution, not a cutover: absent `contentRootAlg`
+  ⇒ the historic `legacy-sortkeys-json-v0` mode, so every already-signed 2.0.0 receipt keeps verifying
+  byte-for-byte. This is **not** a completed universal migration — a CLI flag to select the algorithm is still
+  deferred. Independent cross-implementation (MarkovianProtocol) interop is now proven for RFC 8785
+  canonicalization + content-root binding (see `conformance/decision/crossimpl/`); the same corpus additionally
+  verifies a confirmed Bitcoin anchor (block 957504) offline. The external fixture currently reports 12 findings
+  against the enforced `decision-receipt/v0.1` validator — recorded as an expected-fail, not hidden — so full
+  schema conformance awaits a further schema-conformant regeneration.
 - **Decision Receipts** *(2.1, vendored `decision-receipt/v0.1` predicate)* — a separate predicate for agent
   *decisions* (not eval metrics): who decided, the proposed action, the policy boundary, digest-bound evidence,
   the verdict (`ALLOW`/`DENY`/`REFUSE`/`ESCALATE`/`DEFER`/`OBSERVE`), and explicitly what was *not* checked.
@@ -262,7 +297,7 @@ pip install "proofbundle[pq]"           # verify ML-DSA-44 (post-quantum) witnes
 Requires Python 3.10+. The verify path never rolls its own crypto — Ed25519 comes from
 `cryptography`; Merkle hashing is RFC 6962.
 
-## Status & scope
+## Status, scope and roadmap
 
 Beta, SemVer-committed, with a CI test suite behind a mutation gate + property-based parser fuzzing. Correctness
 is anchored to external RFC 6962 vectors and a real Rekor proof, not just its own bundles. It is
@@ -270,6 +305,13 @@ is anchored to external RFC 6962 vectors and a real Rekor proof, not just its ow
 by itself — it is the small, offline, standards-native receipt layer between them. Security policy:
 [SECURITY.md](https://github.com/b7n0de/proofbundle/blob/main/SECURITY.md).
 
+**Roadmap (stated honestly, all forward-looking):**
+
+- A post-quantum *payload* signature (crypto-agility for the receipt itself) is on the roadmap; today the
+  post-quantum coverage is witness-side ML-DSA-44 cosignatures only.
+- A CLI flag to select the content-root algorithm is still deferred (`jcs-sha256-v1` is the signed default).
+- **Preview:** a TEE-attestation bridge — see [docs/EXPERIMENTAL_ENCLAVE.md](https://github.com/b7n0de/proofbundle/blob/main/docs/EXPERIMENTAL_ENCLAVE.md).
+
 ## Contributing
 
 See [CONTRIBUTING.md](https://github.com/b7n0de/proofbundle/blob/main/CONTRIBUTING.md) and the [Code of Conduct](https://github.com/b7n0de/proofbundle/blob/main/CODE_OF_CONDUCT.md). Good first

{proofbundle-2.1.0 → proofbundle-3.0.1}/README.md

@@ -21,12 +21,28 @@ Merkle, one file, no server, no network.
 [![DOI](https://zenodo.org/badge/DOI/10.5281/zenodo.21230467.svg)](https://doi.org/10.5281/zenodo.21230467)
 [![Ruff](https://img.shields.io/endpoint?url=https://raw.githubusercontent.com/astral-sh/ruff/main/assets/badge/v2.json)](https://github.com/astral-sh/ruff)
 [![Mutation tested](https://img.shields.io/badge/tests-mutation_gated-D6248A.svg)](https://github.com/b7n0de/proofbundle/blob/main/scripts/mutation_check.py)
-<!-- SLSA / PEP 740 attestation badges follow once the first attested release lands, see RELEASE.md. -->
+[![PyPI attestations](https://img.shields.io/badge/PyPI-PEP_740_attested-D6248A.svg)](https://pypi.org/project/proofbundle/#files)
+[![SLSA provenance](https://img.shields.io/badge/SLSA-build_provenance-D6248A.svg)](https://slsa.dev/spec/v1.0/provenance)
 
 **Reviewing this for adoption?** Start with the 30-minute adversarial audit path: **[docs/REVIEWERS.md](https://github.com/b7n0de/proofbundle/blob/main/docs/REVIEWERS.md)**.
 
 </div>
 
+## Contents
+
+- [60-second try](#60-second-try-offline)
+- [Inspect-native?](#inspect-native-metr-task-standard-uk-aisi-ecosystem)
+- [The problem](#the-problem)
+- [What a receipt proves, and what it doesn't](#what-a-receipt-proves-and-what-it-doesnt)
+- [How it fits together](#how-it-fits-together)
+- [Post-quantum posture](#post-quantum-posture-honest-two-layers)
+- [What's in the box](#whats-in-the-box)
+- [Docs](#docs)
+- [Install](#install)
+- [Status, scope and roadmap](#status-scope-and-roadmap)
+- [Contributing](#contributing)
+- [License](#license)
+
 ## 60-second try (offline)
 
 ```bash
@@ -37,21 +53,9 @@ git clone https://github.com/b7n0de/proofbundle && cd proofbundle
 pip install -e ".[eval,inspect]" && make demo   # or `make full-demo` for log -> receipt -> verify
 ```
 
-## The problem
-
-Every AI eval number you read — a safety benchmark, a capability score, a leaderboard entry — is an
-**unverifiable claim**. You trust the lab. There's no portable way to check, offline, that a result
-was signed by a stated party, hasn't been altered, and covers the samples it claims.
-
-proofbundle is that check. It's a small MIT-licensed Python tool (a compact, auditable trusted core,
-depends only on [`cryptography`](https://cryptography.io)) that turns a result into a signed
-receipt anyone can verify from a single file — and it's honest about the line it does not cross.
-
-## What the demo shows
-
-You'll see an honest receipt verify `=> OK`, then six independent tampers each verify `FAILED`, then
-a swapped sample get caught — all in memory. `proofbundle demo` exits non-zero if any tamper slips through,
-so it's also a self-test. Full walkthrough: **[docs/DEMO.md](https://github.com/b7n0de/proofbundle/blob/main/docs/DEMO.md)**.
+The demo runs entirely in memory: an honest receipt verifies `=> OK`, six independent tampers each
+verify `FAILED`, and a swapped sample gets caught. `proofbundle demo` exits non-zero if any tamper
+slips through, so it doubles as a self-test. Full walkthrough: **[docs/DEMO.md](https://github.com/b7n0de/proofbundle/blob/main/docs/DEMO.md)**.
 
 ```bash
 # verify a real hosted receipt without writing any code:
@@ -66,7 +70,7 @@ proofbundle verify receipt.json        # exit 0 = crypto OK, 1 = crypto/verifica
 proofbundle verify receipt.json --policy trust_policy.json   # POLICY: OK | FAIL (exit 3) | NOT_EVALUATED
 ```
 
-## Inspect-native? (METR Task Standard / UK-AISI ecosystem)
+## Inspect-native? (METR Task Standard, UK-AISI ecosystem)
 
 The receipt layer runs directly on [Inspect AI](https://inspect.aisi.org.uk/) — and the proof is
 reproducible offline in minutes:
@@ -81,7 +85,22 @@ In your own pipeline the end-of-task hook signs every run automatically. Walkthr
 **[docs/INSPECT_HAPPY_PATH.md](https://github.com/b7n0de/proofbundle/blob/main/docs/INSPECT_HAPPY_PATH.md)** · worked example:
 **[examples/inspect_receipt.py](https://github.com/b7n0de/proofbundle/blob/main/examples/inspect_receipt.py)**.
 
-## What a receipt proves — and what it doesn't
+## The problem
+
+Every AI eval number you read — a safety benchmark, a capability score, a leaderboard entry — is an
+**unverifiable claim**. You trust the lab. There's no portable way to check, offline, that a result
+was signed by a stated party, hasn't been altered, and covers the samples it claims.
+
+proofbundle is that check. It's a small MIT-licensed Python tool (a compact, auditable trusted core,
+depends only on [`cryptography`](https://cryptography.io)) that turns a result into a signed
+receipt anyone can verify from a single file — and it's honest about the line it does not cross.
+
+In plain language: a proofbundle receipt is the cash-register receipt of an AI test result. It shows
+who claimed the number and that nobody quietly changed it afterwards. It does not show the test was
+good — the way a cash-register receipt does not show the meal was good — but without a receipt there
+is nothing to check at all.
+
+## What a receipt proves, and what it doesn't
 
 | ✅ It proves | ❌ It does **not** prove |
 |---|---|
@@ -95,6 +114,21 @@ This boundary is the point, not a weakness. A receipt makes a claim **attributab
 and — with pre-registration and per-sample auditing — bounded and spot-checkable**. Full detail:
 **[THREAT_MODEL.md](https://github.com/b7n0de/proofbundle/blob/main/THREAT_MODEL.md)**.
 
+## How it fits together
+
+*(diagram renders on GitHub — [view it there](https://github.com/b7n0de/proofbundle#how-it-fits-together); PyPI shows the source)*
+
+```mermaid
+flowchart LR
+    H["eval harness<br/>inspect_ai · lm-eval · promptfoo · pytest"] --> A["adapter → signed claim<br/>salted commitments · provenance · samples root"]
+    A --> R["receipt<br/>one portable file"]
+    R --> V{{"proofbundle verify — offline"}}
+    V --> C["signature · Merkle inclusion · SD-JWT/KB ·<br/>witness quorum · status list · sample openings"]
+    C --> OK(["CRYPTO: OK / FAILED"])
+    style V fill:#D6248A,stroke:#D6248A,color:#fff
+    style OK fill:#D6248A,stroke:#D6248A,color:#fff
+```
+
 ## Post-quantum posture (honest, two layers)
 
 proofbundle is **not** "quantum-proof" or "quantum-safe" as a whole. It combines two cryptographic layers
@@ -119,28 +153,6 @@ On the witness side, C2SP checkpoints already carry post-quantum **ML-DSA-44** (
 (`proofbundle[pq]`); a post-quantum *payload* signature — crypto-agility for the receipt itself — is on the
 roadmap.
 
-## In plain language
-
-A proofbundle receipt is the cash-register receipt of an AI test result: it shows who claimed the
-number and that nobody quietly changed it afterwards. It does not show the test was good — the way a
-cash-register receipt does not show the meal was good — but without a receipt there is nothing to
-check at all.
-
-## How it fits together
-
-*(diagram renders on GitHub — [view it there](https://github.com/b7n0de/proofbundle#how-it-fits-together); PyPI shows the source)*
-
-```mermaid
-flowchart LR
-    H["eval harness<br/>inspect_ai · lm-eval · promptfoo · pytest"] --> A["adapter → signed claim<br/>salted commitments · provenance · samples root"]
-    A --> R["receipt<br/>one portable file"]
-    R --> V{{"proofbundle verify — offline"}}
-    V --> C["signature · Merkle inclusion · SD-JWT/KB ·<br/>witness quorum · status list · sample openings"]
-    C --> OK(["CRYPTO: OK / FAILED"])
-    style V fill:#D6248A,stroke:#D6248A,color:#fff
-    style OK fill:#D6248A,stroke:#D6248A,color:#fff
-```
-
 ## What's in the box
 
 - **Core** — Ed25519 signature + RFC 6962 / 9162 Merkle inclusion, verified fully offline. Checks a
@@ -148,7 +160,8 @@ flowchart LR
 - **Eval receipts** — a signed claim (`metric ⋈ threshold`, `n`, salted model/dataset commitments,
   assurance level, provenance) from your run. See [EVAL_CLAIM.md](https://github.com/b7n0de/proofbundle/blob/main/EVAL_CLAIM.md).
 - **Selective disclosure** — SD-JWT ([RFC 9901](https://datatracker.ietf.org/doc/rfc9901/)) with Key
-  Binding: prove a threshold while withholding the exact score.
+  Binding: prove a threshold while withholding the exact score. Secure-by-default in 3.0.0 (breaking): an
+  unsigned SD-JWT, or one whose disclosures do not bind this bundle, now fails verification (was warn-only).
 - **Transparency-log interop** — C2SP `tlog-checkpoint` / cosignature / `.tlog-proof`, with
   post-quantum **ML-DSA-44** witness cosignatures. Optional Token-Status-List revocation snapshots.
 - **Per-sample audit** — commit to every sample; an auditor challenges random indices (with a fresh
@@ -164,12 +177,34 @@ flowchart LR
   [docs/INSPECT_HAPPY_PATH.md](https://github.com/b7n0de/proofbundle/blob/main/docs/INSPECT_HAPPY_PATH.md) — run an eval, get a receipt, verify it offline.
 - **External time anchors** *(v2.0 beta, the `[anchors]` extra)* — an optional `anchors[]` layer that
   attaches external evidence of *when* a commitment or receipt existed, from a party the producer does not
-  control. Two built-in types verify offline: **RFC 3161** TSA tokens (against a frozen cert chain) and
-  **OpenTimestamps** Bitcoin proofs (honest pending → confirmed lifecycle). A `register_anchor_type`
+  control. Two built-in types verify offline: **RFC 3161** TSA tokens (against a relying-party-supplied TSA
+  root, see the 3.0.0 trust note below) and **OpenTimestamps** Bitcoin proofs (honest pending → confirmed lifecycle). A `register_anchor_type`
   extension interface lets a third party ship its own fail-closed type; two worked examples ship — a
   first-party **`chia-datalayer/v1`** (offline Merkle inclusion of a canonical root under a published Chia
   DataLayer root) and a third-party **`markovian-provenance/v1`** (a wallet-attributable, Bitcoin-anchored
-  stamp). See [docs/ANCHORS.md](https://github.com/b7n0de/proofbundle/blob/main/docs/ANCHORS.md).
+  stamp). **Since 2.1:** a `verify --require-anchor` relying-party gate (optionally narrowed by
+  `--anchor-type`) turns "no verifying anchor of that type" into a failure layered over the crypto result
+  (exit 3, like `--policy`); a pending anchor does not satisfy it unless `--allow-pending`. Plus RFC 3161
+  hardening — the frozen cert chain is validated at the token's own `gen_time`, with optional `policyOid`
+  pinning. **Breaking in 3.0.0:** an anchor's TRUST now comes only from the relying party — supply a TSA
+  root (`--trusted-tsa-root`) or a Bitcoin block header (`--bitcoin-header`), or the equivalent `anchors`
+  policy keys; the bundle's producer-controlled `frozen` block is evidence, never a trust source, so
+  `--require-anchor` without relying-party trust material is unmet (exit 3). An anchor stays detached from
+  the content root, and the `statement` target is RESERVED for decision receipts.
+  See [docs/ANCHORS.md](https://github.com/b7n0de/proofbundle/blob/main/docs/ANCHORS.md).
+- **Universal content root** *(2.1, `jcs-sha256-v1`, [ADR 0002](https://github.com/b7n0de/proofbundle/blob/main/docs/adr/0002-universal-content-root.md))* — one shared primitive now underlies both the
+  decision-receipt path and the in-toto eval-result / test-result / SVR exports: SHA-256 over the RFC 8785
+  (JCS) canonical bytes of the full pre-signature Statement, so a content root survives counter-signing and
+  key rotation. The algorithm is a versioned id signed inside the payload (`contentRootAlg`, default
+  `jcs-sha256-v1`); a verifier re-serializes with exactly the declared algorithm, never falls back, and an
+  unknown algorithm fails closed. Migration is a compatible evolution, not a cutover: absent `contentRootAlg`
+  ⇒ the historic `legacy-sortkeys-json-v0` mode, so every already-signed 2.0.0 receipt keeps verifying
+  byte-for-byte. This is **not** a completed universal migration — a CLI flag to select the algorithm is still
+  deferred. Independent cross-implementation (MarkovianProtocol) interop is now proven for RFC 8785
+  canonicalization + content-root binding (see `conformance/decision/crossimpl/`); the same corpus additionally
+  verifies a confirmed Bitcoin anchor (block 957504) offline. The external fixture currently reports 12 findings
+  against the enforced `decision-receipt/v0.1` validator — recorded as an expected-fail, not hidden — so full
+  schema conformance awaits a further schema-conformant regeneration.
 - **Decision Receipts** *(2.1, vendored `decision-receipt/v0.1` predicate)* — a separate predicate for agent
   *decisions* (not eval metrics): who decided, the proposed action, the policy boundary, digest-bound evidence,
   the verdict (`ALLOW`/`DENY`/`REFUSE`/`ESCALATE`/`DEFER`/`OBSERVE`), and explicitly what was *not* checked.
@@ -208,7 +243,7 @@ pip install "proofbundle[pq]"           # verify ML-DSA-44 (post-quantum) witnes
 Requires Python 3.10+. The verify path never rolls its own crypto — Ed25519 comes from
 `cryptography`; Merkle hashing is RFC 6962.
 
-## Status & scope
+## Status, scope and roadmap
 
 Beta, SemVer-committed, with a CI test suite behind a mutation gate + property-based parser fuzzing. Correctness
 is anchored to external RFC 6962 vectors and a real Rekor proof, not just its own bundles. It is
@@ -216,6 +251,13 @@ is anchored to external RFC 6962 vectors and a real Rekor proof, not just its ow
 by itself — it is the small, offline, standards-native receipt layer between them. Security policy:
 [SECURITY.md](https://github.com/b7n0de/proofbundle/blob/main/SECURITY.md).
 
+**Roadmap (stated honestly, all forward-looking):**
+
+- A post-quantum *payload* signature (crypto-agility for the receipt itself) is on the roadmap; today the
+  post-quantum coverage is witness-side ML-DSA-44 cosignatures only.
+- A CLI flag to select the content-root algorithm is still deferred (`jcs-sha256-v1` is the signed default).
+- **Preview:** a TEE-attestation bridge — see [docs/EXPERIMENTAL_ENCLAVE.md](https://github.com/b7n0de/proofbundle/blob/main/docs/EXPERIMENTAL_ENCLAVE.md).
+
 ## Contributing
 
 See [CONTRIBUTING.md](https://github.com/b7n0de/proofbundle/blob/main/CONTRIBUTING.md) and the [Code of Conduct](https://github.com/b7n0de/proofbundle/blob/main/CODE_OF_CONDUCT.md). Good first

{proofbundle-2.1.0 → proofbundle-3.0.1}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "setuptools.build_meta"
 
 [project]
 name = "proofbundle"
-version = "2.1.0"
+version = "3.0.1"
 description = "Emit and verify portable cryptographic evidence bundles, offline: Ed25519 + RFC 6962 Merkle + optional SD-JWT."
 readme = "README.md"
 requires-python = ">=3.10"
@@ -22,6 +22,9 @@ keywords = [
     "rfc6962",
 ]
 classifiers = [
+    # Stays Beta until the funded external security review passes (Owner decision E1, 2026-07-12):
+    # "stable is evidenced, not asserted". The move to "5 - Production/Stable" is a separate,
+    # audit-gated milestone (see docs/GRANT_MILESTONES.md), never claimed pre-audit.
     "Development Status :: 4 - Beta",
     "Intended Audience :: Developers",
     "License :: OSI Approved :: MIT License",

{proofbundle-2.1.0 → proofbundle-3.0.1}/src/proofbundle/__init__.py

@@ -13,12 +13,12 @@ from __future__ import annotations
 
 from typing import TYPE_CHECKING
 
-__version__ = "2.1.0"
+__version__ = "3.0.1"
 
 # The `proofbundle/v0.1` normative spec revision this build implements — kept in sync with the
 # `Revision:` line at the top of SPEC.md by tests/test_docs_truth.py (WP-B1, closes #28). Bump
 # both together whenever SPEC.md's normative text changes (not on every package release).
-SPEC_REVISION = "2026-07-10"
+SPEC_REVISION = "2026-07-11"
 
 __all__ = [
     "__version__",

proofbundle-3.0.1/src/proofbundle/_strict_json.py

@@ -0,0 +1,72 @@
+"""Duplicate-key-rejecting JSON parsing — the one strict parser for every verify path (WP-C1).
+
+``json.loads`` silently keeps the LAST occurrence of a duplicated key (last-wins). On a verify
+path that is a classic parser differential (Bishop Fox 2021; the exact bug class behind several
+JWT/JOSE CVEs): two implementations parsing the same bytes can disagree about which ``root_b64``
+or ``sig_b64`` they verified, so "cross-verifier consensus" silently stops meaning one thing.
+RFC 8785 (JCS) forbids duplicate keys outright, and the DSSE statement paths already reject them
+INDIRECTLY (a duplicated payload cannot be byte-equal to its own canonical re-serialization) —
+but the native bundle path accepted them silently, and an explicit reject with a clear message
+beats an incidental byte-mismatch everywhere.
+
+Converted paths: the native bundle (``load_bundle``, the HF ``pb1.`` token), the DSSE statement
+verifiers (eval-result / test-result / SVR / decision), the trust-policy loader, the per-sample
+disclosure record, the chia-datalayer and markovian anchor envelopes, the status-list token, the
+enclave EAT, and every ``json.load`` in the CLI. Emit-side inputs (a claim/predicate file the
+caller authored) use it too — a duplicate key in something about to be signed is at best an
+authoring bug, at worst an attempted differential.
+
+Resolved 2026-07-12 (F12, release-audit): the SD-JWT/KB-JWT payload sites in ``sdjwt.py`` /
+``kbjwt.py``, ``bundle._issuer_requires_holder_binding``, ``sdjwt_issue._jwt_payload`` and
+``evalclaim.sd_jwt_hidden_count`` now parse with ``loads_strict`` too, each routed fail-closed —
+a duplicate ``cnf`` is rejected, and ``_issuer_requires_holder_binding`` returns True on a duplicate
+(binding REQUIRED), never the inverted "no holder binding required". Keys that differ only by Unicode normalization
+(NFC/NFD) or a BOM are DISTINCT JSON keys by spec and stay distinct here — normalization games are
+a downstream concern of the field validators, not of the parser.
+
+Stdlib-only (``object_pairs_hook``), so the base install keeps rejecting duplicates without any
+extra. The hook fires for every nested object (including objects inside arrays), so duplicates are
+rejected at ANY depth.
+"""
+from __future__ import annotations
+
+import json
+from typing import Any, Union
+
+from .errors import BundleFormatError
+
+__all__ = ["loads_strict"]
+
+
+def _reject_duplicate_keys(pairs: list) -> dict:
+    obj: dict = {}
+    for key, value in pairs:
+        if key in obj:
+            raise BundleFormatError(
+                f"duplicate JSON key {key!r} — rejected fail-closed (a duplicated key parses "
+                "differently across JSON implementations; parser-differential guard, WP-C1)")
+        obj[key] = value
+    return obj
+
+
+def loads_strict(text: Union[str, bytes]) -> Any:
+    """``json.loads`` that rejects duplicate object keys at any nesting depth.
+
+    Raises :class:`BundleFormatError` for a duplicate key (fail-closed, clear message), maps
+    ``RecursionError`` from pathologically deep nesting to the same documented malformed-input
+    error, and maps the ``int``/``str`` conversion-limit ``ValueError`` from a JSON integer literal
+    with more than ``sys.get_int_max_str_digits()`` digits (CWE-674 / CVE-2020-10735) to it too —
+    never a raw traceback — mirroring :func:`proofbundle.bundle.load_bundle`. Ordinary JSON syntax
+    errors keep raising ``ValueError`` (``json.JSONDecodeError``) so existing ``except (ValueError,
+    ...)`` handling at the call sites stays correct."""
+    try:
+        return json.loads(text, object_pairs_hook=_reject_duplicate_keys)
+    except RecursionError as exc:
+        raise BundleFormatError("JSON nesting is too deep") from exc
+    except ValueError as exc:
+        # The int<->str conversion cap raises a plain ValueError DURING parsing (not a JSONDecodeError),
+        # which a pre-auth caller without a broad `except ValueError` would surface as a raw traceback.
+        # Map only that specific case; a normal JSONDecodeError keeps raising ValueError as documented.
+        if "integer string conversion" in str(exc):
+            raise BundleFormatError("JSON integer literal is implausibly long (fail-closed)") from exc
+        raise

{proofbundle-2.1.0 → proofbundle-3.0.1}/src/proofbundle/adapters/eee.py

@@ -22,10 +22,12 @@ has_unknown_level == true means Unknown and is rejected (not silently mapped to
 from __future__ import annotations
 
 import json
+import re
 from pathlib import Path
 from typing import Optional, Union
 
 from ..evalclaim import build_eval_claim
+from ._provenance import add_provenance
 
 _SCHEMA_PATH = Path(__file__).resolve().parent.parent / "eee_eval_schema.json"
 _SCHEMA_VERSION = "0.2.2"
@@ -95,6 +97,65 @@ def _extract_score(score_details: dict, metric_config: dict) -> str:
     return _num_to_decimal_str(raw)
 
 
+def _model_id_stripped(record: dict) -> dict:
+    """A deep copy of the EEE record with the cleartext model identity removed (WP-I3 privacy fix).
+    Removes ``model_info.id`` and the id-bearing top-level fields (``evaluation_id`` which embeds the
+    id, and ``evaluation_result_id``) so a digest over the result cannot be used as a model-id
+    confirmation / enumeration oracle, while still binding every score, timestamp, dataset and metric
+    for tamper-evidence.
+
+    M2 (6-lens review 2026-07-11): ``evaluation_result_id`` was left IN the digest record while the
+    run_id provenance path already `_leaks_model_id`-guards it — an asymmetry that kept the digest a
+    model-id oracle (the id can correlate to / embed the model). It is a provenance identifier, not a
+    scored/content field, so stripping it from the DIGEST removes the oracle without weakening the
+    tamper-evidence over the actual result content (it stays available for run_id provenance, which
+    applies its own leak guard)."""
+    import copy  # noqa: PLC0415
+    r = copy.deepcopy(record)
+    if isinstance(r.get("model_info"), dict):
+        r["model_info"].pop("id", None)
+    r.pop("evaluation_id", None)          # format eval_name/model_id/timestamp — embeds the id
+    # M2: strip the per-result ``evaluation_result_id`` (nested in each ``evaluation_results[*]``) —
+    # it is a provenance id that can embed/correlate the model id (a digest over it is an oracle).
+    for er in r.get("evaluation_results", []) or []:
+        if isinstance(er, dict):
+            er.pop("evaluation_result_id", None)
+    return r
+
+
+def _record_digest(record: dict) -> str:
+    """``"<alg>:<hex>"`` over the canonical EEE record JSON with the cleartext model identity removed
+    (WP-I3; six-lens review: an UNSALTED digest over a record embedding ``model_info.id`` is a model
+    confirmation/enumeration oracle, so it is stripped first — the digest still binds scores,
+    timestamps, dataset and metrics for tamper-evidence). JCS when the ``[eval]`` extra is present,
+    else a labeled deterministic sort_keys fallback (the label tells a verifier which normalization
+    produced the hex, never a silent difference)."""
+    import hashlib  # noqa: PLC0415
+    stripped = _model_id_stripped(record)
+    try:
+        import rfc8785  # noqa: PLC0415
+        return "sha256-jcs:" + hashlib.sha256(rfc8785.dumps(stripped)).hexdigest()
+    except (ImportError, ValueError, TypeError):
+        canonical = json.dumps(stripped, sort_keys=True, separators=(",", ":"),
+                               ensure_ascii=False).encode("utf-8")
+        return "sha256-sortkeys:" + hashlib.sha256(canonical).hexdigest()
+
+
+def _leaks_model_id(text: str, model_id: str) -> bool:
+    """True iff ``text`` contains the model id or any of its name components (WP-I3 privacy, six-lens
+    review). Case-insensitive; checks the full ``org/name`` id, the bare name after the last '/',
+    and slug variants where '-', '_' and '.' are unified — so 'arc/gpt2/run1' is caught for a model
+    id whose bare name is 'gpt2'."""
+    hay = text.lower()
+    hay_norm = re.sub(r"[-_.]+", "", hay)
+    tokens = {model_id.lower()}
+    bare = model_id.split("/")[-1].lower()
+    if bare:
+        tokens.add(bare)
+        tokens.add(re.sub(r"[-_.]+", "", bare))   # slug-normalized ('gpt-2' -> 'gpt2')
+    return any(t and (t in hay or t in hay_norm) for t in tokens)
+
+
 def from_eee_dataset(source: Union[str, Path, dict], *, comparator: str, threshold: str,
                      timestamp: Optional[str] = None, eval_index: int = 0, metric_name: Optional[str] = None,
                      model_salt: Optional[bytes] = None, dataset_salt: Optional[bytes] = None,
@@ -149,6 +210,20 @@ def from_eee_dataset(source: Union[str, Path, dict], *, comparator: str, thresho
         raise EEEAdapterError("no timestamp: pass timestamp= or set retrieved_timestamp/evaluation_timestamp")
 
     provenance = {"source": "every_eval_ever", "eee_schema_version": record.get("schema_version") or _SCHEMA_VERSION}
+    # WP-I3: bind the receipt to the EXACT source record — the only adapter without a provenance
+    # binding. sha256 over the RFC-8785 (JCS) canonical record JSON with the cleartext model identity
+    # stripped first (see _record_digest — the digest binds scores/timestamps/dataset for
+    # tamper-evidence but is not a model-id oracle). Same "<alg>:<hex>" label scheme as
+    # adapters/_provenance.config_hash, but note it uses NO domain-separation tag (the label
+    # distinguishes it); it is provenance metadata, never a security commitment.
+    provenance["eee_record_sha256"] = _record_digest(record)
+    # the RESULT-level id is traceability metadata; the TOP-level evaluation_id embeds the model id
+    # in cleartext and stays deliberately excluded. Guard the result id: drop it if ANY model-name
+    # component appears (six-lens review: the exact full-repo-id substring test missed the bare
+    # name and slug variants — 'arc/gpt2/run1' leaked 'gpt2'). Case-insensitive over a token set.
+    _rid = chosen.get("evaluation_result_id")
+    if isinstance(_rid, str) and _rid and not _leaks_model_id(_rid, str(model_id)):
+        add_provenance(provenance, run_id=_rid)
     if eval_library.get("name"):
         provenance["harness"] = str(eval_library["name"])
     if eval_library.get("version"):