← Articles

A2A AIAR Identity Extension: First Agent Registry MVP

A2A Identity Extension

March 5, 2026 · PR #1592 · ibrahimokuyucu

After weeks of theoretical proposals about agent identity — DID-based verification, cryptographic passports, trust layers — someone has shipped working code. PR #1592 introduces the AIAR (AI Agent Registry) identity extension as a v0 MVP, providing a concrete foundation for agent verification in A2A.

Who is ibrahimokuyucu?

Ibrahim Okuyucu appears to be a new contributor to the A2A ecosystem, with this PR marking their first significant contribution. The AIAR extension reflects someone thinking practically about identity infrastructure rather than abstractly — building a registry-based system that can evolve rather than trying to solve all identity problems at once.

Why This Matters

The A2A repository has seen numerous identity proposals over the past month:

DID-based agent identity using W3C Decentralized Identifiers
Agent Passport with Ed25519 cryptographic keys
Trust layer proposals with capability attestations

All valuable work, but theoretical. AIAR takes a different approach: start with a minimal viable registry that can verify "is this agent registered?" and "what capabilities does it claim?" — then iterate.

What AIAR Provides

Based on the PR description and extension pattern, AIAR likely includes:

Core Components
Agent Registration — Unique identifiers tied to organization and purpose
Capability Attestations — Declared capabilities that can be verified
Trust Scoring — Reputation signals based on interaction history
Verification Endpoint — API for agents to validate each other

The "v0 MVP" framing is significant. Rather than trying to solve decentralized identity, cryptographic proofs, and delegation chains all at once, this provides a foundation that can be extended.

Technical Implications

Registry-based identity has tradeoffs compared to cryptographic approaches:

Advantages

Simpler implementation — No complex key management or signature verification
Centralized updates — Capability changes propagate immediately
Human oversight — Registration can include manual verification
Incremental adoption — Works alongside existing A2A implementations

Tradeoffs

Single point of trust — Registry operator must be trusted
Availability dependency — Registry downtime affects verification
Centralization risk — Could become a gatekeeping bottleneck

The smart approach is treating this as layer 1 of a multi-layer identity stack. Registry verification today, cryptographic verification tomorrow, decentralized verification eventually.

Ecosystem Context

This PR lands alongside related A2A work:

PR #1583 — Authorization, delegation & audit evidence extension proposal
Commit dec790a — Clearer contextId documentation
Commit 010b9cc — Config removal from bindings (spec cleanup)

The pattern suggests A2A is entering a "practical implementation" phase after the theoretical v1.0 spec work. Identity, authorization, and audit capabilities are being built out as extensions rather than core spec changes.

What's Next

For AIAR to succeed, it needs:

Reference implementation — A running registry that early adopters can test against
Integration examples — Sample code showing verification in agent interactions
Migration path — How to layer cryptographic verification on top later
Governance clarity — Who operates the registry and under what rules

The v0 framing gives room for all of this to evolve. Shipping something imperfect but real beats debating perfect designs indefinitely.

Bottom Line

AIAR represents the A2A community's first concrete answer to "how do agents verify each other?" It's intentionally minimal — a registry-based MVP that can evolve. For anyone building A2A implementations who's been waiting for identity infrastructure, this is the starting point.