Keeping a TRACE record checkable after the 24 hour freshness window: an external pin (working, open to test)

[ogasurfproject-jpg]

Section 3.2.2 has verifiers reject a record older than 24 hours by default, and iat is written by the issuer. Both are right for admission decisions. They leave a gap for anyone who has to answer a question about a run weeks later (an audit, a dispute, an incident review): a conformant verifier will refuse the record, and nothing outside the issuer bounds when it existed.

I run a small public ledger and added a pin for exactly this. It is live and free, and I would like it tested by people who know TRACE better than I do.

POST https://ledger.horizonshield.dev/evidence/trace with {"record": <signed TRACE record>} does four things at intake: checks eat_profile is the v0.2 identifier, that the ten required members are present, that the Ed25519 signature over the RFC 8785 form verifies with the cnf.jwk key, and that iat is not more than 300 seconds ahead of the ledger clock (a postdated record is refused, since the anchor would otherwise seem to confirm a time the issuer chose). It then keeps the exact bytes under the sha256 of their RFC 8785 form and anchors that sha in a daily batch stamped to Bitcoin through OpenTimestamps. Old records are accepted and flagged fresh_at_intake: false, because keeping them checkable is the point.

What a pin does not establish: any claim inside the record, that the key belongs to the subject (compare key_thumbprint, RFC 7638, with a key you trust), revocation status, whether the transparency receipt resolves, or who submitted it.

The tests run against records produced by agentrust-trace 0.11.0 from PyPI, and require the pinned sha to equal Python's RFC 8785 bytes and the thumbprint to equal jwk_thumbprint. Code and tests: https://github.com/ogasurfproject-jpg/horizon-shield/tree/main/workers/hs-ledger/nenrin/trace-pin-v0

Because a pin is only as durable as its copies, the ledger is also rebuilt every day from Software Heritage with the operator's hosts blocked, and the report is published whatever it says. The first run today rebuilt all 66 entries and confirmed every anchor against two block explorers: https://github.com/ogasurfproject-jpg/horizon-shield/tree/main/workers/hs-ledger/nenrin/survive-v0

Two questions for the spec authors, if this is useful:

1. Would an informative note on long-term verifiability (verifying a record past the freshness window against an external time bound) be welcome, and should it point at the transparency member or stand beside it?
2. Is there a shared set of test vectors I should run the intake against beyond the library's own output?

No record from an outside party has been pinned yet. If you issue TRACE records and want to see what a pin looks like for one of yours, I would rather get a finding than a like.

[imran-siddique]

@ogasurfproject-jpg on 1: yes, as an informative docs PR in trace-spec beside the transparency member, since an external time bound is that member's job. Build on replay at a pinned now in docs/verification-outcome-statements.md and the anchors in trace-registry, and keep it implementation-neutral. On 2: run intake against the 33 vectors in trace-tests tests/vectors, which include records it must refuse, such as invalid_missing_runtime.json and the invalid canonical-form cases.

[ogasurfproject-jpg]

@imran-siddique thank you, both done.

On 2, the 33 vectors. The intake now runs against trace-tests tests/vectors with a stated expectation for every file, and all 33 come out as expected (the 60 under trace-spec conformance/tests/vectors as well):

• pinned, signature verified: the four canonicalization/ records, signed_root.json, signed_delegated_hop.json
• refused with the matching reason: invalid_canonical_integer_out_of_range and invalid_canonical_plain_trace (integer range), invalid_canonical_lone_surrogate, invalid_canonical_non_finite_float, invalid_missing_runtime (missing runtime), invalid_wrong_profile
• refused as out of scope, not as wrong: the valid records without an embedded signature (no_embedded_signature, since a pin attests a verified signature) and valid_cmcp_runtime.json (enveloped_form)
• not Trust Records, marked n/a: the policy bundles, resolutions.json and, in the conformance copy, anchor-inclusion/

One change came out of it: a cMCP RuntimeClaim used to be refused as a wrong profile, and is now refused by name. Runner and expectations: https://github.com/ogasurfproject-jpg/horizon-shield/blob/ae5808b6/workers/hs-ledger/nenrin/trace-pin-v0/run_trace_tests_vectors.mjs

On 1, the docs page. agentrust-io/trace-spec#480 adds docs/verifying-after-the-freshness-window.md, informative and implementation-neutral, beside the transparency member: a separate, historical check that replays only the freshness comparison at a time taken from a Registry Anchor Format v1 inclusion check, with the statement it supports and its non-claims. It treats ts as written by the batch producer, which can be the issuer, and leaves revocation to section 3.2.3's entry ordering.

[ogasurfproject-jpg]

@imran-siddique following up now that agentrust-io/trace-spec#480 is in. Three things changed on our side today (commit a3f0a1aa, ledger redeployed), and one small ask at the end.

1. The intake runs against the conformance vectors every night. nenrin-trace-intake-v0 is a corpus of the 28 Trust Records among trace-spec conformance/tests/vectors (at 4c7d6ecc; each vector spliced in byte for byte, Apache-2.0 notice kept), with the expected outcome written per file: the signed and canonicalization records are pinnable, each invalid_* record is refused with the matching reason, unsigned records and the cMCP envelope are out of scope for a pin. Our public board referees four implementations on it nightly, starting tonight: the ledger's production intake module and our JS, Python and Go SDKs (https://github.com/ogasurfproject-jpg/horizon-shield/blob/main/ops/tsunagi/BOARD.md). Policy bundles, the resolution table and anchor-inclusion are not cases.

2. Registered producers. A pinned record whose key thumbprint is listed under trace-registry producers/ is now answered with registered_producer: the producer id and the registry file at a fixed commit (https://ledger.horizonshield.dev/evidence/trace/producers). Checked on the two real records in staging/processed/: the Bernstein 3.20.0 record and the summit demo record both verify under their listed keys. Question: is producers/ the binding you would want a verifier to rely on, or is a better anchor coming (for example a signed registry checkpoint)?

3. A link from a TRACE record to an act. nenrin-trace-bind-v0 (https://github.com/ogasurfproject-jpg/horizon-shield/blob/main/workers/hs-ledger/nenrin/trace-bind-v0/SPEC.md) is a record signed by the actor that names one of our execution records and one pinned TRACE record by sha256, and says the act was performed under that attestation. The relying party pins the TRACE key thumbprints it accepts. It consumes a verified record and adds nothing to TRACE semantics; what it does not establish is listed in section 5.

The ask, only if it suits you. On agentrust-io/trace-registry#122 you set the reopening condition as external producers pinning their own records. The two producer keys listed with your contact (cmcp-gateway/0.1.0 and verifiable-agent-summit-demo/0.1.0) are the only ones besides Bernstein's. If you are willing to submit one fresh bare record signed with the summit demo key (the cMCP envelope is still refused by name in v0):

curl -s -X POST https://ledger.horizonshield.dev/evidence/trace \
  -H 'content-type: application/json' -d '{"record": <the signed record>}'

it would be the first pin by a producer of its own record, and the answer would carry registered_producer. A pinned record is public and cannot be withdrawn, so please only send one you are fine publishing. We have not pinned any registry record ourselves, so that the count stays a count of producers. No pressure either way.

[ogasurfproject-jpg]

@imran-siddique thank you for merging agentrust-io/trace-spec#480. One concrete instance of the independent bound the page describes under "Independence of T", in case it is useful to readers:

The HORIZON SHIELD mirror listed in trace-registry's MIRRORS.md writes a witness record each time canonical main moves (and once a day otherwise), and stamps it with OpenTimestamps. For the current head:

• record: witness/heads/2026/10/20261008T235921Z_58850e9d0f71.json, sha256 03d10fb90e254ade5a24b464fcc9bc4b09bc620b040e002d429587703bb1152c
• canonical head and mirror head both 58850e9d0f71, observed 2026-10-08T23:59:21Z, with the SHA-256 of every registry NDJSON file at that head
• the .ots proof beside it carries Bitcoin block attestations from block 970550 on

So for any entry already in the registry at 58850e9, T can be taken from a party other than the producer. Check it without us:

shasum -a 256 20261008T235921Z_58850e9d0f71.json
ots verify 20261008T235921Z_58850e9d0f71.json.ots   # needs a Bitcoin node; `ots info` lists the attestations without one

The record says nothing about whether any signature or Trust Record in the registry is valid; it fixes which bytes existed by that block. The two registered mirrors are both at 58850e9 as of now.