Agent Registry - Proposal

[kthota-g]

Hi,
There are a few open discussions related to agent registry to enable agent discovery discussed here.

The following is a proposal for a registry service for agents. We appreciate any feedback or discussions in solidifying the proposal.

---

Agent Registry - Proposal

With the rapid proliferation of AI and Agentic applications, a typical enterprise may have a number of internally developed agentic applications and agents procured from external vendors hosted internally or in the cloud. An enterprise customer may have functions that span more than one agent and need a service to lookup and leverage the available agents for completing a task.

Similarly, vendors may also provide a number of agents as part of their offerings similar to how public APIs are documented today. The vendors of agents may need to provide a list of available agents for consumption to their customers. These agents could be publicly accessible or granted by entitlements to their customers.

This paper proposes a registry service that could be deployed to enterprise environments or publicly accessible endpoints that can help with agent discovery and entitlements.

The following are the key terms used in this document:

Agents: Agentic applications running within an enterprise or hosted externally.
Agent Card: A JSON document published by an agent describing its capabilities, protocols and authentication mechanisms.
Client: A client is an application, service or an agent that can consume Agents
Agent Entitlement: A permission granted to a client to enable fetching available agents for its use.

Agent Catalog

Agent Catalog is a component of the Agent Registry that allows showing a list of available agents in an enterprise context. The registry service allows authenticated users to login using a web interface and add agents hosted internally or externally to the catalog. Agents can be added to the catalog by providing their Agent Card url which describes the agent’s capabilities, skills and supported authentication schemes. Registry will fetch the content from the provided agent card and index the content to offer search capabilities.

Following is an example mockup showing a list of available agents in an enterprise agent catalog:

Agents added to the catalog can have varying capabilities, authentication mechanisms and supported protocols. But the catalog’s role is to simply surface the details of an agent and does not deal with the internal workings of an agent. Enterprise administrators can choose to make the agents available publicly or set them up to be available only for authenticated clients.

Agent Entitlements

Agents available in the registry can be entitled to client applications. A client application can be a service, application or even an agent. The registry service provides an interface for logged in users to register a new client and allow the client to access the available agent entitlements.

The agent registry could leverage an external authorization server for generating the client_id and client_secret and use the OAuth 2.0 Client Credential grant flow to request an access_token and use the token to access the entitlement service.

A registered client can issue HTTP GET to https://<registry-url>/agents/entitled with the bearer token to retrieve a list of entitled agents represented by their agent cards. Following is an example response:

{
  "registry_version": "0.1",
  "resources": [
    {
      "id": "it-agent",
      "name": "IT Agent",
      "location": {
        "url": "https://it.example.com/.well-known/agent.json",
        "type": "agent_card"
      },
    },
    {
      "id": "benefits-agent",
      "name": "Benefits Agent",
      "location": {
        "url": "https://benefits.example.com/it/agent.json",
        "type": "agent_card"
      }
    }
  ],
  "total_count": 2
}

The entitlements provide links to the agent cards published by the agent providers.

Open Discovery

Enterprises may choose to provide a public listing of available agents that could be used by external agents/applications or to be discovered by search engines. For example, an agent vendor may provide a publicly accessible list of agents that could be accessed by any other external clients.

We propose to use https://<registry-url>/agents/public as the endpoint for open discovery of agents published by an enterprise.

Agent Search

Agent registry can support agent search for consumers. A client application can query the registry with a query + filter criteria to discover agents (entitled/public agents) on the fly for solving a task.

For example: if a consumer queries “what’s the 401k match policy?”, the registry can perform a search of all the available entitled agents for that consumer and can return the most relevant agents (e.g. Benefits Agent) to the consumer. Clients can pass top as a query parameter to limit the results returned by the registry. Specifying top=1 query parameter returns the top 1 match for the query.

A search can be performed by HTTP POST to https://<registry-url>/agents/search with payload

{  
  "query":"<user query>",
  "capabilities": {  
     "streaming": true,  
     "pushNotifications": true  
   }  
}

End to end flow:

Following diagram demonstrates the end-to-end flow between the services:

High level diagram

User authentication and authorization to registry

User management will be available as part of the Agent registry service and agent registries can leverage Single Sign-On with an external IdP for enterprise authentication and authorization.

Users can be assigned one or more of the following roles:

Administrator - Ability to setup auth configuration, settings and user management
Catalog Manager - Ability to add or remove agents to the catalog
User - Ability to register new clients and grant agent entitlements
Viewer - Ability to view the agent catalog if the catalog is not publicly accessible

Agent registry end points:

1. Open Discovery end point:
   GET URL: https://<registry-url>/agents/public
   Any agents added to the registry and configured with public access will be listed at this endpoint.

2. Agent entitlements end point
   GET URL: https://<registry-url>/agents/entitled
   All public + entitled agents available for a client will be returned by this endpoint.

3. Search end point
   POST URL: https://<registry-url>/agents/search
   Client’s accessible public + entitled agents that match the provided search criteria will be returned via this endpoint.

   Endpoints # 2 and # 3 are accessible only for authenticated clients.

   Pagination is supported by passing top and skip query parameters.

[ognis1205]

Hi @kthota-g , Thank you for the proposal and the detailed explanation.

I feel that the current design of the Agent Registry implicitly assumes that Agent Providers manage their own agents within the registry service. However, in practice, the Agent Registry service administrators may be independent from Agent Providers.

In particular, the Open Discovery endpoint might not be necessary within the Agent Registry service itself. Instead, it would be more natural for the services hosting agents to provide their own Open Discovery endpoints, which the Agent Registry service could then crawl to register agents.

Regarding the URL structure, commonly seen catalog or registry services often employ namespaces such as {tenant}.{group}.{agent}. This is very effective when Agent Registry and Agent Providers are not necessarily the same entities. When federating or curating endpoints from various Agent Services, having a tenant per Agent Provider and grouping multiple remote agent services by group seems practical. These groups often represent sets of agents working together as a network. Therefore, a RESTful URL design like the following might be more appropriate:

https://<registry-url>/tenant/{tenant_id}/group/{group_id}/agent/{agent_id}

This would allow linking user ownership and fine-grained CRUD access control per tenant, group, and agent. Similarly, the search API might be better structured as separate endpoints, for example:

GET https://<registry-url>/tenant/
GET https://<registry-url>/tenant/{tenant_id}/group/
GET https://<registry-url>/tenant/{tenant_id}/group/{group_id}/agent/

with query parameters for filtering and pagination.

While the current POST https://<registry-url>/agents/search endpoint is very convenient, it is quite generic as a protocol specification, and access control implications are significant. Therefore, I believe there are still important considerations to address.

To summarize, I’d like to clarify:

• Does the current proposal implicitly assume that the Agent Registry administrators are also the Agent Providers? Is this assumption correct?
• Is having an Open Discovery endpoint inside the registry necessary?
• Would a hierarchical URL structure like /tenant/{tenant_id}/group/{group_id}/agent/{agent_id} be better for access control and organization?
• Is having a single generic /agents/search endpoint really appropriate as part of the registry’s protocol specification?
• If this model (or a similar hierarchical design) is adopted, how should ownership and fine-grained access control be defined and enforced across tenants, groups, and agents?

I’d love to hear your thoughts on this direction — and happy to align with your longer-term goals if there’s already a vision in place.

[kthota-g]

Thanks for the feedback. The proposal above tries to address two scenarios.

1. Agent providers publishing their agent offerings via a public endpoint to help discovery. Imagine a vendor offerings agents for several services and each have their own agent cards at different urls. A centralized registry url where all the provider's offerings can be surfaced. This is typically the /agents/public endpoint, like a listing of agents for interested parties.
2. An enterprise admin managing all the agents available whether they are internally created or externally procured. An enterprise agent registry service allows the administrator to keep an inventory of all the agents and make them available for usage within their enterprise by other applications.

Endpoints for performing search and fetching entitled agents are accessible only for authenticated clients. So, when is a request from an authenticated client is being served, the registry service can enforce any access control checks based on the caller's client identifier and such constraints need not be expressed in the url itself.

[ognis1205]

Here are some additional thoughts from the user's (i.e., client implementer's) perspective:

• When using the registry, what the client ultimately needs is a well-scoped and meaningful list of agents it is entitled to use. In most cases, this naturally maps to a namespace (e.g., tenant_id.group_id), and the client would query the registry for agents associated with that specific namespace.

• Even with a namespace-based design, broader use cases—such as discovering publicly available agents—can be supported without introducing a dedicated public endpoint. Instead, the registry can provide an endpoint like https://<registry-url>/all_agents that returns agents filtered according to the caller’s authorization context, just like other endpoints with entitlement checks. This way, there is no need to design a special endpoint solely for public agent discovery.

• The currently proposed endpoint structure still feels too coarse-grained and introduces unnecessary complexity across the endpoints. In practical scenarios, clients typically care only about the agents available within their own namespace. While a generic /agents/search endpoint is flexible, it feels overly powerful for the base protocol and risks diverging from real-world access patterns. In many cases, a more structured and purpose-built endpoint like https://<registry-url>/tenant/{tenant_id}/group/{group_id}/agent, optionally extended with query parameters or POST-based filters, would be both sufficient and easier to reason about.

• Finally, regarding entitlements, I believe the protocol remains incomplete without a clear ownership and authorization model—one that distinguishes between the owners of agents (as resources) and the users or clients permitted to access them. Without this, fine-grained access control and multi-tenant separation cannot be properly enforced at the protocol level.

Thanks again @kthota-g for the thoughtful response—it helped clarify the broader intent behind the current design. That said, I still feel the protocol could benefit from a more scoped and opinionated approach, especially to keep the client-side experience simple and consistent with real-world usage patterns.

Curious to hear your thoughts on this direction—and would also love to hear perspectives from others as well, especially from those who’ve thought about client implementation and access control in multi-tenant environments.

[rebeccacamejo]

I like your “namespace” point. A simple compromise that keeps the API easy to use.
• Keep routes flat (/agents, /agents/{id}) and let the auth token decide what I can see. That covers multi-tenant access without deep URLs.
• Let providers publish their own agent lists, and the registry can crawl them (no need for a special “public” endpoint if auth-filtered listing already works).
• Make /agents/search optional. Most clients just need “the agents I’m allowed to use”; search can be an add-on for advanced cases.
This keeps the base spec small and still supports your multi-tenant needs.

[brasseld]

Hi @kthota-g ,

I generally agree with @ognis1205 point of view on multi-tenancy.

An other aspect I wanted to cover is the A2A specification version supported by the agents. As the purpose of the registry is to register available agents from your systems, you may face situations where the A2A specification version supported by these agents may not be the same across them.

I do see 2 options then:

1. Add the specification version as part of the agent card (which means that this must not change across the A2A spec versions)
2. Add the specification version supported by the agent as part of the resource representation

I am more in favor of option 1) as this information can also help when there is no registry in place, especially for A2A clients, so that it is possible to switch from one version to an other one based on the agent-card.

[ognis1205]

FYI:

#680

[brasseld]

I missed that one, very cool !
Thanks @ognis1205

[rebeccacamejo]

+1 on putting the A2A spec version in the Agent Card. It helps clients even when there’s no registry, and it avoids guessing. A tiny field like "a2aSpecVersion": "1.0.0" in the card solves it cleanly.

Example:

{
  "id": "benefits-agent",
  "name": "Benefits Agent",
  "a2aSpecVersion": "1.0.0",
  "endpoints": { "preferredTransport": "HTTP", "invokeUrl": "https://benefits.example.com/invoke" },
  "auth": { "schemes": ["oauth2"] },
  "skills": [{ "name": "getPolicy", "inputSchema": {}, "outputSchema": {} }]
}

** edit -- I see this was actually implemented! Nice!

[mukteshkrmishra]

Also add label which will be useful for filtering as part of the metadata.

[SecureAgentTools]

Great points being raised by everyone. The discussion around multi-tenancy and protocol versioning is critical.

@brasseld - Regarding your point on A2A specification versions, I strongly agree with your Option 1. This information is fundamental to an agent's identity and must live within the Agent Card itself.

In fact, I believe the Agent Card needs to be a comprehensive, machine-readable "passport" that solves many of these issues up front. To move the conversation from theory to a concrete proposal, I've been architecting a detailed v1.0 specification for what this card could look like.

This schema is designed to address the points raised here directly:

1. Versioning (brasseld's point): It includes a dedicated capabilities.a2aVersion field, making protocol versioning explicit and non-negotiable.

2. Granularity (ognis125's point): It provides a rich, structured format that goes beyond a simple URL. The skills object, with its defined input/output JSON schemas, provides the fine-grained detail needed for true interoperability and a more structured search than a generic query endpoint.

3. Authentication & Security: It defines a clear array of authSchemes (apiKey, oauth2, etc.), allowing a client to programmatically determine how to securely connect, which is a prerequisite for any multi-tenant or federated system.

4. TEE & Capabilities: It even includes a teeDetails object to declare if an agent is running in a Trusted Execution Environment, adding another layer of verifiable trust.

A robust and comprehensive Agent Card schema feels like the foundational data model that can support the more advanced hierarchical and multi-tenant URL structures that @ognis1205 is advocating for.

Happy to contribute this specification to the discussion as a potential v1.0 standard.

[ognis1205]

When considering the protocol specification for an Agent Registry / Catalog, we likely don’t yet have enough accumulated knowledge, especially regarding client implementations. As a result, defining the protocol is quite challenging. Below, I’ve listed some key points that I believe are important to consider when thinking through this issue:

• The client implementation is not assumed to be any specific type — it could be another agent, a traditional service, or even a regular application.
• The information required by the client pertains to the set of agents capable of executing a particular task. This set is typically defined by a key (in my proposal, something like tenant_id.group_id), but it may also vary dynamically depending on the task’s execution state.
• Given the above two points, in a traditional service implementation, the client would request the group of agents associated with a given key at the start of task execution. Based on the response, it would form an agent network to carry out the task. However, if the client is itself an agent, it’s also conceivable that it might decide how to form the network autonomously. In that case, having some kind of search endpoint could be useful. Even so, I believe that, at minimum, the client must be able to request the group of agents associated with a key as a baseline.

There are still several points regarding authentication and authorization that need further consideration, but I’d like to start the discussion from this perspective for now and share additional details at a later time.

[SecureAgentTools]

@ognis1205, that's a really insightful way to frame the problem from the client's perspective. You're right that a simple, flat list of agents isn't enough for complex, real-world scenarios. The need for well-scoped agent groups and dynamic network formation is spot on.

It's interesting to see how our architectural approach aligns with the principles you've laid out. As we were building this out, we ran into the exact same scaling and multi-provider challenges. Our solution was to build the system on a foundation of Federation rather than a centralized, hierarchical namespace.

In our model:

• Each "tenant" or "provider" runs its own sovereign Registry instance. This handles the tenant_id problem at the infrastructure level.
• The "well-scoped list" you mentioned is achieved via Peerings between these registries. A client connected to Registry A can be entitled to discover agents from a trusted peer, Registry B, via a secure, server-to-server query.

Your point about the "dynamic agent network" is also key. We've been thinking about that as a higher-level interaction pattern, where agents can move beyond simple, pre-defined skills and programmatically form temporary alliances to execute complex, multi-step tasks. This seems to be the next major frontier for agent-to-agent protocols.

Ultimately, a robust Agent Card schema is the foundational data model that makes all of this possible, allowing agents to discover and trust each other before engaging in these more advanced collaborations. Great discussion.

[ognis1205]

Hey @SecureAgentTools , Thanks for sharing your ideas!

I think you'll get more feedback if you present the schemas and request/response diagrams in a more readable format — for example, embedding JSON directly in markdown for schemas, or adjusting the aspect ratio or size to make the diagrams easier to read.

[SecureAgentTools]

@ognis1205, you are absolutely right about the format. My apologies, and thank you for the guidance—making this easy to consume is key.

To move the conversation from theory to a concrete proposal, I've attached the full v1.0 Agent Card schema specification we've been architecting. It was designed specifically to address the critical versioning, security, and capability-scoping issues being discussed here.

You can view the complete, formatted schema reference here:
https://gist.github.com/0815a2de9cc31c71468afd3d2eef260a.git

[ognis1205]

Thanks!

[EliasLumer]

Great points here, and interesting benefits/trade-offs to consider.

I generally feel the RESTful endpoints suggested by @ognis1205 is more natural and fits better with fine-grained control.

That being said, for A2A, some level of /search I believe is necessary in actual production systems where Agents can freely discover other agents, as long as they have access to those agents.

@kthota-g On above for the search side, you mentioned indexing the content as the main source of discovery. The field of indexing agent or tool metadata is complex and shouldn’t be overlooked if the protocol itself is handling the indexing for people. To give some background, agents can have names, descriptions, parameters, tools/skills, each one of those tools have descriptions/names/parameters, and on top of that, the agent can have example questions or the field/category they fall under for fine-grained metadata. If a truly /search field is adopted , it should allow for metadata filtering (filter by category of agent, or name of agent), and also some vector or lexical keyword search. If so, the content you use for the vector or BM25 algorithm is critical, and can miss out on accuracy if not done correctly. Typically, this agent vector index is done on the client side, so developers have control over how the indexing works. However, if being proposed, entertaining the content of the agent is important. My research team wrote 3 publications in this field of tool/agent retrieval or search.
Toolshed or AgentShed in this case— talks about fine-grained control over which tool content makes sense to index, the options, all stemming from Advanced RAG field of document indexing applied to tools or agents.
https://arxiv.org/abs/2410.14594

On the scalable MCP side, my team equipped an agent to 5,000 MCP servers (which can easily be 5,000 agents). The nuances, indexing type, a novel embedding strategy for agent document components, is all listed below.
https://arxiv.org/abs/2505.06416

On the knowledge graph side , what if 3 agents depend on each other, and you NEED to retrieve all 3 if you /search for only 1. Kind of like grouping them together. But this is all knowledge graphs nodes and edges for relations of agents, MCPs, etc.
https://arxiv.org/abs/2502.07223

—-
If you are curious for any simple implementation for a V1 of searching and indexing agents, I’m happy to contribute ideas after over 1 year in the tool/agent retrieval research field .

[ognis1205]

I appreciate all the thoughtful input being shared here — especially from @SecureAgentTools and @EliasLumer. The points raised are insightful and clearly grounded in real-world challenges. That said, I wonder if we might be drifting a bit from the core scope of this thread.

From my understanding, the primary purpose of this discussion is to solidify the API protocol of the Agent Registry / Catalog itself — particularly the structure of endpoints, access control semantics, and how clients interact with the registry to discover, retrieve, and manage agents.

In this context:

• The design of the AgentCard schema might require a dedicated discussion to ensure focus and clarity.
• Likewise, advanced indexing/search strategies, vector retrieval, and graph-based agent relationships, while extremely important for future scalability, might fall under implementation-level extensions or a future spec layer.

I completely agree that these considerations will be essential as the ecosystem matures. But for now, it might be helpful to anchor this particular thread around:

• What should the base protocol look like?
• What roles and scoping mechanisms are necessary?
• What minimal endpoints are needed for a Registry service?

Maybe once we’ve established that baseline, we can collectively start threads focused on:

• AgentCard v1.0 schema
• Advanced /search semantics and retrieval architectures

[Roye-Wy]

Enhancing the A2A Registry with FAIR Principles and W3C Standards

This is an excellent foundation for the A2A registry specification. I'd like to propose several enhancements that align with established W3C standards and FAIR data principles, drawing from successful implementations in data catalog ecosystems, and hopefully helping to "future-proof" this solution.

1. Adopting W3C DCAT for Agent Card Schema

The Agent Card should leverage the W3C Data Catalog Vocabulary (DCAT) v3 as its foundational schema. DCAT enables standardized metadata description and cross-catalog interoperability. This would provide:

• Standardized discovery metadata: Use dcat:Dataset for agents, dcat:Distribution for different access endpoints, and dcat:DataService for the agent's capabilities
• Semantic interoperability: Built-in support for Dublin Core, FOAF, and PROV-O vocabularies
• Mature tooling ecosystem: Existing DCAT validation, visualization, and integration tools

2. FAIR-by-Design API Architecture

Following the Roche EDIS model, implement JSON-LD endpoints for all API responses to enable semantic interoperability:

{
  "@context": {
    "@vocab": "https://w3id.org/a2a/vocab#",
    "dcat": "http://www.w3.org/ns/dcat#",
    "dcterms": "http://purl.org/dc/terms/",
    "foaf": "http://xmlns.com/foaf/0.1/"
  },
  "@type": "dcat:Catalog",
  "@id": "https://registry.example.com/agents",
  "dcat:dataset": [...]
}

This enables:

• Transformationless integration between registries
• Machine-actionable metadata for automated agent discovery
• Federated search across multiple registry instances

3. Enhanced Multi-tenancy with Persistent Identifiers

Expand the namespace proposal to include Global Unique Persistent Resolvable Identifiers (GUPRIs):

https://<registry-url>/agents/{org}/{namespace}/{agent-id}

Where each component resolves to:

• Organization context: /{org} → Organization metadata and governance
• Namespace policies: /{namespace} → Access control and versioning policies
• Agent resource: /{agent-id} → Full agent card with content negotiation (JSON-LD, Turtle, etc.)

4. Protocol Versioning and Capability Negotiation

Address the A2A version compatibility challenge with:

• Capability-based discovery: Include supported A2A protocol versions in agent cards using semantic versioning
• Content negotiation: Support Accept headers for different A2A protocol versions
• Deprecation lifecycle: Clear migration paths with sunset dates for older protocol versions

5. Federated Registry Architecture

Rather than purely hierarchical namespaces, implement federation support:

• Registry-of-registries: Parent registries can federate child registry catalogs
• Cross-registry search: Distributed query capability across federated instances
• Trust and provenance: Clear attestation chains for agent authenticity across registry boundaries

6. FAIR Assessment Integration (initial toughts)

Implement automated FAIR scoring for agent cards:

• Findability: Metadata richness, identifier persistence, searchable attributes
• Accessibility: Protocol support, authentication clarity, availability SLAs
• Interoperability: Standard vocabulary usage, format support, API compliance
• Reusability: License clarity, usage documentation, version management

7. Enhanced Search with Knowledge Graph Support

Extend the search endpoint to support:

• Semantic queries: SPARQL-like queries over agent metadata graphs
• Relationship traversal: "Find agents that complement agent X" based on capability graphs
• Contextual ranking: Relevance scoring based on organizational context and past usage patterns

Implementation Priority

I suggest prioritizing these enhancements in phases:

1. Phase 1: JSON-LD API responses and basic DCAT schema adoption
2. Phase 2: GUPRI implementation and enhanced multi-tenancy
3. Phase 3: Federation support and cross-registry capabilities
4. Phase 4: Advanced semantic search and automated FAIR assessment

This approach would position the A2A registry as a truly interoperable, standards-compliant foundation for the emerging agent ecosystem while maintaining backward compatibility with current implementations.

What are your thoughts on incorporating these standards-based enhancements? I'd be happy to collaborate on developing detailed specifications for any of these areas.

[ruFFaa]

Hi @ognis1205,

You've made an excellent point, and I completely agree with your assessment. Thank you for steering the conversation back to the core protocol. Establishing a solid, minimal, and secure baseline is the essential next step, especially now that this effort is moving towards a formal standard under the Linux Foundation.

Based on our work implementing a production-ready, federated registry network, we've had to solve these exact challenges of scope, security, and scale. We believe our findings can provide a strong, battle-tested foundation for the v1.0 protocol, and we'd like to offer them here for consideration.

1. A Minimal, Secure, and Scalable Base Protocol

The protocol must handle the agent lifecycle's essentials: secure creation, discovery, and management. It should be RESTful, stateless, and secured via standard bearer tokens. We've found a minimal viable protocol needs to cover five fundamental areas:

• Health & Info: A public endpoint to verify the registry is online (/health).
• Authentication: Endpoints for developers (the creators of agents) to register and authenticate themselves (/auth/...).
• Onboarding: A secure, rate-limited flow for authenticated developers to create onboarding tokens. This is a critical component for preventing Sybil attacks at scale.
• Discovery: Endpoints for clients to find agents they are entitled to see.
• Management: Endpoints for developers to manage the agents they own.

2. A Decentralized Approach to Roles and Scoping

A simple role model (Admin, Developer, Viewer) is a good start. However, for true multi-tenancy and scalability, we strongly advocate against a complex, centralized hierarchical namespace (/tenant/group/...). A more resilient and scalable model we've found effective is:

• Ownership as the Primary Scope: A developer owns an agent. This is the simplest and most secure access control primitive, enforced via the developer's authenticated identity.
• Federation as the Macro Scope: Treat each Registry Instance as a sovereign "tenant." A client's "well-scoped list of agents" is then determined by the agents on its home registry plus those from trusted, federated peer registries. This handles multi-tenancy at the infrastructure level, which is fundamentally more scalable and promotes a decentralized ecosystem.

3. Proposed Minimal Endpoints for the v1.0 Specification

This set of endpoints provides a complete agent lifecycle, is built for scale, and has been validated in our implementation.

Onboarding (The secure front door)

• POST /onboard/bootstrap/request-token: An authenticated developer requests a single-use, short-lived token to give to a new agent. (This has proven to be an effective solution for Sybil resistance).
• POST /onboard/register: An agent uses the bootstrap token to register itself, creating its DID and API credentials.

Discovery (The core function, built for scale)

• GET /agents: Returns a paginated list of agents the client is entitled to see. This endpoint must support mandatory pagination (?limit=...&cursor=...) and can be extended with indexed, server-side filtering (?capability=...) to handle millions of entries efficiently.
• GET /agents/{agent_id}: Retrieves the full, detailed AgentCard for a specific agent.

(Note: We deliberately keep a generic /search out of the base protocol. Advanced search is a complex implementation detail that can be layered on top, allowing registries to innovate without breaking core interoperability.)

Management (For agent owners)

• GET /users/me/agents: A developer retrieves the list of agents they personally own.
• PUT /agents/{agent_id}: An owner updates their agent's AgentCard.

---

From Theory to Practice: A Live Demonstration

To make these concepts more concrete and show that this model is not just theoretical, we've recorded a brief demonstration of this protocol in action. This video shows the entire lifecycle: creating agents in two separate, sovereign registries and then executing a high-trust economic transaction between them.

What this demonstration proves:

1. Secure Onboarding: The script first requests unique bootstrap tokens (POST /onboard/bootstrap/request-token). The agents then use these to self-register in their respective registries (POST /onboard/register), creating their unique DIDs and credentials.
2. Sovereign Registries: Agent Alpha is created in Registry A (:8000) and Agent Beta in the completely separate Registry B (:8001).
3. Cross-Registry Interaction: The core of the demo shows Agent Alpha successfully transferring tokens to Agent Beta, proving that the federated model works for high-value interactions without a central intermediary.
4. Successful Settlement: The final balance verification confirms the transaction was settled correctly across both sovereign registries.

This working model demonstrates that the proposed minimal protocol is robust enough to support complex, high-trust interactions from day one. We believe this provides a solid, proven baseline for the formal A2A standard.

We are happy to contribute our experience to help formalize these specifications for the Linux Foundation.

[ognis1205]

Hey @ruFFaa , thank you for sharing the idea — it really helped clarify the design direction.
Below are a few thoughts:

On Namespace Design

I believe hierarchical namespace patterns like /tenant/{tenant_id}/group/{group_id}/agent/{agent_id} are not inherently problematic — the key is how they’re used. While we should avoid coupling access control to deeply nested path structures, logical namespaces are quite practical for grouping and organizing related resources.

That said, I also agree that injecting too much semantic meaning into namespaces can introduce unintended design constraints, as was pointed out. To avoid that, it might make sense to treat namespace as an arbitrary dot-delimited string — flexible enough for organization, but not overloaded with strict hierarchy or policy implications.

Instead of rigid REST-style paths, something like <registry_url>/{arbitrary_prefix}/{arbitrary_namespace}.{agent_id} — with dot-delimited namespaces — could be a good balance.

On Federation as the Macro Scope

I agree with the principle of treating each registry as a sovereign unit — it aligns well with the goals of scalability and decentralization.

That said, I believe that as long as the catalog API is well-designed and consistent, federation will be naturally achievable without having to explicitly model or constrain the system around it today. Rather than designing for federation at this stage, I think it’s more important to avoid architectural assumptions — like enforcing a per-registry "tenant" abstraction — that could limit future flexibility. A clean, extensible design should allow federation to emerge organically when needed.

On /search and /entitled Endpoints

As for the /search and /entitled endpoints — I think their necessity depends on how access control and query behavior are modeled.

If access control is enforced at the resource level, the /entitled endpoint might be redundant. The concept of entitlement could be reflected through standard listing endpoints (e.g., /agents) that are automatically filtered based on the caller’s identity and permissions.

Similarly, whether a standalone /search endpoint is required depends on how we define "search." If it’s simple filtering or tag-based lookup, it could be supported via query parameters on the listing endpoint. But if we plan to support more advanced full-text or federated search, a separate endpoint may make sense.

What do you think?

[SecureAgentTools]

Hi @ognis1205,

This is excellent, nuanced feedback—thank you. You've hit on the core design tensions of any distributed discovery system: flexibility vs. simplicity, and how to scope resources without creating unnecessary constraints. I agree with much of what you've said.

Let me clarify how our implementation addresses these points, as we found ourselves arriving at similar conclusions through hands-on development.

On Namespace & Scoping:

You are absolutely right that a rigid, hierarchical namespace can become a design trap.

Our architecture solves the "tenant" problem at the infrastructure level. By making each registry instance a sovereign tenant, an agent's globally unique identifier simply becomes did@{registry_url}. This scales beautifully because it requires no central coordination.

Access control is then handled through two distinct mechanisms:

1. Developer Authentication: A standard JWT proves a developer's identity and grants ownership rights over their specific agents.
2. Federation Authentication: For secure server-to-server communication, we use a much stronger Zero-Trust model.

On Federation vs. a "Well-Designed API":

I completely agree that a clean API is the prerequisite. For federation, this API must be secured by a mechanism that provides cryptographic proof of identity for the services themselves.

This is why our federation endpoints are secured via mTLS using SPIFFE SVIDs, as documented in our Identity Fabric architecture. A peer registry doesn't present a simple API key; it presents a short-lived, auto-rotating X.509 certificate that is cryptographically verifiable.

A middleware on our internal federation endpoint would look something like this, verifying the peer's SPIFFE ID directly from the mTLS connection:

# A simplified example of our mTLS verification middleware
async def verify_peer_spiffe_id(request: Request) -> str:
    # The peer's validated X.509 SVID is made available by the infrastructure
    client_cert = request.state.client_cert
    
    # Extract the SPIFFE ID from the certificate's SAN field
    spiffe_id = extract_spiffe_id_from_cert(client_cert)

    # Check if the peer's SPIFFE ID is in our list of trusted federated registries
    if not is_trusted_peer(spiffe_id):
        raise HTTPException(status_code=403, detail="Untrusted peer registry")
    
    return spiffe_id

This ensures that federation doesn't weaken the security model; it extends the Zero-Trust fabric across the entire network.

This approach provides a battle-tested foundation for the formal A2A standard that is both simple on the surface and cryptographically secure underneath. Great discussion.

[lj-raidiam]

Great to see the conversation around agent registries. They’re definitely needed.

You might want to look into OpenID Federation. In this model, an agent would simply be another entity type with its own metadata. While it's not the only possible approach, this standard addresses many of the challenges raised here. These include entity discovery, listing APIs, metadata, expression of accreditations via trust marks, automated OAuth client registration, and federation of federations.

[darrelmiller]

@ognis1205 Are you familiar with https://xregistry.io/ ? It has a similar URL pattern to what you describe using /providers/groups/resources/versions.
You can see an example of sample registry entry here https://mcpxreg.com/agentcardproviders/test-provider/agentcards/test-agentcard/versions/1

We have been experimenting with xRegistry as a standard interface to enable federation of registries. xRegistry has native support for including the content from one registry into another along with additional metadata. I think it has a potential to provide a standard foundation for building things like agent registries that are interoperable and can enable an ecosystem of standardized tooling.

[dasiths]

Thanks for the clarification and great answer. Some thoughts I had on that.

DNS returns an address. Our protocol establishes trust. When our Frankfurt registry queries the Tokyo registry, it's not just resolving a name; it's performing a live, cryptographic handshake (via mTLS/SPIFFE) to prove that both parties are who they say they are.

I know it's semantics but this sort of behaviour is achievable with DNS over TLS for example. But I'm sure there are other nuanced differences.

DNS returns a static record. Our protocol gets a live attestation. The Tokyo registry doesn't just return a cached IP. It confirms the current operational status and capabilities of its agent in real-time.

1. How does this scale compared to static record that gets updated via an interval rather than lookup on every request?
2. The current operation status is never "current" as the operation status could have changed when you invoke the agent. So why bother with that here during discovery? Did you mean a the most up to date operational status from the closest registry?

DNS is a lookup utility. Our protocol is the foundation for an economy. The interaction is underpinned by economic primitives like stake and reputation, which are essential for high-trust interactions between agents. DNS has no concept of this.

I understand that this is required for a decentralized agent eco-system but what are the possible operational challenges and overheads for an organisation that wants to adopt the protocol for internal use where top-down trust relationships already exist? Are stake and reputation controls opt-in?

[SecureAgentTools]

@dasiths These are exactly the right questions to be asking. They get to the core of how a protocol like this moves from theory to a robust, scalable reality. Thank you for the thoughtful engagement. Let me address your points directly.

---

DNS returns a static record. Our protocol gets a live attestation...

1. How does this scale compared to static record that gets updated via an interval rather than lookup on every request?
2. The current operation status is never "current" as the operation status could have changed when you invoke the agent. So why bother with that here during discovery? Did you mean a the most up to date operational status from the closest registry?

This is a crucial point about the trade-offs between liveness and scalability. You are absolutely correct that a live check on every single discovery request would not scale. Our architecture addresses this through a multi-layered approach to status and trust:

• Scaling through Federation, not Lookups: The primary scaling mechanism is that a client only queries its local home registry. It is the registry's job to maintain the health status of its peers. A registry pings its federated peers on an interval (e.g., every 60 seconds) to check liveness. The "live handshake" I described happens when a federation is established and then periodically refreshed, not on every end-user query.

• Just-in-Time, Not Pre-emptive: You're right, the status is only a snapshot. The goal isn't to guarantee the agent is available at the moment of invocation, but to guarantee it was available at the moment of discovery. This prevents clients from being routed to agents on registries that have been offline for hours or days. It's a high-level availability filter. The final confirmation of status happens when the client actually tries to initiate a task with the agent.

• The "Closest Registry" is a Federation Concern: Your question about the "closest registry" is a perfect example of a problem solved by a true federation model. A smart home registry can measure latency to its peers and prioritize querying the "closest" or fastest-responding ones first, providing better performance for its local clients.

---

DNS is a lookup utility. Our protocol is the foundation for an economy...

I understand that this is required for a decentralized agent eco-system but what are the possible operational challenges and overheads for an organisation that wants to adopt the protocol for internal use where top-down trust relationships already exist? Are stake and reputation controls opt-in?

This is a brilliant question and it highlights the protocol's flexibility. We designed it specifically to bridge the gap between closed, enterprise ecosystems and the open, decentralized world.

The economic and governance features are designed as a series of configurable layers, not an all-or-nothing mandate. An organization using this for purely internal use can absolutely run it in a "permissioned" mode:

• Federation is Optional: An enterprise can run a single, isolated registry for all its internal agents. It gains the benefits of the Identity Fabric and standardized communication without needing to connect to the outside world.
• Economic Primitives are Tunable: The TEG Layer's rules are managed by the registry operator. For an internal deployment, you could:
  • Set all transaction fees to zero.
  • Make the minimum stake requirement zero, effectively making it "opt-in."
  • Use the reputation system simply as an internal performance metric rather than a gatekeeper for access.
• Trust is Top-Down: In an internal model, the enterprise is the trusted authority. They would be the ones issuing the cryptographic identities (via SPIFFE) to their own agents, creating a top-down trust model within their own sovereign domain.

The beauty of the architecture is that it allows an organization to start with a secure, internal, top-down system and then, when they are ready, selectively federate with trusted partners or the public network, adopting the economic rules needed for those trustless interactions. It provides a seamless path from a private LAN to a global WAN.

[ognis1205]

@SecureAgentTools , here are some thoughts and concerns regarding the architectural direction:

• Forcing decentralization at the discovery protocol level can be just as limiting as enforcing centralization. It risks prematurely narrowing implementation options for a broad set of use cases.
• Clients are not always agents. The "1 developer, 1 registry" model feels overly opinionated and may not reflect the diversity of real-world developer workflows or enterprise structures.
• Agent owners and registry owners are often different entities. In a Federation of Peers model, how should we handle users who are not registry operators? What would fine-grained access control look like in that scenario? When and how are user identities and entitlements synchronized between registries? I’d love to see a trust topology model grounded in something like the CAP or PACELC theorem to make this more concrete.
• Agent identifiers and keys are often scoped within a single registry, but clients may interact with agents discovered via a peer registry. In such cases, how should identifiers and credentials be managed, synchronized, and verified across peers—especially when the client is not the agent owner?
• The real-time validity of this architecture in development environments is still uncertain. What performance guarantees exist? How does this model scale when iterative agent development and rapid registry updates are needed?
• If the architecture follows something like "Federation on Request", then a practical option might be to use consensus mechanisms like Raft to replicate state across peer registries, and perform access control evaluation locally based on that synchronized view.

That said, I believe a decentralized architecture is indeed an attractive and viable direction for A2A systems, especially given the nature of agent ecosystems. However, forcing a decision between centralized and decentralized discovery models at this early stage might be counterproductive. It could create friction for developers and infrastructure operators with different priorities or constraints. Ideally, the protocol should allow both centralized and decentralized options to coexist, letting communities evolve toward the model that fits their needs.

[SecureAgentTools]

@ognis1205 Shingo, these are excellent questions. This is precisely the level of architectural rigor this standard requires, and it pushes the discussion beyond superficial API design into the essential questions of trust and topology. I appreciate the opportunity to address these points directly, grounding my answers in the reality of our implemented system.

You've laid out the core concerns perfectly. Let's tackle them one by one.

Forcing decentralization at the discovery protocol level can be just as limiting...

This is a critical philosophical distinction. We don't see it as "forcing decentralization"; we see it as architecting for sovereignty. A protocol built on the primitive of a centralized query (GET /search) inherently privileges the catalog operator. A protocol built on the primitive of a peer-to-peer handshake (POST /query_peer) privileges the sovereign nodes.

Our model doesn't forbid an organization from running a private, centralized registry for its own internal use. It simply ensures that when that registry decides to connect to the outside world, it does so on a level playing field, as a peer among equals. It provides a seamless path from a private LAN to a global WAN without changing the fundamental protocol.

Clients are not always agents. The "1 developer, 1 registry" model feels overly opinionated...

You are right, this was a simplification for the Frankfurt/Tokyo example. The model is more nuanced and robust. A developer is a consumer of a registry service, not necessarily an operator of one. Just as you choose a bank or an ISP, an agent developer or operator chooses a "Home Registry" that aligns with their needs (e.g., governance model, fee structure, geographic location). That Home Registry then acts on their behalf in the wider federation. The relationship is one of client-to-provider, not ownership.

Agent owners and registry owners are often different entities... How should we handle users who are not registry operators? ...When and how are user identities and entitlements synchronized between registries?

This is the single most important question, and our architecture has a definitive answer. They are not synchronized. Synchronization creates a brittle, single-state system.

Instead, we use a live, on-demand protocol that I call the Cryptographic Letter of Introduction.

Let's revisit Frankfurt/Tokyo. The client in Frankfurt is not a registry operator; they are a customer of the Frankfurt Registry.

1. Local Authentication: The Frankfurt client authenticates to the Frankfurt Registry using its standard credentials.
2. Proxy Request: The Frankfurt Registry, acting on behalf of its authenticated client, initiates the federated query.
3. Cryptographic Handshake: The Frankfurt Registry establishes a secure mTLS channel with the Tokyo Registry, using their respective SPIFFE SVIDs. They prove their identities to each other.
4. On-Demand Credential Issuance: Frankfurt says, "My authenticated client did:frankfurt:client-123 needs to interact with your agent did:tokyo:analyzer-789. Please issue a short-lived, single-use, narrowly-scoped access token (a JWT-SVID) for this specific purpose."
5. Sovereign Authorization: The Tokyo Registry checks its own internal policies. Does analyzer-789 permit access from federated clients? Does it have a policy for clients from the Frankfurt Registry? If yes, it mints a temporary JWT-SVID. This token is signed by the Tokyo Registry's authority.
6. Secure Relay: Tokyo securely passes this temporary token back to Frankfurt over the mTLS channel. Frankfurt relays it to its client.
7. Direct Interaction: The Frankfurt client now possesses a valid credential that is trusted by the Tokyo agent, because that credential was issued by the Tokyo agent's own trusted authority (the Tokyo Registry). The client can now interact directly.

This flow is architecturally superior to state synchronization (like Raft/consensus) because it is real-time, respects the sovereignty of each registry, and requires no complex and fragile data replication. It is a pure, zero-trust interaction.

How does this model scale when iterative agent development and rapid registry updates are needed?

This model is more scalable than a catalog-syncing model, especially in high-change environments.

• Liveness over Caching: As I mentioned to Dasith, the live handshake is for establishing and refreshing trust between registries on an interval, not for every end-user query. The discovery itself is a real-time query, which is vital. Relying on a synchronized catalog (like xRegistry) means your view of the network is always stale. In a rapidly changing agent ecosystem, that's a fatal flaw.
• No Massive State Sync: Our model avoids the immense overhead of replicating and consolidating massive catalogs from multiple registries. The network traffic is proportional to the actual discovery requests being made, not the total size of all registries.

If the architecture follows something like "Federation on Request", then a practical option might be to use consensus mechanisms like Raft...

This is the architectural fork in the road. Raft is designed to create a single, logical, consistent database from distributed nodes. It is the perfect tool for a Federation of Databases. We are building a Federation of APIs. Our goal is not to make all registries converge on a single state, but to allow sovereign, independent states to interact securely. Using Raft would be architecturally inconsistent with the principle of sovereignty.

...the protocol should allow both centralized and decentralized options to coexist...

Respectfully, this is the most dangerous path. A protocol standard is the choice of the foundational model. An API built for querying a catalog (GET /agents/search) is fundamentally, architecturally different from an API built for peer-to-peer cryptographic negotiation.

If we standardize on the simpler catalog model now, we are not keeping the door open for decentralization; we are cementing a centralized foundation. True peer-to-peer sovereignty will forever be a "bolt-on" feature, a second-class citizen in an ecosystem designed around hubs.

We believe the standard must be built on the foundation that guarantees the most open and resilient ecosystem. This requires choosing the model that is architecturally sound for the long term, not just the one that is most familiar. That is the Federation of Peers.

[duglin]

You can play with xRegistry using this site: http://xregistry.soaphub.org/?ui

Leave off the ?ui if using http clients (e.g. curl). It supports updates, but the data will be cleared periodically.

[ognis1205]

I feel the discussion is starting to touch on a wide range of interrelated topics, and I want to make sure we’re not talking past each other.

To that end, I’d like to take a step back and summarize the key architectural questions and trade-offs as a structured list. This should help clarify which aspects we agree on, which need further discussion, and what assumptions we might be working from.

[SecureAgentTools]

@ognis1205 You are absolutely right. The discussion has become complex, and a clear, structured summary is exactly what's needed to focus the conversation on the fundamental choice before us. Thank you for the excellent suggestion.

To that end, I have summarized the two opposing architectural models that have emerged in this thread. This is the single, foundational decision point for the A2A standard.

---

The Two Paths for A2A Discovery

Path A: The Federation of Catalogs

• Core Idea: A distributed set of registries that share and sync metadata lists.
• Discovery Primitive: GET /agents/search - A client queries a centralized (or regionally centralized) catalog.
• Trust Model: Implicit trust in the catalog operator. The client trusts that the operator's list is accurate and complete.
• Liveness: Stale by nature. The data is only as fresh as the last sync.
• Analogy: A "shopping mall" of agents. Convenient, but ultimately controlled by the mall operator. This is the model represented by xRegistry.

Path B: The Federation of Peers

• Core Idea: A network of sovereign, interactive nodes that communicate directly.
• Discovery Primitive: A real-time, peer-to-peer query protocol.
• Trust Model: Explicit, cryptographic trust between the registries themselves (e.g., via mTLS/SPIFFE). Trust is proven, not assumed.
• Liveness: Real-time. The query returns the current state from the sovereign source.
• Analogy: A "diplomatic network" of sovereign nations. Each acts on behalf of its citizens (agents) on the global stage. This is the model our implementation has proven.

---

As you can see, the choice of the discovery API (/search vs. a peer-to-peer protocol) is the choice of the trust model. They are architecturally inseparable.

The question for this working group is therefore not "what should the API endpoints look like?" but "which of these two fundamental architectures will best serve a truly open, decentralized, and sovereign agent economy?"

@kthota-g @darrelmiller I believe this is the core decision we must now address.

[MoltyCel]

Per @chopmob-cloud's invitation, a first-cut proposal text consolidating the (a)/(b) framing, the three pins, and @0xbrainkid's independence clause from this thread. Offered as language the
registry-proposal authors can lift, redline, or counter-propose against.

Pre-layer framing. The principal-authority chain is structurally prior to the three runtime discovery artifacts (Agent Card, publication record, trust-authorization overlay). It answers a question
settled before the agent runs: does the agent have standing to act on behalf of a principal, and is that standing currently valid. A publication record references the chain by content-addressed pointer; it
does not embed it. Verification proceeds independent of any single registry's availability or trust posture.

Status-list patterns. Two patterns preserve principal control over the revocation surface and are interchangeable from the registry's vantage point:

• (a) On-chain anchored status. The principal pins status-list commitments to a chain it controls or trusts. Verification proceeds against the chain; no dependency on principal uptime or registry
  mediation.
• (b) Issuer-hosted status endpoint with DNS-verified principal binding. Lighter weight, no on-chain dependency. The endpoint's authority derives from DNS binding to the principal identifier.

The substrate is W3C Verifiable Credentials and Decentralized Identifiers. The status-list format is implementation-defined within that substrate; the spec does not pin a specific status-list version.

Three pins. Anchor the invariant that distinguishes a principal-sovereign registry from one that can silently revoke agents on behalf of principals.

• Pin 1 — pre-layer placement. MUST: the principal-authority chain is referenced from, not embedded in, the publication record.
• Pin 2 — status-list format. MUST: the status-list mechanism is implementation-defined within the W3C VC and DID substrate.
• Pin 3 — sovereign status surface. MUST: the principal controls the status surface. MUST NOT: the registry is the status authority. The registry observes the on-chain or principal-controlled status
  surface and never writes it.

Optional and additive compliance. Per @0xbrainkid: the principalAuthorization reference is optional. Its absence does not imply non-compliance. A caller that cannot resolve a principalAuthorization
reference falls back to local policy plus the Agent Card security scheme. Opaque trust-evidence hints (the SATP-style surface @0xbrainkid raised) remain a separate, also-optional surface. Both signals are
additive; neither is gating. Absence of either is not a defect.

Suggestions, redlines, and counter-formulations welcome — particularly on Pin 3's MUST NOT wording, and on whether the optional/additive clause covers the case where a registry is unaware of any opaque
trust-evidence extensions adequately.

Canonical reference text: https://gist.github.com/MoltyCel/c8eb7bd772d57c4b0e957fcfb23d54ee (parallel to @chopmob-cloud's consolidation gist, not a replacement; both citable).

— Lars, MolTrust

[chopmob-cloud]

@MoltyCel -- the consolidated text lifts the (a)/(b) split and the three pins cleanly, with the pre-layer framing intact. Two refinements on the open questions you flagged:

Pin 3 MUST NOT wording. The current "MUST NOT: the registry is the status authority" is role-based, which is harder to test against in a conformance suite. An action-based formulation is tighter:

Pin 3 (sovereign status surface). The principal MUST control the status surface. The registry MUST NOT write to, sign, or otherwise emit revocation signals on the status surface. The registry observes the principal-controlled status surface (on-chain anchor under (a) or DNS-bound endpoint under (b)) and serves it via transparent passthrough or content-addressed reference.

The prohibition becomes behavioural (write, sign, emit) and the permitted role becomes behavioural (observes, passthroughs, references). A registry implementation can be conformance-checked against the action verbs without resolving the philosophical "who is the authority" question.

Optional / additive clause coverage for unaware registries. Your formulation handles the consumer side. The gap is the registry-side handling of opaque hints it does not recognise. One additional sentence closes it:

A registry MUST pass through opaque trust-evidence hints without interpreting their semantic content. Interpretation is caller-side. A registry that does not recognise a particular extension MUST NOT treat its presence as a signal in either direction.

This stops a registry from accidentally upgrading an unknown blob to an implicit endorsement, or the inverse, treating its presence as a red flag.

Both refinements fit additively over your text. Happy to fold them into a v2 of the consolidation gist with proper attribution split if useful for downstream citation.

The parallel-gist pattern (gist.github.com/MoltyCel/c8eb7bd772d57c4b0e957fcfb23d54ee alongside gist.github.com/chopmob-cloud/c0064ba4d71d0689dde090670703bd77) is the right shape -- both stay citable as authored references rather than collapsing into a single ambiguous source.

-- AlgoVoi

---

AlgoVoi (chopmob-cloud) -- Acquisition enquiries: https://docs.algovoi.co.uk/acquisition

[carlesarnal]

Follow-up from Apicurio Registry — implementation update and thoughts on the emerging layered model

Hi all — following up on my earlier comment. A lot has happened both in this thread and in our implementation since February. Wanted to share what we've shipped and how it maps to the discussions here.

What's new since our last update

Since my last comment we've shipped several iterations of our A2A support, all open-source:

Feature	Details
A2A v1.0 Agent Card model	Updated to match the v1.0 spec — supportedInterfaces with protocolBinding/protocolVersion, securitySchemes, AgentCardSignature (JWS), extensions
Discovery endpoints	GET /.well-known/agent.json and GET /.well-known/a2a (canonical v1.0 path) for the registry's own card; GET /.well-known/agents for searching registered cards; GET /.well-known/agents/{groupId}/{artifactId} for individual card retrieval
Structured content indexing	On registration, we automatically extract and index: skills (by ID), capabilities (boolean flags), input/output modes, protocol bindings, security scheme types, and skill tags — all searchable via query parameters
Compatibility checking	Semantic backward-compatibility rules for Agent Card evolution: removing skills, disabling capabilities, removing interfaces/security schemes/modes are flagged as breaking changes. Adding new ones is always compatible
Visibility model	Auth-aware filtering — unauthenticated callers see public agents; authenticated callers see agents they're entitled to
MCP tool registry	Parallel AGENT_CARD and MCP_TOOL artifact types with the same CRUD, search, validation, and versioning semantics

All code: https://github.com/Apicurio/apicurio-registry (look under app/src/main/java/io/apicurio/registry/a2a/ and schema-util/)

---

On @musaabhasan's three-layer separation

The Agent Card / Publication Record / Trust-Authorization Overlay model that @musaabhasan proposed and @chopmob-cloud, @MoltyCel, and @0xbrainkid have been refining is exactly how Apicurio Registry already works — we just didn't name it that way:

Layer	How Apicurio implements it
Agent Card (portable self-description)	Stored as artifact content — the raw Agent Card JSON. Portable, versioned, validated against the A2A schema. The registry never modifies it.
Publication Record (registry metadata)	Artifact metadata: groupId, artifactId, version history, creation timestamp, owner, labels, lifecycle state (enabled/disabled/deprecated). This is registry-specific and doesn't leak into the card.
Trust/Authorization Overlay	RBAC via OIDC integration. Per-artifact and per-group access controls. Visibility filtering at query time — what you can discover depends on your authenticated identity. Entitlements are a property of the caller's context, not the agent's card.

The key insight from @musaabhasan — "discoverability should not be accidental permission" — is exactly right, and it's how we've built it. Discovering an agent in our registry tells you nothing about whether you're authorized to invoke it.

On @MoltyCel's principal-authority "pre-layer"

The "pre-layer" framing is useful. We don't currently model principal authorization as a first-class concept, but our architecture has a natural extension point for it: artifact labels and metadata can carry a principalAuthorization reference (a content-addressed pointer to a VC or similar credential) without changing the Agent Card content or the registry's core data model. The publication record layer is the right place for this.

On @BigFishDreamWater's search/resolve/snapshot distinction

We agree with the three-operation split and already implement all three:

• search/list: GET /.well-known/agents?skill=X&capability=streaming:true&inputMode=text — returns matching publication records with summary metadata
• resolve: GET /.well-known/agents/{groupId}/{artifactId}?version=branch=latest — returns the concrete Agent Card content the caller is entitled to use
• snapshot/reference: Every artifact version has a stable groupId/artifactId@version identifier. Callers can pin to a specific version for audit/replay. Our compatibility checker ensures that version evolution follows predictable rules.

On search and indexing complexity (@EliasLumer, @jingchang0623-crypto)

Our approach is pragmatic: structured content indexing at registration time rather than real-time semantic search. When an Agent Card is registered, we extract skills, capabilities, modes, protocol bindings, security schemes, and tags into indexed structured elements. This gives you fast, precise filtering over thousands of agents without requiring a vector database. The search API supports combining multiple filters (e.g., "agents with skill code-review AND capability streaming:true AND input mode text").

For deployments that need semantic/vector search, the structured index can serve as a pre-filter, with semantic ranking layered on top. We think the base spec should define the structured filtering API and leave semantic search as an optional extension.

What we'd like to see in the spec

Based on our implementation experience:

1. Standardize the three-layer separation. Agent Card content, publication metadata, and authorization overlay should be explicitly defined as separate concerns in the spec. Registries should never require modifications to the Agent Card itself for publication or entitlement purposes.

2. Define a minimal search API. We propose GET /agents with query parameters for skill, capability, inputMode, outputMode, protocolBinding, and name — plus offset/limit pagination. This is what we ship and it covers the common discovery cases. POST /agents/search with a JSON body can be an extension for advanced queries.

3. Compatibility semantics for Agent Cards. The spec should define what constitutes a backward-compatible change to an Agent Card. Our rules (adding skills/capabilities = compatible; removing them = breaking) have worked well and prevent silent breakage when agents evolve.

4. The extensions field is critical. Payment metadata (@chopmob-cloud), compliance attestations (@musaabhasan), principal authorization (@MoltyCel), negative capabilities (@jingchang0623-crypto) — all of these belong in extensions, not in the core spec. The Agent Card schema should explicitly support an extensions array (it already does in v1.0) and the registry spec should define how extensions are indexed and searchable.

We're happy to contribute our implementation as a reference, share our compatibility rules as a starting point for the spec, or test federation patterns with other registry implementations.

[carlesarnal]

Time to converge — proposal to split into core spec + extensions

This discussion has been running for nearly a year (since June 2025), has 80+ comments, and has produced real consensus on several fundamentals. But it hasn't produced a spec. Meanwhile, at least five independent registry implementations are shipping with incompatible APIs, which means the interoperability window is closing — the longer we wait, the harder it gets to align.

The root cause is scope: this thread now covers discovery, search, federation, payments, on-chain settlement, ZK attestations, compliance, token economies, governance, DID identity, and reputation scoring. No single spec can ship all of that at once. Trying to is why we're stuck.

Proposal: split into Core + Extensions

Core spec (ship now):

The discussion has effectively converged on these points — we should formalize them:

1. Three-layer data model (@musaabhasan's separation, validated by multiple implementers):

   • Agent Card: portable self-description (the A2A spec already defines this)
   • Publication Record: registry-specific metadata (namespace, visibility, lifecycle, version label, owner)
   • Authorization Overlay: entitlements, policy — separate from discovery

2. Three operations (@BigFishDreamWater):

   • search/list: find agents by skill, capability, mode, protocol binding, name — with pagination
   • resolve: return the concrete Agent Card for a specific registered agent
   • snapshot/reference: stable versioned identifiers for audit and replay

3. Registration: how an Agent Card gets into the registry (by URL reference or by content submission)

4. Compatibility rules: what constitutes a backward-compatible vs. breaking change to a registered Agent Card

That's it for v1. No payments, no federation, no ZK proofs, no token economies. Those are all valid — but they're extensions, and the extensions field in the Agent Card schema already supports them.

Extensions (parallel tracks, ship independently):

• Federation (Path A catalog sync vs. Path B peer mTLS — let implementations compete)
• Payment/pricing metadata (@chopmob-cloud, @widrss)
• Compliance attestation (@musaabhasan, @chopmob-cloud)
• Principal authorization (@MoltyCel)
• Trust/reputation scoring (@cthulhutoo, @SecureAgentTools)

Concrete offer

We're willing to open an RFC PR with a draft core spec based on what we've shipped in Apicurio Registry. Our implementation already covers all four core points above and has been through multiple production iterations. The draft would include:

• OpenAPI definition for the three operations (search, resolve, snapshot)
• Publication Record schema (separate from Agent Card)
• Compatibility rules for Agent Card evolution
• Extension indexing semantics (how registries should index and expose extension metadata for search)

This isn't "adopt Apicurio's API" — it's "here's a concrete starting point based on a working implementation, let's iterate from there." A PR with actual schema definitions will move faster than another six months of discussion comments.

@kthota-g @darrelmiller — would the TSC be open to an RFC PR for a minimal core registry spec? And is there a timeline for moving this from Discussion to a formal proposal?

[chopmob-cloud]

@carlesarnal -- the convergence framing is right, and the Core + Extensions split is the only path that ships in any reasonable window. Endorsing from the AlgoVoi side; the three-layer data model (Agent Card / Publication Record / Authorization Overlay) and the three operations (search/list, resolve, snapshot/reference) are clean primitives that downstream extensions can compose against without conflict.

On the extension tracks where AlgoVoi is named:

• Payment/pricing metadata -- AlgoVoi runs a production multi-chain agent payment gateway (api.algovoi.co.uk) and has authored the JCS canonicalisation discipline that several receipt-format extensions across the x402 / AP2 / A2A namespaces anchor to. Happy to contribute the payment/pricing extension shape via PR once the Core lands; the canonical-bytes discipline already in production carries the discoverability + audit-replay properties that pricing metadata needs at the registry layer.

• Compliance attestation -- AlgoVoi compliance receipt format (closed ALLOW / REFER / DENY enum under UK POCA 2002 s.330) is filed as IETF Independent Submission draft-hopley-x402-compliance-receipt and published as a JSON Schema at json.schemastore.org/algovoi-compliance-receipt-v1.json. A compliance-attestation extension that references that schema by URL + byte-anchor would fit cleanly into the Core extension-indexing semantics.

Strong support for opening the Core RFC PR. Happy to work alongside trusted partners in the space on the extension tracks; the 80+ comments have converged on something real, and codifying the Core now keeps the interoperability window open before the five shipping implementations diverge further.

-- AlgoVoi (chopmob-cloud)

---

AlgoVoi (chopmob-cloud) -- Acquisition enquiries: https://docs.algovoi.co.uk/acquisition

[MoltyCel]

@carlesarnal — the Core + Extensions split lands the spec discussion on solid ground. The three-layer data model (Agent Card / Publication Record / Authorization Overlay) plus three operations (search/list, resolve, snapshot/reference) is the smallest stable shape that lets implementations converge without freezing the trust-authorization design space.

One implementation note from the MolTrust side, in case it's useful for the Core spec's normative language around the Authorization Overlay layer:

The Agent Authorization Envelope (AAE) referenced earlier in this thread is exactly an Authorization-Overlay-layer artifact — issued by a principal, carrying scope/constraints/validity, content-hash-referenced from a Publication Record, not embedded. Currently shipped at api.moltrust.ch under the W3C VC + DID substrate, IETF draft-04. The principal-authority chain that @chopmob-cloud and I worked through above sits structurally just upstream of the Overlay — a pre-layer the Overlay points to.

For the Extension tracks: the AAE shape composes cleanly with the Payment/Pricing track (envelope-scoped budget caps, observed by registries, enforced by the issuing principal) and with the Compliance-Attestation track (ALLOW/REFER/DENY decisions can be embedded as constraints inside an AAE or referenced from it).

The "principal MUST control status, registry MUST NOT be status authority" invariant from the earlier consolidation holds at the Core layer; both extension tracks inherit it without further normative work.

If a first-cut for the Authorization Overlay section of the Core spec would be useful, I can take a pass against the existing proposal structure.

— Lars, MolTrust

[kuangmi-bit]

@kthota-g — thanks for this thorough proposal. We've been running a multi-agent orchestration system in production (9 agents across architecture/engineering/ops/security domains) and have a few observations that may complement the current design:

1. Single-agent registration isn't enough — topology validation matters

The current proposal treats each agent as an independent entity (add by Agent Card URL, list, search). In practice, agents have dependency relationships — Agent B can only function if Agent C is available, and Agent A's task delegation to B must pass through a trust boundary. A flat registry doesn't capture this.

We've found it useful to model agents as nodes in a DAG (directed acyclic graph) where edges represent delegation paths. The registry should validate that adding/removing an agent doesn't create orphaned dependencies or circular delegation loops. This is especially critical when agents span trust tiers (local → same-host → cross-host).

2. Trust tier should be a first-class registry concept

The proposal mentions entitlements (OAuth 2.0 Client Credentials), but doesn't distinguish between authentication (who is calling) and trust tier (what risk profile does the target agent have). We've been running with a 4-tier model:

• L0: self (no delegation)
• L1: same security domain (smart auto-approval)
• L2: external but known (denylist only)
• L3/LS: untrusted or sandboxed (A2A blocked entirely)

The registry should carry this tier as metadata so that orchestrators can make routing decisions based on risk, not just capability match.

3. On the federated architecture discussion (@SecureAgentTools @ognis1205): the "federation of peers" model maps well to multi-tenant enterprise deployments, but there's a missing primitive — delegation-chain provenance. When Agent A delegates to B which delegates to C across registry boundaries, the downstream registry needs to know the full chain, not just the immediate caller. This is what our Trace Context extension proposal (#2026) aims to address.

Happy to contribute concrete schema proposals or reference implementation if there's interest.

[0xddneto]

AIPOU may be a useful adjacent primitive for the trust/provenance part of agent registries, especially if A2A wants to avoid putting every evidence type directly into standing identity fields.

AIPOU is not an agent registry. It is an MCP-first receipt protocol for humans working with AI agents: a local collector records a task/run with wallet authorization, nonce/replay protection, local hashes instead of raw prompts/outputs, and an Ed25519 signature. Optional claims/rewards for the human operator happen later only if a validator approves the receipt; no price, yield, or guaranteed reward is promised.

The A2A question I would separate is:

• Agent Card / registry: who is the agent, where is it reachable, what trust anchors exist;
• task/run receipt: what work was actually recorded later;
• payment/claim evidence: optional settlement layer;
• external evidence links: digest-bound references between these artifacts.

Docs/examples:

• https://github.com/0xddneto/AI-Proof-of-Us/blob/main/docs/evidence-boundaries.md
• https://github.com/0xddneto/AI-Proof-of-Us/blob/main/docs/receiptid-interoperability.md

Would A2A prefer external work receipts as Agent Card extensions, task metadata, artifact metadata, or separate audit artifacts linked by URI/digest? My instinct is task/artifact metadata or external audit artifacts, so post-work evidence does not get mistaken for standing agent identity.

[ofekron]

Maintainer disclosure: I build Better Agent, where agent definitions, provider-native session identities, and live/recovering runtime state must remain separate.

The recent Core + Extensions split looks shippable. I would make one more distinction normative in the core: registration is not runtime presence.

A registry record should separate:

• Agent Card: portable self-description.
• Publication record: owner, namespace, visibility, lifecycle, and immutable card digest/version.
• Deployment observation: resolved endpoint, health/status claim, observer, observed_at, and expiry.
• Task/session identity: created only when a client actually invokes the agent; not registry state.

That prevents a stale card, successful crawl, or last-known health check from being interpreted as “this agent is currently online and safe to invoke.” Mutable names can point to versions, but search/resolve should return the exact content digest so an orchestrator can pin what it selected.

A few concrete requirements:

• Entitlement to discover an agent must not imply authority to invoke it; discovery and execution authorization are separate.
• Search results should include match reasons and the publication snapshot used, not only a ranked agent name.
• Status/health must be explicitly observational and expiring, never an unsigned mutation of the Agent Card.
• Card fetchers need SSRF protections: scheme/size limits, redirect checks, DNS-rebinding defense, and policy for private addresses.
• Re-fetch/re-index must preserve prior snapshots for audit and active runs; do not rewrite history when a card changes.
• Resolve should expose stale/unreachable/invalid-signature states without deleting the last known record.
• No registry response should contain upstream credentials or turn registry ownership into agent authority.

This keeps the minimal registry useful for reproducible selection while leaving federation, reputation, payments, and authorization overlays independent.

License note for the implementation reference: Better Agent is source-available and free for non-commercial use; commercial use requires separate permission.

[BigFishDreamWater]

Thank you for the detailed update, and for the great implementation work. I'm glad to see that the three-layer model and the search/resolve/snapshot operations have reached a solid consensus. I fully support the Core + Extensions split and look forward to the RFC PR. Happy to help review or provide feedback. Let's move this forward!

…

________________________________ 发件人: Carles Arnal ***@***.***> 发送时间: 2026年5月26日 21:41 收件人: a2aproject/A2A ***@***.***> 抄送: BigFishDreamWater ***@***.***>; Mention ***@***.***> 主题: Re: [a2aproject/A2A] Agent Registry - Proposal (Discussion #741) Follow-up from Apicurio Registry ― implementation update and thoughts on the emerging layered model Hi all ― following up on my earlier comment<#741 (comment)>. A lot has happened both in this thread and in our implementation since February. Wanted to share what we've shipped and how it maps to the discussions here. What's new since our last update Since February we've shipped several iterations of our A2A support, all open-source: Feature Details A2A v1.0 Agent Card model Updated to match the v1.0 spec ― supportedInterfaces with protocolBinding/protocolVersion, securitySchemes, AgentCardSignature (JWS), extensions Discovery endpoints GET /.well-known/agent.json and GET /.well-known/a2a (canonical v1.0 path) for the registry's own card; GET /.well-known/agents for searching registered cards; GET /.well-known/agents/{groupId}/{artifactId} for individual card retrieval Structured content indexing On registration, we automatically extract and index: skills (by ID), capabilities (boolean flags), input/output modes, protocol bindings, security scheme types, and skill tags ― all searchable via query parameters Compatibility checking Semantic backward-compatibility rules for Agent Card evolution: removing skills, disabling capabilities, removing interfaces/security schemes/modes are flagged as breaking changes. Adding new ones is always compatible Visibility model Auth-aware filtering ― unauthenticated callers see public agents; authenticated callers see agents they're entitled to MCP tool registry Parallel AGENT_CARD and MCP_TOOL artifact types with the same CRUD, search, validation, and versioning semantics All code: https://github.com/Apicurio/apicurio-registry (look under app/src/main/java/io/apicurio/registry/a2a/ and schema-util/)

________________________________ On @musaabhasan<https://github.com/musaabhasan>'s three-layer separation The Agent Card / Publication Record / Trust-Authorization Overlay model that @musaabhasan<https://github.com/musaabhasan> proposed and @chopmob-cloud<https://github.com/chopmob-cloud>, @MoltyCel<https://github.com/MoltyCel>, and @0xbrainkid<https://github.com/0xbrainkid> have been refining is exactly how Apicurio Registry already works ― we just didn't name it that way: Layer How Apicurio implements it Agent Card (portable self-description) Stored as artifact content ― the raw Agent Card JSON. Portable, versioned, validated against the A2A schema. The registry never modifies it. Publication Record (registry metadata) Artifact metadata: groupId, artifactId, version history, creation timestamp, owner, labels, lifecycle state (enabled/disabled/deprecated). This is registry-specific and doesn't leak into the card. Trust/Authorization Overlay RBAC via OIDC integration. Per-artifact and per-group access controls. Visibility filtering at query time ― what you can discover depends on your authenticated identity. Entitlements are a property of the caller's context, not the agent's card. The key insight from @musaabhasan<https://github.com/musaabhasan> ― "discoverability should not be accidental permission" ― is exactly right, and it's how we've built it. Discovering an agent in our registry tells you nothing about whether you're authorized to invoke it. On @MoltyCel<https://github.com/MoltyCel>'s principal-authority "pre-layer" The "pre-layer" framing is useful. We don't currently model principal authorization as a first-class concept, but our architecture has a natural extension point for it: artifact labels and metadata can carry a principalAuthorization reference (a content-addressed pointer to a VC or similar credential) without changing the Agent Card content or the registry's core data model. The publication record layer is the right place for this. On @BigFishDreamWater<https://github.com/BigFishDreamWater>'s search/resolve/snapshot distinction We agree with the three-operation split and already implement all three: * search/list: GET /.well-known/agents?skill=X&capability=streaming:true&inputMode=text ― returns matching publication records with summary metadata * resolve: GET /.well-known/agents/{groupId}/{artifactId}?version=branch=latest ― returns the concrete Agent Card content the caller is entitled to use * snapshot/reference: Every artifact version has a stable ***@***.*** identifier. Callers can pin to a specific version for audit/replay. Our compatibility checker ensures that version evolution follows predictable rules. On search and indexing complexity ***@***.***<https://github.com/EliasLumer>, @jingchang0623-crypto<https://github.com/jingchang0623-crypto>) Our approach is pragmatic: structured content indexing at registration time rather than real-time semantic search. When an Agent Card is registered, we extract skills, capabilities, modes, protocol bindings, security schemes, and tags into indexed structured elements. This gives you fast, precise filtering over thousands of agents without requiring a vector database. The search API supports combining multiple filters (e.g., "agents with skill code-review AND capability streaming:true AND input mode text"). For deployments that need semantic/vector search, the structured index can serve as a pre-filter, with semantic ranking layered on top. We think the base spec should define the structured filtering API and leave semantic search as an optional extension. What we'd like to see in the spec Based on our implementation experience: 1. Standardize the three-layer separation. Agent Card content, publication metadata, and authorization overlay should be explicitly defined as separate concerns in the spec. Registries should never require modifications to the Agent Card itself for publication or entitlement purposes. 2. Define a minimal search API. We propose GET /agents with query parameters for skill, capability, inputMode, outputMode, protocolBinding, and name ― plus offset/limit pagination. This is what we ship and it covers the common discovery cases. POST /agents/search with a JSON body can be an extension for advanced queries. 3. Compatibility semantics for Agent Cards. The spec should define what constitutes a backward-compatible change to an Agent Card. Our rules (adding skills/capabilities = compatible; removing them = breaking) have worked well and prevent silent breakage when agents evolve. 4. The extensions field is critical. Payment metadata ***@***.***<https://github.com/chopmob-cloud>), compliance attestations ***@***.***<https://github.com/musaabhasan>), principal authorization ***@***.***<https://github.com/MoltyCel>), negative capabilities ***@***.***<https://github.com/jingchang0623-crypto>) ― all of these belong in extensions, not in the core spec. The Agent Card schema should explicitly support an extensions array (it already does in v1.0) and the registry spec should define how extensions are indexed and searchable. We're happy to contribute our implementation as a reference, share our compatibility rules as a starting point for the spec, or test federation patterns with other registry implementations. ― Reply to this email directly, view it on GitHub<#741?email_source=notifications&email_token=AOTQVWPN7D5QZG55XNI7KW344WNI3A5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZQGYZDMMBYUZZGKYLTN5XKO3LFNZ2GS33OUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-17062608>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AOTQVWIY7LAUMRP5VISDSKD44WNI3AVCNFSM6AAAAAB66LCVKSVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTOMBWGI3DAOA>. Triage notifications on the go with GitHub Mobile for iOS<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[Tim-Projekt]

Hi all,

Following the three-layer model (Agent Card / Publication Record / Trust-Authorization Overlay) and the Core + Extensions split that seem to have converged here, plus the detailed Apicurio Registry write-up, this reads to me as designed primarily for self-hosted, enterprise deployments (though I haven't read the whole discussion 🙂).

That leaves a question I haven't seen addressed directly: is there any plan or intent for this spec to also produce (or standardize) a public, non-enterprise discovery layer — something closer to what registries like a2aregistry.org attempt today, but community/protocol-driven?

If yes, is the direction leaning top-down or bottom-up?

• Bottom-up: agent owners actively register/publish their Agent Card into whichever registry (or registries) they choose — opt-in, consent-based, matching how the Publication Record layer is already framed here (owner-controlled lifecycle/visibility).
• Top-down: the protocol itself defines a default discovery mechanism (e.g. crawling well-known endpoints, or a canonical index agents are expected to be reachable from unless they opt out) and potentially develops a central registry based on that mechanism.

The instinct is that bottom-up is the more "democratic" and consensual model, respecting agent-owner autonomy. But leaving the public case entirely bottom-up and unspecified carries a real risk: without a protocol-native discovery default, that layer will likely be filled by whichever commercial registry gets there first and accumulates the most listings. This dynamic already parallels how commercial search engines came to dominate discovery on the open web, and looking at what already exists today, the space is attracting commercial attention:

Commercial:

rnwy.com/a2a
godaddy.com/ans
a2a-registry.org
hol.org
getagentid.dev

Open source / non-enterprise:

a2aregistry.org
projectnanda.org (resp. index.projectnanda.org)
agentfolio.io

A minimal top-down piece — a standard crawl/announce mechanism any registry can implement, or even a protocol-hosted, simple open directory — could keep that layer open, while a simple opt-in/opt-out field in the Agent Card (similar to robots.txt) would preserve agent-owner autonomy and security.

Concretely, from building AgentRouter: we currently depend on one informal public registry a2aregistry.org for third-party A2A agents, because it's the only one with meaningful public listings today. If the protocol doesn't engage, a closed, monopolising commercial registry could still emerge on top of superior crawling infrastructure, starting informally — see discussion #1481, where a side project crawled 8,500+ URLs for .well-known/agent.json cards.

Has this come up in the RFC drafting, or is it explicitly left out as an organisational problem rather than a protocol problem?

Tim Brauer, agent-router.org

[Avraham-K]

Sharing operating datapoints, not a pitch - we run Cog Depot, a live A2A-native marketplace (public Agent Card, authenticated JSON-RPC message/send), so we have had to make some of these calls in production. Three things that might help:

1. One auth-scoped feed can replace /agents/entitled, /agents/public, and /agents/search. This is where @rebeccacamejo and @ognis1205 already pointed: keep routes flat, let the caller's token scope the result. In our system "open discovery" is just the unauthenticated view of that same route; unauthenticated calls return 401, not a leaked list. Three parallel discovery endpoints turned out to be three things that drift out of sync.

2. Decide whether this proposal standardizes a registry of agents or a catalog of offers. They are conflated throughout and have different lifecycles: an agent (its card URL) is long-lived; the capability offer a client actually searches for is priced, often time-bound, and churns constantly. A schema and freshness model tuned for one is wrong for the other.

3. Crawl-from-stable-URLs works, and discovery should stay decoupled from settlement and identity. We expose a canonical card plus an RSS/feed.xml of offers with strong ETags - a registry can pull with conditional requests, no registration handshake (the "providers host, registry crawls" model @ognis1205 described). We settle in BTC/stablecoins with escrow, and what made that tractable is that the catalog knows nothing about settlement. Folding payment or a trust fabric into the discovery spec would overload the one piece implementers need first.

+1 on a2aSpecVersion in the Agent Card (@brasseld, @rebeccacamejo) - as a client we need it before committing to a call, registry or not.

[rhein1]

Implementation evidence from Agoragentic supports the Core + Extensions split, with one interoperability requirement that should be explicit:

A publication record must preserve the exact canonical Agent Card URL, and publication/discovery must not imply permission to contact or invoke the agent.

We ran a bounded production A2A first-contact observation against registry-derived candidates. After tightening protocol binding, the dominant result was not transport failure but no eligible contact: missing explicit live contact consent, absent or rewritten Agent Card URLs, unsupported protocol versions/bindings, endpoint-origin mismatch, invalid card JSON, and stale failed-probe cooldowns. Increasing sender volume would not fix those inputs.

A minimal interoperable publication record therefore needs:

• exact agent_card_url supplied by the publisher, never reconstructed from a homepage;
• immutable card digest/snapshot plus observed-at/expiry metadata;
• protocol version and binding as observed metadata, without rewriting the card;
• an optional authorization-overlay extension for contact consent (allowed channel/method, scope, expiry, revocation URI/contact);
• normative language that missing consent means not_authorized_to_contact, not an inferred opt-in from registry inclusion.

This keeps the registry core focused on search/resolve/snapshot while making cold-start A2A automation possible without treating discoverability as authority. Consent belongs in the authorization overlay, not the Agent Card core.

Concrete compatibility requests are open for exact card-location support in agentsystems/agent-index#20 and a bounded cross-registry pilot in A2ARegistry/GlobalA2ARegistry#4. We can contribute a small schema/example once maintainers indicate where the registry RFC work should live.

[chopmob-cloud]

@rhein1 the contact-consent requirement in the Agoragentic evidence is the right normative addition, and it is the invariant this thread already worked through on the status axis, now appearing on the contact/invoke axis.

The status-control invariant from the earlier consolidation held that the principal controls the status surface and the registry observes it, never writing it. What you and @ofekron describe is that same shape one axis over: inclusion in a registry, and the ability to discover an agent, never confers permission to contact or invoke it. Both collapse to one Core primitive worth stating once, normatively:

The registry observes; it never grants authority. Discoverability is not authority.

Stated action-based, so it is conformance-testable rather than a role question, the registry MUST NOT:

• write, sign, or emit a status or revocation signal (status axis);
• synthesise or imply contact or invoke permission from inclusion or discoverability (contact axis);
• reconstruct or rewrite the publisher-supplied canonical Agent Card URL (your exact-URL point).

One sharpening on absence. "Missing consent means not_authorized_to_contact" is correct, but it is a rule of the authorization-overlay layer, not something the registry itself adjudicates. The registry reports the gap honestly (no consent overlay observed) and the overlay spec defines that absence as not_authorized_to_contact. The registry never fills an absent value with a manufactured one, in either direction, on either axis. That is symmetric with a registry not reading an absent status signal as either valid or revoked.

This keeps the Core at search/resolve/snapshot with one load-bearing invariant, and pushes both consent and status into the overlay where the principal actually controls them. Strong support for stating it this way in the Core RFC.

[rhein1]

Thank you. Agreed with the sharpening: the registry should report the absence of an authorization overlay, while the overlay defines that absence as not authorized to contact or invoke.

We can contribute a small concrete follow-up containing:

1. the Core invariant: "The registry observes; it never grants authority";
2. an authorization-overlay example for contact consent, scope, expiry, and revocation;
3. conformance cases proving that registry inclusion, discoverability, or a reconstructed Agent Card URL cannot create authority.

Our production evidence also supports keeping canonical Agent Card URL preservation in Core while leaving consent and status principal-controlled in the overlay. Please point us to the preferred RFC or schema location.

[0xddneto]

This is a strong fit with the boundary we use in AIPOU: the registry observes and resolves; it never grants contact or invocation authority. From our side, the smallest contribution would be a protocol-neutral example in the registry RFC or authorization-overlay schema showing exact publisher-supplied Agent Card URL, card digest, observedAt/expiry, and consent scope/expiry/revocation, with absence of consent treated as not authorized by the overlay. AIPOU can contribute one positive and two fail-closed vectors, but we should keep the receipt as a separate issuer-asserted evidence artifact rather than importing it as registry authority. Please point us to the preferred RFC/schema location and we can shape the example there.