v0.1.0 Draft

RFC 2119

OpenAPI 3.1

duadp.org

Decentralized Universal AI Discovery Protocol
(DUADP)

The Problem

There is no standard way to discover AI agents, skills, or tools

Today, every AI platform has its own registry, its own discovery mechanism, and its own marketplace. MCP servers list tools one way. A2A uses Agent Cards. LangChain has its own hub. Drupal has its own module registry. There is no common protocol for asking: “What AI capabilities exist at this endpoint?”

This means agents can't find each other across platforms. Skills built for one framework are invisible to another. Enterprises can't federate their internal agent registries. And there's no way to verify trust before importing a capability from an external source.

“The Initiative will ensure that the next generation of AI — AI agents capable of autonomous actions — can function securely on behalf of its users and interoperate smoothly across the digital ecosystem.”

— NIST Center for AI Standards and Innovation (CAISI), AI Agent Standards Initiative, February 2026

NIST explicitly calls out the need to “identify and reduce barriers to interoperable agent protocols.” DUADP is our answer: a minimal, open discovery protocol that any platform can implement in an afternoon.

Think of it like DNS for AI. DNS tells you where to find things. HTTP tells you how to talk to them. DUADP tells you where to find AI capabilities. OSSA tells you what those capabilities are.

What is DUADP?

A minimal, open protocol for discovering AI capabilities across any platform

Platform A

MCP tools, skills

Platform B

A2A agents, tools

Platform C

Marketplace, skills

DUADP

“What AI capabilities exist at this endpoint?”

/.well-known/duadp.json/api/v1/skills/api/v1/agents

DUADP is a decentralized, hybrid-federated protocol for the discovery, validation, and exchange of AI Agents, Skills, Tools, and Marketplaces. Drawing from ActivityPub and WebFinger, it ensures anything built on one platform can be discovered and securely utilized from any other.

Any system that implements the endpoints below is a DUADP node. No required language, framework, or database. A static JSON file on GitHub Pages, an Express server, a Drupal site, or a Kubernetes sidecar — all valid.

Why DUADP is Separate from OSSA

DNS tells you where to find things. HTTP tells you how to talk to them.

DUADP is an independent protocol that happens to carry OSSA payloads — but any discovery mechanism could transport OSSA manifests, and DUADP could discover non-OSSA agents. The separation is deliberate and aligns with established security architecture principles.

The analogy: Nobody puts the DNS spec inside the HTTP spec. DNS = where to find things (DUADP). HTTP = how to talk to them (OSSA). They compose but are independently auditable, independently versioned, and independently adoptable.

Principle	Separated	Combined
Minimal Authority (Least Privilege)	Discovery layer has no knowledge of agent internals	Discovery + creation share attack surface
Supply Chain Risk (SP 800-161)	"Do I trust this registry?" is separate from "Do I trust this agent?"	Registry compromise = spec compromise
Modular Composability	Adopt discovery without adopting the creation toolkit	All-or-nothing adoption
Independent Verification	Verify node conformance separately from manifest validity	Single audit conflates transport with payload
Trust Boundaries	Clear: DUADP = "where to find things", OSSA = "what things are"	Blurred: is a vulnerability in discovery or in the spec?

For Audit: Two Distinct Compliance Scopes

DUADP Compliance

Access controls (SP 800-53 AC-*), HTTPS transport (SC-8), rate limiting (SC-5), circuit breakers prevent cascading failures (SI-17)

OSSA Compliance

Safety guardrails declared in manifests, cryptographic signatures (SI-7), trust tiers for provenance (SA-12), Cedar pre-authorization (AC-3)

An auditor reviews each independently. Clean, bounded, defensible.

Conformance Requirements

RFC 2119 keyword conformance

Requirement	Level
`GET /.well-known/duadp.json`	MUST
At least one of `/api/v1/skills` or `/api/v1/agents`	MUST
`Content-Type: application/json` for all DUADP endpoints	MUST
OSSA-formatted payloads (`apiVersion: ossa/v0.4` or later)	MUST
`GET /api/v1/federation`	SHOULD
`POST /api/v1/skills/validate`	MAY

Discovery Layer

Well-known endpoint + resource enumeration

discovery flow

text

Client                          DUADP Node
  |                                 |
  |  GET /.well-known/duadp.json     |
  |-------------------------------->|
  |  200 OK { endpoints: {...} }    |
  |<--------------------------------|
  |                                 |
  |  GET /api/v1/skills?search=... |
  |-------------------------------->|
  |  200 OK { data: [...], meta }   |
  |<--------------------------------|

Well-Known Manifest

GET /.well-known/duadp.json

json

{
  "protocol_version": "0.1.0",
  "node_name": "Acme Corp Skills Hub",
  "node_description": "Enterprise AI skills registry",
  "contact": "admin@acme.com",
  "endpoints": {
    "skills": "https://api.acme.com/api/v1/skills",
    "agents": "https://api.acme.com/api/v1/agents",
    "federation": "https://api.acme.com/api/v1/federation",
    "validate": "https://api.acme.com/api/v1/skills/validate"
  },
  "capabilities": ["skills", "agents", "federation", "validation"],
  "public_key": "-----BEGIN PUBLIC KEY-----\n...",
  "ossa_versions": ["v0.4", "v0.5"]
}

15 Endpoints. One Protocol.

Discovery, registry, governance, federation, and search — all in one standard

GETDiscovery

/.well-known/duadp.json

Node identity, endpoint URLs, capabilities, public key

GETDiscovery

/api/v1/agents

Paginated agent registry with search and trust_tier filters

GETDiscovery

/api/v1/skills

Paginated skill registry with category and search filters

GETDiscovery

/api/v1/tools

Tool registry with protocol filtering (MCP, REST, GraphQL)

GETSearch

/api/v1/search

Unified cross-kind search (?q=&kind=Agent|Skill|Tool)

POSTRegistry

/api/v1/publish

Publish agent, skill, or tool manifests to the registry

POSTRegistry

/api/v1/validate

Validate OSSA manifests against the spec schema

GETGovernance

/api/v1/governance

Node governance policies, trust requirements, and compliance rules

GETOperations

/api/v1/health

Node health status, uptime, and version info

GETFederation

/api/v1/federation

Peer node list with health status and trust scores

POSTFederation

/api/v1/federation

GETFederation

/api/v1/federation/peers

Detailed peer discovery with capability filtering

POSTFederation

/api/v1/federation/gossip

Gossip protocol for propagating registry updates

GETIdentity

/api/v1/node

Node identity document (DID-based)

GETOperations

/api/v1/metrics

Prometheus-compatible metrics for monitoring

End-to-End: From Discovery to Import

A complete lifecycle in 5 steps

Discover

Client fetches /.well-known/duadp.json

Gets node name, capabilities, endpoint URLs, public key

Client queries /api/v1/skills?search=code-review

Paginated results with OSSA-formatted manifests, trust tiers, GAIDs

Verify

Client checks trust_tier and validates signature

official > verified-signature > signed > community > experimental

Validate

Client posts manifest to /api/v1/skills/validate

Schema validation against OSSA spec, returns errors/warnings

Import

Client imports OSSA manifest into local platform

Works with any platform: Drupal, LangChain, Claude Code, Cursor, etc.

NIST CAISI alignment →DUADP research paper →OSSA specification →

Token Efficiency by Design

Every token spent on discovery is a token NOT spent on task execution

An agent's context window is its working memory. Today, discovering what another agent or tool can do often means scanning documentation files, parsing README content, or crawling API descriptions. This is catastrophically wasteful.

Approach	Tokens	Notes
Scan 10 README files	~20,000	Avg 2,000 tokens each, mostly irrelevant
Parse AGENTS.md files	~5,000	Better, but still free-text parsing
DUADP .well-known/duadp.json	~500	Structured JSON, machine-optimized

40x reduction in discovery overhead. A single DUADP manifest replaces scanning multiple documentation files. Agents discover capabilities via structured data, not free-text parsing. This is the knowledge graph approach: every capability is a node, every relationship is an edge, and semantic search replaces brute-force scanning.

This matters at scale. An orchestration agent coordinating 20 sub-agents would spend 400,000 tokens on discovery via README scanning versus 10,000 tokens via DUADP — freeing 97.5% of context window capacity for actual task execution.

Token efficiency is the frontier problem in agent systems. DUADP treats it as a first-class design constraint, not an afterthought.

Trust Tiers

Five levels of trust attestation

Tier	Badge	Description
official	Gold	Published by the OSSA project or node operator
verified-signature	Blue	Cryptographically signed + verified identity
signed	Green	Cryptographically signed (identity not verified)
community	Gray	Published by authenticated user, no signature
experimental	Orange	Unreviewed, use at own risk

Global Agent Identifiers (GAID)

Cross-registry resolution via duadp:// URI scheme

GAID format

text

duadp://<namespace>/<type>/<name>

Examples:
  duadp://acme.com/skills/code-review
  duadp://marketplace.openstandardagents.org/agents/security-auditor
  duadp://skills.sh/skills/web-search

Resolution: duadp://skills.sh/skills/web-search
  → GET skills.sh/.well-known/duadp.json  (find skills endpoint)
  → GET /api/v1/skills?search=web-search

Federation

Peer discovery, registration, and circuit breaker

peer discovery flow

text

Node A                          Node B
  |                                 |
  |  POST /api/v1/federation       |
  |  { url: "https://node-a.com" }  |
  |-------------------------------->|
  |                                 |
  |  Node B validates:              |
  |  GET node-a.com/.well-known/    |
  |       duadp.json                 |
  |<--------------------------------|
  |  200 OK (valid DUADP manifest)   |
  |-------------------------------->|
  |                                 |
  |  201 Created { peer: {...} }    |
  |<--------------------------------|
  |                                 |
  |  Node B can now query:          |
  |  GET node-a.com/api/v1/skills  |

Circuit Breaker

Track consecutive fetch failures per peer
After 3 failures, mark peer as degraded
Stop active fetching from degraded peers
Retry after 24-hour backoff period
On success, reset to healthy

Peer status values: healthy, degraded, unreachable

DNS-Based Agent Registration

Agents as first-class web citizens — discoverable at the infrastructure layer

Websites are discoverable because DNS makes them so. A DNS A record points to a website. A DNS MX record points to a mail server. A DNS TXT _uadp record points to an agent manifest.

DNS TXT record for agent registration

text

; DNS TXT record — registers agent manifest at DNS layer
_uadp.example.com  TXT  "v=uadp1; endpoint=https://example.com/.well-known/duadp.json"

; Comparison to how the web already works:
example.com         A      93.184.216.34        ; → website
example.com         MX     mail.example.com     ; → email server
_uadp.example.com   TXT    "v=uadp1; ..."       ; → agent manifest

How DNS Agent Discovery Works

DNS Query

Agent queries _uadp.example.com TXT record

Same DNS infrastructure that resolves every website

Endpoint Resolution

TXT record returns DUADP manifest URL

Points to .well-known/duadp.json — RFC 8615 compliant

Capability Discovery

Agent fetches structured manifest

JSON with endpoints, capabilities, public keys, trust level

Trust Verification

Validate signatures and trust tier

DNSSEC + cryptographic attestation + PKI certificates

OWASP Agent Naming System (ANS) alignment: OWASP ANS proposes DNS-native agent discovery with PKI certificates and capability-based resolution. DUADP implements this vision with .well-known endpoints, GAID URIs, and federated trust verification. The result: agents are discoverable at the same layer as websites — using the same infrastructure that already runs the web.

Knowledge Graph Integration

From static registries to dynamic, queryable capability graphs

DUADP federation doesn't just build a list of agents — it builds a knowledge graph of agent capabilities. Each node is an agent, skill, or tool. Each edge is a relationship: provides, requires, trusts, delegates.

Nodes

Agents, skills, tools, providers

Each with OSSA manifest metadata

Edges

provides, requires, trusts, delegates

Typed relationships from federation

Embeddings

Vector search via Qdrant

Semantic capability matching

Example semantic queries:

>“Find agents that can analyze financial data” → semantic search across capability embeddings
>“Which tools does agent X require?” → graph traversal on ‘requires’ edges
>“Show all Tier 3 audited agents in the healthcare domain” → filtered graph + vector query

Knowledge graphs + vector stores are superior to static files. Traditional agent registries are flat lists that require exact keyword matches. A knowledge graph with vector embeddings enables semantic discovery — agents find each other based on what they can do, not what they're named.

As DUADP federation meshes grow, the knowledge graph becomes richer. Every new node adds capabilities, every new edge adds context. The graph is self-improving: more participants means better discovery for everyone.

The Specification

Everything in spec/duadp/ — language-agnostic, OpenAPI 3.1

File	Purpose
README.md	Full DUADP v0.1.0 spec (RFC 2119 conformance, 10 sections)
openapi.yaml	OpenAPI 3.1 — all endpoints, schemas, parameters
schemas/duadp-manifest.schema.json	JSON Schema for /.well-known/duadp.json
schemas/duadp-skills-response.schema.json	JSON Schema for /api/v1/skills response
schemas/duadp-agents-response.schema.json	JSON Schema for /api/v1/agents response
schemas/duadp-federation-response.schema.json	JSON Schema for /api/v1/federation response

SDKs: 4 Languages, Same Spec

All generated from the same openapi.yaml + JSON schemas

Concern	TypeScript	Python	Go	PHP (Drupal)
Package	@bluefly/duadp	bluefly-duadp	github.com/blueflyio/uapd/sdk/go	ai_agents_marketplace
Types	types.ts	types.py (Pydantic)	types.go	Entity classes
Client	client.ts	client.py (httpx)	client.go	N/A (is the node)
Server	server.ts (Express)	server.py (FastAPI)	server.go (net/http)	Drupal controllers
Validate	validate.ts	validate.py	validate.go	UadpSkillsController
Conformance	test.ts	conformance.py	cmd/duadp-test/main.go	N/A

Install (TypeScript)

npm install @bluefly/duadp

Install (Python)

pip install bluefly-duadp

Install (Go)

go get github.com/blueflyio/uapd/sdk/go

Architecture

Spec-first. SDKs generated. Drupal is the first live node.

architecture — separate repos, independent audit scopes

text

blueflyio/ossa/openstandardagents       <- OSSA spec (agent/skill format)
    spec/v0.4/
    spec/v0.5/
    src/                                    <- validator, CLI, SDK

blueflyio/ossa/lab/duadp                 <- DUADP spec (discovery protocol)
    spec/
        README.md                           <- the standard (RFC 2119)
        openapi.yaml                        <- endpoint contracts
        schemas/                            <- JSON schemas
    sdk/
        typescript/   @bluefly/duadp            <- npm install
        python/       bluefly-duadp          <- pip install
        go/           blueflyio/uapd/sdk/go  <- go get

    Implementations:
    +---> Drupal (ai_agents_marketplace)    <- reference (5 phases done)
    +---> Express middleware                 <- @bluefly/duadp server
    +---> FastAPI router                    <- bluefly-duadp server
    +---> Static site (just JSON files)     <- simplest possible node

DUADP references OSSA (payloads are OSSA-formatted) but doesn't
contain it. Independent layers that compose together.

Reference Implementation: Drupal

ai_agents_marketplace — the first live DUADP node

Phase	What	Status
1	Skill entity + CRUD + REST	Done
2	Node UI: SkillsPage, SkillCard, useSkills hook, API updates	Done
3	DUADP endpoints: well-known, skills, agents, validate	Done
4	Federation: FederationService, registry management, RegistrySettingsPage	Done
5	Inbound federation, admin settings (uadp_enabled/node_name), UadpNodeInfoPage	Done

Build a Minimal DUADP Node

The simplest possible node is two static JSON files

minimal DUADP node

text

your-domain.com/
  .well-known/duadp.json     <- discovery manifest
  duadp/v1/skills            <- skills list (can be static JSON)

A more complete implementation adds:

Database-backed skill/agent storage
Federation with peer discovery and caching
Authentication for write operations
Manifest validation service
Conformance test suite (duadp-test <url>)

Get Started

Run a DUADP node in minutes — or query the live reference node

1Query the Live Registry

The OSSA reference node is live. Try it now:

Try it now

bash

# Discover all agents
curl https://discover.duadp.org/api/v1/agents

# Search for skills
curl https://discover.duadp.org/api/v1/search?q=security

# Check node identity
curl https://discover.duadp.org/.well-known/duadp.json

2Publish an Agent

Publish

bash

# Validate your OSSA manifest
npx @bluefly/openstandardagents validate agent.ossa.yaml

# Publish to the registry
curl -X POST https://discover.duadp.org/api/v1/publish \
  -H "Content-Type: application/json" \
  -d @agent.ossa.yaml

Tutorials

Build a DUADP Node

Stand up your own discovery node with the reference implementation. Supports Hono, Express, or Cloudflare Workers.

Federate with Other Nodes

Connect your node to the mesh network. Peer discovery, gossip protocol, and circuit breaker patterns built in.

Add Trust Verification

Implement the 5-tier trust model with DID-based identity and cryptographic attestation chains.

GitLab Repository GitHub Mirror Live Reference Node →duadp.org

Decentralized Universal AI Discovery Protocol
(DUADP)

The Problem

What is DUADP?

Why DUADP is Separate from OSSA

For Audit: Two Distinct Compliance Scopes

Conformance Requirements

Discovery Layer

Well-Known Manifest

15 Endpoints. One Protocol.

End-to-End: From Discovery to Import

Token Efficiency by Design

Trust Tiers

Global Agent Identifiers (GAID)

Federation

Circuit Breaker

DNS-Based Agent Registration

How DNS Agent Discovery Works

Knowledge Graph Integration

The Specification

SDKs: 4 Languages, Same Spec

Install (TypeScript)

Install (Python)

Install (Go)

Architecture

Reference Implementation: Drupal

Build a Minimal DUADP Node

Get Started

1Query the Live Registry

2Publish an Agent

Tutorials

Resources

DUADP Research Paper

OSSA Specification

NIST CAISI Alignment

DUADP Repository

GitHub Mirror

Blog: Token Efficiency Dark Ages

Blog: Agents as First-Class Web Citizens

Research: Agent Identity & DNS Registration

Research: Token Efficiency in Agent Systems

Decentralized Universal AI Discovery Protocol(DUADP)

The Problem

What is DUADP?

Why DUADP is Separate from OSSA

For Audit: Two Distinct Compliance Scopes

Conformance Requirements

Discovery Layer

Well-Known Manifest

15 Endpoints. One Protocol.

End-to-End: From Discovery to Import

Token Efficiency by Design

Trust Tiers

Global Agent Identifiers (GAID)

Federation

Circuit Breaker

DNS-Based Agent Registration

How DNS Agent Discovery Works

Knowledge Graph Integration

The Specification

SDKs: 4 Languages, Same Spec

Install (TypeScript)

Install (Python)

Install (Go)

Architecture

Reference Implementation: Drupal

Build a Minimal DUADP Node

Get Started

1Query the Live Registry

2Publish an Agent

Tutorials

Resources

DUADP Research Paper

OSSA Specification

NIST CAISI Alignment

DUADP Repository

GitHub Mirror

Blog: Token Efficiency Dark Ages

Blog: Agents as First-Class Web Citizens

Research: Agent Identity & DNS Registration

Research: Token Efficiency in Agent Systems

Decentralized Universal AI Discovery Protocol
(DUADP)