Hi — I maintain the agent-registry work in Apicurio Registry (an LF project). We store A2A AgentCards and MCP tool definitions as versioned artifacts, and I'm implementing /.well-known/ai-catalog.json as a projection over our existing storage so the registry can be crawled by ARD/AI-Catalog clients.
I've hit a design question that I think affects every existing registry adopting the standard, not just us, and I couldn't find it addressed in the spec.
The tension
The spec strongly recommends (and ARD mandates, for federation) the identifier form:
urn:air:<publisher>:<namespace>:<name>
But existing registries already have their own stable, globally-meaningful artifact identity:
- Apicurio keys artifacts by
groupId / artifactId (plus version).
- The MCP Registry keys servers by name.
- OCI registries key by repository path + tag.
When such a registry projects its content into a catalog, there are two plausible mappings and they have different trade-offs:
Option A — synthesize urn:air: from the registry's own coordinates.
e.g. urn:air:registry.example.com:<groupId>:<artifactId>.
- ✅ Stable, unique, no extra user input.
- ❌ The
<publisher> segment becomes the registry's domain, not the artifact publisher's domain. For a multi-tenant registry hosting artifacts from many organizations, this conflates the host with the publisher, which seems to cut against the "domain-anchored trust anchor" rationale in Appendix C.
Option B — require/allow the artifact to declare its own urn:air: publisher.
e.g. the publisher sets it in metadata, and the registry surfaces it verbatim.
- ✅ Preserves the publisher-as-trust-anchor semantics.
- ❌ Breaks the "no extra infrastructure / progressive complexity" goal — now every publisher must mint and manage URNs, and the registry must validate that the declared publisher domain actually matches the serving domain (otherwise trivial namespace squatting, which Appendix C is explicitly trying to prevent).
What I did (for now)
I went with Option A as the default, with the publisher domain configurable, because it is the only option that works with zero publisher friction. But I'm not confident it's the intended reading, and I suspect other registry implementers are hitting the same fork.
Ask
Could the spec add guidance (or normative text) on:
- Whether the
<publisher> segment, when served from a registry, is meant to be the registry operator or the artifact publisher?
- If it's the artifact publisher, what the registry's verification obligation is before it serves a
urn:air: identifier it didn't mint?
- Whether a registry-native identifier (e.g. an
https:// URL to the artifact, or an OCI ref) is acceptable as the identifier when urn:air: can't be honestly constructed — Appendix C reads as "MUST be urn:air: for federated systems", which is hard to satisfy truthfully in case (1)-vs-(2) above.
Happy to open a PR with example text once there's a rough consensus on direction. I can also walk through the concrete implementation on a community call if that's easier.
Thanks!
Hi — I maintain the agent-registry work in Apicurio Registry (an LF project). We store A2A
AgentCards and MCP tool definitions as versioned artifacts, and I'm implementing/.well-known/ai-catalog.jsonas a projection over our existing storage so the registry can be crawled by ARD/AI-Catalog clients.I've hit a design question that I think affects every existing registry adopting the standard, not just us, and I couldn't find it addressed in the spec.
The tension
The spec strongly recommends (and ARD mandates, for federation) the identifier form:
But existing registries already have their own stable, globally-meaningful artifact identity:
groupId/artifactId(plus version).When such a registry projects its content into a catalog, there are two plausible mappings and they have different trade-offs:
Option A — synthesize
urn:air:from the registry's own coordinates.e.g.
urn:air:registry.example.com:<groupId>:<artifactId>.<publisher>segment becomes the registry's domain, not the artifact publisher's domain. For a multi-tenant registry hosting artifacts from many organizations, this conflates the host with the publisher, which seems to cut against the "domain-anchored trust anchor" rationale in Appendix C.Option B — require/allow the artifact to declare its own
urn:air:publisher.e.g. the publisher sets it in metadata, and the registry surfaces it verbatim.
What I did (for now)
I went with Option A as the default, with the publisher domain configurable, because it is the only option that works with zero publisher friction. But I'm not confident it's the intended reading, and I suspect other registry implementers are hitting the same fork.
Ask
Could the spec add guidance (or normative text) on:
<publisher>segment, when served from a registry, is meant to be the registry operator or the artifact publisher?urn:air:identifier it didn't mint?https://URL to the artifact, or an OCI ref) is acceptable as theidentifierwhenurn:air:can't be honestly constructed — Appendix C reads as "MUST beurn:air:for federated systems", which is hard to satisfy truthfully in case (1)-vs-(2) above.Happy to open a PR with example text once there's a rough consensus on direction. I can also walk through the concrete implementation on a community call if that's easier.
Thanks!