If you build agent-to-agent infrastructure, you've probably hit the cross-framework trust problem: how does an MCP agent verify a claim emitted by an x402 service, attested to by an ERC-8004 identity contract, with a behavioral history from a third-party observer? You can't ask each framework to extend the others. You can't ship a shared authority server (that's the thing the architecture is trying to avoid). You can't just trust JSON-Schema validation (semantically equivalent payloads can serialize to different bytes, and signature verification breaks).
The answer that fell out of 18 months of working-group convergence: a substrate-layer canonical form that every framework can emit and every consumer can verify, with zero cross-framework knowledge required.
CTEF v0.3.2 publishes that substrate.
Six normative additions, each driven by a partner-thread interop incident:
claim_subtype: tier_upgrade
registry first entrytier_upgrade_proof
fixture lands as the first reference implementation of the authority-claim registry pattern.The bar a substrate spec needs to clear before it's actually a substrate (and not just a proposal) is empirical byte-match across multiple independent implementations. The v0.3.2 publish window crosses two such bars:
JCS canonicalization × vector sets: 5 independent JCS implementations validated against 4 distinct vector sets — 20/20 cells byte-identical, 265 byte-for-byte agreements:
| Implementation | Lang | CTEF/APS (14) | AP2 OMH v0 (7) | privacy_class v0.1 (13) | per-chain envelope v0 (19) |
|---|---|---|---|---|---|
rfc8785@0.1.4 |
Python (Trail of Bits / William Woodruff) | ✓ | ✓ | ✓ | ✓ |
canonicalize@3.0.0 |
JavaScript (Erdtman; Rundgren contributor) | ✓ | ✓ | ✓ | ✓ |
gowebpki/jcs@v1.0.1 |
Go | ✓ | ✓ | ✓ | ✓ |
cyberphone/json-canonicalization |
Java (Rundgren — RFC 8785 reference) |
✓ | ✓ | ✓ | ✓ |
serde_jcs@0.2.0 |
Rust (seritalien) | ✓ | ✓ | ✓ | ✓ |
cyberphone/json-canonicalization
is Anders Rundgren's reference implementation cited in RFC 8785 itself. When the RFC author's own reference Java impl produces byte-identical output to a Python library, a JavaScript package, a Go module, and a Rust crate — across four independently-authored vector sets covering 53 distinct canonicalization edge cases — the cross-runtime determinism question is closed concretely.
The substrate is reproducible in-tree at agentgraph-co/agentgraph/tests/cross-impl/ — single-file runner per language, run any one and get 53/53 PASS or a divergence report.
Implementations × byte-match validation: 10 independent implementations have all reproduced the CTEF v0.3.2 reference vectors:
AgentGraph (substrate maintainer) · APS · AgentID · @nobulex/crypto · HiveTrust · msaleme/red-team-blue-team-agent-fabric · Foxbook · Dominion Observatory · ArkForge · AlgoVoi (chopmob-cloud). No coordination. Each implementation built independently, validated independently, produced identical canonical bytes.
A relying-party agent in 2026 doesn't get to pick the framework its counterparty was built on. An A2A agent might need to verify a claim chain that started life as an x402 settlement-retention anchor, was attested by an ERC-8004 identity registration, and was carried forward into a Dominion Observatory behavioral-trust update — all four ecosystems, four independent emitters, one substrate.
CTEF v0.3.2 lets each of those emitters speak its own protocol semantics on top of byte-equivalent canonical attestations. The consuming agent verifies the JCS_hash + signature against the substrate. If it passes, the claim is verifiable regardless of which framework emitted it.
The architectural pattern: every framework can be a substrate emitter without any framework being authoritative.
v0.3.2 is the last byte-match-led publish. The substrate is solved — 5 implementations × 53 vectors × 4 author sets is the bar, and the bar has been cleared. What comes next composes ON TOP of that substrate, not against it.
The Consilium pass (aeoess + 8 implementers, substrate window through Jun 5, normative outputs before Jul 1) is the next coordination layer. Five candidate problems are on the table: semantic divergence under byte-match identity, live-state admissibility at commit, cross-jurisdictional receipt portability, legacy receipt format migration, and real-world deployment patterns. Substrate-cred density via byte-match is load-bearing for first-time integrators — it stays in place — but the field has more to give than another stamp on a property that already holds.
v0.3.3 (mid-June) lands the cross-extension URN-layer matrix — a row-per-URN-namespace table that binds substrate emitters to claim_type, evidenceType, and live fixture sets. Four of seven rows are already PR-accepted by maintainers (AlgoVoi, Arian, Erik Newton on Concordia, ArkForge open question). Remaining rows scaffolded for PRs:
`urn:erc8004:identity`
(cryptographic identity)`urn:mycelium:trail`
(behavioral continuity, argentum-core)`urn:x402:audit-chain`
(settlement-retention authority)`urn:nobulex:receipt`
(behavioral continuity, Nobulex AAIF)`urn:observatory:eval`
(behavioral, Dominion)`urn:foxbook:leaf`
(cryptographic identity)`urn:concordia:attestation`
(third-party authority)v0.4 (Q3 2026) opens APP↔CTEF composability and the Trust Policy Manifest.
`/.well-known/cte-test-vectors.json`
`/.well-known/interop-harness.json`
If you maintain a framework that emits trust-relevant attestations, the v0.3.3 cross-extension matrix branch is open for PRs.