Research & Interoperability Analysis: ANS Draft, AI Catalog, and Agent Finder

AF_vs_ANS_overview.md

Agent Finder × ANS — Interoperability Analysis

How Agent Finder / AI Catalog (discovery + semantic search) and the Agent Name Service (ANS) (domain-anchored identity + verification) fit together — written for the people who maintain each.

One-line thesis: they are different layers and they stack. Agent Finder answers "what agents exist and which one fits my need?" ANS answers "who is this agent, and is it provably the real one?" The highest-value work is wiring them at one seam — search semantically, verify cryptographically.

ANS already designs for this: its architecture decouples identity (the Registration Authority) from discovery (independent Discovery Services that subscribe to its event stream). Agent Finder is a natural Discovery Service. Neither side has to absorb the other's hard problem.

---

What's in this gist

• project_profiles.md — what each system is: naming, discovery, trust model, protocol coverage.
• interoperability_analysis.md — the integration: mapping, the seam, and the concrete to-do / payoff for ANS maintainers and for Agent Finder maintainers.

---

The short version, per maintainer group

If you maintain ANS

• You do: publish a stable, subscribable event stream / Transparency Log feed and a documented resolution + /root-keys verification path that a non-ANS Discovery Service can consume without bespoke integration. Keep the client-side Protocol Adapter emitting A2A / MCP / OpenAPI cards.
• You get: a discovery and ranking surface you don't have to build. ANS resolves and verifies; it doesn't do semantic search or "best fit." Agent Finder brings the users and the query UX to your verified identities — distribution for the trust layer.

If you maintain Agent Finder / AI Catalog

• You do: add ANS as an identity scheme in the trustManifest (an ans:// identity + the cert / Transparency-Log pointers), and an optional verify step between discovery and activation. No core spec change — both slot into the existing extension surface and the registry ingestion layer.
• You get: verifiable, domain-anchored identity for catalog entries — the one thing the catalog carries but cannot itself prove — plus a "verified" signal you can rank and filter on. That's the feature enterprises ask for when they worry about agent sprawl and impersonation.

---

Living document. Last updated 2026-06-02.

interoperability_analysis.md

Interoperability: Agent Finder × ANS

How to wire semantic discovery (Agent Finder / AI Catalog) to domain-anchored verification (ANS). The thesis: search semantically, verify cryptographically. This document is organized around what each maintainer group has to do and what they get.

---

1. The seam

ANS already splits its world into two halves:

• the Registration Authority (RA) — owns identity, issues dual certificates, seals lifecycle events into a SCITT-aligned Transparency Log;
• Discovery Services — independent indexers that subscribe to the RA's event stream and build whatever search experience they want.

Agent Finder is a Discovery Service. That is the entire integration in one sentence: Agent Finder indexes ANS-verified identities for search; at selection time, a client verifies the identity against ANS before it acts. No layer has to swallow the other.

  user / orchestrator
        │  "find me a HIPAA sentiment analyzer"   (semantic)
        ▼
  ┌─────────────────────────┐     subscribe / ingest     ┌──────────────────────┐
  │  Agent Finder registry  │ ◀───── event stream ────── │  ANS RA + Transparency│
  │  (Discovery Service)     │                            │  Log + dual-cert PKI  │
  └─────────────────────────┘                            └──────────────────────┘
        │  ranked result carrying ans:// + cert/log pointers
        ▼
  client runs ANS verify (cert chain + OCSP/CRL + optional log proof)   (cryptographic)
        │  passes → activate & invoke
        ▼
  A2A / MCP / OpenAPI endpoint

---

2. Identifier mapping

A catalog entry carries the ANS identity rather than re-inventing it.

ANS	Agent Finder / AI Catalog entry
ANSName = ans://v<semver>.<agentHost>	trustManifest.identity (verbatim ans://…)
agentHost (FQDN, domain-anchored)	publisher / domain of the entry
version (semver)	version
Identity Certificate (ans:// URI SAN)	attestation pointer in trustManifest
Transparency Log inclusion proof	optional attestation pointer (enables Gold-tier checks)
Server Certificate (FQDN SAN)	the entry's url host, TLS-verified at call time

Concrete ai-catalog.json entry with an ANS identity (uses the existing extension surface — no core schema change):

{
  "humanReadableId": "example.com/sentiment-analyzer",
  "type": "application/mcp-server+json",
  "version": "1.0.0",
  "url": "https://api.example.com/mcp/sentiment.json",
  "description": "HIPAA-compliant text sentiment analyzer.",
  "trustManifest": {
    "identity": "ans://v1.0.0.sentiment-analyzer.example.com",
    "identityType": "ans",
    "attestations": [
      { "type": "ans-identity-cert", "uri": "https://example.com/.well-known/ans-identity-cert.pem",
        "mediaType": "application/x-x509-ca-cert" },
      { "type": "ans-transparency-receipt", "uri": "https://ra.example/ans/receipts/abc123" }
    ]
  }
}

---

3. For ANS maintainers — what you do, what you get

What you need to do

1. Make the event stream consumable by outsiders. A non-ANS Discovery Service should be able to subscribe to RA lifecycle events (register / renew / revoke) and backfill, with stable record IDs and the ans:// name on every event. This is the single most important enabling step for adoption.
2. Document the verifier path for third parties. Publish how an external service/client fetches /root-keys, validates the dual certs, checks OCSP/CRL, and (for Gold) requests a Transparency Log inclusion proof — without bespoke per-integrator work.
3. Keep the client-side Protocol Adapter emitting standard cards. A2A / MCP / OpenAPI translation already produces artifacts a catalog can envelope by media type; keep those outputs stable so a Discovery Service can map them 1:1 to catalog entries.
4. Expose tier metadata per record (Bronze / Silver / Gold) so a Discovery Service can surface assurance as a filterable, rankable signal.

What you get

• Distribution and a discovery UX you don't have to build. ANS resolves and verifies; it has no semantic search or "best fit" ranking. Discovery Services like Agent Finder bring the natural-language query surface and the users to your verified identities.
• Pull-through for higher tiers. When assurance is a visible, sortable signal in a popular search surface, publishers have a concrete reason to climb from Bronze toward Gold.
• Reach across protocols without runtime coupling — your single RA payload, surfaced through a registry that already speaks A2A/MCP/OpenAPI envelopes.

---

4. For Agent Finder / AI Catalog maintainers — what you do, what you get

What you need to do

1. Add identityType: "ans" to trustManifest. A small, additive scheme alongside DID/SPIFFE, carrying the ans:// identity plus pointers to the identity cert and (optionally) a Transparency Log receipt. Use the existing URI-identified extension mechanism — no core-spec change.
2. Build an ANS ingestion source in the registry. Subscribe to (or crawl) an ANS RA's event stream and map each verified agent to a catalog entry (Section 2). This mirrors how the reference registry ingests other sources today; it's ingestion-plugin work, not a protocol change.
3. Add an optional verify step between discovery and activation. After a match, validate the ANS cert chain + OCSP/CRL (and a log proof for Gold) before activating/invoking. Gate it: entries without an ans identity behave exactly as today.
4. Surface "verified" as a first-class facet. Let users filter/sort by ANS presence and assurance tier in search results.

What you get

• The one thing the catalog can't do itself: provable identity. trustManifest carries DID/SPIFFE claims but nothing adjudicates them. ANS supplies a real authority — domain-anchored, dual-cert, revocable, tamper-evident — so your trust signals finally have a root of trust behind them.
• An enterprise-grade differentiator. "Search across agents, return only domain-verified ones, sorted by assurance" directly answers the agent-sprawl and impersonation worries enterprises raise. It's also the pattern already shipping in industry (MuleSoft Agent Fabric consuming GoDaddy-registered ANS identities) — being the open-ecosystem counterpart is a credible position.
• No reinvention cost. You consume an identity layer instead of building PKI, ACME, revocation, and a transparency log yourself — work that is squarely ANS's job, not a registry's.

---

5. Recommended path

1. Define identityType: "ans" in trustManifest (Agent Finder side) and a documented, third-party verifier + event-subscription contract (ANS side). These two are the whole interface.
2. Ship an ANS ingestion source in the Agent Finder reference registry — immediate value, no spec changes on either side.
3. Expose assurance tier as a search facet, which creates the incentive loop that pulls publishers toward higher ANS tiers.

Net: keep discovery and identity as separate layers, and connect them at exactly one seam. Agent Finder finds and ranks; ANS proves and resolves. Search semantically, verify cryptographically.

---

Sources

• ANS: IETF draft-narajala-courtney-ansv2 (ANSName grammar; domain-anchoring via ACME; dual Server/ Identity certs with ans:// URI SAN; OCSP/CRL [RFC 6960]; /root-keys; SCITT-aligned append-only Transparency Log; Bronze/Silver/Gold tiers; RA-publishes-events / independent-Discovery-Services split; client-SDK Protocol Adapter for A2A / MCP / OpenAPI).
• Agent Finder / AI Catalog: github.com/Agent-Card/ai-catalog (.well-known/ai-catalog.json; media-type envelopes; advisory humanReadableId; optional trustManifest with DID/SPIFFE; URI-identified extension mechanism) and agentfinder-project.github.io.
• Industry proof point: MuleSoft Agent Fabric × GoDaddy ANS (verified discovery + governance).

project_profiles.md

Project Profiles: Agent Finder / AI Catalog and ANS

What each system actually is — naming, discovery, trust, and protocol coverage — so maintainers on either side can see exactly where their surface ends and the other's begins.

---

1. Agent Finder / AI Catalog

What it is. A discovery layer. AI Catalog is a typed, nestable JSON container published at /.well-known/ai-catalog.json that indexes heterogeneous AI artifacts (MCP servers, A2A Agent Cards, OpenAPI tools, skills) by IANA media type. Agent Finder is the registry/search layer on top that makes that index queryable in natural language.

Naming & identifiers. Entries are referenced by media type + url, with version and an advisory humanReadableId (org/agent-name). Identifiers are logical and stable; the physical endpoint is a separate url. There is no mandated global naming authority.

Discovery. Static well-known manifests, crawled into a registry index; the registry exposes semantic search and structured filtering. Discovery dynamics (ranking, search API) live in the registry, deliberately outside the catalog core.

Trust & identity. An optional trustManifest carries identity (DID, SPIFFE), attestations, provenance, and detached signatures. New identity schemes are added via the URI-identified extension mechanism — no core-spec change required. Key property: the catalog carries identity claims but does not adjudicate them. There is no authority that proves a given key actually owns the agent.

Protocol coverage. Artifact-agnostic envelope via media types (application/mcp-server+json, application/a2a-agent-card+json, OpenAPI, etc.). It does not govern execution protocols.

Net for the seam: strong at what / which / find me; intentionally empty at prove who.

---

2. Agent Name Service (ANS)

What it is. A domain-anchored identity and verification layer for agents — DNS + PKI for the agentic web. Crucially for integration, ANS separates identity from discovery: a Registration Authority (RA) owns identity and publishes lifecycle events; independent Discovery Services subscribe to that event stream and build their own searchable indexes.

Naming & identifiers. Canonical ANSName:

ANSName  = "ans://v" version "." agentHost
version  = 1*DIGIT "." 1*DIGIT "." 1*DIGIT        ; semantic version
agentHost = FQDN (RFC 1035 / RFC 1123)

Example: ans://v1.0.0.sentiment-analyzer.example.com. Identity is anchored to a DNS domain, with ownership verified by the RA via ACME.

Trust & identity (dual-certificate PKI).

• Server Certificate — X.509 from a public CA, dNSName SAN for the agent's stable FQDN.
• Identity Certificate — from a private CA on the RA's behalf, carrying a URI SAN with the ans:// scheme (something no public CA will issue).
• Revocation propagates via standard OCSP / CRL (RFC 6960). Verifiers fetch RA verification keys from /root-keys so they can check signatures without calling the RA on every lookup.

Transparency Log. An append-only, SCITT-aligned log seals every lifecycle event (e.g. the hash of an agent's registration metadata) and yields inclusion/consistency proofs — tamper-evident registration history with interoperable receipts.

Assurance tiers. Clients pick assurance to match transaction risk:

Tier	Requires
Bronze	PKI
Silver	PKI + DANE
Gold	PKI + DANE + Transparency Log verification

Resolution & lifecycle. An Agent Hosting Platform registers via the RA's /register endpoint (metadata, version, endpoints); the RA verifies domain ownership, issues the dual certs, and seals the metadata hash into the log. Agents renew before expiry; the RA re-checks policy and reissues.

Protocol coverage. A client-side SDK Protocol Adapter translates A2A Agent Cards, MCP manifests, and OpenAPI documents into the RA's single registration payload — so the RA accepts one format regardless of agent protocol.

Net for the seam: strong at prove who / resolve where / tamper-evident history; not a search or ranking surface, by design — that's what Discovery Services (like Agent Finder) are for.

---

3. Where the surfaces meet

Dimension	Agent Finder / AI Catalog	ANS
Primary job	Discover + rank by capability	Anchor identity + verify + resolve
Naming	Media type + url + advisory humanReadableId	ans://v<semver>.<fqdn>
Discovery	Registry semantic search over well-known manifests	RA event stream → independent Discovery Services
Trust	Carries claims (trustManifest: DID/SPIFFE/JWS)	Adjudicates: domain-anchored dual-cert PKI, OCSP/CRL, Transparency Log, Bronze/Silver/Gold
Protocols	Media-type envelopes (A2A/MCP/OpenAPI)	Client-SDK adapter → single RA payload (A2A/MCP/OpenAPI)
The gap it has	Cannot prove identity	Cannot rank / "find me the best X"

The two gaps are each other's core competency. That is why the integration is additive for both sides, not a competition — detailed in interoperability_analysis.md.