docs: add agent identity verification and trust framework

[thebenignhacker]

Closes #1497

Summary

• Proposes an Agent Identity and Trust Framework for A2A using existing extension points (zero protobuf schema changes)
• Addresses security gaps exploitable in current deployments: agent impersonation, missing trust evaluation, delegation chain attacks, and absent revocation mechanisms
• Defines three identity verification levels (self-asserted, domain-verified, organization-verified), standardized trust signals, mandatory AgentCard signing for production, revocation endpoints, delegation chain security with scope narrowing and depth limits, and application-layer message signing with replay protection

Files

• docs/proposals/agent-identity-trust-framework.md — Main proposal
• docs/proposals/agent-identity-trust-framework-design-rationale.md — Design rationale (ADR format, 4 options considered)

Design Approach

Uses the existing AgentExtension mechanism and message metadata fields. All changes are additive. Existing agents continue to work at Level 0 (self-asserted). Progressive adoption path from Level 0 to Level 2.

Considered and rejected: W3C DIDs/VCs (too complex for current ecosystem), X.509 certificates (too heavyweight for agent interactions), do-nothing (unacceptable given exploitable gaps).

Backward Compatibility

No protobuf schema changes. No existing fields modified. The MAY-to-MUST change for AgentCard signing applies only to production deployments over public networks, aligning with the existing MUST for encrypted communication (Section 7.1).

[gemini-code-assist]

Summary of Changes

Hello @abdelsfane, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request introduces a comprehensive Agent Identity Verification and Trust Framework for the A2A protocol. The primary goal is to address critical security vulnerabilities, such as agent impersonation and lack of trust evaluation, which are currently exploitable in multi-agent ecosystems. By defining clear identity verification levels, standardized trust signals, and robust mechanisms for delegation chain security and message integrity, this proposal aims to enhance the overall security posture of A2A deployments, paving the way for broader enterprise adoption in sensitive use cases.

Highlights

• Agent Identity Verification Levels: Introduced three levels of agent identity verification: self-asserted, domain-verified (via DNS TXT records), and organization-verified (via third-party attestations), allowing clients to evaluate agent trustworthiness.
• Standardized Trust Signals: Defined a set of standardized trust signals (e.g., uptime, compliance, security contact) that agents can declare, enabling clients to make informed trust decisions.
• Mandatory AgentCard Signing: Elevated AgentCard signing from optional (MAY) to mandatory (MUST) for production deployments over public networks, enhancing security guarantees.
• AgentCard Revocation Mechanisms: Established mechanisms for revoking compromised AgentCards, including removal from JWKS endpoints, DNS record updates, and a well-known revocation notification endpoint.
• Delegation Chain Security: Implemented security measures for multi-agent delegation chains, such as maxDepth limits, scope narrowing, and mandatory signing of delegation contexts to ensure provenance and authorization.
• Application-Layer Message Signing: Introduced application-layer message signing with timestamps and nonces to provide integrity and replay protection for sensitive messages, complementing TLS security.

Changelog

• docs/proposals/agent-identity-trust-framework-design-rationale.md
  • Added a new design rationale document for the Agent Identity and Trust Framework.
• docs/proposals/agent-identity-trust-framework.md
  • Added a new proposal document detailing the Agent Identity Verification and Trust Framework.

Activity

• No human activity (comments, reviews, etc.) has been recorded on this pull request yet.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This is a well-written and comprehensive proposal that addresses critical security and trust gaps in the A2A protocol. The introduction of identity verification levels, trust signals, and delegation chain security is a significant step forward. The design rationale is sound, and the choice of an extension-based approach ensures backward compatibility. My review includes a few suggestions to improve clarity and consistency in the proposal, particularly regarding the structure of the AgentCard extension, the specification of the delegation signing mechanism, and consistency in enum value casing. These changes will help ensure a smoother implementation and adoption of this important framework.

[The-Nexus-Guard]

Excellent proposal — this addresses the right gaps. A few thoughts from building a working implementation of agent identity (AIP):

On verification levels: The three-tier model (self-asserted → domain-verified → org-verified) maps well to real deployment patterns. In practice, we found that a fourth level is useful: vouched — where another already-verified agent attests to a new agent's identity. This creates organic trust propagation without requiring every agent to go through DNS or org verification. It's especially important for ephemeral agents that spin up for a single task.

On DNS verification: The _a2a-identity TXT record approach is clean. One practical concern: DNS propagation delays mean there's a window where a revoked agent still appears valid. Have you considered specifying a maximum cache TTL for identity DNS records? We've seen 5-minute TTLs work well in practice.

On trust signals: The self-asserted vs. attested distinction is crucial. In our experience, self-asserted uptime/compliance signals are mostly ignored by clients — they need third-party attestation to be meaningful. Would it make sense to require attestation for signals above a certain trust threshold?

On revocation: The .well-known/a2a-revocations.json endpoint is a good addition. One gap: what happens when the agent's domain itself is compromised? A central or federated revocation registry (similar to CRL/OCSP for TLS) might be needed as a fallback.

On message signing: Strong +1 on mandatory signing for production. The replay protection via nonces is essential — we've seen replay attacks in the wild even in internal deployments.

Would be happy to share implementation experience from AIP's Ed25519 + DID-based approach if useful. The vouch chain mechanism in particular has been battle-tested with real agents.

[thebenignhacker]

Excellent proposal — this addresses the right gaps. A few thoughts from building a working implementation of agent identity (AIP):

On verification levels: The three-tier model (self-asserted → domain-verified → org-verified) maps well to real deployment patterns. In practice, we found that a fourth level is useful: vouched — where another already-verified agent attests to a new agent's identity. This creates organic trust propagation without requiring every agent to go through DNS or org verification. It's especially important for ephemeral agents that spin up for a single task.

On DNS verification: The _a2a-identity TXT record approach is clean. One practical concern: DNS propagation delays mean there's a window where a revoked agent still appears valid. Have you considered specifying a maximum cache TTL for identity DNS records? We've seen 5-minute TTLs work well in practice.

On trust signals: The self-asserted vs. attested distinction is crucial. In our experience, self-asserted uptime/compliance signals are mostly ignored by clients — they need third-party attestation to be meaningful. Would it make sense to require attestation for signals above a certain trust threshold?

On revocation: The .well-known/a2a-revocations.json endpoint is a good addition. One gap: what happens when the agent's domain itself is compromised? A central or federated revocation registry (similar to CRL/OCSP for TLS) might be needed as a fallback.

On message signing: Strong +1 on mandatory signing for production. The replay protection via nonces is essential — we've seen replay attacks in the wild even in internal deployments.

Would be happy to share implementation experience from AIP's Ed25519 + DID-based approach if useful. The vouch chain mechanism in particular has been battle-tested with real agents.

Follow up -
Thanks for the thoughtful work here, @The-Nexus-Guard, and for referencing #1496's design rationale in your PR. It's encouraging to see more people thinking about cryptographic identity for agents. A few technical and architectural concerns I'd want to address before this moves forward:

1. Protocol specs should be implementation-agnostic

The spec as written hardcodes a specific hosted service (aip-service.fly.dev) into the extension definition — the verification_endpoint and trust_score_endpoint both point to a single provider's infrastructure. A protocol-level extension should define interfaces and behaviors, not route traffic to a particular service. If this extension were adopted, every A2A agent advertising DID identity would depend on one third-party endpoint for verification and trust scoring. That's a centralization risk that contradicts the goals of decentralized identity.

For comparison, #1496 defines an extensible trust framework with levels (0/1/2) that any implementation can satisfy — it doesn't mandate a specific verification service.

2. Single point of failure / trust anchor concerns

Related to the above: the spec doesn't mention self-hosting, federation, or what happens when aip-service.fly.dev is unavailable. If this becomes the reference implementation for DID-based identity in A2A, we're creating a single point of failure for agent identity verification across the ecosystem. The spec should at minimum define how alternative AIP service providers could operate, or better yet, define the verification protocol abstractly so it's not coupled to one deployment.

3. Signature serialization is underspecified

The Gemini review already flagged this, but I want to reinforce it — "the signature covers method + params.message.parts + timestamp + nonce" is not precise enough for interoperability. Without a canonical serialization format (RFC 8785 or equivalent), two compliant implementations could produce different byte sequences for the same message, causing verification failures. This needs to be fully specified before it's viable as a protocol extension.

4. Substantial overlap with existing work in #1496

The capabilities covered here — Ed25519 signatures, trust scoring, vouch/delegation chains, capability scoping, real-time revocation — are already addressed or planned within the Agent Identity and Trust Framework in #1496. Specifically:

• Ed25519 identity: built and shipping in AIM
• Trust scoring: 8-factor algorithm already implemented
• Capability-based delegation: part of the AIM capability grant system
• DID integration: explicitly on the docs: add agent identity verification and trust framework #1496 roadmap

Rather than a parallel spec, it might be more productive to contribute DID-specific extensions within the framework #1496 already establishes — particularly at Level 2 (cryptographic verification), where DID methods are a natural fit.

5. The "DID infrastructure doesn't exist" framing needs context

The design rationale in #1496 noted that DID infrastructure doesn't yet exist for agents specifically — meaning a purpose-built system with agent lifecycle management, NHI governance, capability enforcement, and supply chain verification integrated into the identity layer. A generic DID service with vouch chains is a useful primitive, but it doesn't solve the full problem that #1496's framework was designed to address.

---

To be clear, I think DID-based identity is valuable and should be part of the A2A identity story — that's why it's on the roadmap. My concern is with merging a spec that's tightly coupled to a single hosted service when we should be defining protocol-level interfaces that any implementation (AIP, AIM, or others) can satisfy.

Happy to discuss how we can incorporate DID verification into the existing framework in #1496 in a way that's implementation-agnostic and benefits the whole ecosystem.

[gstudiogdesigns-max]

We've built a production implementation of agent identity verification for A2A (Ed25519 message signing, identity registry, HITL escalation, prompt injection detection). Happy to share learnings from our deployment. Some of the design decisions here align with what we've shipped — particularly the trust levels and message signing approach

[thebenignhacker]

Belated reply to @The-Nexus-Guard's points from 2026-02-23 — taking positions now that the layered stack (#1496 / #1786 / #1575 / #1829) is crystallizing and v0.3.3 alignment is on the table per @kenneives's coordination read.

1. Vouched as a 4th verification level — deferred, model as attestation type.

#1496's three levels are deliberately taxonomic on provenance of the binding: SELF_ASSERTED, DOMAIN_VERIFIED, ORGANIZATION_VERIFIED. Vouching is a runtime trust-propagation mechanism, not a discovery-time verification — adding it as a fourth level breaks the orthogonality (what level is a domain-verified agent who is also vouched by five others?). Better modeled as an attested trust signal: an attestations[] entry of type: vouch issued by an already-verified agent. The §1 attestation format already accommodates this without changing the level set, and the ephemeral-agent use case (an agent spinning up for a single task) is well-served by short-lived vouch attestations. Open to formalizing the vouch attestation shape (issuer agentId, vouchee agentId, scope, expiry, signature) in a follow-up extension.

2. DNS TTL cap on _a2a-identity records — accepted.

Adding normative guidance to §4 (Revocation via DNS): _a2a-identity TXT records SHOULD use TTL ≤ 300s, with a security note that longer TTLs delay revocation propagation by the same amount. Spec already uses TTL=300 in the §Implementation Notes example, but without a normative cap the whole DNS revocation mechanism is undermined by a 24h-TTL implementer. Goes in alongside the v0.3.3 alignment work.

3. Attestation requirement above a trust threshold — accepted with nuance.

§2 line 199 already SHOULD-weights attested signals higher. Strengthening: clients making authorization decisions based on a trust signal SHOULD require third-party attestation for that signal; self-asserted signals MAY be used for informational display only. The threshold itself remains a client-side policy decision (the spec can't define "high trust" — it's use-case dependent: a weather query and a wire transfer have different bars).

4. Federated revocation registry as fallback for domain compromise — deferred to v2, flagged as future work.

Real concern: if the agent's domain itself is compromised, DNS revocation (§4) and .well-known/a2a-revocations.json are both unreachable or attacker-controlled. The three existing revocation mechanisms (JWKS removal, DNS TXT update, well-known endpoint) cover the domain-intact compromise case but not domain takeover. A federated revocation registry needs a trust anchor that doesn't yet exist for agents — the same chicken-and-egg the design rationale flagged for Level 2 attestation registries. Better solved by a CT-style (Certificate Transparency, RFC 6962) append-only log with multiple monitors than by a bolted-on section in #1496. Flagging as future work and a separate proposal venue rather than expanding #1496 v1 scope.

---

On wire-format coordination: #1496 §6 (Message Signing) will adopt RFC 9421 + content-digest per #1829 once that proposal stabilizes. The current §6 ad-hoc JCS-over-message construction will be replaced by the RFC 9421 envelope; the extension URI, identity-level layers, and attestations[] shape are unaffected. Per @kenneives's coordination, the envelope-shape work is the v0.3.3 cycle (mid-June target).

Will fold #2 (DNS TTL cap) and #3 (attestation-requirement strengthening) into the same follow-up commit as the §6 RFC 9421 alignment, so the next push on this PR is a single coherent v0.3.3-aligned update rather than three churns.

[kenneives]

@thebenignhacker — all four decisions align cleanly with the substrate-vs-primitive layering. Quick notes:

Decision 1 (vouch as attestation type, not 4th level): correct architecturally. Same reasoning CTEF uses for claim_subtype registry — discovery-time taxonomy stays orthogonal, runtime trust-propagation mechanisms land as primitive-level evidence. If a vouch claim_subtype ever lands in CTEF (under authority or a new top-level claim_type for transitive trust), the shape you sketched (issuer agentId, vouchee agentId, scope, expiry, signature) is the right schema. No urgency — primitive-layer decision for whoever ships the first production vouch issuer.

Decision 4 (federated revocation → CT-style RFC 6962 log, deferred to v2): worth noting CTEF v0.4 §7 Trust Policy Manifest carries a dispute primitive (deferred from v0.3.2 per the Musaab/Arian thread on #1786 — own claim_type, not subtype, forward-compatible with the four-claim_type set). CT log and dispute primitive address different layers — CT is transparency/discovery (multi-monitor consensus on what's been revoked), dispute is issuer-side challenge to existing attestations. They compose: an issuer's dispute lands on the CT log, which makes the revocation discoverable to other verifiers without trusting the issuer's /.well-known/. Worth a coordination note in the v0.4 + #1496 v2 cycle.

Decisions 2 + 3: substrate-pass-through, no CTEF conflict.

Watching the a432d86 + f75a568 commits land. v0.3.3 cycle (mid-June) absorbs §6 alignment per the locked sequence.

— Kenne

[kenneives]

@thebenignhacker + everyone on #1496 — State of Agent Security 2026 landed at 8am ET.

§3.8 cites AgentID's claim_type: "identity" deployment on /verify (32/32 tests passing, JCS byte-match against APS bilateral-delegation 10/10) as the second of eight byte-match validated CTEF v0.3.1 implementations. The identity-layer claim_type taxonomy that crystallized on this PR's discussion thread is the foundation §3 builds on — closed {identity, transport, authority, continuity} set, formal error codes, two-level version discipline (composition_version + per-slot version).

§4 Co-signer Perspectives carries Harold Frimpong's quote on AI-agent identity verbatim: "Every AI agent needs an identity, the same way every website needs SSL."

Live: https://agentgraph.co/state-of-agent-security-2026
PDF: https://agentgraph.co/state-of-agent-security-2026-v1.pdf

The four-decision closure documented on this thread (claim_type taxonomy, byte-match-as-conformance signal, identity-layer substrate ownership, JCS canonicalization) is now anchored in a published reference. Happy to coordinate wording in any subsequent revisions if useful for AgentID downstream cites.

[thebenignhacker]

Three reference artifacts for A2A-IDF (this PR) are now live. Posting a status update and asking the TSC for a review track.

The layered split that frames the spec set (wire signature #1829, identity framework #1496 / this PR, identity claims #1786 CTEF, delegation and continuity #1575 APS) was crystallized on the #1829 thread on 2026-05-11 with explicit endorsements from @aeoess, @jschoemaker, @kenneives, and @lawcontinue. @kenneives re-confirmed alignment on the four implementation decisions on this PR a day later in #1496 (comment).

A2A-IDF now ships with three reference artifacts. Each is independently maintainable, Apache-2.0, and not normatively required by the spec text.

Artifact	Repository	Role
TypeScript SDK	https://github.com/opena2a-org/a2a-idf-sdk (@opena2a/a2a-idf)	Reference SDK. RFC 9421 + Ed25519 sign/verify, dual-shape keyid resolution per §6, verification levels 0/1/2, attestation arrays, delegation chains. Byte-matches Envoys signature/v1 §13 Vectors 1, 2, 3 against RFC 8032 §7.1 Test 1 keypair. Two runtime dependencies (@noble/ed25519, @noble/hashes).
Conformance suite	https://github.com/opena2a-org/a2a-idf-conformance	Canonical fixture and verifier set. First composition fixture (fixtures/composition/aim-did-rfc9421/signature-alone.json) byte-matches Envoys §13 Vector 1 with the keyid resolved to a W3C DID Document instead of the §6 compact form. Two independent reference verifiers (Node stdlib crypto, Python cryptography). Neither verifier depends on the SDK.
Specification page	https://opena2a.org/identity	Spec-first landing page. Names the four-layer stack, the three verification levels, the reference artifacts (SDK + suite + AIM), the public spec trajectory through v1.0 / v1.1 / v1.2 / v2.0.

AIM is named as a reference implementation alongside the SDK and suite. AIM is not a normative requirement of A2A-IDF and is not given a privileged position in the conformance suite. Implementations can adopt one layer at a time and substitute their own infrastructure at any layer.

Reproducing the composition byte-match

git clone https://github.com/opena2a-org/a2a-idf-conformance.git
cd a2a-idf-conformance
node scripts/verify.mjs fixtures/composition/aim-did-rfc9421/signature-alone.json
# PASS  fixtures/composition/aim-did-rfc9421/signature-alone.json
python3 scripts/verify.py fixtures/composition/aim-did-rfc9421/signature-alone.json
# PASS  fixtures/composition/aim-did-rfc9421/signature-alone.json

The same signature base validates under Envoys §6 (compact form) and A2A-IDF §6 (DID Document). The wire signature is unchanged. That is the core interop claim §6 of this PR makes; the fixture is the proof.

The ask

Requesting a TSC review track for this PR with the goal of landing in A2A v1.1. Concretely:

1. A reviewer or sub-committee to walk the §1-§9 normative text against the four-layer split.
2. Direction on whether the §6 dual-shape acceptance language reads cleanly against §1829's Content-Type discriminator (application/did+json → DID Document, else compact form). A follow-up PR with the five edits sketched in the Proposal: minimal Ed25519 + RFC 9421 signing extension for A2A messages #1829 ack is ready to file once the §6 alignment is confirmed.
3. Direction on whether a Working Group is the right venue for the v1.1 → v1.2 → v2.0 trajectory (vouching attestations → federated revocation → post-quantum signature algorithm agility), or whether that stays inside this PR's surface.

Happy to present at a TSC meeting if helpful. The agenda link in GOVERNANCE.md is the right channel for that, but flagging here so this PR doesn't sit indefinitely between implementer consensus and TSC review.

TSC reps per GOVERNANCE.md: @ToddSegal · @darrelmiller · @muscariello · @siwachabhi · @spetschulatSFDC · @hughesthe1st · @SivaNSAP · @geneknit

[kenneives]

@thebenignhacker — supporting the TSC review track ask; the three reference artifacts shipped this morning are exactly the maturity signal a v1.1 inclusion review needs.

Confirming the four-layer split alignment from CTEF's side:

Layer	Anchor	This PR's role
wire signature	A2A #1829 (RFC 9421)	Out of scope
identity framework	#1496 (this PR)	Sets the §6 dual-shape acceptance language + §1-§9 normative shape
identity claims	A2A #1786 / CTEF v0.3.1	Supplies claim_type: identity substrate; closed {identity, transport, authority, continuity} set
delegation + continuity	#1575 / APS	Bilateral-delegation + rotation-attestation fixtures cited in CTEF §3.8 byte-match validation

The four implementation decisions ratified on this PR (depth-first proof-stripping invariant, scope-narrowing-only authority composition, stale-action per-category override, required-vs-informational field discipline) sit cleanly under the identity-framework layer with CTEF substrate supplying the JCS-canonical envelope shape.

On §6 dual-shape acceptance language vs #1829's Content-Type discriminator: the application/did+json → DID Document, else compact form discriminator reads as a clean substrate-side dispatch. CTEF substrate doesn't care which shape the keyid resolves through — the signature base is identical either way (the conformance suite first composition fixture fixtures/composition/aim-did-rfc9421/signature-alone.json proves exactly this). The alignment is internally consistent; the dual-shape language belongs at the identity-framework layer (§6), not the wire-signature layer (#1829).

On Working Group venue for v1.1 → v1.2 → v2.0 trajectory: vouching attestations + federated revocation + post-quantum signature algorithm agility are scope-broad enough that a WG seems right — but the four-layer split should stay as the framing surface, with each layer's WG (when formed) coordinating with the others through the cross-extension fixture matrix being assembled in the v0.3.3 working doc (here). Profile-level extensions (e.g., @eriknewton + @a2cN + @bidangel's cross-protocol relationship vocabulary) can live as named profiles on top of the layer specs without forking the trajectory.

TSC reps tagged: happy to support presentation if requested. CTEF substrate is positioned to land its own conformance + spec text into whatever review structure the TSC sets up.

[aeoess]

Supporting the v1.1 review-track ask.

The four-layer split — wire, identity, claims, continuity — is the right decomposition for the current substrate work. It keeps transport mechanics, identity binding, attestable claims, and continuity/rotation concerns separated without forcing one issue to carry the whole stack.

APS continuity-layer interlock still holds: bilateral_receipt absent-tag default and the rotation-attestation chain compose with the #1496 dual-shape keyid resolution without protocol changes.

Happy to confirm any APS-side fixture pins the review track needs.

[thebenignhacker]

Thanks @kenneives and @aeoess for the v1.1 review-track endorsements and the four-layer alignment confirmation.

On the four-layer split. @kenneives's table (wire / identity / claims / continuity) plus @aeoess's APS continuity-layer interlock confirmation (bilateral_receipt absent-tag default + rotation-attestation chain composing with §6 dual-shape keyid without protocol changes) means the four-layer composition is already exercised end-to-end on the conformance side. The aim-did-rfc9421/* fixtures in opena2a-org/a2a-idf-conformance plus the bilateral-receipt and delegation-chain-3link composition fixtures already shipped carry the byte-match proofs.

On §6 dual-shape vs #1829. Agree the substrate-side dispatch (application/did+json → DID Document, else compact form) belongs at the identity-framework layer, not the wire-signature layer. A §6 follow-up PR refining the dual-shape acceptance language is ready to file once a reviewer or sub-committee picks up the §1-§9 walk.

On State of Agent Security 2026. @kenneives's report (https://agentgraph.co/state-of-agent-security-2026) §3.8 cites AgentID's /verify deployment as one of eight byte-match-validated CTEF v0.3.1 implementations, with §4 carrying Harold Frimpong's identity quote verbatim. Useful artifact for the v1.1 review track: published byte-match evidence plus two cross-implementer endorsements landing on this PR's surface.

Next. Waiting on TSC reviewer assignment per GOVERNANCE.md (reps tagged on the prior comment). The Working Group venue for the v1.1 → v1.2 → v2.0 trajectory is sketched in roadmap PR #1850.