[minitru]

The narrow resubmission suggested on #337. One thing only: the software-only Level 0 Trust Record an xChk registry mints per run, with one approval-outcome reference per act a person was asked about, and how a relying party verifies it with released agentrust-trace against the key the registry publishes: pinned, or fetched under the record's kid from /.well-known/xchk-keys.json, never the key the record itself carries.

Contents: integration.yaml (record-producer, Level 0, community tier), a README that says what the record is and what it does not claim (nothing about what a reference resolves to; no hardware; no ordering), one committed record from a live run with the pinned signer key, five offline tests, an opt-in live key check, and a floating/fixed workflow that runs the tests and trace-tests verify --level 0. The receipt verifier, the bundles and the claims about the approver's assertion are not in this PR; they come separately once the private findings are settled with the maintainers.

Reproduction:

pip install -e "integrations/xchk-registry[test]" agentrust-trace-tests
pytest integrations/xchk-registry/tests -q
trace-tests verify --record integrations/xchk-registry/examples/01-trust-record.json --level 0

🤖 Generated with Claude Code

[noah-ing]

Reviewed exact head 5ae0b47df7f34a74f03d7e5b0ea01ed34aa63a0a. This is a useful reduction from #337: it limits itself to a software-only Level 0 record producer and explicitly excludes receipt verification and ordering claims. The five offline tests pass (one live check skipped); the opt-in live key check passes; Level 0 conformance passes. The reported hosted check is green, while the maintainer approval gate awaits a current-head approval.

Requesting focused changes for the freshness and reproducibility findings below. A separate signer-key trust concern persists in the default published-key path; I documented its current-head evidence in the existing private security advisory, without asserting the old receipt-verifier findings against this narrower PR. Please keep this PR open for those bounded fixes and negative regressions.

[minitru]

Thanks, both points taken, fixed at 9d97b87.

P1, record age. max_age_seconds=None is gone. The verifier now has MAX_AGE_SECONDS = 86400, the library's
default and §3.2.2's, overridable with --max-age, which must be positive: the bound cannot be switched off. A
retained record is re-verified at its own time with --now <epoch seconds> rather than by widening the bound, which
is also how the offline tests now pin the historical fixture (at the minute it was minted). Negative tests added: a
record one second past the bound is invalid with the library's reason; --max-age 0, a negative value and None
are refused; a month-old record is stale at the default.

P1, revocation. The output now carries revocation as the library reports it. This tool passes no bundle and no
store, so it prints no_check_performed, and the README says that this is not an affirming appraisal (§3.2.3). A
refused record carries reason.

P2, README. The conformance command carries --max-age 315360000, the same as the workflow, with a sentence
saying why: the example record is from 17 Oct 2026, and the verifier's own default stays 24 hours.

On the signer-key concern in the advisory: I still cannot see it as the PR author, so I have not tried to address
it here. If a maintainer can forward it or add me, I will take it up in the same bounded way.

[noah-ing]

Reviewed exact head 9d97b879a796e3b46e11b1ec742c7b81f249fd2e. The finite 24-hour age bound, revocation outcome, stale negative tests, and historical-fixture command address my prior public findings. Local checks passed: eight tests including the opt-in live key check, Level 0 conformance, and 1,000 seeded age/clock cases; three tampered records were rejected. The hosted workflow is still action_required, so I am not treating it as a green CI result.

Requesting two bounded output fixes below. Separately, the signer-key trust concern already documented in the private advisory remains on this head's published-key path. @carloshvp has been added to that advisory for maintainer triage; please coordinate the details privately. This is based on a synthetic local check and does not assert production exposure.

[noah-ing]

Correction to my review above: I checked the collaborator list and @carloshvp has not yet been added to this particular private advisory. I had conflated its access with separate reports. The confidential finding is documented there, and I am checking the appropriate maintainer access path. I also see new head 858aa7f and am re-reviewing it now; I am not yet claiming it resolves the concern.

[minitru]

One more change, at 858aa7f, on the default (published-key) path, since it is the one the review named. The tool
used to fetch the key document from the resolver the record itself carried, so a record could name the server its
key would be fetched from. Now the trusted origin is the relying party's (--registry) or the origin under the
record's did:web subject; the record's resolver must agree with it and is never followed. The fetch is https
only, follows no redirect, checks the status and reads at most 256 KB; the output names the trusted origin and a
refusal says why. Tests: a resolver pointing elsewhere, a subject moved to another host, an http origin, a redirect
and an oversize document all end in no-key with nothing fetched from the record's server. If that is the concern
in the advisory, good; if it is something else, I would still like to see it.

[noah-ing]

Reviewed exact head 858aa7fc6337f41d0926475a7683a152869eac49. The new origin check, HTTPS-only fetch, redirect refusal and size bound are useful improvements. In isolated checks, nine offline tests passed (one opt-in live check skipped), and Level 0 conformance passed. The hosted gate failure is the independent maintainer-approval requirement; I have not inferred a successful technical workflow from it.

The default published-key path still lacks a trust origin supplied by the relying party, as documented with a synthetic current-head control in the existing private advisory; @carloshvp now has access to assess it. Please keep the reproduction private. I am requesting the focused trust-anchor and malformed-key-document fixes below. My prior current-head review's profile/accepted_profiles and historical --now output comments remain open and are not duplicated here. No production exposure or released affected version is established.

[minitru]

Round 3 at bfd4dcf, all four open items, checked against every thread on the PR.

P1, trust anchor. You are right that deriving the origin from the record's own subject only showed the record
agreed with itself. --registry is now the one source of the published-key origin; without it or --jwk there is
no trust anchor and the answer is no-key. The record's subject and resolver must agree with the origin given.
Negative control added as you described: a record signed end to end by a key of the attacker's making, with its own
subject and resolver under the attacker's host and that host publishing the key. It is no-key without an anchor,
no-key against the relying party's registry, and invalid against the pinned real key; nothing is fetched from
the attacker's host in any case.

P2, profile fields. A verified result carries profile and the complete accepted_profiles from the library
result (§3.3), and the trusted key's thumbprint; asserted in the verified-output test.

P2, as-of time. Every verdict, no-key included, carries verified_at, the instant passed to verify_record,
and verified_at_overridden. Tested as the stale-current / historical-verified pair.

P2, malformed key document. key_from_published refuses every malformed shape without raising, the fetch wraps
it besides, and the negative test runs sixteen bad documents through it. A bad document is no-key, exit 1.

13 tests pass locally under 3.11 including the live key fetch. Also run here, from the workflow definitions: the
Validate steps (manifest schema, compatibility floors, integration index and Marketplace catalog --check), the
repository-wide Lint command, and every link in the README and manifest; all pass. On the advisory: understood that
@carloshvp has it now; I will keep anything about the reproduction private.

[dinakarjs]

Public-scope review of exact head bfd4dcf. The published-key path now requires an explicit relying-party origin/key, and 14 additional malformed-key-document controls refuse without a parsing exception. The no-origin control performs zero key fetches. The committed integration suite passes 12 tests with its one opt-in live test skipped; root validation passes 28 tests, and the committed record passes the released 0.6.2 Level 0 selection (not hardware appraisal).

One remaining public reporting defect: verify_with_key_source samples as_of_fields(now) into bounds, then verification samples it again when now is omitted. The final **bounds overwrites the instant actually used by verify_record. With a two-value clock [100, 101] and a spy on verify_record, the library receives now=101 while the result says verified_at=100. This is a deterministic metadata-binding discrepancy, not a signature forgery or a claim of production exposure.

Please freeze one effective instant at the wrapper boundary, use it both for library verification and every emitted verdict, and preserve whether the caller explicitly overrode time. Add a no-override two-clock-value regression plus an explicit --now control; both should assert the recorded instant equals the one supplied to the verifier.

All returned technical workflows on this head currently require maintainer authorization, so I am not calling hosted CI green. This public review neither assesses nor resolves the separate private report, and does not establish what an approval-outcome reference proves.

[minitru]

First, an apology. The verified_at defect was introduced by my own previous round, in the change meant to fix the
as-of reporting, and I then said the head had been checked against every thread. It had not been checked well
enough. Thank you both for the scrutiny, and for the patience across four rounds in one day; the reviews have been
precise every time and the integration is better for each of them.

The clock, fixed at 122d959. One Instant is frozen where the request enters (verify_with_key_source, or
main for the CLI) and the same object reaches the library call and every emitted verdict, no-key included; the
clock is read at most once per verdict, and whether the caller supplied the time is preserved. Your two-value
control is now a test, with a spy on verify_record, on the pinned, published and no-key paths and through the
CLI with and without --now; each asserts the recorded instant equals the one given to the verifier.

Then, rather than wait for the next shape to be found one review at a time, at 2dcb159 every top-level field of
the record, its key fields and its reference fields were set to each of fourteen odd values and run through
main() on all three paths: 40 mutations crashed (a record that is not an object, cnf or cnf.jwk not an
object, references not a list, a resolver that is not a string), and the pinned-key file crashed on anything but
an object. All of it now ends in a JSON verdict and an exit code: a non-object record is invalid; a pinned key
that is not an Ed25519 JWK is no-key; references and resolver are read only when shaped; an exception the library
raises on a shape it did not foresee is invalid with the exception named; a record or key file that is not JSON
is a verdict, not a traceback; --registry must be an https origin and nothing more; --now must be non-negative.
The verdict's kid is always the key the record names, pinned_kid the pinned key's own, and the thumbprint the
key actually used. The mutation loop is committed as a test (798 runs), beside a test per input.

18 tests pass under Python 3.11 and 3.12 including the live key fetch; Level 0 conformance passes; the
repository's Validate and Lint steps pass locally. I have not run 3.13 here.

[noah-ing]

Reviewed exact head 2dcb15961f28d6581e8735b50f82e6fef0abdf4a. The out-of-band trust anchor, one frozen verification instant, and fail-closed key-document handling address my earlier findings on those paths. The local integration suite passes (17 passed, one opt-in live check skipped), and the committed record passes Level 0 conformance. Independent freshly signed synthetic controls exposed the bounded origin-contract and malformed-URL issues below. Please cover these cases with negative tests. This review does not reassert the earlier private signer-key finding on this head, and it does not claim production exposure. The hosted gate currently fails for independent maintainer approval; I am not treating that as a green technical CI run.

[dinakarjs]

Re-reviewed exact head 2dcb159. The verification-instant finding is resolved: four additional clock controls pass, including equality with the actual verify_record argument and preservation of explicit versus implicit time. The committed integration suite plus root tests pass 45 tests with one opt-in live test skipped. The released 0.6.2 Level 0 selection passes (15 checks, four skipped); this is software/historical verification, not receipt or hardware appraisal.

One remaining bounded CLI error-handling defect: https_origin calls urlsplit and then u.port without handling their ValueError refusals. With the committed record and --now 1792252551, each of --registry https://in.xchk.io:bad, --registry https://in.xchk.io:65536, and --registry 'https://[broken' raises an uncaught ValueError before emitting any JSON. The malformed bracket case fails in urlsplit; the other two fail while reading u.port. Three independent CLI controls reproduce this, while a valid-origin control verifies with the expected fetched key and all four clock controls pass (three failures, five passes in that additional selection). These cases require no network request.

Please handle origin parsing/port validation as an explicit refusal, retaining a nonzero exit and a reason (consistent with this head's documented verdict contract), and add malformed-port/range/bracket controls with a valid-origin twin and zero-fetch assertions. This is a caller-option crash, not a signature bypass or production-exposure claim.

Ruff at the repository's E4/E7/E9/F scope and whitespace checks pass. All returned current-head hosted workflows still require maintainer authorization; I have not called hosted CI green. This public review does not assess or close the existing private report.

[minitru]

Thank you both. All three at 09c436b, each with a freshly signed synthetic control and a valid twin, and then the
sweep that should have come before this round.

Malformed --registry (both of you). https_origin now catches what urlsplit and .port raise, so a bad
bracket, a non-numeric or out-of-range port is a no-key refusal with the reason, exit 1, no fetch. The netloc must
also be exactly host or host:port, so a trailing colon or an empty port is refused; https://host:443 is the
same origin as https://host (RFC 6454); and a malformed --registry is refused even beside --jwk, since an
option that is given is checked. Controls: eight malformed origins through verify_with_key_source and the CLI,
with the valid twin fetching the key once.

Subject. The published-key path now requires a did:web subject under the trusted origin; absent, non-string,
did:key, did:web: and another host are each refused before any fetch, with signed controls (the did:key and
other-host ones verify under their own key, as yours did) and a twin under the origin that verifies with the
fetched key.

Every approval-outcome reference. All of them must resolve at the trusted origin, whatever their position; one
that names no resolver is a refusal (§3.1.2 obliges the registry to keep each one resolvable, so one with no
resolver is not a reference this tool can check); references of other kinds are ignored. Signed controls for
[on, off], [off, on], [on, on, off], [on, unnamed], and the twins [on, on], [on, other-kind], [].

The sweep. 43 origin strings × 19 subjects × 8 reference sets, each a signed record through
verify_with_key_source, asserting a verdict every time and a fetch only when the origin is well formed and the
record agrees with it; the same origins through the CLI, pinned and published. It is a committed test.

22 tests pass under 3.11 and 3.12 including the live key fetch; the repository's Validate and Lint steps and Level
0 conformance pass locally.

[noah-ing]

Reviewed exact head 09c436b48f7787146b9844979ab43b9b62300181. The three findings from my preceding review are addressed on the published-key path: malformed origins produce a refusal, a did:web subject is required under the trusted origin, and every approval-outcome resolver is checked. Locally, 21 integration tests passed with one opt-in live test skipped; the committed record passed Level 0 conformance, and the diff check was clean. I am requesting one bounded fix for the combined --jwk + --registry mode below: the program accepts both options but currently enforces only the pinned key and the registry URL syntax, which can misstate the caller’s intended origin constraint. Either enforce both when both are supplied, or reject their combination and document the choice. The default-port observation is a separate, nonblocking false refusal. The hosted gate is still blocked on independent maintainer approval; I have not treated it as a green technical CI run. These are local controls, not a claim of production exposure.

[noah-ing]

Reviewed exact head dd97be8cb54ece88604badf2d63fa68c0f2d730e. The combined --jwk + --registry path now enforces the supplied origin before pinned-key verification, and approval resolvers are compared as canonical HTTPS origins; the explicit :443 positive control verifies. Independent freshly signed controls also refused foreign subjects and first/second foreign approval resolvers before any key fetch, while matching pinned and published paths verified. Locally, all 24 integration tests passed with the opt-in live key check enabled; the committed record passed Level 0 conformance (15 checks, four optional skips), and the exact-head diff check was clean. I found no remaining blocking issue in this narrow Trust Record verifier scope, so this approval supersedes my earlier changes requests on #338. It does not assess the receipt verifier from closed #337, establish what an approval reference proves, or claim production/hardware assurance. I did not run the repository-wide validation/lint jobs locally; the hosted gate is still awaiting a named maintainer approval on this head, which my Reviewer approval does not satisfy.

[minitru]

Thanks. Both at dd97be8, and the sweep rebuilt as you described.

P2, combined mode. An origin that is given is now enforced whichever way the key comes: with --jwk beside
--registry, the pinned key verifies the signature and the record's subject must be a did:web under the origin
and every approval-outcome resolver must be that origin; a disagreeing record is no-key before the key is
consulted. Controls: the committed record pinned with its own registry (verified, trusted_origin reported) and
with another (refused on the subject); signed records with a non-did:web subject and with an off-origin second
reference, pinned, refused by the origin and verified by the key alone; and the README says what the combination
means.

P3, resolver normalisation. Resolvers are compared as origins through the same canonical form as --registry,
so an explicit :443 or a different case is the same origin and a resolver with a path, another scheme or
credentials is refused as not an origin. Your %3A443 / :443 / --registry https://in.xchk.io:443 twin is a
test and verifies with the fetched key.

The sweep. It now runs every combination pinned as well as published (6,536 runs each way), and its
expectation of what an origin string means is written in the test from RFC 6454, sharing no code with the
verifier. That oracle found one more case on the way: a leading space, which urlsplit strips and the verifier
had accepted; whitespace and control characters in --registry are now refused.

24 tests pass under 3.11 and 3.12 including the live key fetch; the repository's Validate and Lint steps and Level
0 conformance pass locally.

[dinakarjs]

Re-reviewed exact head dd97be8 against the public, narrow Trust Record integration scope. My earlier verification-instant and malformed-origin findings are resolved, and the combined pinned-key/origin and all-resolver checks remain enforced. This approval supersedes my earlier public changes-requested reviews on #338 within that scope.

Fresh Linux/Python 3.12.14 with released agentrust-trace 0.11.0 and agentrust-trace-tests 0.6.2: committed integration tests 23 passed, 1 opt-in live check skipped; root repository tests 28 passed. The retained committed record passes released Level 0 conformance (15 checks, 4 optional skips) under the explicitly documented historical age allowance. This is not a fresh live run.

Nine separately written controls using a fixed synthetic Ed25519 signer pass: pinned/published/combined valid paths feed the library exactly the reported instant after one clock read; bad port, out-of-range port and broken bracket refuse with zero fetches; validly signed off-origin references in either position verify under the key alone but refuse in combined mode before fetching; explicit :443 subject/resolver/registry forms agree. An isolated mutant that skips origin enforcement only when a pin is supplied causes both resolver-position controls to fail on status assertions; restoring the source passes all nine controls. No source changes were retained, and the checkout is clean.

Repository integration-manifest validation (48 integrations, zero failures), compatibility validation, generated index/catalog checks, root tests, Ruff in CI's E4/E7/E9/F scope and whitespace checks pass. The sole returned current-head hosted check is the failed maintainer gate; no hosted technical success is inferred from it.

No remaining blocking finding in this bounded re-review. No live published-key fetch, receipt/bundle verification, proof of what an approval reference establishes, ordering, hardware or production assurance is claimed. This does not assess or resolve the separate private findings associated with the receipt work, and Reviewer approval does not substitute for the named maintainer acceptance gate. Reviewed with OpenAI Codex assistance.

[minitru]

Pushed 7646077 on top of the approved dd97be8, one commit: the CodeQL clear-text-logging alert on xchk_trace_record.py's verdict print. The heuristic matched two names: trusted_key_thumbprint, an RFC 7638 thumbprint of the public key, now taken from the library's own jwk_thumbprint(); and trusted_origin(), the --registry origin, renamed anchor_origin(). Output field names are unchanged.

Found while tracing the flow, and included: a pinned key file that carries a private member d is refused with fixed text and nothing of it is echoed; a key file that does not decode is reported by error class only. Three tests (tests/test_trust_record.py).

26 passed, 1 skipped under Python 3.11; ruff --target-version py39 --select E4,E7,E9,F clean. No other change. The same two-file change is in #350, which is restacked on this head. Sorry for moving the head after your approval; I took that over merging with an open security alert.

[dinakarjs]

Reviewed the two-file delta from dd97be8 to 7646077. The fixed-text pinned-private-key refusal and error-class-only key-file decoding report have direct regressions; the public-key thumbprint parity test retains the existing output contract. No additional defect established in this delta.

The changed implementation and test_trust_record.py are byte-identical in stacked #350 head 9b1622e, where I ran the complete offline selection: 73 passed, 1 live check skipped with released agentrust-trace 0.11.0 / agentrust-trace-tests 0.6.2 on Python 3.12.14. This is shared-file validation, not a separate full #338 run or a live registry assessment.

All 14 returned current-head hosted workflows are action_required, including CodeQL and xchk-registry conformance. A maintainer needs to authorize them and review this new head; the earlier approval predates this commit. No assertion that the scanner finding is cleared until the current-head scan runs. Reviewed with OpenAI Codex assistance.