| Internet-Draft | A Framework for Agent Discovery in DAWN | September 2026 |
| Zhang | Expires 8 March 2027 | [Page] |
The IETF DAWN (Discovery of Agents, Workloads, and Named Entities) working group is developing a suite of documents addressing agent discovery across organizational boundaries. Existing DAWN contributions include terminology, requirements, use cases, gap analysis, a discovery mechanism survey, and an information model for Minimum Discoverable Information (MDI).¶
This document describes a two-layer federated reference architecture framework that operates within the DAWN. The first layer, the Local Discovery Plane, performs zero-configuration agent advertisement and collection inside each local site, without mandating a specific link-local protocol. The second layer, the Federation Plane, builds a federation among site gateways to exchange lightweight Federation Metadata Records (FMRs) — a concrete binding of DAWN MDI — across independent administrative domains, while full Capability Cards are retrieved on demand via authenticated unicast.¶
The architecture emphasizes data sovereignty through an Export Policy Engine, separates lightweight metadata indexes from full capability documents, and supports multiple federation synchronization strategies. This document is informational. It does not define normative protocol formats, nor does it compete with existing DAWN proposals such as ACAP, Agent Directory, or ARDP; rather, it provides a deployment framework showing how these mechanisms may be composed at administrative boundaries.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 5 March 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
The IETF DAWN working group [I-D.akhavain-moussa-dawn-problem-statement] is chartered to develop interoperable discovery mechanisms for agents, workloads, and named entities across organizational boundaries. Its problem statement identifies that no single existing mechanism satisfies all discovery scenarios, particularly when crossing trust and administrative boundaries [I-D.moussa-dawn-gap-analysis]. DAWN requirements [I-D.king-dawn-requirements] call for support for capability-oriented discovery, resource-oriented discovery, administrative scope extensions, and operational discovery [I-D.kay-dawn-use-cases].¶
A growing number of individual submissions propose concrete mechanisms within this space: DNS-based naming extensions (DNS-AID [I-D.mozleywilliams-dnsop-dnsaid], DN-ANR [I-D.cui-dns-native-agent-naming-resolution], AID [I-D.nemethi-aid-agent-identity-discovery]); host-level self-description (A2A Agent Cards, ACAP [I-D.zahed-acap], ANP agent-descriptions, api-catalog [RFC9727]); and registry protocols (ARDP [I-D.pioli-agent-discovery], Agent Directory [I-D.jimenez-agent-directory], AGNTCY ADS [I-D.mp-agntcy-ads]). A survey by Jimenez et al. [I-D.jimenez-dawn-discovery-landscape] compares these mechanisms and identifies gaps, including the lack of interoperable federation and the absence of a standardized semantic discovery layer.¶
Cui [I-D.cui-dawn-mdi-model] proposes an encoding-neutral information model for Minimum Discoverable Information (MDI) — a common header that any discovery response may carry, independent of transport or format. MDI defines three mandatory elements (Entity Identifier, Entity Type, Endpoint) and a short set of recommended elements (Capability Summary, Authentication Hint, Trust Reference, Freshness).¶
This document complements the above work by defining a reference architecture for cross-domain deployment. It addresses the "Administrative Scope Extensions" use case [I-D.kay-dawn-use-cases], where discovery must cross organizational boundaries while preserving data sovereignty. The architecture introduces a Federation Gateway (FGW) as the boundary component between a local site and external domains, and an Export Policy Engine that controls which agent metadata may leave the site. It binds DAWN MDI into a lightweight Federation Metadata Record (FMR) for inter-gateway exchange, while keeping full Capability Cards on demand.¶
This document does not define a new discovery protocol competing with ACAP, Agent Directory, or ARDP. Instead, it shows how a site may deploy a gateway that federates with peer gateways, using existing or future DAWN protocols as the synchronization substrate. The FGW concept fills a gap not yet addressed by existing proposals: the explicit modeling of the administrative boundary and per-peer export policy.¶
This document defines a reference architecture. It specifies logical layers, functional components, data flow, security model, and deployment considerations for cross-domain agent discovery within the DAWN framework.¶
The following items are explicitly out of scope for this informational document:¶
Normative protocol message formats, encodings, or state machines. These are addressed in separate protocol specifications that may be developed based on this architecture.¶
Mandatory cryptographic algorithms or cipher suites. The architecture requires transport security and metadata integrity, but specific algorithm selection is deferred to protocol documents.¶
A global root trust authority or certificate hierarchy. The architecture supports federation-local trust models, consistent with DAWN's initial scope [CSA-DAWN-Note].¶
Agent runtime execution, task scheduling, or inter-agent communication protocols beyond discovery.¶
Business-level service level agreements or commercial federation governance rules.¶
Stable identifier issuance, comprehensive trust evaluation, and capability negotiation — these are explicitly out of scope for DAWN's initial phase and are left to adjacent working groups [CSA-DAWN-Note].¶
Section 2 defines terminology, aligned with DAWN [I-D.farrel-dawn-terminology]. Section 3 states architectural requirements and maps them to DAWN requirements. Section 4 positions this architecture relative to existing DAWN family protocols. Section 5 provides a state-of-the-art review and gap analysis. Section 6 defines the two-layer reference architecture and functional components. Section 7 describes deployment models. Section 8 presents the layered security model. Section 9 covers resilience and operational considerations. Section 10 describes the relationship between this architecture and normative protocol documents. Section 11 is IANA considerations. Appendix A provides detailed considerations for federation synchronization protocols.¶
This document uses terms defined in [I-D.farrel-dawn-terminology], including Entity, Discovery, Discovery Information, Discoverable Object, Minimum Discoverable Information (MDI), Capability Card, and Trust Indicator. The following additional terms are defined for the purpose of this architecture:¶
Agent: An autonomous network-resident entity that can execute tasks, expose service interfaces, and advertise capability metadata. Aligns with the DAWN definition of Entity when the entity type is "agent".¶
Administrative Domain: A network or set of networks under a single organizational authority, with its own security and operational policies. Equivalent to the DAWN scope concept.¶
Federation Metadata Record (FMR): A lightweight, sanitized descriptive record of an agent, exchanged among Federation Gateways in the Federation Plane. An FMR is a concrete binding of DAWN Minimum Discoverable Information (MDI) [I-D.cui-dawn-mdi-model] for cross-domain transport: it contains Entity Identifier, Entity Type, origin gateway, capability summary tags, status, and time-to-live. It does not carry full capability detail.¶
Capability Card: The complete, detailed capability manifest of an agent. Aligns with the DAWN Capability Card. Capability Cards are NOT distributed in the federation control plane; they are retrieved on demand via authenticated unicast. ACAP's Agent Capability Document (ACD) [I-D.zahed-acap] and A2A Agent Cards are examples of concrete Capability Card formats.¶
Site / Local Domain: An independent administrative area, typically one local-area network or a single tenant namespace, where agents run.¶
Federation Gateway (FGW): A network component deployed at the boundary of a local site. It collects agent discovery information from local agents, applies export policy, and participates in cross-domain federation. The FGW realizes the boundary function between DAWN's local discovery and cross-domain registry planes.¶
Federation: A trust group formed by multiple federation gateways from different administrative domains, for exchanging agent discovery metadata.¶
Federation Peer: A remote FGW with which a local FGW has established an authenticated control relationship.¶
Federated Agent Directory (FAD): The local database maintained by each FGW, containing all FMRs received from federation peers plus locally-originated FMRs. Functionally analogous to a distributed Agent Directory [I-D.jimenez-agent-directory].¶
Export Policy Engine: A functional module on the FGW that filters, redacts, and controls which agent metadata may be shared with which federation peers. This is the core mechanism for data sovereignty.¶
Local Discovery Plane: The first architectural layer, operating within a single site, responsible for zero-configuration or low-configuration agent advertisement and collection. This plane may use mDNS/DNS-SD, local API registration, edge platform discovery, or other site-local mechanisms.¶
Federation Plane: The second architectural layer, operating across administrative domains, responsible for FMR exchange among FGWs.¶
This section defines high-level architectural requirements for the two-layer agent-discovery architecture. These requirements are derived from the DAWN working group's problem statement [I-D.akhavain-moussa-dawn-problem-statement], requirements [I-D.king-dawn-requirements], and use cases [I-D.kay-dawn-use-cases]. They are non-normative for this informational document.¶
F-1: Cross-Domain Discovery -- The architecture MUST enable discovery of agents that reside in administrative domains different from the requester's domain. Satisfies DAWN use case "Administrative Scope Extensions" [I-D.kay-dawn-use-cases].¶
F-2: Zero-Configuration Local Discovery -- Agents MUST be capable of advertising themselves on the local network without pre-provisioned discovery server addresses. Satisfies DAWN requirements for local-context discovery [I-D.king-dawn-requirements].¶
F-3: Data Sovereignty -- Each site administrator MUST retain full control over which agent metadata records can be shared outside its local domain, including per-record filtering, field redaction, and per-peer access policy. Addresses the gap identified in [I-D.moussa-dawn-gap-analysis] regarding lack of interoperable federation with per-domain policy control.¶
F-4: Decentralized Federation -- The architecture MUST NOT require a mandatory global centralized directory. Federation participants MUST be able to operate without submitting data to a third-party central authority. Aligns with DAWN's emphasis on avoiding single points of failure [I-D.king-dawn-requirements].¶
F-5: Lightweight Index vs. Full Detail Separation -- The architecture MUST distinguish between lightweight metadata indexes (distributed in the federation plane) and full Capability Cards (retrieved on demand). This reduces cross-domain data volume and enables access control on detailed information. Directly instantiates the DAWN MDI principle of "thin core, rich references" [I-D.cui-dawn-mdi-model].¶
F-6: Dynamic Agent Lifecycle -- The architecture MUST efficiently handle frequent agent events: startup, graceful shutdown, network disconnection, and capability update. Metadata MUST become invalid promptly after an agent goes offline. Satisfies DAWN requirements for dynamic updates and freshness [I-D.king-dawn-requirements].¶
F-7: Multi-Protocol Support -- The architecture MUST permit multiple alternative synchronization mechanisms for the federation plane, allowing different deployment scales and trust models to select appropriate protocols. Aligns with DAWN's requirement to support multiple discovery models [I-D.king-dawn-requirements].¶
NF-1: Security Against Forged Advertisements -- The architecture MUST provide a mechanism to verify the origin and integrity of FMRs, preventing malicious federation participants from injecting forged agent advertisements.¶
NF-2: Fault Tolerance -- The architecture MUST tolerate individual gateway failures, network partitions, and transient connectivity loss without catastrophic loss of discovery capability.¶
NF-3: Interoperability -- The architecture MUST support interoperability among different federation synchronization protocols, so that gateways using different protocols can coexist within the same overall architecture. Supports DAWN's goal of cross-domain interoperability [I-D.king-dawn-requirements].¶
NF-4: Privacy Protection -- The architecture MUST prevent leakage of internal network topology, private IP addresses, and sensitive agent details to unauthorized external parties. Satisfies DAWN privacy considerations [I-D.king-dawn-requirements].¶
NF-5: Scalability -- The architecture MUST scale from small federations of a few sites to large federations of hundreds or thousands of sites, without requiring per-site full-mesh manual configuration.¶
NF-6: Operational Simplicity -- The architecture MUST minimize operational overhead for site administrators, particularly for local-site deployment where zero-configuration is a primary goal.¶
This architecture is designed to complement, not replace, existing protocols being discussed in the DAWN community and adjacent efforts. The following positioning statements clarify the relationship.¶
ACAP [I-D.zahed-acap] defines a well-known URI scheme, a rich Agent Capability Document (ACD) format, and HTTP/3 operations (GET, PUT, POST) for retrieval, registration, and capability-based search. ACAP operates primarily at the Description Plane: it specifies how a host publishes its capabilities and how a domain-level query endpoint answers capability searches.¶
This architecture treats ACAP as a valid implementation of the Description Plane within a site. An FGW may collect ACDs via ACAP PUT/GET from local agents, translate the ACD content into an FMR (binding ACAP fields to MDI elements), and distribute the FMR in the Federation Plane. Cross-domain capability queries in this architecture may be answered by the FAD (local cache) or forwarded to peer FGWs, rather than requiring a global ACAP query endpoint. Thus, ACAP and this architecture are composable: ACAP handles intra-domain rich description, while this architecture handles inter-domain federation and export policy.¶
The Agent Directory [I-D.jimenez-agent-directory] adapts the CoRE Resource Directory [RFC9176] to software agents, providing an HTTP/JSON service for registration and lookup with soft-state lifetimes. It defines a well-known URI (/.well-known/ad) and supports capability filtering.¶
This architecture is complementary: the Agent Directory may serve as the Local Discovery Plane mechanism within a site, collecting agent registrations and answering local queries. The FGW may subscribe to the local Agent Directory, extract MDI-compliant records, apply export policy, and generate FMRs for federation. The FAD maintained by the FGW is conceptually a distributed extension of the Agent Directory across administrative boundaries. Federation across multiple Agent Directory instances is acknowledged but not specified in [I-D.jimenez-agent-directory]; this architecture provides one possible federation model.¶
ARDP [I-D.pioli-agent-discovery] specifies a lightweight federated protocol for registering and discovering agents, with cryptographic proof-of-control via JWS signatures and support for cross-domain federation through explicit trust relationships.¶
This architecture aligns with ARDP's federation goals but operates at a different granularity. ARDP focuses on agent-level registration and discovery; this architecture focuses on site-level gateway federation. An FGW could use ARDP as its Federation Plane synchronization protocol, aggregating multiple local agents into a single gateway-level ARDP registration, or ARDP could be used directly between FGWs for FMR exchange. The Export Policy Engine in this architecture adds a layer of data sovereignty not explicitly addressed by ARDP.¶
AGNTCY ADS [I-D.mp-agntcy-ads] is a distributed directory using libp2p Kad-DHT for content routing and OASF for capability-based matching. It achieves semantic discovery via a hierarchical skill taxonomy.¶
This architecture differs in approach: ADS is a global or wide-area distributed hash table, while this architecture is a federated gateway model with explicit per-peer trust and policy control. ADS is well-suited for open, Internet-scale, capability-oriented discovery (the "free-form search" use case [I-D.jimenez-dawn-discovery-landscape]). This architecture is better suited for closed or semi-closed federations where data sovereignty and per-peer export policy are paramount. A hybrid deployment is possible: an FGW may publish a subset of its FMRs to AGNTCY ADS for broad discoverability, while retaining sensitive records for private federation peers only.¶
DNS-AID [I-D.mozleywilliams-dnsop-dnsaid], DN-ANR [I-D.cui-dns-native-agent-naming-resolution], and AID [I-D.nemethi-aid-agent-identity-discovery] propose DNS-based mechanisms for agent naming and location resolution. These operate at the DAWN Naming Plane, providing decentralized name-to-location mapping.¶
This architecture treats DNS-based discovery as one valid mechanism for the Local Discovery Plane (e.g., resolving a known partner's domain to locate its FGW or agents). The FGW may itself be advertised via DNS records, and FMRs may contain DNS-based locators. The two approaches are orthogonal and composable.¶
The MDI information model [I-D.cui-dawn-mdi-model] defines an abstract, encoding-neutral common header for discovery responses. This architecture directly adopts MDI as the basis for FMRs: an FMR is a concrete, protocol-specific binding of MDI elements (Entity Identifier, Entity Type, Endpoint, Capability Summary, Freshness, Provenance) for the purpose of cross-gateway exchange. By grounding FMRs in MDI, this architecture ensures that federated metadata can be translated to and from other DAWN discovery formats (ACAP ACDs, Agent Directory records, A2A Agent Cards) without loss of the minimal necessary information.¶
This section reviews existing approaches to cross-domain service and agent discovery, and identifies gaps that motivate the proposed two-layer architecture. It extends the gap analysis in [I-D.moussa-dawn-gap-analysis] and [I-D.jimenez-dawn-discovery-landscape].¶
One approach is to deploy a hierarchical, DNS-like or WebFinger-like global registration system. Sites register their agent metadata with regional or global directory servers; requesters query the directory to discover agents.¶
Strengths: Familiar operational model; query latency is controllable; well-understood caching and delegation mechanisms.¶
Gaps: (1) Data sovereignty — sites must submit agent metadata to a third-party directory, which many organizations resist for industrial and enterprise deployments. (2) Trust and governance — operating a global root directory requires a governance body that all participants accept. (3) Single-point-of-failure and scaling concerns at the root level. (4) Granular per-peer access control is difficult in a public query model. These gaps are noted in [I-D.moussa-dawn-gap-analysis] as "no interoperable federation" and "no standard for semantic discovery".¶
mDNS/DNS-SD [RFC6762] [RFC6763] provides excellent zero-configuration discovery within a single broadcast domain.¶
Strengths: Zero configuration; widely deployed; no infrastructure required; excellent for local-area networks.¶
Gaps: (1) Link-local multicast does not cross IP routers, so discovery is confined to a single LAN. (2) No built-in mechanism for cross-domain metadata exchange. (3) Large LANs can experience multicast storm issues without a proxy or gateway. This satisfies only the "local context" use case [I-D.kay-dawn-use-cases].¶
In this approach, every gateway establishes direct peering sessions with every other gateway in the federation, exchanging metadata via incremental updates (similar to BGP [RFC4271]).¶
Strengths: Fast convergence; fine-grained per-peer policy control; clear data sovereignty; well-understood operational model from routing protocols.¶
Gaps: (1) Full-mesh configuration becomes operationally expensive at large scale (N-squared peering). (2) Every site must manually configure and maintain peer relationships. (3) Not ideal for loosely-managed, open federations with high member churn.¶
Gossip-based protocols propagate metadata probabilistically among a small set of neighbors, achieving eventual consistency across the federation.¶
Strengths: Excellent horizontal scalability; robust against partial failures; low per-node connection count; self-organizing topology.¶
Gaps: (1) Eventual consistency means convergence delay is unavoidable. (2) Precise per-record distribution policies are difficult to enforce. (3) Malicious participants can rapidly spread forged metadata across the overlay. (4) Security and trust management are more complex than in static peering models.¶
No single existing approach satisfies all requirements simultaneously:¶
Centralized directories fail F-3 (data sovereignty) and F-4 (decentralized federation).¶
Link-local multicast fails F-1 (cross-domain discovery).¶
Full-mesh peering fails NF-5 (scalability) at large federation sizes.¶
Gossip dissemination fails NF-1 (security against forged advertisements) and F-6 (prompt lifecycle invalidation) due to convergence delay.¶
The two-layer federated architecture addresses these gaps by: (1) keeping local discovery zero-configuration and decentralized, without mandating a specific local protocol; (2) introducing a federation gateway layer that enforces data sovereignty via export policy; (3) supporting multiple federation synchronization protocols (full-mesh, gossip, and optionally centralized registration) so that deployments can select the mechanism matching their scale and trust model; and (4) separating lightweight FMRs (MDI bindings) from full Capability Cards to reduce cross-domain data exposure.¶
The overall architecture consists of two logically separated layers: the Local Discovery Plane (Layer 1) and the Federation Plane (Layer 2). Traffic and control logic between the two layers are decoupled. The Federation Gateway (FGW) is the only component that spans both layers.¶
The first layer runs inside each independent local site (LAN, tenant namespace, or edge cluster). Its responsibilities are agent advertisement, local metadata collection, and export policy enforcement.¶
After startup, every agent advertises lightweight agent metadata via a site-local discovery mechanism. The primary candidate is link-local multicast mDNS/DNS-SD (service type such as "_agent._tcp.local"), but alternative mechanisms are permitted: local API registration to an Agent Directory [I-D.jimenez-agent-directory], edge platform discovery (e.g., Kubernetes service discovery), or ACAP [I-D.zahed-acap] registration. The architecture does not mandate a single local discovery protocol.¶
Advertised records carry compact metadata entries (Entity Identifier, basic capability tags, endpoint for Capability Card retrieval). Large Capability Cards are NOT transmitted via multicast or local broadcast packets.¶
Local peers (other agents) may discover and communicate directly within the site. The FGW is NOT required to forward agent data traffic; it only collects discovery metadata.¶
The FGW listens to local agent advertisements (via mDNS passive listening, Agent Directory subscription, or ACAP endpoint polling) and maintains a site-local agent table for all agents discovered inside this site.¶
The Export Policy Engine on the FGW applies local sharing policy: it filters which agents may be advertised externally, redacts sensitive fields, and generates federation-ready FMRs before exporting them to remote federation peers. Different peers may receive different subsets of FMRs.¶
Federation Gateways from separate administrative domains compose a federation control plane. Agent business data plane traffic does NOT flow through federation gateways by default.¶
Each FGW only distributes sanitized FMRs to its authenticated federation peers, according to its export policy.¶
When an agent's state changes (online, offline, capability update), the local FGW generates an incremental metadata update and propagates it to federation peers according to the selected synchronization protocol (see Appendix A for protocol considerations).¶
Remote receiving FGWs update their local Federated Agent Directory (FAD). Every FGW maintains its local copy of federation agent metadata.¶
When an agent from one site needs to discover cross-domain agents with specific capabilities, the local FGW queries its local FAD cache. Full Capability Card details are fetched directly from the source site FGW by authenticated unicast on demand.¶
Federation membership can be dynamically adjusted: FGWs may join or leave the federation according to trust agreements.¶
The complete discovery data flow proceeds as follows:¶
An agent starts up in Site A and advertises itself via a site-local mechanism (e.g., mDNS on the local LAN, or registration with a local Agent Directory).¶
The FGW in Site A collects the advertisement, validates it, and passes it to the Export Policy Engine.¶
The Export Policy Engine determines that this agent may be shared with federation peers, redacts any sensitive fields, and produces an FMR binding the agent's MDI elements.¶
The FGW in Site A propagates the FMR to its federation peers (including the FGW in Site B) via the selected synchronization protocol.¶
The FGW in Site B receives the FMR, validates its origin and integrity, and stores it in its local FAD.¶
An agent in Site B queries its local FGW for agents matching a capability tag. The FGW searches its FAD and returns the FMR for the agent in Site A.¶
If the requester needs full capability details, it sends an authenticated HTTPS request to the Capability Card URI in the FMR, which points to the FGW in Site A (or directly to the agent, depending on deployment policy). The FGW in Site A enforces access control and returns the Capability Card.¶
Local Agent Discovery Module (on FGW): Captures local agent advertisements via passive mDNS listening, Agent Directory subscription, or other local mechanisms; maintains the site-local agent table.¶
Export Policy Engine (on FGW): Executes data filtering, privacy redaction, and per-peer export access policy. This is the core data sovereignty mechanism.¶
Federation Control Module (on FGW): Manages peer sessions, transmits incremental metadata updates, receives records from federation peers, maintains the FAD.¶
On-Demand Capability Card Retrieval Service (on FGW): Responds to authenticated remote requests for complete agent capability documents over unicast HTTPS.¶
Metadata Integrity Module (on FGW): Signs outgoing FMRs and verifies signatures on incoming FMRs, providing origin authentication and integrity protection.¶
FAD Aging Module (on FGW): Periodically scans the FAD and purges expired FMR entries based on their TTL values.¶
The two-layer architecture supports multiple deployment models. Different federations, or different subsets within a federation, may adopt different synchronization mechanisms according to their scale, trust model, and operational requirements. Detailed protocol considerations for these mechanisms are provided in Appendix A.¶
This model applies to medium-scale, tightly-managed federations such as industrial compute consortiums, multi-site enterprise AI deployments, and operator-managed edge-agent networks. Participants are known and pre-authenticated; membership changes infrequently.¶
Recommended synchronization: Structured peer-to-peer incremental unicast synchronization (e.g., BGP-style full-mesh or partial-mesh peering). See Appendix A.1.¶
Rationale: Fast convergence, fine-grained per-peer sharing policy, clear data sovereignty control, and consistent local agent directory for capability queries. The operational overhead of mesh peering is acceptable for medium-scale federations.¶
Scale range: Approximately 2 to 200 sites.¶
This model applies to large, loosely-managed federations with high member churn, such as open edge-computing networks or cross-industry AI agent marketplaces. Participants may join and leave frequently; mesh manual configuration is impractical.¶
Recommended synchronization: Gossip-based epidemic dissemination, with a bounded neighbor set and periodic anti-entropy synchronization. See Appendix A.2.¶
Rationale: Excellent horizontal scalability, robust against partial failures, and self-organizing topology that minimizes per-node configuration. Convergence delay is acceptable for use cases that do not require instant global consistency.¶
Scale range: Hundreds to thousands of sites.¶
Note: Due to the security challenges of gossip dissemination, this model is RECOMMENDED for experimental or controlled deployments rather than as a mandatory standards-track protocol.¶
This model applies to deployments on the open public internet, where agents may need to be discoverable by arbitrary external parties. Pure peer federation may not provide sufficient discoverability for unknown requesters.¶
Recommended approach: Hybrid deployment. The FGW participates in a peer federation for trusted partners, AND optionally publishes a subset of sanitized FMRs to a public or semi-public directory service (e.g., AGNTCY ADS [I-D.mp-agntcy-ads] or a DNS-based registration system).¶
Rationale: Combines the data sovereignty and trust benefits of peer federation with the broad discoverability of public directories. The Export Policy Engine controls which records are published to the public directory versus retained for federation peers only.¶
Note: The architecture does not mandate a specific public directory protocol. Existing or future registration protocols may be used.¶
The architecture permits different subsets of an overall federation to adopt different synchronization mechanisms. For example, a core group of trusted operators may use structured peering among themselves, while a broader set of peripheral participants connects via gossip. The FMR metadata format is shared across all mechanisms, ensuring that records are interoperable regardless of how they are transported.¶
Security is a primary concern in cross-domain agent discovery. A malicious or compromised federation gateway could inject forged agent advertisements, causing requesters to connect to rogue agents. This section defines a layered security model for the architecture. It aligns with the DAWN security considerations and the authentication framework in [I-D.klrc-aiagent-auth].¶
All federation control traffic between FGWs MUST be protected by authenticated encrypted transport. TLS 1.3 [RFC8446] with mutual X.509 certificate authentication [RFC5280] is the RECOMMENDED mechanism. Plaintext metadata exchange over public networks MUST NOT be used.¶
Mutual authentication ensures that each FGW can verify the identity of its federation peers. A federation may use its own certificate authority (CA) or a web-of-trust model; the architecture does not mandate a global root CA. This aligns with DAWN's position that no global root trust authority is required [CSA-DAWN-Note].¶
Transport security alone protects messages in transit but does not prevent a compromised peer from forging FMRs that claim to originate from another gateway. The architecture therefore requires that each FMR carry an origin authentication and integrity mechanism.¶
Each outgoing FMR MUST be signed by the originating FGW using its private key. The signature covers the FMR content (Entity Identifier, Origin-GW-ID, timestamp, capability tags, TTL, and other mandatory fields).¶
Each receiving FGW MUST verify the FMR signature against the originating gateway's public key before accepting the record into its FAD.¶
FMRs that fail signature verification MUST be discarded and MUST NOT be propagated further.¶
The specific signature algorithm and key management mechanism are deferred to normative protocol documents. The architecture requires the capability but does not mandate a particular algorithm. JWS [RFC7515] as used in ACAP [I-D.zahed-acap] and ARDP [I-D.pioli-agent-discovery] is a candidate mechanism.¶
This mechanism ensures that even if a malicious gateway joins the federation, it cannot forge FMRs on behalf of other gateways. It can still forge its own local agent records, which is an inherent trust-boundary issue addressed by federation admission control (see Section 8.4).¶
Full Capability Cards may contain sensitive information about agent capabilities, endpoints, and configuration. The architecture requires that Capability Card retrieval endpoints enforce access control.¶
Capability Card URIs in FMRs point to the originating FGW, not directly to the agent's local address, preserving internal topology privacy.¶
The FGW's Capability Card retrieval service MUST authenticate the requester (e.g., via mutual TLS, API token, or federation identity) before releasing the full document.¶
The FGW MAY apply per-requester access policies, returning different levels of detail to different parties, or rejecting requests from unauthorized parties entirely. This realizes the DAWN privacy requirement that sensitive information be placed behind access-controlled references [I-D.cui-dawn-mdi-model].¶
The architecture's trust boundary is the federation membership. A gateway that is admitted to the federation is trusted to accurately report its local agents (though FMR signing prevents it from forging other gateways' records).¶
Federation admission is governed by out-of-band administrative policy, not by the protocol itself.¶
Operators SHOULD carefully vet new gateway participants before admitting them to a federation, particularly in closed trusted federations (Model A).¶
In gossip-based federations (Model B), the larger and more open the participant set, the higher the risk of malicious participants. Operators SHOULD consider additional reputation or rate-limiting mechanisms.¶
Rate limiting MUST be applied to incoming federation control messages per peer. An FGW SHOULD implement a maximum message rate and disconnect peers that exceed it.¶
The FAD database size MUST be bounded. An FGW SHOULD implement a maximum number of FMRs per origin gateway and reject excess entries.¶
TLS handshake rate limiting protects against connection-flood attacks.¶
The hold timer and keepalive mechanism (in peering protocols) or neighbor timeout (in gossip protocols) detect dead peers and free resources.¶
When a network partition occurs, FGWs on each side lose connectivity to peers on the other side. The architecture handles this as follows:¶
FMRs previously learned from now-unreachable peers remain in the local FAD until their TTL expires. This prevents transient partitions from causing mass agent disappearance.¶
When connectivity is restored, a full resynchronization (in peering protocols) or anti-entropy exchange (in gossip protocols) reconciles the two sides.¶
Operators SHOULD set TTL values that balance prompt stale-record removal against tolerance for transient partitions. A TTL of 300 seconds (5 minutes) is RECOMMENDED as a default.¶
When an FGW fails, FMRs originated by that gateway remain in peer FADs until TTL expiry, providing a grace period for recovery.¶
Upon recovery, the FGW rebuilds its site-local agent table via Layer 1 discovery, then re-originates its FMRs to federation peers.¶
If an FGW is permanently decommissioned, operators SHOULD gracefully withdraw all its FMRs before shutdown (see Section 9.3).¶
When an FGW is administratively shut down, it SHOULD send withdrawal messages for all of its locally-originated FMRs to all federation peers before closing sessions. This allows peers to immediately remove the shutting-down gateway's agents rather than waiting for TTL expiry. A notification message indicating administrative shutdown follows the withdrawals.¶
Each FMR carries a TTL value. When an FGW inserts or updates an FMR in its FAD, it records an expiry time. A background aging process periodically scans the FAD and removes any FMR whose expiry time has passed. Expired records are NOT announced via withdrawal; they simply disappear from the local FAD. If the origin gateway still has the agent, it refreshes the FMR before TTL expiry by sending a new update.¶
Origin gateways MUST send refresh updates for each active local agent at an interval of no more than half the TTL value, ensuring that transient federation disruptions do not cause valid agents to expire prematurely.¶
The FMR format uses self-describing TLV (Type-Length-Value) encoding, allowing new optional fields to be added without breaking backward compatibility. Recipients MUST ignore unknown TLV types.¶
The architecture supports multiple protocol versions simultaneously. FGWs SHOULD negotiate protocol capabilities during session establishment (for peering protocols) or hello exchange (for gossip protocols).¶
Major architectural changes that break compatibility require a new version of this framework document and SHOULD be discussed in the DAWN working group before deployment.¶
Operators of federation gateways SHOULD monitor the following metrics:¶
Number of active federation peers and peer session uptime.¶
FAD size and growth rate, per origin gateway.¶
FMR update rate and withdrawal rate.¶
Signature verification failure rate (indicator of potential attacks or misconfiguration).¶
TTL expiry rate (high expiry rate may indicate origin gateway refresh problems or network instability).¶
Capability Card retrieval request rate and authorization failure rate.¶
This informational architecture document does not define any normative protocol. It is intended to serve as a deployment framework within the DAWN working group's overall discovery architecture. The relationship with other documents is as follows:¶
DAWN Core Documents (Informational): The DAWN terminology [I-D.farrel-dawn-terminology], problem statement [I-D.akhavain-moussa-dawn-problem-statement], requirements [I-D.king-dawn-requirements], use cases [I-D.kay-dawn-use-cases], and gap analysis [I-D.moussa-dawn-gap-analysis] provide the foundational context. This architecture is a concrete instantiation of the "Administrative Scope Extensions" use case and addresses several identified gaps.¶
MDI (Informational): [I-D.cui-dawn-mdi-model] defines the abstract information model. This architecture defines FMRs as a concrete binding of MDI for cross-gateway transport.¶
ACAP (Standards Track candidate): [I-D.zahed-acap] may serve as the Description Plane protocol within a site. This architecture does not compete with ACAP; it federates ACAP-described agents across domains.¶
Agent Directory (Standards Track candidate): [I-D.jimenez-agent-directory] may serve as the Local Discovery Plane protocol. This architecture provides a federation model for Agent Directory instances.¶
Future Federation Protocol Documents: Normative protocol specifications for the Federation Plane (e.g., a BGP-style peering protocol or a gossip-based dissemination protocol) may be developed as separate standards-track or experimental documents based on the architectural considerations in Appendix A.¶
The FMR metadata format is shared across all protocol documents, ensuring that agent metadata records are interoperable regardless of which synchronization mechanism transports them. Protocol documents MAY define additional protocol-specific fields in their message headers, but the FMR payload format — as a binding of MDI — MUST remain consistent.¶
This informational document does not request any new IANA registrations. The architecture itself does not define protocol numbers, ports, or message types.¶
Future normative protocol specifications derived from this architecture MAY request IANA allocations, including but not limited to: well-known TCP/UDP ports for federation control protocols, message type registries, FMR TLV type registries, and capability code registries. Such requests are the responsibility of the respective protocol documents.¶
A shared FMR TLV type registry MAY be established to ensure interoperability across different federation protocols. If established, it SHOULD be managed under the "Specification Required" policy [RFC8126].¶
The author thanks the DAWN working group participants for their foundational work on agent discovery terminology, requirements, and gap analysis. This architecture builds directly on the DAWN problem statement, requirements, use cases, and the discovery mechanism survey by Jimenez et al.¶
This appendix provides detailed considerations for federation synchronization protocols that may be standardized separately based on this architecture. These details are informational and are provided to guide future protocol design.¶
For closed trusted federations (Model A, Section 7.1), a structured peering model analogous to BGP [RFC4271] provides fast convergence and fine-grained policy control.¶
Each FGW establishes persistent unicast sessions with configured peer FGWs.¶
Incremental updates are sent when local agent state changes. Full table dumps are exchanged only upon session establishment or after a reset.¶
Per-peer export and import policies control which FMRs are advertised to or accepted from each peer.¶
Keepalive and hold timers detect peer failures.¶
Route reflection or confederation concepts may be applied to reduce full-mesh requirements in large closed federations.¶
For large-scale loose federations (Model B, Section 7.2), gossip-based protocols provide horizontal scalability at the cost of eventual consistency.¶
Each FGW maintains a small, bounded set of neighbor FGWs (e.g., log N for N participants).¶
During each gossip cycle, the FGW exchanges a digest of its FAD with a randomly selected neighbor, followed by exchange of missing or updated FMRs.¶
Anti-entropy synchronization reconciles divergent states during periodic full exchanges.¶
Neighbor selection may be random, topology-aware, or latency-optimized.¶
Due to the risk of rapid forged metadata propagation, this model SHOULD be combined with strict FMR signature verification and rate limiting.¶
In a mixed-protocol federation, FGWs using different synchronization mechanisms must still exchange FMRs. This may be achieved by:¶
Deploying protocol translators or bridge FGWs that participate in multiple synchronization overlays.¶
Defining a common FMR advertisement format that is opaque to the synchronization protocol.¶
Using a shared bootstrap mechanism (e.g., DNS-SD or a well-known URI) for neighbor discovery across protocols.¶