Considerations for Agent Gateway Integration within the DAWN Framework

Introduction The rapid proliferation of artificial intelligence entities, autonomous workloads, specialized datasets, and compute resources has highlighted a fundamental architectural challenge in modern network infrastructure: how can an autonomous agent discover another agent or discover a specific capability situated behind an administrative boundary in a secure, privacy-preserving, and interoperable manner? As described in the DAWN Problem Statement and established in the IETF DAWN Working Group Charter, current discovery methods are heavily fragmented. Existing systems rely on proprietary directories, static IP configurations, or localized name lookups that fail to scale across administrative trust boundaries, cannot express dynamic entity attributes (such as real-time compute load or availability status), and lack standardized mechanisms for discovering sub-agents operating within private local networks behind Network Address Translation (NAT) and firewalls. The DAWN framework establishes a high-level lifecycle for interacting entities, spanning identity provisioning, authentication, authorization, access to a Discovery Substrate via an Access Point, peer-to-peer invocation, and continuous monitoring. However, realizing this lifecycle across heterogeneous networks requires a concrete middleware component capable of bridging local domain mechanisms with wide-area discovery fabrics. The Agent Gateway (AGW) serves as that essential universal infrastructure component. Operating at the boundary of administrative domains, the Agent Gateway acts primarily as a Dual-Directional Discovery Proxy:

Outbound Discovery Proxy (Access Point Mode): Assisting resource-constrained or domain-internal agents in querying wide-area DAWN discovery substrates, resolving remote agent endpoints, and verifying peer credentials without requiring every local node to implement complex wide-area discovery protocols.
Inbound Domain Discovery Proxy (Aggregator/Broker Mode): Receiving external DAWN discovery queries, evaluating query parameters against an internal Local Agent Registry, performing capability matching for sub-agents situated behind the gateway, and exporting an aggregated Minimum Discoverable Information (MDI) descriptor. This mechanism enables external agents to discover matching sub-agent capabilities while shielding internal network topologies, sub-agent IP addresses, and private domain architecture.

Terminology and Conceptual Mapping This document aligns with the core terminology established in the DAWN problem space and the Agent Gateway functional specifications. Key terms include:

Agent Gateway (AGW): A logical or physical middleware gateway deployed at domain boundaries or central management hubs, responsible for cross-domain trust, protocol translation, task routing, and capability discovery.
Discovery Substrate: The underlying distributed framework or federation protocol through which discoverable objects are registered, indexed, searched, and resolved.
Discoverable Object: The formal descriptor (such as an Agent Card or Task Card) exposed by an entity or gateway to represent its capabilities, requirements, or endpoints within the discovery substrate.
Minimum Discoverable Information (MDI): The standardized minimal payload structure embedded in a Discoverable Object, containing essential identity, skill schemas, security requirements, dynamic health metrics, and communication URIs necessary for remote entities to determine interaction suitability.
A2A Gateway: The AGW functional sub-module dedicated to inter-agent protocol translation, authentication, task lifecycle management, P2P NAT traversal, and skill routing.
Network Gateway: The AGW functional sub-module handling transport-layer connectivity, STUN/TURN/ICE P2P traversal, link failover, and quality-of-service (QoS) management.

DAWN Conceptual Requirement	Agent Gateway Architecture Realization
Discovery Substrate Access Point	AGW Outbound Discovery Engine & Wide-Area Query Relay
Broker / Aggregator Entity	AGW Inbound Discovery Proxy & Aggregated MDI Exporter
Discoverable Object / MDI	Aggregated Agent Card exposed at `/.well-known/agent.json`
Sub-Agent Discovery Behind Gateway	AGW Local Agent Registry & Internal Capability Matcher
Selective Disclosure & Privacy	AGW Topology Obfuscation & MDI Masking Engine
Dynamic Attribute Handling	AGW TTL Cache & Active Heartbeat Monitor
Local / Wide-Area Resolution	Dual-Mode mDNS (LAN) / Unicast DNS-SD (WAN) Responder

Dual-Directional Discovery Proxy Architecture and Operational Modes The following diagram below illustrates the dual-directional discovery proxy architecture of the Agent Gateway within the DAWN framework:

Mode A: Outbound Discovery Proxy (Serving Local Agents to Discover External Entities) In Mode A, a local domain agent needs to discover an external agent or service operating in a remote domain or public federation. Rather than requiring the local agent to implement wide-area DNS-SD resolution, mTLS certificate validation, and complex DHT lookup protocols, the local agent delegates the discovery task to the Agent Gateway:

Local Query Submission: The local agent issues a lightweight discovery query (e.g., via local mDNS or HTTP GET) to the AGW, specifying required skills, domain parameters, or target entity names.
AGW Substrate Resolution: The AGW acts as the DAWN Discovery Substrate Access Point, querying wide-area DNS-SD registries, federated AGW peers, or public DAWN indexers.
Validation & Filtering: The AGW retrieves candidate MDI descriptors, verifies cryptographic domain signatures, enforces local security policies, and filters out unverified or malicious endpoints.
Response Delivery: The AGW returns a sanitized list of verified remote agent endpoints to the requesting local agent.

Mode A work flow: Outbound Agent Discovery via AGW Access Point | | | | | (2) Unicast DNS-SD Query | | | | _dawn-agw._tcp.domain.org | | | |------------------------------>| | | |<------------------------------| | | | (3) PTR, SRV, TXT Answer | | | | | | | | (4) Out-of-band Fetch MDI | | | | GET /.well-known/agent.json | | |------------------------------------------------------------>| | |<------------------------------------------------------------| | | (5) Full MDI Descriptor | | | | | | | | (6) Validate Provenance & Cert| | | (7) Return Filtered Candidates| | | |<------------------------------| | | ]]> The execution sequence below details how a local sub-agent delegates wide-area agent discovery to the Agent Gateway acting as a DAWN Discovery Substrate Access Point.

Local Internal Discovery Query (Step 1): Local Sub-Agent A (a lightweight entity in Domain A) requires a third-party logistics agent. Lacking wide-area DNS-SD capabilities, Sub-Agent A sends a simple local discovery request to Local AGW (POST /local-discovery).
Wide-Area DAWN Substrate Resolution (Step 2 & 3): Local AGW acts as the Discovery Substrate Access Point. It executes unicast DNS-SD queries against wide-area DNS servers, searching for _dawn-agw._tcp PTR, SRV, and TXT resource records. The DNS infrastructure returns candidate gateway endpoints.
Out-of-Band Remote MDI Fetch (Step 4 & 5): Local AGW contacts candidate Remote AGW (Domain B) at its HTTPS MDI URI (/.well-known/agent.json) to fetch the full JSON-Schema capability descriptor.
Policy & Cryptographic Validation (Step 6): Local AGW validates Remote AGW's domain provenance, verifies cryptographic certificate chains, and filters out candidate endpoints that fail domain security policies.
Filtered Candidate Delivery (Step 7): Local AGW returns a verified, sanitized list of discovered remote agent endpoints to Local Sub-Agent A, completing the outbound discovery sequence.

Mode B: Inbound Domain Discovery Proxy (Serving External Agents to Discover Sub-Agents Behind Gateway) In Mode B, an external remote agent seeks to discover whether a specific capability (e.g., skill: hvac_control or skill: energy_storage_query) is available within Domain B. The internal sub-agents possessing these capabilities reside behind symmetric NATs or corporate firewalls and cannot directly expose public IP addresses or DNS records. The AGW processes the inbound discovery request through the following steps:

Inbound Query Reception: The external agent queries the AGW's public MDI endpoint (/.well-known/agent.json) or performs a DNS-SD TXT lookup against _dawn-agw._tcp.example.org.
Internal Capability Matching: The AGW's Capability Matcher queries the Local Agent Registry, cross-referencing requested skill IDs, version constraints, and dynamic status (e.g., current load and online status of sub-agents).
Selective MDI Aggregation: If one or more internal sub-agents match the requested criteria, the AGW constructs an aggregated MDI payload. The MDI reports that Domain B possesses the requested capabilities and provides the AGW's public ingress URI as the reachable endpoint.
Topology Concealment: The internal sub-agent's private IP address, host identifier, hardware architecture, and internal network placement remain completely hidden from the external requester.

Mode B work flow: Inbound Discovery of Sub-Agent Capabilities Behind AGW | | | | Store Sub-Agent Entry | | | | | | | (1) Inbound DAWN Query: | | | | GET /.well-known/agent.json | | | |------------------------------>| | | | | (2) Match Skill | | | |------------------------------->| | | | Query: skill=hvac_control | | | |<-------------------------------| | | | (3) Return Sub-Agent B Match | | | | | | | | (4) Aggregate MDI & Mask IPs | | | (5) Return Aggregated MDI | | | | (200 OK, Public Ingress) | | | |<------------------------------| | | ]]> The execution sequence below details how an External Requester Agent discovers matching sub-agent capabilities situated behind a Target Agent Gateway (Domain B) while preserving domain topology privacy.

Internal Sub-Agent Capability Registration (Step 0): Upon initialization within private Domain B, Internal Sub-Agent B (e.g., an HVAC Controller) sends an intra-domain registration payload to Target AGW. The registration contains Sub-Agent B's fine-grained skill schema (skill_id: hvac_control), versioning, required authorization scopes, and internal transport endpoint. Target AGW validates the payload and stores the entry in its Local Agent Registry.
Inbound DAWN MDI Discovery Query (Step 1): External Agent (Domain A) seeks an entity capable of managing environmental controls in Domain B. It issues an HTTP GET request to Target AGW's standardized MDI endpoint (GET /.well-known/agent.json).
Internal Capability Matching (Step 2 & 3): Target AGW receives the query and invokes its Capability Matcher engine. The engine queries the Local Agent Registry, searching for active sub-agents matching skill: hvac_control with online status and available capacity. The registry confirms that Sub-Agent B matches all criteria.
Selective MDI Aggregation & Topology Masking (Step 4): Target AGW constructs a public Discoverable Object (Aggregated Agent Card). Crucially, the gateway strips out Sub-Agent B's internal IP address, internal host name, and network topology. It substitutes its own public HTTPS/WebSocket ingress URI as the official reachability endpoint.
MDI Response Delivery (Step 5): Target AGW returns the aggregated MDI payload (HTTP 200 OK) to External Agent. External Agent successfully discovers that Domain B supports hvac_control and learns the public endpoint and authentication requirements necessary for subsequent interaction.

Mode A work flow (Outbound Discovery) and Mode B work flow (Inbound Discovery) fall directly IN-SCOPE for the IETF DAWN Working Group, as they pertain exclusively to initial capability querying, DNS-SD resolution, and Minimum Discoverable Information (MDI) retrieval.

Sub-Agent Discovery Scenarios Across Network Topologies Following the multi-agent communication scenario analysis, AGW discovery proxying adapts to three canonical deployment environments:

Scenario 1: Single-Domain Single-Agent Environment In localized environments (such as a smart device hub controlling local sensors), the embedded AGW translates local device protocol schemas (MQTT/Modbus) into standard Agent Cards. The AGW registers local capabilities with intra-domain mDNS responders (.local domain), allowing local discovery while preventing unauthorized WAN exposure.

Scenario 2: Single-Domain Multi-Agent LAN Environment In smart campus or enterprise LAN environments, multiple sub-agents (Lighting Agent, Security Agent, HVAC Agent) co-exist across VLANs. The Campus AGW acts as the central Intra-Domain Capability Registry. Sub-agents register their skills upon boot. When an emergency event occurs, the Security Agent queries the AGW to discover local HVAC and Notification sub-agents via LAN-first mDNS/DNS-SD without requiring internet connectivity.

Scenario 3: Cross-Domain Multi-Agent Environment In cross-domain environments (e.g., a Vehicle Agent querying a Home Domain AGW), the Vehicle Agent cannot access the private residential LAN. The Vehicle Agent queries the Home AGW's public DAWN MDI endpoint. The Home AGW matches the request against its internal registry (finding local HVAC and Garage controllers), evaluates OAuth 2.0 authorization scopes, enforces Human-In-The-Loop (HITL) safety policies for high-risk skills, and returns an aggregated MDI descriptor.

Agent Gateway Roles in DNS-SD / mDNS Discovery The IETF DAWN framework leverages the Domain Name System (DNS) and Multicast DNS (mDNS) as foundational transport mechanisms for initial AI resource locating. However, standard DNS infrastructures are inherently static, domain-unaware, and incapable of representing complex AI agent capability hierarchies, dynamic health metrics, or topology isolation policies. Within the DAWN discovery fabric, the Agent Gateway (AGW) serves as the essential intelligent mediation layer between AI entities and the underlying DNS/mDNS protocols. When DNS-SD and mDNS are employed for DAWN discovery, the Agent Gateway fulfills four crucial architectural roles across local and wide-area networks: Local Multicast mDNS (UDP 5353, .local) | | [ Role 2: WAN DNS-SD Aggregator ] <---> Authoritative DNS Zone Management | | [ Role 3: Outbound DNS Resolver] <---> Wide-Area DNSSEC & Policy Validation | | [ Role 4: Dynamic TTL/MDI Adapter] <---> Two-Stage Filtering & Cache Control | | | | +---------------------------------------------------------------------------------+ | | | Local Agent Registry | Capability Matcher Engine | Topology Masking Module | | | +---------------------------------------------------------------------------------+ | +---------------------------------------------------------------------------------------+ ^ ^ | Intra-Domain Registration / Query | Direct Inbound Discovery v v +-----------------------+ +-----------------------+ | Internal Sub-Agents | | External Requesters | | (HVAC, Security, etc) | | (Remote Agents / AGW) | +-----------------------+ +-----------------------+ ]]>

Local LAN mDNS Proxy Registrar & Responder:
- Problem: Lightweight or specialized internal sub-agents (e.g., embedded sensors, HVAC controllers, micro-agents) often lack full mDNS/DNS-SD protocol stacks or cannot safely participate in LAN multicast traffic.
- AGW Role: The AGW runs an internal mDNS Responder (listening on UDP port 5353). As internal sub-agents register their skills with the gateway's Local Agent Registry, the AGW automatically proxies and announces their capabilities on the local subnet under the .local domain. When local peers query for available capabilities, the AGW responds on behalf of all internal sub-agents, eliminating the need for every micro-agent to host a standalone mDNS daemon.
Wide-Area DNS-SD Authoritative Aggregator & Topology Masking Proxy:
- Problem: Directly publishing individual sub-agent hostnames, private IP addresses, or internal port numbers into public DNS zones creates severe security vulnerabilities, leaks network topology, and fails for nodes situated behind NATs.
- AGW Role: The AGW acts as an authoritative DNS-SD aggregator for wide-area domain zones (e.g., _dawn-agw._tcp.example.org). Instead of exposing individual sub-agents, the AGW aggregates internal skill schemas into a unified gateway descriptor. It registers itself as the sole public SRV target and A/AAAA endpoint, completely shielding internal sub-agent IP addresses, host counts, and network topologies from WAN inspection.
Outbound DNS Discovery Proxy & Safety Filter:
- Problem: Internal sub-agents seeking external services often lack the complexity to perform multi-stage DNS-SD PTR/SRV/TXT parsing, validate DNSSEC cryptographic provenance, or enforce domain security policies.
- AGW Role: The AGW serves as an outbound DNS resolution proxy. A local sub-agent issues a simplified discovery request to the gateway; the AGW executes unicast DNS-SD queries across wide-area DNS servers, validates DNSSEC signatures, verifies remote gateway certificate chains, filters out unverified or malicious endpoints, and returns a sanitized list of verified remote targets to the local requester.
Dynamic Attribute Adapter & DNS TTL Cache Manager:
- Problem: Standard DNS infrastructures are optimized for static or slow-changing resource records, whereas AI agents exhibit highly dynamic operational states (e.g., real-time CPU/memory load, instant availability status, dynamic skill enablement). Storing rapidly changing metrics directly in DNS causes record thrashing, excessive DNS traffic, and stale caching issues.
- AGW Role: The AGW reconciles standard DNS caching mechanics with dynamic AI agent states by enforcing a strict separation:
  - Static / Semi-Static Attributes (Skill IDs, protocol versions, authentication methods, domain endpoints) are mapped into DNS-SD TXT records with moderate TTL values (120s - 300s).
  - Highly Dynamic Metrics (real-time load, queue depth, precise memory availability) are excluded from DNS records and served dynamically during the Stage 2 out-of-band HTTPS MDI query, ensuring DNS records remain stable while real-time state remains accurate.

Scope Alignment: Agent Gateway Architecture vs. IETF DAWN Charter Scope To ensure strict compliance with IETF standardization boundaries, the table and text below delineate which Agent Gateway functions fall directly within the IETF DAWN Working Group Charter scope and which represent out-of-scope downstream middleware functions.

Scope Boundaries Summary

IETF DAWN Working Group Scope (In-Scope):
- Initial Client Locating & Endpoint Resolution;
- Public Minimum Discoverable Information (MDI) Payload Structure;
- DNS-SD / mDNS Resource Record Mappings (_dawn-agw._tcp);
- Aggregated Broker Discovery & Selective Disclosure Principles.
Agent Gateway Downstream Functions (Out-of-Scope for DAWN):
- Post-Discovery Task Execution & Message Dispatch (POST /a2a/tasks);
- Fine-grained Tool Schema Validation & Execution Sandboxing (MCP Gateway);
- LLM Inference Proxying & Semantic Caching (Model Routing Gateway);
- OAuth 2.0 / mTLS Identity Issuance & Human-In-The-Loop (HITL) Intercept;
- STUN/TURN P2P Transport & NAT Traversal (Network Gateway).

Detailed Scope Boundary Analysis

Initial Locating vs. Post-Discovery Execution: The DAWN Charter explicitly limits its work to the initial phase of locating and discovering AI resources. In the AGW architecture, MDI querying and DNS-SD resolution belong strictly to DAWN. Once an agent discovers the AGW endpoint, subsequent task submission (POST /a2a/tasks), asynchronous queuing, and message passing fall outside DAWN's scope and are governed by inter-agent protocols (e.g., A2A / MCP).
Public MDI vs. Detailed Capability Catalogs: The DAWN Charter specifies that detailed catalogs of capabilities are out of scope. AGW aligns with this by exposing only high-level skill tags, protocol versions, and security requirements in the public MDI (agent.json). Deep tool parameter schemas (JSON RPC / OpenAPIs) remain behind the gateway, managed by the MCP Gateway upon authenticated post-discovery invocation.
Identity Management & Trust: DAWN excludes deep trust management, relying on existing IETF standards (OAuth, WIMSE, PKIX). AGW enforces OAuth 2.0 Bearer tokens and mTLS at the boundary, treating identity verification as an orthogonal dependency as specified by DAWN.

Gateway Operational Capability	IETF DAWN Charter Status	Responsible AGW Sub-Module	Applied Standards / Protocol
Initial Public MDI Discovery	In-Scope	Ingress & Registration Engine	`/.well-known/agent.json`, DNS-SD
Domain MDI Aggregation & Masking	In-Scope	Selective Disclosure Engine	DAWN MDI Schema, Selective Disclosure
mDNS LAN / Unicast WAN Discovery	In-Scope	Dual-Mode DNS Engine	mDNS, DNS-SD
Post-Discovery Task Execution	Out-of-Scope	A2A Gateway (`POST /a2a/tasks`)	Inter-Agent Protocol (A2A / HTTP/2)
OAuth2 / mTLS Authentication	Out-of-Scope (Dependency)	Security Module	OAuth 2.0 , mTLS
P2P Relay & NAT Traversal	Out-of-Scope (Transport)	Network Gateway	STUN/TURN/ICE

Technical Resolution Matrix: DAWN Challenges vs. AGW Interventions The DAWN Problem Statement identifies six fundamental challenges facing internet-scale discovery. The table below details how the Agent Gateway architecture resolves each challenge during the discovery phase:

DAWN Core Challenge	AGW Technical Intervention & Architecture Solution
Skills & Capabilities at Scale	AGW indexes internal sub-agent skills in its Local Agent Registry, constructs hierarchical capability trees, and exposes lightweight aggregated MDI schemas for fast wide-area matching.
Fragmented Discovery Ecosystem	AGW acts as a universal discovery proxy, bridging local mDNS/DDS/MQTT discovery mechanisms with wide-area unicast DNS-SD and DAWN JSON MDI endpoints.
Trust in Discovery Information	AGW enforces mandatory mTLS for inter-gateway peering, verifies DNS-SD DNSSEC signatures, and checks authoritative domain provenance to eliminate discovery poisoning.
Scalability & Decentralization	AGW enables autonomous domain governance. Each gateway manages its local sub-agent registry and publishes minimal MDI descriptors without relying on centralized internet directories.
Static vs. Dynamic Properties	AGW separates long-lived static capabilities (skill IDs, protocol versions) from dynamic operational status (load, availability) using explicit TTL fields and active heartbeat validation.
Future Extensibility	AGW employs a modular, plugin-based capability matching engine, permitting seamless integration of future AI entity types, specialized model formats, and new network transports.

Security Considerations As the single ingress and egress boundary for cross-domain multi-agent discovery, the Agent Gateway MUST enforce strict security and privacy protections compliant with IETF guidelines:

Transport Security: All external discovery interfaces MUST require TLS 1.3 encryption . Plaintext HTTP or unencrypted DNS queries over untrusted public networks MUST be upgraded to DoT (DNS over TLS, or DoH (DNS over HTTPS, ).
Anti-Poisoning & Authority Validation: AGWs MUST validate DNSSEC signatures for unicast DNS-SD records and verify OAuth 2.0 / JWT domain signatures to prevent malicious third parties from injecting toxic discovery responses.
Selective Disclosure & Mutual Privacy: Conforming to and DAWN privacy requirements, AGW implements selective disclosure. The gateway conceals internal sub-agent counts, private IP topologies, and hardware specifications, returning only aggregated MDI descriptors. Simultaneously, discovery queries digest requester identity to limit intent tracking.
Human-in-the-Loop (HITL) Out-of-Band Safety: High-risk operations discovered via MDI (marked with require_human_approval: true) MUST cause downstream execution engines to suspend task processing and push verification requests to the domain owner's authenticated device via an isolated push channel.
Tamper-Proof Audit Logging: AGW components MUST record structured audit logs for all cross-domain discovery queries and capability lookups, capturing timestamp, issuer identity, target skill ID, and authorization scope.

Appendix: Use Cases and Deployment Scenarios To provide practical guidance for implementers, this section details three representative deployment use cases focusing specifically on discovery workflows.

Use Case 1: Sub-Agent Registration and LAN Discovery in Smart Home In a smart home environment, a localized Supervisor Agent acts as an embedded AGW. When a new smart thermostat sub-agent boots up, it broadcasts an intra-domain mDNS registration (thermostat._dawn-agw._tcp.local.). The embedded AGW stores the sub-agent's skill (skill: climate_control) in its Local Agent Registry. When a local voice assistant agent queries the embedded AGW for climate control capabilities, the AGW matches the request instantly over LAN without querying external cloud servers.

Use Case 2: Campus AGW Capability Indexing & Emergency Discovery A university campus operates multiple domain agents (Security, HVAC, Lighting) across distinct VLANs. During an environmental safety incident, the Security Agent queries the Campus AGW seeking entities matching category: environmental_safety and latency: <50ms. The Campus AGW checks its Local Agent Registry, matches the request to the HVAC Agent (skill: isolation_ventilation) and Lighting Agent (skill: emergency_strobe), and returns internal endpoints. LAN-first resolution completes in < 10 ms, allowing immediate damper closure even if internet connectivity is severed.

Use Case 3: Vehicle Agent Discovering Home Sub-Agent Capabilities Behind Residential Gateway An Autonomous Vehicle Agent (Domain A) approaching the owner's home (Domain B) queries the DAWN wide-area substrate to locate Domain B's Home AGW. The Vehicle Agent fetches Domain B's aggregated MDI (/.well-known/agent.json), discovering available capabilities (skill: preheat_hvac and skill: unlock_garage_gate). The Home AGW matches the request against its internal sub-agents while hiding private home IP addresses and network topology. The Vehicle Agent obtains the Home AGW ingress endpoint and authentication requirements necessary for subsequent interaction.

IANA Considerations TBC