Repository navigation
TR-ANC-002 can earn Level 2 without binding receipt root/count to the transparency-named entry #464
Description
Continued from trace-tests agentrust-io/trace-spec#547 as part of repository consolidation. Original author: @solloek369-arch. The original discussion and maintainer decisions remain in that linked issue; this migration does not resolve the conformance question. Implementation coordination also remains in trace-registry agentrust-io/trace-tests#102 and trace-spec #280.
Lineage: trace-tests agentrust-io/trace-tests#70 → trace-tests agentrust-io/trace-tests#79 → caller root/count ↔ transparency-named entry binding
What TR-ANC-002 checks today
At the exact unreleased main snapshots below, TR-ANC-002
replays an inclusion proof against merkle_root and leaf_count supplied in
the caller receipt.
It does not establish that those values belong to the registry entry named by
the transparency URI in the signed record. A receipt can therefore be
internally consistent and still earn Level 2 without that authority relation
having been established.
What the Anchor Format says
The Anchor Format
identifies the registry entry through the record's transparency URI. The
question here is whether a Level-2 verdict must also establish that the caller
receipt's root and count describe that identified entry.
Decisive controls
| World | Suite result | Independent paired-entry check |
|---|---|---|
| Matching sealed paired entry | ✅ Level 2 | ✅ established |
| Wrong caller root | ❌ refused | — |
| Only paired-entry root changed | ✅ Level 2 | ❌ not established |
| Only paired-entry count changed | ✅ Level 2 | ❌ not established |
The Merkle check is load-bearing: a wrong caller root is refused. The narrower
gap is that changing only the separately retained paired entry's root or count
leaves the suite at Level 2 while the independent check reports the binding not
established.
Decision requested
Is binding of the caller receipt's merkle_root and leaf_count to the
registry entry named by transparency part of what a Level-2 verdict must
establish?
No upstream API or network-resolution design is proposed here.
Currentness and scope
Currentness checked: 2026-09-02T10:31:53Z — the trace-tests and
trace-spec default branches matched these exact unreleased pins at that time:
trace-tests:98c34c7b62f55886ba170609f268645994ba8c1ftrace-spec:98aae176aa9ae4053d944624dad7629c76789ff7
Replay if TR-ANC-002 or the Anchor Format entry-binding relation changes.
This does not claim released impact, registry compromise, remote
exploitability, severity, production prevalence, downstream authorization, or
a prescribed upstream API.
Evidence
An unsigned self-verifying local packet, including paired worlds and replay
receipts, is available on request:
d32607ee1f272c8c16f39e44b323e0bd85cd7e897dc3e330a6b5807670318410
Activity
imran-siddique commentedon Oct 15, 2026
@solloek369-arch yes, required. TR-ANC-002 now needs the registry entry supplied offline. Root or count differing from it is refused, and with no entry Level 2 is not earned. Nothing identifies an entry from the
transparencyURI yet, so a pass says that link was not checked; it stays with #448 finding 21. Until then this replaces my 09-23 line on trace-tests#92.This redefines a conformance level, so under GOVERNANCE.md this comment opens the 30-day comment period, closing no earlier than 2026-11-14. What breaks: a Level 2 result from a receipt alone. What implementers do: keep the registry entry with the record and pass it with
--entry. Record, receipt and entry shapes do not change.Your four worlds and the absent entry are tests in #533.
spec(anchor)!: a Level 2 anchor verdict requires the registry entry (#…
philippecyberian commentedon Oct 27, 2026
Reading this from the standpoint of an integrator. We operate a registry of independent verification receipts, produced by a verifier that did not execute the workload, and we plan to anchor its roots into the TRACE registry, so the new precondition for a Level 2 (transparency-anchored) verdict in #533 touches us directly. Two questions, neither an objection.
External registries and mirrors. Under spec(anchor)!: a Level 2 anchor verdict requires the registry entry #533 the verdict requires the registry entry itself, with root and count matching. For a record anchored through a second registry (a mirror of the reference registry, or an external registry that in turn anchors into it), what is the intended path to a Level 2 verdict: must the verifier hold the reference registry's own entry, or can a chain of entries satisfy the requirement, and if so where would that chain be specified (Registry Anchor Format section 6, or a profile)?
The anchoring pipeline after the handover. The maintainer handover notes leave the operator of the registry anchoring pipeline and the holder of the agentrust-io.com domain to be decided. Since a Level 2 verdict now depends on an entry that only that pipeline produces, is there a plan for who operates it, and are entries expected to remain obtainable offline for records anchored before any change of operator?
Thanks for the explicit comment period; I read the close date as no earlier than 14 November per the comment above.
Philippe Laporte, Cyberian Systems
solloek369-arch commentedon Oct 29, 2026
@philippecyberian thanks for raising these. Your questions connect directly to some forgotten earlier work and what I was testing in #92/#464.
#533 merged on 22 October and now binds the receipt to the supplied registry entry. That's an important improvement.
But §6 still doesn't establish that this is the entry identified by the signed
transparencyURI. A TR-ANC-002 PASS alone is not a complete Level 2 verdict.Finding 21 in #448 also documents the circularity in the published direct anchoring flow: the signed record must identify an entry that does not yet exist when the record is signed.
For your external-registry case, wouldn't it make sense to establish a reproducible, non-circular single-registry Level 2 path first? Then we can define what each additional registry hop actually proves, without silently inheriting assurance.
On continuity, §4 already requires public retrieval without operator credentials. Independent mirrors help preserve historical evidence, but don't automatically confer authority to issue new anchors. I'd welcome the maintainers' view on pipeline and signing-key succession.
Thanks for bringing the integrator perspective into this.