Thanks Jacky — this is a really clean way to frame the v2 work, and the registry subsystem in particular lands exactly where those discussions were heading. (Apologies for the delay on this reply — a forum posting restriction on my account took a few weeks to clear.)
A few implementation details from the issuer side, now that the first profile is live and wired all the way through.
Where verification.v0.3 sits today. The reference implementation lives at TKCollective/agentoracle-receipt-spec under examples/v0.3-composed/. It carries a deterministic build (build_fixtures.py), three published JWKS (AgentOracle, AgentTrust, Presidio), and both accept and reject vectors as detached JWS files, so a cold clone can recompute everything byte-for-byte. The format is also in live production as of 2026-08-02 — self-serve issuance, receipts signed against the published JWKS. A usage showcase demonstrating verifiable delivery evidence for ACP agents is filed at Virtual-Protocol/acp-cli-demos#97 (under review), with a live production receipt in the folder.
Multi-issuer composition. The composed envelope carries three signer slots today: v_gate (AgentOracle’s verifier leg), v_gate_skill (AgentTrust’s verifier leg; their adapter runs their own /v1/compose against the same canonical bytes), and screen_ref (Presidio’s screen leg, as demonstrated in the June 28 x402 middleware thread). The rule is “all present legs must recompute or the decision halts,” and that halt behavior is covered by a dedicated conformance vector in the composed fixture set.
Conformance vectors and independent grading. Both AgentOracle’s and AgentTrust’s suites are anchored in the argentum-core fixtures rather than in our own repos, and were recompute-graded there before merge; that’s how we’ve been operationalizing the “two independent implementers” bar you described. Since then it’s gone a step further: a v0.4 revision is in open draft (agentoracle-receipt-spec PR #5 — sealed evidence, multi-clock anchors), and its conformance suite completed 2026-08-01 with every envelope and wrapper hash recomputed byte-identical by two independent implementations. Not yet normative — the draft is deliberately unmerged while it collects hostile readings — but the two-implementer discipline held through a second full cycle, which is the property worth reporting to this thread.
Since drafting the above, two additions relevant to the registry conversation. The production API now ships a deterministic verification mode (POST /v1/verify-facts): six check types resolved with no model anywhere in the pipeline, check_mode recorded inside the signed payload so a verifier can prove — not be told — that nothing probabilistic was in the trust chain for that decision; claims outside the deterministic class are refused (HTTP 422) rather than silently escalated. And the v0.4 draft’s provenance design has been advancing through public review on the spec repo (issues #7/#8) — per-layer mode ∈ {recomputable, signed} with divergence between rerun and signature treated as a first-class diagnostic, with the design contributions credited inline. Both are the kind of profile-lifecycle material the registry path seems built to absorb over time.
Verification tooling. The same canonicalization and signature rules are implemented in three environments: Node (via jose), Python (agentoracle-receipt-verify on PyPI), and browser (WebCrypto-only bundle). All three consume the same JWKS and recompute the same hash; verification succeeds or fails purely on whether the bytes match, with no dependency on our infrastructure.
On the two open questions you flagged:
-
Multi-issuer envelope citation: from our side, Direction B (protocol-neutral prose in the ERC body, registry as the naming mechanism) feels like the right long-term move now that the registry is content-addressed. The profile identifier is the stable hook; specific issuers and fixtures can live in the registry and reference repos without forcing ERC revisions.
-
Behavioral similarity as a fifth category: we’ve been treating verification.v0.3 as independence-model agnostic so far, so an additional category in IIndependenceSignal would slot in without changes on our side; no strong view beyond that.
Happy to keep contributing profiles and lifecycle transitions through the registry PR path. The content-addressed registry plus a reference implementation and fixtures has been a good division of labor; it keeps the ERC body stable while letting implementations move.