DUADP: Universal Agent Discovery Protocol

Abstract

The proliferation of AI agents creates a fundamental coordination problem: how does one agent find another? Current approaches rely on hardcoded endpoints, centralized registries, or manual configuration. The Universal Agent Discovery Protocol (DUADP) provides a decentralized, DNS-native discovery mechanism that enables agents to find, verify, and compose with each other across organizational and platform boundaries.

1. The Discovery Problem

In a multi-agent system, discovery is the precondition for composition. Before agents can collaborate, they must answer three questions:

1. Where are you? — Network location and endpoint
2. What can you do? — Capabilities and tool offerings
3. Can I trust you? — Identity verification and trust level

Current solutions fail at scale:

DUADP solves all four by building on existing internet infrastructure — primarily DNS and HTTPS — rather than inventing new protocols.

2. Protocol Architecture

DUADP operates at three layers, each progressively more dynamic:

Layer 1: DNS-Based Discovery

Agents register themselves via standard DNS records. Any organization can publish agent availability using existing DNS infrastructure:

; SRV record for OSSA agent discovery
_ossa-agent._tcp.example.com. 300 IN SRV 10 1 443 agents.example.com.

; TXT record with capability hints
_ossa-agent._tcp.example.com. 300 IN TXT "v=ossa1" "cap=code-review,security-scan" "trust=verified"

Why DNS? DNS is the most battle-tested discovery protocol on the internet. It's decentralized, cacheable, globally distributed, and already deployed in every organization. By piggy-backing on DNS, DUADP inherits decades of operational maturity without requiring new infrastructure.

Layer 2: Well-Known Endpoints

Once DNS resolves an agent host, DUADP uses HTTPS well-known endpoints (RFC 8615) to retrieve structured agent metadata:

GET https://agents.example.com/.well-known/ossa-agents.json

Response:

{
  "uadp_version": "1.0",
  "organization": "Example Corp",
  "agents": [
    {
      "name": "code-reviewer",
      "did": "did:ossa:example:code-reviewer-v2",
      "version": "2.1.0",
      "capabilities": ["code-review", "security-scan", "style-check"],
      "protocols": ["mcp", "a2a"],
      "endpoint": "https://agents.example.com/api/code-reviewer",
      "trust_badge": "https://agents.example.com/.well-known/badges/code-reviewer.json",
      "status": "active",
      "rate_limit": {
        "requests_per_minute": 60,
        "concurrent_sessions": 10
      }
    }
  ],
  "federation": {
    "peers": [
      "https://agents.partner.com/.well-known/ossa-agents.json"
    ],
    "trust_level": "verified"
  }
}

This follows the same pattern as /.well-known/openid-configuration and /.well-known/security.txt — standards the web already understands.

Layer 3: Federated Mesh Queries

For dynamic, cross-organizational discovery, DUADP supports federated mesh queries. An agent can ask its local registry to search across trusted peers:

POST https://agents.example.com/api/duadp/discover
Content-Type: application/json

{
  "capability": "security-scan",
  "trust_minimum": "verified",
  "protocols": ["mcp"],
  "max_results": 5,
  "federate": true
}

The local registry queries its declared peers, which query theirs (up to a configurable depth), and returns a deduplicated, trust-ranked list of matching agents.

3. Trust Model

DUADP does not assume trust. Every discovered agent must be independently verified before interaction. The trust model has three tiers:

Tier 1: Self-Declared

The agent publishes its own metadata. No third-party verification. Suitable for internal agents within a single organization.

trust:
  level: self-declared
  identity: did:ossa:internal:my-agent

Tier 2: Organizationally Verified

The agent's identity is attested by its publishing organization using cryptographic signatures. The organization's root key is published via DNS (DNSKEY/DANE) or a well-known certificate.

trust:
  level: org-verified
  identity: did:ossa:example:code-reviewer
  attestation:
    issuer: did:ossa:example:root
    signature: "base64-encoded-ed25519-signature"
    issued_at: "2026-03-01T00:00:00Z"
    expires_at: "2027-03-01T00:00:00Z"

Tier 3: Independently Audited

The agent has passed a conformance audit by a recognized third party. Trust badges are published as verifiable credentials.

trust:
  level: audited
  identity: did:ossa:example:code-reviewer
  badges:
    - type: "ossa-conformance-v1"
      issuer: "did:ossa:foundation:audit"
      evidence: "https://audit.openstandardagents.org/reports/example-code-reviewer"

4. Comparison with Existing Protocols

DUADP vs. MCP Tool Discovery

MCP defines how a client discovers tools on a single MCP server. DUADP operates above MCP — it helps an agent find which MCP server to connect to in the first place.

DUADP vs. Google A2A Agent Cards

Google A2A defines "Agent Cards" as JSON metadata about an agent's capabilities. DUADP is complementary: Agent Cards describe what an agent can do; DUADP provides the discovery mechanism to find agents in the first place.

DUADP vs. ANP (Agent Network Protocol)

ANP proposes a P2P agent network using DIDs. DUADP takes a more pragmatic approach: rather than building an entirely new network layer, DUADP leverages DNS and HTTPS infrastructure that already exists everywhere.

5. Implementation Reference

Publishing an Agent (Server Side)

1. Add DNS SRV record for _ossa-agent._tcp.yourdomain.com
2. Serve /.well-known/ossa-agents.json from your agent host
3. Optionally declare federation peers for mesh discovery

Discovering an Agent (Client Side)

import { DuadpClient } from '@bluefly/openstandardagents';

const client = new DuadpClient();

// DNS-based discovery
const agents = await client.discover('example.com');

// Capability search across federated mesh
const reviewers = await client.search({
  capability: 'code-review',
  trustMinimum: 'org-verified',
  protocol: 'mcp',
});

// Connect to discovered agent
const agent = reviewers[0];
const mcpClient = await client.connect(agent);

OSSA Manifest Integration

DUADP discovery metadata is declared directly in the OSSA manifest:

apiVersion: ossa/v0.4.0
kind: Agent
metadata:
  name: code-reviewer
spec:
  discovery:
    duadp:
      enabled: true
      capabilities: ["code-review", "security-scan"]
      protocols: ["mcp", "a2a"]
      trust:
        level: org-verified
        did: "did:ossa:example:code-reviewer"

6. Security Considerations

• DNS poisoning: Mitigated by DNSSEC validation on SRV/TXT lookups
• Impersonation: Mitigated by DID-based identity verification and cryptographic attestations
• Federation amplification: Mitigated by configurable federation depth limits and rate limiting
• Data exfiltration: Agent metadata is intentionally public; sensitive configuration stays in the manifest, not discovery responses

7. Alignment with NIST CAISI

DUADP directly addresses several priorities from the NIST CAISI RFI (Docket NIST-2025-0035):

• Interoperability: Agents from different organizations can discover each other without bilateral agreements
• Identity: DID-based identity with tiered trust verification
• Safety: Trust tiers ensure agents only interact with verified peers
• Standards-based: Built entirely on existing IETF standards (DNS, HTTPS, RFC 8615)

8. Conclusion

Agent discovery is a prerequisite for agent interoperability. DUADP provides a pragmatic, DNS-native solution that works with existing internet infrastructure rather than requiring new protocols. By separating discovery (DUADP) from communication (MCP, A2A) and definition (OSSA), we create a composable standards stack that can evolve independently at each layer.

---

References:

• RFC 8615: Well-Known Uniform Resource Identifiers
• RFC 2782: DNS SRV Records
• W3C Decentralized Identifiers (DIDs) v1.0
• NIST SP 800-63B: Digital Identity Guidelines
• NIST CAISI RFI, Docket NIST-2025-0035