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.

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.

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