Gap Analysis and Applicability Statement for Discovery Protocols of Agents, Workloads, and Named Entities (DAWN)
draft-moussa-dawn-gap-analysis-01
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Hesham Moussa , Arashmid Akhavain | ||
| Last updated | 2026-06-12 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-moussa-dawn-gap-analysis-01
Network Working Group H. Moussa
Internet-Draft A. Akhavain
Intended status: Informational Huawei Technologies Canada
Expires: 14 December 2026 12 June 2026
Gap Analysis and Applicability Statement for Discovery Protocols of
Agents, Workloads, and Named Entities (DAWN)
draft-moussa-dawn-gap-analysis-01
Abstract
This Internet-Draft provides a gap analysis and applicability
statement that maps existing Discovery Mechanisms and protocols to
the DAWN problem statement and discovery requirements. The analysis
evaluates security, privacy, applicability, flexibility, and
suitability of existing standardized, non-standardized, and proposed
discovery solutions and protocols to the DAWN problem statement and
REQ-DISC corpus. It identifies high priority gaps, proposes
mitigations and hybrid patterns, and serves as reference for future
prototyping and development. The intention is for this draft to
evolve as new solutions come to existence.
Status of This Memo
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 14 December 2026.
Copyright Notice
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.
Moussa & Akhavain Expires 14 December 2026 [Page 1]
Internet-Draft DAWN Gap Analysis June 2026
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Intended audience . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Key Motivating Scenarios and Risks . . . . . . . . . . . 5
4. Analysis Methodology . . . . . . . . . . . . . . . . . . . . 7
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Evaluation steps . . . . . . . . . . . . . . . . . . . . 7
4.3. Notes for further guidance and considerations . . . . . . 8
5. Summary of REQ-DISC document . . . . . . . . . . . . . . . . 9
6. Summary of use case document . . . . . . . . . . . . . . . . 10
7. Discovery Mechanism High-level Descriptions and Evaluation . 10
7.1. DNS (including SVCP/HTTPS and TXT) . . . . . . . . . . . 10
7.2. mDNS/DNS-SD . . . . . . . . . . . . . . . . . . . . . . . 13
7.3. SSDP/UPnP . . . . . . . . . . . . . . . . . . . . . . . . 16
7.4. DNS-AID . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.5. A2A (Agent2Agent) . . . . . . . . . . . . . . . . . . . . 19
7.6. CATS (Compute-Aware Traffic Steering) — IETF working
group . . . . . . . . . . . . . . . . . . . . . . . . . 24
7.7. MCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
7.8. AGNTCY . . . . . . . . . . . . . . . . . . . . . . . . . 27
7.9. Service registries & orchestration . . . . . . . . . . . 27
7.10. HTTP/.well-known RFC8615 . . . . . . . . . . . . . . . . 27
7.11. WebFinger RFC7033 . . . . . . . . . . . . . . . . . . . . 27
7.12. Search & crawling . . . . . . . . . . . . . . . . . . . . 31
7.13. Centralized marketplaces . . . . . . . . . . . . . . . . 31
7.14. P2P/DHT and decentralized registries . . . . . . . . . . 31
7.15. Manual/configuration-based discovery . . . . . . . . . . 31
8. Security Considerations . . . . . . . . . . . . . . . . . . . 35
9. Operational Considerations . . . . . . . . . . . . . . . . . 35
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 35
12.1. Normative References . . . . . . . . . . . . . . . . . . 36
12.2. Informative References . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
Moussa & Akhavain Expires 14 December 2026 [Page 2]
Internet-Draft DAWN Gap Analysis June 2026
1. Introduction
1.1. Purpose
Many distributed processing environments depend on the interaction
between components that do not have pre-configured capability,
location, or reachability relationships. In order for these systems
to operate correctly, the components must be able to discover each
other. For complete generality, we call these components "entities".
Entities may be tasks, workloads, endpoints, services, AI agents,
etc. In each case, an entity needs knowledge of other entities
before interaction can proceed: what they are, what they offer, and
whether they can be trusted. Such knowledge could be obtained via
various forms of discovery ranging from static and passive pre-
configuration of the knowledge of other entities, to more advanced
active search and location processes.
DAWN frames the discovery challenge as the need for interoperable,
scalable mechanisms that enable a diverse set of entities to find and
uncover information about one another either within or across
administrative and network boundaries. This document provides a
neutral, actionable assessment of how current discovery mechanisms
meet the DAWN problem statement and requirements, and where gaps
remain along areas including security, privacy, applicability,
flexibility, and suitability for the DAWN use cases.
1.2. Scope
This document is expected to continuously evolve as solutions to the
DAWN discovery problem continue to evolve. The following is to set
the scope of the current version of the document as a reference:
* Mechanisms evaluated: DNS family (DNS [RFC1123], DNS-SD [RFC6763],
SVCB/HTTPS [RFC9460], TXT), DNS-AID
[I-D.mozleywilliams-dnsop-dnsaid], HTTP/.well-known [RFC8615] and
WebFinger [RFC7033], A2A agent cards and Agntcy, MCP discovery,
service registries (Consul, Kubernetes), multicast local discovery
(mDNS [RFC6762]/SSDP), centralized catalogs, P2P/DHT, search/
crawler and semantic indexes, push/pubsub (LISP [RFC9437])
channels, CATS (Compute-Aware Traffic Steering). This is an
expandable list and shall continue to grow as additional DAWN
solutions become available.
* Discovery targets: agents, tools, skills, tasks, workloads,
datasets, and resources.
Moussa & Akhavain Expires 14 December 2026 [Page 3]
Internet-Draft DAWN Gap Analysis June 2026
* Requirements baseline: the DAWN problem statement
[I-D.akhavain-moussa-dawn-problem-statement], the REQ-DISC
requirements [I-D.king-dawn-requirements], and use cases
[I-D.kay-dawn-use-cases] documents.
* Criteria for solution inclusion: Solutions selected for analysis
within the current document should meet one or more of the
following criteria:
- A standardized solution adopted by one or more Standards
Development Organizations (SDOs), such as IETF, 3GPP, ITU, or
similar bodies.
- A solution proposed as part of an ongoing official
standardization effort, such as active IETF or 3GPP working
groups, ETSI Technical Committees (TCs), or Industry
Specification Groups (ISGs), and showing signs of maturity (for
example, having undergone sufficient critique, development, and
testing).
- Solutions supported by major open-source ecosystems,
foundations, or widely recognized community projects.
- Solutions with clear adoption or deployment by a broad audience
or client base, indicating potential to become a de facto
standard.
* Primary evaluation focus: security, privacy, applicability to DAWN
requirements, flexibility for multiple entity types and deployment
models, operational suitability, and mitigation and development
cost.
1.3. Intended audience
IETF communities, working groups, other standard bodies, and
developers (DAWN, DNSOP, Add others???), platform architects,
registry operators, and developer of agent and tool ecosystems.
2. Terminology
The following terms are used in this document as defined in
[I-D.farrel-dawn-terminology].
* Entity
* Attributes
* Discoverable object
Moussa & Akhavain Expires 14 December 2026 [Page 4]
Internet-Draft DAWN Gap Analysis June 2026
* Minimum Discoverable Information (MDI)
* Discovery
* Capability exchange / negotiation
* Selection
* Discovery Mechanism
3. Motivation
Many modern distributed systems rely on automated interactions among
components that were not preconfigured to work together. Incomplete,
insecure, or poorly designed discovery undermines automation and can
lead to impersonation, stale or incorrect interactions, large-scale
privacy exposure, and brittle cross-domain integrations. The DAWN
Problem Statement and REQ-DISC requirements identify the need for
interoperable, scalable discovery mechanisms that operate across
administrative and network boundaries; this document responds by
assessing existing discovery methods and Mechanisms against those
requirements and by evaluating and highlighting gaps that most affect
safe, privacy-respecting, and ease of deployment to meet DAWN
discovery needs.
3.1. Key Motivating Scenarios and Risks
* Operational risk: Discovery that is operationally stale, allows
unauthenticated entries to participate, or renders incorrect
results can cause connections to wrong or potentially unsecure
endpoints, execution of unsafe actions, and unexpected outcomes.
This includes cases where compromised descriptors/cards or
outdated pointers lead to impersonation, misrouting (to which
entity the request goes to), or cascading failures in workflows.
Mitigations include strong authenticity checks, signed
descriptors/cards, and timely revocation mechanisms. Another
major operation risk lies in queries that potentially may result
in unbounded searches and could be used to invoke denial of
service attacks.
Moussa & Akhavain Expires 14 December 2026 [Page 5]
Internet-Draft DAWN Gap Analysis June 2026
* Privacy risk: Public or poorly controlled discovery query,
response and OAM channels can expose sensitive information about
entities, their relationships, and intentions. Attackers or
unauthorized parties can scrape open indexes, correlate query
logs, or exploit predictable naming to build profiles, infer
business plans, or target specific systems. Mitigations include
minimizing the need for exposing sensitive information during the
discovery process, gating access to rich descriptors/cards, secure
transport channels, and proper handling of logs, tracking, and
history records.
* Interoperability gap: Many discovery solutions are
platform-specific or use incompatible formats, which prevents
entities from discovering one another across administrative
domain, vendor boundaries, or even within the same organization.
This fragmentation increases operational and integration costs,
slows automation, and encourages siloed ecosystems. Mitigations
include defining a standardized minimum common descriptor schema/
cards, being hardware and underlay network agnostic, and supports
backward compatibility and integration with legacy systems.
* Scalability and deployment: Some discovery mechanisms do not scale
to internet-wide, federated use or impose heavy operational
burdens on operators. Problems include excessive indexing costs,
high query volumes on authoritative servers, lack of a unified
solution to support discovery of various types of entities, costly
monitoring mechanisms to maintain up-to-date entity statuses, and
complex deployment process.
* DAWN suitability: Solution suitability for DAWN refers to its
practicality to meet DAWN Problem Statement, REQ-DISC goals, and
suggested use cases. This includes utilizing strong
authentication and provenance mechanisms, enabling privacy
controls and anti-disclosure measures, representing the full range
of entity types, allowing extensible and standardized descriptor/
card formats, operating at internet scale without undue operator
burden, and support interoperability. When the above criteria
cannot be met by existing solutions, there will be a need to
develop solutions that support at least aspects such as
standardized descriptor mappings and different methods of
publication and disclosure to achieve interoperable, secure, and
deployable discovery.
This document therefore aims to produce actionable outcomes for
implementers and operators by analyzing currently implemented or
proposed Discovery Mechanisms and protocols. The objective is to
help guide standardization efforts by shedding light on potential
gaps and recommending some mitigation measures.
Moussa & Akhavain Expires 14 December 2026 [Page 6]
Internet-Draft DAWN Gap Analysis June 2026
4. Analysis Methodology
4.1. Overview
We adopt an itemized analytical approach where each Discovery
Mechanism is examined against the same set of evaluation metrics.
Figure 1 of the problem statement document
[I-D.akhavain-moussa-dawn-problem-statement] serves as the reference
architecture accepted by DAWN. As per this architecture, entities
are to be discovered using their discoverable information registered
into the Discovery Mechanism. Fields of the discoverable information
are divided into mandatory and optional. As an initial baseline, a
single discoverable information model for evaluation is considered
for all types of entities consisting of mandatory fields that cover
the following aspects: entity identifier, standard entity descriptor
(what is it, what can it do, how to interact with it...etc), human
summary (for ease of accessibility by humans), endpoints/pointers,
conveying trust related material, privacy/access indicators,
freshness/lifecycle (i.e. status), operational metadata, indexing
hints, current status, and entity provenance.
4.2. Evaluation steps
* Preparation step:
- Select, based on the criteria mentioned in section Section 1.2,
the discovery mechanisms to be evaluated.
- Extract REQ-DISC items from the requirements document
[I-D.king-dawn-requirements] and map them to Mechanism
evaluation criteria.
- Extract use case-specific discovery requirement as per
[I-D.kay-dawn-use-cases]
* Evaluate Level of Coverage of REQ-DISC: For each Mechanism,
evaluate coverage of REQ-DISC items, use case-specific
requirements, and discoverable information fields using a
three-level scale: Full, Partial, None. Also note native encoding
of each Mechanism were, for each, record one of: native support,
common extension to the Mechanism, hybrid pattern, or no practical
support without extensive redesign.
* Security, privacy, and DAWN suitability evaluation:
- Conduct informed analysis: Evaluate exposure to assumed
adversaries (passive observer, on-path attacker, operator
adversary, malicious publisher, Sybil);
Moussa & Akhavain Expires 14 December 2026 [Page 7]
Internet-Draft DAWN Gap Analysis June 2026
- Examine potential information leakage: potential for public
metadata leakage, enumeration risk, query logging exposure,
linkability, and stale exposure;
- Compare against DAWN REQ-DISC and use case-specific criteria.
- Assign a numeric impact score from 0–3 that reflects how well a
Mechanism meets the three criteria (security, privacy, DAWN
suitability): (0) Not suitable:
High security or privacy risk; does not meet DAWN requirements;
(1) Low suitability: Requires only minor changes to meet at least
one of the three criteria; (2) Moderate suitability: Meets one
criterion natively and can meet at least one of the remaining
criteria with minor changes; (3) High suitability: Meets at least
two criteria natively and meets the third either natively or with
only minor changes. It should be noted here that these measures
are intended to evaluate how secure and private the discovery
process is.
* Operational cost: Study deployment and operation cost of each
Mechanism. Assign a simple adoption values (low, medium, high)
for operator reflecting expected operation burden and deployment
friction.
* Mitigation cost: First, identify potential gaps by analyzing each
Discovery Mechanism and determining what features are missing to
meet security, privacy, and DAWN REQ-DISC items. Accordingly,
evaluate cost for mitigation by proposing protocol-level,
operational, and/or hybrid mitigations and prototype patterns to
potentially alleviate Mechanism downfalls against the
requirements. Assign simple values to reflect mitigation costs
(low, medium, high).
4.3. Notes for further guidance and considerations
Performance assessment:
* List common extensions or hybrid patterns that fill gaps (e.g.,
DNS pointer → HTTPS descriptor; registry webhook for revocation).
* Mitigations: note whether mitigations are supported natively, via
extension, or only by operational practice.
* Cache model: document caching semantics (TTL, intermediate caches,
CDN behavior).
Moussa & Akhavain Expires 14 December 2026 [Page 8]
Internet-Draft DAWN Gap Analysis June 2026
* Revocation channels: identify available mechanisms (short
validity, push notifications, status endpoints).
* Estimate stale window: provide a worst-case stale exposure
estimate and practical mitigations (short TTL, signed timestamps,
push).
Inter-operability assessment:
* Round-trip checks: verify that a descriptor encoded in Mechanism A
can be represented and validated when consumed via Mechanism B;
note lossy fields.
* Adapter patterns: document minimal adapter logic required to
translate between formats.
Operational assessment:
* Deployability: list operator requirements (hosting, key
management, logging, rate limiting).
* Scale considerations: estimate query load, indexing cost, and
storage needs for representative use cases.
5. Summary of REQ-DISC document
As per the REQ-DISC document [I-D.king-dawn-requirements], a
discovery solution addressing the DAWN requirements should:
* Support discovery of agents, services, workloads, and other named
entities by both human users and automated systems across
organizational and administrative boundaries.
* Enable discovery based on entity identity, attributes, roles, and
advertised capabilities, allowing requesters to locate entities
that satisfy specific functional requirements.
* Provide machine-readable metadata describing discovered entities,
including capabilities, ownership, policy information, security
characteristics, and references to additional descriptive
resources.
* Operate across heterogeneous administrative domains while
supporting decentralized and federated deployment models that
avoid reliance on a single centralized registry.
Moussa & Akhavain Expires 14 December 2026 [Page 9]
Internet-Draft DAWN Gap Analysis June 2026
* Establish trust in discovery information through mechanisms that
support authenticity, integrity validation, provenance, and
policy-based assessment of discovered entities.
* Support controlled publication and selective disclosure of
discovery information, allowing organizations to manage visibility
of entities and associated metadata according to policy and trust
relationships.
* Scale to Internet-wide deployment, supporting large numbers of
entities, frequent updates, and dynamic environments in which
entities may appear, disappear, or change capabilities over time.
* Accommodate diverse implementation and deployment environments
without imposing assumptions about underlying communication
protocols, transport mechanisms, or execution platforms.
* Minimize opportunities for abuse, including unauthorized
information harvesting, spoofing, tampering, and other attacks
that could undermine the reliability or trustworthiness of
discovery results.
* Provide a foundation upon which higher-layer functions - including
capability negotiation, service selection, orchestration, and
agent-to-agent interaction - can be built, while remaining focused
on discovery itself.
6. Summary of use case document
To be completed as per the draft [I-D.kay-dawn-use-cases]
7. Discovery Mechanism High-level Descriptions and Evaluation
The following analysis is based on evaluations of the various
discovery solutions, substrates, and protocols against the REQ-DISC
summary provided in section Section 5. A quick note on DAWN
suitability block within each subsection. A more systematic and
rigorous evaluation approach against the REQ-DISC items is needed.
What is included is an initial high-level evaluation that shall be
improved with rounds of revisions to the current document.
7.1. DNS (including SVCP/HTTPS and TXT)
* *Summary*: DNS provides global, hierarchical name resolution and
can carry small discovery pointers (TXT, SVCB/HTTPS). It is
excellent for bootstrapping because it is ubiquitous and highly
cached.
Moussa & Akhavain Expires 14 December 2026 [Page 10]
Internet-Draft DAWN Gap Analysis June 2026
* *How it works*: Clients query recursive resolvers for resource
records (A/AAAA, TXT, SVCB, etc.). SVCB/HTTPS records can encode
structured service parameters so clients choose endpoints and
transport parameters before connecting. DNS responses are cached
by resolvers and intermediate caches according to TTLs.
* *Security, Privacy, and DAWN suitability Considerations:*
- Security:
o Strengths: Widely deployed tooling; DNSSEC can provide
signed RRsets and integrity guarantees; SVCB improves client
pre-connection behavior.
o Weaknesses: Trust is concentrated in authoritative servers
and resolvers; on-path or operator adversaries can observe
or manipulate queries unless additional protections are
used.
- Privacy:
o Queries and responses are observable by resolvers and
on-path observers hence increases the risk of privacy
provocation.
o It also builds caches and public records that are indexable
and enumerable allowing various privacy attacks.
o Techniques such as DoH/DoT are used to reduce on-path
exposure but do not fully eliminate operator logging which
exposes a vulnerability.
o Using such limitations, public pointers can be scraped to
build maps of entities and activity patterns within DAWN
leading to a major privacy concern.
- DAWN suitability: Although DNS is excellent for bootstrap
pointers (telling a consumer where to look) and for federation/
bootstrapping at internet scale, its suitability to DAWN is
"Partial" for the following reasons
o DNS is fundamentally a lookup system - it assumes the
consumer knows the name or key to query. That model does
not fit DAWN's need for high-level, descriptive search
(e.g., "find agents that can translate legal contracts and
accept a $budget"), which often requires indexing, semantic
search, or registries that return multiple matches for a
description;
Moussa & Akhavain Expires 14 December 2026 [Page 11]
Internet-Draft DAWN Gap Analysis June 2026
o The DNS key-value model struggles to carry complex nested
capability structures and composite queries, introducing
limitations in expressiveness.
o These limitations suggest that DNS-based discovery
mechanisms may not fully meet the needs of typical DAWN
scenarios such as cross-domain capability filtering, dynamic
resource state queries, and global semantic search.
o However, DNS is suitable as a first hop in DAWN patterns and
covers a subset of discovery types that shall be supported
by DAWN.
- Security, Privacy, and DAWN suitability score: *1/3*
o Scalability and interoperability are supported. However,
security, privacy, information rich and semantic searches,
multi-cast operation, and multi-type of entity support are
still missing.
* *Use case fitness*
- TBC
* *Mitigations grouped by goal*
- Mitigations for Descriptor hosting and integrity:
o Mitigation: Host full descriptors on HTTPS endpoints; sign
descriptors with JWS (include issued_at/expires_at) so
consumers can verify integrity and provenance.
o Cost: Medium - requires hosting, key management, and signing
tooling.
o Impact: Strong integrity and non-repudiation; enables gated
access to rich metadata.
- Mitigations for Freshness and revocation:
o Mitigation: Use short validity windows in signed
descriptors, provide a status/revocation endpoint, and
optionally push revocation notifications (webhooks or pub/
sub).
o Cost: Medium to High - short expiries increase refresh load;
push channels add infrastructure.
Moussa & Akhavain Expires 14 December 2026 [Page 12]
Internet-Draft DAWN Gap Analysis June 2026
o Impact: Reduces stale exposure and limits the window for
compromised descriptors.
- Mitigation for Privacy and anti-enumeration:
o Mitigation: Publish only minimal public pointers in DNS;
keep capability/intent fields behind authenticated
endpoints; use naming entropy or tokenized pointers for
private resources; enforce rate limits and crawler controls.
o Cost: Low to Medium - naming and pointer changes are cheap;
access control and rate limiting add operational work.
o Impact: Substantially reduces mass scraping and profiling
risk.
- Mitigation for Search and descriptive discovery integration:
o Mitigation: Combine DNS bootstrap with a separate indexed
layer (centralized or federated catalog, semantic index)
that supports descriptive queries and returns candidate
names/IDs for DNS resolution. Ensure the index enforces
access control and privacy.
o Cost: High - building or integrating an index and
maintaining privacy controls is substantial.
o Impact: Fills DNS's descriptive-search gap and enables
DAWN-style high-level queries.
- Overall Mitigation score: *HIGH*
7.2. mDNS/DNS-SD
* *Summary*: mDNS/DNS-SD provides zero-configuration, multicast
service discovery on local networks. It's ideal for quick,
low-friction discovery of nearby devices and services but is
limited to link-local scope and lacks built-in authentication or
global search capabilities.
* *How it works*: Devices announce and browse services using
multicast DNS on the local link. Service types are advertised
with PTR/SRV/TXT records; clients listen for announcements or
actively query the multicast group to discover available instances
and connection parameters. Announcements are repeated
periodically and withdrawn when services go away.
* *Security, Privacy, and DAWN suitability Considerations:*
Moussa & Akhavain Expires 14 December 2026 [Page 13]
Internet-Draft DAWN Gap Analysis June 2026
- Security:
o Strengths: Simple, low-overhead; works without central
infrastructure; good UX for trusted LANs.
o Weaknesses: No native authentication or integrity
guarantees; any host on the same link can spoof
announcements or impersonate services; multicast makes
on-link MitM and injection trivial unless application-level
protections are used.
- Privacy:
o Announcements are visible to all hosts on the local link,
enabling easy enumeration and profiling of devices and
capabilities.
o Sensitive attributes in TXT records or predictable instance
names increase local exposure.
o There is no built-in mechanism to gate who can see or query
service announcements.
- DAWN suitability: Partial
o mDNS/DNS-SD is excellent for local bootstrapping and
immediate peer discovery but fails DAWN requirements that
need: authenticated identity, privacy-protected capability
disclosure, revocation at scale, and descriptive,
multi-match search across administrative boundaries.
o It is best used as a local layer within a larger DAWN
architecture, not as the primary cross-domain Discovery
Mechanism.
- Security, Privacy, and DAWN suitability score: *2/3*
o Scalability and interoperability and multi-cast operations
are supported. However, security, privacy, information rich
and semantic searches, and multi-type of entity support are
still missing.
* *Use case fitness:*
- TBC
* *Mitigations grouped by goal*
Moussa & Akhavain Expires 14 December 2026 [Page 14]
Internet-Draft DAWN Gap Analysis June 2026
- Mitigations for Descriptor hosting and integrity:
o Mitigation: Host full descriptors on HTTPS endpoints; sign
descriptors with JWS (include issued_at/expires_at) so
consumers can verify integrity and provenance.
o Cost: Medium - requires hosting, key management, and signing
tooling.
o Impact: Strong integrity and non-repudiation; enables gated
access to rich metadata.
- Mitigation for Local reliability and safe bridging
o Mitigation: Use mDNS only for LAN discovery; deploy
discovery gateways/proxies that vet local announcements and
publish vetted pointers to external registries or descriptor
hosts.
o Cost: Low to Medium - gateway software deployment and
configuration.
o Impact: Preserves zero-config UX while preventing raw
multicast data from being exposed externally.
- Mitigation for Privacy and anti-enumeration
o Mitigation: Advertise only minimal identifiers on multicast;
move capability, intent, and sensitive metadata to gated
endpoints. Use randomized or tokenized instance names for
private services.
o Cost: Low - change in advertisement content and naming
policy.
o Impact: Reduces casual local scraping and profiling.
- Mitigation for Freshness and revocation
o Mitigation: Use short announcement intervals and aggressive
withdrawal semantics; for cross-domain exposure, rely on
hosted signed descriptors with explicit expiry and status
endpoints.
o Cost: Low–Medium - more network chatter for short intervals;
hosting for descriptors.
Moussa & Akhavain Expires 14 December 2026 [Page 15]
Internet-Draft DAWN Gap Analysis June 2026
o Impact: Limits stale information and speeds removal of
retired or compromised services.
- Mitigation for Cross-domain descriptive search
o Mitigation: Do not rely on mDNS for descriptive or semantic
search. Instead, have gateways publish minimal pointers
into a controlled index or registry that supports
descriptive queries and returns candidate identifiers for
resolution. Ensure the index enforces access control and
privacy.
o Cost: High - building/integrating an index and gateway logic
is substantial.
o Impact: Enables DAWN-style high-level queries without
exposing LAN multicast to the internet.
- Overall Mitigation score: *LOW TO MEDIUM*
7.3. SSDP/UPnP
* *Summary*: SSDP/UPnP provides simple, multicast-based discovery
for devices and services on local networks. Devices announce
presence and a LOCATION URL pointing to a device description
(usually XML), enabling zero-config discovery and immediate
interoperability in home and small-office environments.
* *How it works*: Devices use SSDP (Simple Service Discovery
Protocol) over UDP multicast to send NOTIFY announcements and to
respond to M-SEARCH queries. Announcements include a LOCATION
header that points to an HTTP URL hosting a device/service
description (UPnP XML). Clients listen for announcements or
actively query the multicast group, then fetch the description
from the LOCATION URL to learn capabilities and control endpoints.
* *Security, Privacy, and DAWN suitability Considerations:*
- Security:
o Strengths: Very low friction; works without central
infrastructure; widely implemented in consumer devices.
Moussa & Akhavain Expires 14 December 2026 [Page 16]
Internet-Draft DAWN Gap Analysis June 2026
o Weaknesses: No built-in authentication or integrity for
announcements; multicast on the local link is trivially
spoofable by any on-link actor; LOCATION URLs are fetched
over plain HTTP in many deployments, enabling on-path
tampering; SSDP has been used in amplification/reflection
attacks and can expose devices to remote abuse when
improperly bridged.
- Privacy:
o Announcements are visible to all hosts on the local link,
enabling easy enumeration and fingerprinting of devices and
capabilities.
o LOCATION URLs often expose rich device metadata (model,
services, control URLs) that enable profiling.
o There is no native access control or audience restriction
for SSDP announcements.
- DAWN suitability: Partial
o SSDP/UPnP is useful as a local bootstrap for DAWN
(discovering nearby agents, tools, or gateways) but
unsuitable as a cross-domain Discovery Mechanism.
o Key gaps: no authentication/integrity for announcements,
high local enumeration risk, weak transport security in many
deployments, and no support for descriptive, multi-match
search across administrative boundaries. SSDP should be
treated as a local candidate source that must be validated
via stronger channels before being trusted in DAWN flows.
- Security, Privacy, and DAWN suitability score: *1/3*
o Meets the descriptive metadata rich cards that may
facilitate semantic and capability based searches, and can
be expanded to cater for other types of entities
(flexibility). However, security, privacy,
interoperability, and scalability are questionable.
* *Use case fitness:*
- TBC
* *Mitigations grouped by goal*:
- Mitigations for Descriptor hosting and integrity
Moussa & Akhavain Expires 14 December 2026 [Page 17]
Internet-Draft DAWN Gap Analysis June 2026
o Mitigation: Main issue is security and privacy. Thus
mitigation for this key gap is to handle these short
comings. A possible way is to Host device/service
descriptors at HTTPS origins (use https:// in LOCATION where
possible) and publish JWS-signed descriptors or include a
signature reference in the XML. Consumers must verify
signatures and timestamps before trusting descriptor fields.
Publish verification keys via a stable, verifiable channel
(JWK, DID, or TLS pin).
o Cost: Medium - requires HTTPS hosting, signing tooling, and
client verification logic.
o Impact: prevents on-link tampering of descriptors and
provides provenance even if SSDP announcements are spoofed.
- Mitigation for Privacy and anti-enumeration
o Mitigation: Minimize information in multicast announcements
(advertise only a short service identifier and a tokenized
pointer); move capability and intent fields to gated HTTPS
descriptors. Use tokenized LOCATION values for private
services and enforce local firewall rules to limit who can
receive announcements.
o Cost: Low to Medium - changing announcement content is
cheap; token issuance and firewall rules add operational
work.
o Impact: reduces local mass-scraping and profiling and limits
exposure of sensitive metadata.
- Mitigation for Cross-domain descriptive search
o Mitigation: Do not rely on SSDP for descriptive or semantic
search. Instead, have local gateways or proxies publish
vetted pointers (or signed attestations) into a controlled
index or registry that supports descriptive queries. The
index returns candidate IDs or names which clients then
resolve to HTTPS descriptors. Ensure the index enforces
access control and honors publisher privacy flags.
o Cost: High - building gateway logic and an index/federation
is substantial.
o Impact: enables DAWN-style descriptive discovery without
exposing raw SSDP multicast to the internet.
Moussa & Akhavain Expires 14 December 2026 [Page 18]
Internet-Draft DAWN Gap Analysis June 2026
- Mitigation for Freshness and revocation**
o Mitigation: Use SSDP's ssdp:alive/ssdp:byebye semantics and
short announcement intervals for local freshness; for
cross-exposed descriptors, require signed descriptors with
issued_at/expires_at and a status_endpoint for revocation
checks. Optionally support push revocation from gateways to
index subscribers.
o Cost: Medium - shorter intervals increase local traffic;
hosted revocation endpoints add infra.
o Impact: reduces stale exposure and shortens the window for
compromised or retired services.
- Mitigation for Cross-domain descriptive search (federation and
provenance)
o Mitigation: For federated deployments, exchange signed
attestations (not raw descriptors) between indexes; indexes
return candidate IDs and provenance metadata that clients
can verify against the origin's signed descriptor fetched
over HTTPS. Enforce privacy flags and access control at
each hop.
o Cost: High - federation, attestation formats, and access
controls require coordination and infrastructure.
o Impact: preserves provenance and privacy while enabling
descriptive, cross-domain discovery.
- Overall Mitigation score: *MEDIUM*
7.4. DNS-AID
*To be completed*
7.5. A2A (Agent2Agent)
* *Summary*: A2A defines an Agent Card model and a set of discovery
paths (well-known HTTPS URIs, curated registries, local discovery,
and managed provisioning) to enable interoperable agent-to-agent
discovery and invocation. It is mainly agent-centric discovery:
the metadata and discovery flows are designed for locating and
evaluating software agents, agentic services, and for monitoring
agentic workflows, not for discovering arbitrary entity types
(people, tasks, compute, resources, or generic sensors) without
additional architectural and inherent modifications.
Moussa & Akhavain Expires 14 December 2026 [Page 19]
Internet-Draft DAWN Gap Analysis June 2026
* *How it works*: Agents or operator domains publish an Agent Card
(a JSON descriptor) at a resolvable HTTPS location or register a
pointer in a curated registry. Discovery paths include local
discovery (e.g., mDNS/DNS-SD), well-known HTTPS endpoints, curated
registries/marketplaces, and locally managed network options
especially under enterprise settings. A client agent discovers a
pointer to a server where agent cards are stored, fetches the
Agent Card of interest from the HTTPS origin (server address),
verifies signatures or attestations and auth measures, potentially
evaluates declared capabilities and policies, and then initiates
an authenticated invocation using the declared endpoint and auth
method.
* *Security, Privacy, and DAWN suitability Considerations:*
- Security:
o Strengths: A2A is web-aligned and designed to leverage TLS,
standard auth schemes (OAuth2, mTLS, token exchange), and
signed Agent Cards or DID attestations. Curated registries
and enterprise deployments can control who is allowed to
publish or access Agent Cards, check that agents are
legitimate before listing them, and enforce the
organization's rules about how agents are used. The model
lets agents state exactly what they can do and how they
expect to be authenticated, which helps other agents invoke
them safely and according to policy.
o Weaknesses: Discovery methods like local mDNS or public
registries can be misused if Agent Cards are not signed or
protected, allowing attackers to impersonate agents or scan
for them. Registries and trusted operators also become
important points of control; if a registry, signing key, or
hosting service is compromised, an attacker could insert
fake or harmful agents. When agents are discovered on an
untrusted local network, extra checks are needed to confirm
that the agent is real before interacting with it.
- Privacy:
o Agent Cards and registry listings can reveal what an agent
can do, how often it is used, who it interacts with, or when
it tends to run.
o Telemetry and query logs can also be used to build a profile
of an agent's behavior.
Moussa & Akhavain Expires 14 December 2026 [Page 20]
Internet-Draft DAWN Gap Analysis June 2026
o Detailed capability information are published without access
controls, and hence can expose sensitive operational or
commercial details.
- DAWN suitability:
o A2A works well when the goal is to find and interact with
agents, agentic services, or to monitor agent-driven
workflows.
o It is mainly used inside trusted domains or curated
marketplaces, and so far it has not been deployed
commercially at large scale or across multiple vendors and
domains.
o The model assumes that agents describe themselves in a
standard way using Agent Cards, and that discovery is driven
mostly by keyword-based queries.
o A2A is also not designed to serve as a broad, public
discovery system for many different types of entities, such
as data, compute, people, devices, or raw content, and it
does not provide cross-domain semantic search on its own.
o Although its scope is limited, the overall structure can be
extended and strengthened to address its current gaps and
better meet the broader requirements of DAWN.
o It should be noted however, that the discovery method
implemented by A2A runs on top of existing infrastructures
and substrates such as HTTP, JSONRPC, and DNS and thus is
not a full end-to-end solution.
o The main contribution of A2A to the discovery problem is the
introduction of the agent cards, which are metadata rich
descriptors or entities.
- Security, Privacy, and DAWN suitability score: *1/3*
o Meets the descriptive metadata rich cards that may
facilitate semantic and capability based searches, and can
be expanded to cater for other types of entities
(flexibility). However, security, privacy,
interoperability, and scalability are questionable.
* *Use case fitness:*
- TBC
Moussa & Akhavain Expires 14 December 2026 [Page 21]
Internet-Draft DAWN Gap Analysis June 2026
* *Mitigations grouped by goal*
- Mitigations for Descriptor hosting and integrity
o Mitigation: Ensure that Agent Cards are cryptographically
signed and that clients always verify those signatures
before trusting any capabilities or endpoints. Host cards
at secure HTTPS locations, publish the verification keys so
clients can validate them, and require registries to accept
only signed cards. This strengthens the basic A2A model by
making Agent Cards trustworthy across domains and preventing
spoofing or impersonation.
o Cost: Low - requires signing tools, key-hosting, and
verification logic in clients and registries, but does not
require building a full cross-domain PKI.
o Impact: prevents forged or tampered Agent Cards, ensures
provenance, and provides a reliable foundation for
DAWN-grade discovery.
- Mitigation for Privacy and anti-enumeration
o Mitigation: Protect sensitive parts of the Agent Card by
placing them behind authenticated endpoints or controlled
registry access. Add privacy flags so agents can indicate
which fields should be hidden or shared. Limit who can
query the system, use short-lived discovery tokens, apply
rate limits, and share only aggregated or privacy-preserving
telemetry when exposing metrics outside a trusted domain.
For catalog use, publish small signed summaries instead of
full Agent Cards to reduce the amount of sensitive
information exposed.
o Cost: Medium - requires access-control checks, token
issuance, aggregation pipelines, and enforcement of registry
policies.
o Impact: reduces scraping, profiling, and leakage of
sensitive or commercially valuable information while still
allowing authorized discovery.
- Mitigation for Cross-domain descriptive search
o Mitigation: Rather than treating the A2A discovery plane as
a semantic index, create small signed summaries
(attestations) derived from Agent Cards and publish those
into a separate catalog that is designed for descriptive or
Moussa & Akhavain Expires 14 December 2026 [Page 22]
Internet-Draft DAWN Gap Analysis June 2026
cross-domain queries. The catalog returns candidate agent
IDs or attestations, and clients then fetch the
authoritative Agent Card and verify its signature and
provenance before interacting with the agent. This keeps
A2A focused on secure resolution while allowing richer
search to happen in a controlled layer above it.
o Cost: High - requires building or integrating a catalog,
defining an attestation format, and establishing rules for
federation and access control.
o Impact: enables DAWN-style descriptive discovery while
maintaining provenance, privacy, and controlled access to
sensitive information.
- Mitigation for Freshness and revocation
o Mitigation: Include issued_at and expires_at in Agent Cards
and attestations; provide status and revocation endpoints;
support push notifications (webhooks/pubsub) for card
updates and de-registration; enforce short lifetimes for
ephemeral offers. Require controllers to revalidate before
committing long-running interactions.
o Cost: Medium - revocation/status infrastructure, pub/sub
channels, and more frequent control-plane updates.
o Impact: reduces stale or compromised listings and improves
correctness for time-sensitive tasks and agent capabilities.
- Mitigation for Federation and provenance
o Mitigation: Exchange signed attestations (not raw cards or
metrics) between operators and catalogs; require provenance
chains and trust anchors per federation member; include
policy, consent, and billing metadata in attestations;
enforce verification of provenance chains before accepting
remote agent invocation.
o Cost: High - attestation formats, trust management, legal
agreements, and operational coordination.
o Impact: preserves provenance and trust across domains and
enables accountable cross-domain discovery and invocation.
- Overall Mitigation score: *MEDIUM*
Moussa & Akhavain Expires 14 December 2026 [Page 23]
Internet-Draft DAWN Gap Analysis June 2026
7.6. CATS (Compute-Aware Traffic Steering) — IETF working group
* *Summary*: CATS defines a control-plane framework for steering
traffic to compute locations by combining service announcements,
compute and network metrics, and policy-driven selection. It is
explicitly compute-centric: the primitives, metrics, and selection
logic are designed for operators to be able to locate and steer
traffic to compute sites and service instances, not for
discovering arbitrary entity types (people, documents, sensors, or
generic agents).
* *How it works*: For 'discovery' in CATS, service instances and
contact instances are announced into the CATS control plane.
Metric agents collect compute (C-SMA) and network (C-NMA)
telemetry and publish metrics to controllers or selectors (C-PS).
A path selector or controller queries available sites, evaluates
policy and metrics, and chooses a target site/instance.
Forwarders (CATS-Forwarders) then enforce steering decisions.
* *Security, Privacy, and DAWN suitability Considerations:*
- Security:
o Strengths: Designed for authenticated agents and operator
trust domains; control-plane messages and metric flows are
intended to be authenticated and access-controlled.
Selection decisions are policy-driven, enabling fine-grained
operator governance.
o Weaknesses: Trust is concentrated in operator controllers
and metric collectors; exposing metrics or announcements
beyond trusted domains risks manipulation or information
leakage. Compromise of metric agents or controllers can
mislead selection and routing.
- Privacy:
o Risks: Compute and network metrics can reveal capacity,
load, topology, and usage patterns; if distributed widely,
they enable profiling of service placement and demand.
While this is acceptable as long as the operation is within,
CATS does not implement specific privacy mechanisms for
external intruders except gating and authenticity
verification. Thus, if such measures are bypassed, privacy
is compromised.
Moussa & Akhavain Expires 14 December 2026 [Page 24]
Internet-Draft DAWN Gap Analysis June 2026
o Controls: The model assumes authenticated, limited
distribution of metrics; without strict access controls and
aggregation, metric publication can violate privacy or
commercial confidentiality.
- DAWN suitability: Partial (compute-only)
o discovery within CATS is well suited for a discovering one
type of entities that reside within the vicinity of
authenticated networked elements. That is, CATS is an
operator-centric discovery of compute locations and precise
selection based on metrics (good for low-latency,
policy-aware steering) within compute environment.
o CATS discovery is not a DAWN-style public, multi-entity,
descriptive Discovery Mechanism: it does not provide
semantic, multi-match search across administrative
boundaries out of the box and assumes operator trust and
scoped distribution.
- Security, Privacy, and DAWN suitability score: *1/3*
o implements a control plane and announcement mechanism that
gives a flexible structure that can be expanded, however
lacks in scalability, interoperability, security, and
privacy domains.
* *Use case fitness: TBC*
* *Mitigations grouped by goal*
- Mitigations for Descriptor hosting and integrity
o Require signed service/site/task descriptors and signed
announcements; publish verification keys via operator PKI,
JWK sets, or DID documents; enforce signature verification
in controllers and selectors before acting on any
announcement or descriptor.
o Cost: Medium - Needs signing libraries, descriptor schema
work, KMS integration, and client verification logic.
o Impact: Prevents forged announcements, ensures provenance,
and enables non-repudiation for placement and steering
decisions.
- Mitigation for Privacy and anti-enumeration
Moussa & Akhavain Expires 14 December 2026 [Page 25]
Internet-Draft DAWN Gap Analysis June 2026
o Aggregate and redact metrics, limit audience via RBAC and
tokens, apply rate limits to discovery APIs, and use
differential privacy or noise injection for telemetry
exported beyond the operator domain.
o Cost: Medium - Requires metric aggregation pipelines, access
control systems, and policy enforcement.
o Impact: Reduces profiling, commercial leakage, and mass
scraping while preserving steering utility.
- Mitigation for Cross-domain descriptive search
o Publish signed, minimal pointers or attestations from CATS
into a separate indexed or federated catalog that supports
descriptive queries. The catalog returns candidate IDs or
attestations which clients resolve back to CATS-announced
sites under controlled access and verification.
o Cost: High - Building a catalog, federation protocols,
attestation formats, and access controls requires
substantial engineering and governance.
o Impact: Enables DAWN-style descriptive discovery while
preserving operator control, provenance, and privacy.
- Mitigation for Freshness and revocation
o Include explicit validity windows in announcements and
descriptors, provide status and revocation endpoints, and
use push pub/sub to propagate revocations and state changes.
Enforce short lifetimes for highly dynamic metrics and
ephemeral offers.
o Cost: Medium to High - Requires revocation/status
infrastructure, pub/sub channels, and more frequent
control-plane updates.
o Impact: Reduces stale placements, limits the window for
compromised information, and improves correctness for
time-sensitive tasks.
- Mitigation for Cross-domain descriptive search (federation and
provenance)
Moussa & Akhavain Expires 14 December 2026 [Page 26]
Internet-Draft DAWN Gap Analysis June 2026
o Exchange signed attestations (not raw metrics) between
operators; require provenance chains and trust anchors per
federation member; enforce policy translation and explicit
consent for metric and task sharing.
o Cost: High - Federation requires attestation formats, trust
management, legal agreements, and operational coordination.
o Impact: Preserves provenance and trust across domains and
enables controlled cross-domain discovery and placement.
* overall mitigation score: *MEDIUM TO HIGH*
7.7. MCP
*To be completed*
7.8. AGNTCY
*To be completed*
7.9. Service registries & orchestration
List includes: Consul, etcd, Eureka, Kubernetes Service DNS, service
meshes.
*To be completed*
7.10. HTTP/.well-known [RFC8615]
*To be completed*
7.11. WebFinger [RFC7033]
* *Summary*: WebFinger (RFC 7033) is an HTTP-based mechanism for
resolving information about a subject identified by a URI, most
commonly an account-style identifier such as
acct:alice@example.com. A WebFinger server returns a JSON
Resource Descriptor (JRD) containing properties and typed links
associated with the subject. WebFinger is widely used for account
and profile resolution in federated systems, but it is not a
general discovery substrate and does not support descriptive or
capability-oriented search.
* *How it works*: A client constructs a query to /.well-known/
webfinger on the domain extracted from the subject identifier and
includes the subject URI in the resource parameter. The server
responds with a JRD document containing:
Moussa & Akhavain Expires 14 December 2026 [Page 27]
Internet-Draft DAWN Gap Analysis June 2026
- subject: the canonical identifier
- aliases: alternative identifiers
- properties: key–value attributes
- links: typed links to related services or endpoints
WebFinger assumes that the client already knows the subject
identifier. It does not define indexing, search, or mechanisms
for discovering subjects in the first place. It functions
strictly as a resolution protocol.
* *Security, Privacy, and DAWN suitability Considerations:*
- Security
o Strengths: WebFinger relies on HTTPS for server
authentication and transport integrity. The protocol is
simple, widely deployed, and benefits from mature HTTP
security practices. Operators may apply access control or
filtering policies, although these are not mandated.
o Weaknesses: There is no cryptographic signing of JRD
responses, no per-field integrity, and no offline
verification. Trust is tied entirely to the HTTPS endpoint;
clients cannot verify provenance across domains.
Enumeration resistance, rate limiting, and abuse controls
are deployment specific and not standardized. A compromised
server can return forged or misleading metadata without
detection.
- Privacy
o Risks: JRD responses may expose personal or sensitive
information such as profile attributes, service endpoints,
or relationships. Servers that respond differently for
valid and invalid subjects may leak account existence.
Without strict filtering, WebFinger can reveal information
that enables profiling or cross-service correlation.
o Controls: RFC 7033 recommends cautious publication, but does
not define structured privacy controls, consent mechanisms,
or privacy flags. Operators must implement their own access
control, redaction, and rate limiting to avoid leakage.
Without these measures, WebFinger can compromise privacy or
commercial confidentiality.
Moussa & Akhavain Expires 14 December 2026 [Page 28]
Internet-Draft DAWN Gap Analysis June 2026
- DAWN suitability: Partial (identifier-resolution only)
o WebFinger is well suited for resolving known identifiers to
structured metadata within a single administrative domain.
o It is not a DAWN-style public, multi-entity, descriptive
Discovery Mechanism.
o It does not provide semantic search, multi-match discovery,
cross-domain ranking, or task-oriented discovery.
o It assumes that the client already possesses the subject
identifier and that the server is authoritative for that
identifier.
o WebFinger can serve as a resolution layer in DAWN, but not
as a general discovery substrate.
- Security, Privacy, and DAWN suitability score: *1/3*
o Webfinger implements a lightweight resolution mechanism with
a flexible JSON-based structure, but lacks scalability,
interoperability, security, and privacy features required
for DAWN-grade discovery. WebFinger is suitable only for
identifier-based lookups and does not provide the
protections, controls, or semantic capabilities needed for
multi-entity, cross-domain discovery.
* *Mitigations grouped by goal*
- Mitigations for Descriptor hosting and integrity
o Require signed JRD responses or signed metadata objects when
WebFinger is used in cross-domain or adversarial
environments. Publish verification keys via operator PKI,
JWK sets, or DID documents, and enforce signature
verification in clients before trusting any returned
properties or links.
o Cost: Medium – Requires signing libraries, schema
adjustments, key-management integration, and client-side
verification logic.
o Impact: Prevents forged responses, ensures provenance, and
enables non-repudiation for downstream selection or
resolution decisions.
- Mitigation for Privacy and anti-enumeration
Moussa & Akhavain Expires 14 December 2026 [Page 29]
Internet-Draft DAWN Gap Analysis June 2026
o Mitigation: Limit information returned to unauthenticated
queries, apply RBAC and token-based access for sensitive
fields, enforce rate limits, and avoid response patterns
that reveal account existence. Use aggregation or redaction
when exposing metrics or relationship data.
o Cost: Medium – Requires access-control enforcement,
rate-limiting infrastructure, and privacy-aware response
policies.
o Impact: Reduces profiling, enumeration, and leakage of
personal or sensitive information while preserving
legitimate resolution functionality.
- Mitigation for Cross-domain descriptive search
o Mitigation: Do not overload WebFinger as a search substrate.
Publish minimal signed pointers or attestations into a
separate catalog that supports descriptive queries. The
catalog returns candidate identifiers, which clients then
resolve via WebFinger under controlled access and
verification.
o Cost: High – Requires catalog construction, attestation
formats, federation rules, and access-control mechanisms.
o Impact: Enables DAWN-style descriptive discovery while
preserving provenance, privacy, and operator control.
- Mitigation for Freshness and revocation
o Include explicit validity windows in published metadata,
provide status and revocation endpoints, and use push-based
mechanisms to propagate updates. Enforce short lifetimes
for dynamic attributes or ephemeral offers.
o Cost: Medium to High – Requires revocation infrastructure,
update channels, and more frequent metadata refresh.
o Impact: Reduces stale or incorrect metadata, limits exposure
to compromised information, and improves correctness for
time-sensitive discovery.
- Mitigation for Cross-domain descriptive search (federation and
provenance)
Moussa & Akhavain Expires 14 December 2026 [Page 30]
Internet-Draft DAWN Gap Analysis June 2026
o Exchange signed attestations rather than raw metadata
between operators. Require provenance chains and trust
anchors for each federation member, and enforce policy
translation and explicit consent for sharing subject
metadata.
o Cost: High – Requires attestation formats, trust-management
systems, governance agreements, and operational
coordination.
o Impact: Preserves provenance and trust across domains and
enables controlled cross-domain discovery and resolution.
- overall mitigation score: *MEDIUM TO HIGH*
7.12. Search & crawling
List includes: Web crawlers, site indexes, capability search engines,
and Vector indexes and semantic matchers for capability search.
*To be completed*
7.13. Centralized marketplaces
List includes: Vendor app stores, plugin registries, dataset
catalogs.
*To be completed*
7.14. P2P/DHT and decentralized registries
*To be completed*
7.15. Manual/configuration-based discovery
* *Summary*: Manual or configuration-based discovery refers to
environments where entities, endpoints, or services are discovered
through static configuration rather than automated mechanisms.
Examples include manually entering IP addresses, URLs, service
endpoints, credentials, or metadata into configuration files,
orchestration systems, or device settings. This approach is
common in tightly controlled deployments, legacy systems, embedded
environments, and small-scale networks where automation is
unnecessary or undesirable.
* *How it works*: Operators or administrators explicitly configure
discovery parameters depending on the scenario under
consideration. These parameters may include static addresses or
Moussa & Akhavain Expires 14 December 2026 [Page 31]
Internet-Draft DAWN Gap Analysis June 2026
identifiers, service endpoints or URLs, credentials or tokens,
routing or workflow rules, and metadata describing capabilities or
roles. Manual configuration is typically used in environments
where entities are known in advance and where dynamic discovery is
unnecessary or intentionally avoided. If physical or logical
connectivity changes, operators must update the configuration
accordingly. The resulting discovery information is embedded into
static structures such as lookup tables, configuration files,
orchestration manifests, or device-level settings. Clients do not
perform discovery; they simply read the configured information and
act on it.
* *Security, Privacy, and DAWN suitability Considerations:*
- Security
o Strengths:
+ Manual configuration avoids many attack surfaces
associated with automated discovery protocols.
+ Operators maintain full control over what is reachable,
reducing exposure to unsolicited or untrusted entities.
+ Static configurations can be protected through existing
access-control and configuration-management systems.
o Weaknesses:
+ Stale or incorrect configurations can persist
indefinitely and misroute traffic or expose sensitive
endpoints.
+ Manual errors can introduce vulnerabilities,
misconfigurations, or unintended trust relationships.
+ No built-in authentication, integrity, or provenance for
configured entries; trust is entirely operator-dependent.
+ Does not scale to dynamic or adversarial environments
where entities appear, disappear, or change frequently.
- Privacy
o Risks:
+ Static lists can leak operational structure if shared or
replicated across domains.
Moussa & Akhavain Expires 14 December 2026 [Page 32]
Internet-Draft DAWN Gap Analysis June 2026
+ Manual distribution of configuration files increases the
risk of accidental disclosure.
+ Entrusting configuration of private information into the
hands of operators reduces control over information
leakage.
o Controls:
+ Strong access control on configuration repositories and
deployment pipelines.
+ Regular audits to remove stale entries and sensitive
metadata.
+ Encryption of configuration files at rest and in transit
and while updating configurations.
- DAWN suitability: Minimal (static and non-scalable)
o Manual discovery is suitable only for small, static,
operator-controlled environments where entities are known in
advance.
o It does not support DAWN-style public, multi-entity,
descriptive discovery.
o It lacks semantic search, capability matching, cross-domain
interoperability, and dynamic updates.
o It assumes a trusted operator domain and does not provide
mechanisms for discovery across administrative boundaries.
o It lacks flexibility, ease of operation, and is costly to
maintain information freshness.
o Manual discovery may serve as a fallback or bootstrap
mechanism to discovery substrate components and fixed
elements, but it cannot function as a general discovery
mechanism for DAWN to provide its intended discovery
services.
- Security, Privacy, and DAWN suitability score: *1/3*
o Manual or configuration-based discovery provides
predictable, operator-controlled behavior, but it lacks
scalability, interoperability, and dynamic adaptability. It
offers minimal built-in security or privacy protections and
Moussa & Akhavain Expires 14 December 2026 [Page 33]
Internet-Draft DAWN Gap Analysis June 2026
does not support DAWN-style multi-entity as it is often used
within small networks, lacks descriptive and/or cross-domain
discovery. It is suitable only for small, static, trusted
environments and cannot serve as a general discovery
mechanism for DAWN.
* *Mitigations grouped by goal*
- Mitigations for Descriptor hosting and integrity
o Mitigation: Requires signed configuration bundles or signed
metadata files. Store verification keys in operator PKI or
configuration-management systems, and enforce signature
verification before applying any configuration.
o Cost: Medium - Requires signing tools, key-management
integration, and validation logic in deployment pipelines.
o Impact: Prevents tampering, ensures provenance, and reduces
the risk of misconfiguration due to unauthorized edits.
- Mitigation for Privacy and anti-enumeration
o Mitigation: Redact sensitive metadata, apply RBAC to
configuration repositories, enforce least-privilege access,
and avoid distributing full topology or endpoint lists to
unnecessary components.
o Cost: Medium - Requires access-control systems, audit
processes, and policy enforcement.
o Impact: Reduces leakage of internal structure and prevents
unauthorized enumeration of services.
- Mitigation for Cross-domain descriptive search
o Mitigation: Do not rely on manual configuration for
cross-domain discovery. Instead, publish minimal signed
pointers or references into a catalog that supports
descriptive queries. Manual entries should only reference
catalog endpoints, not full service lists.
o Cost: High - Requires catalog infrastructure, attestation
formats, and federation rules.
o Impact: Enables DAWN-style discovery while keeping manual
configuration limited to trusted bootstrap information.
Moussa & Akhavain Expires 14 December 2026 [Page 34]
Internet-Draft DAWN Gap Analysis June 2026
- Mitigation for Freshness and revocation
o Mitigation: Include explicit validity periods in
configuration bundles, require periodic refresh, and use
automated alerts when configurations become stale. Provide
revocation channels for compromised or outdated entries.
o Cost: Medium to High - Requires monitoring, versioning, and
revocation infrastructure.
o Impact: Reduces stale configurations, improves correctness,
and limits exposure to outdated or compromised information.
- Mitigation for Cross-domain descriptive search (federation and
provenance)
o Mitigation: Exchange signed attestations rather than raw
configuration data between operators. Require provenance
chains and trust anchors for each federation member, and
enforce explicit consent for sharing configuration-derived
metadata.
o Cost: High - Requires attestation formats, trust-management
systems, and governance agreements.
o Impact: Preserves provenance and trust across domains and
enables controlled cross-domain discovery.
- Overall mitigation score: *MEDIUM TO HIGH*
8. Security Considerations
TBC
9. Operational Considerations
TBC
10. IANA Considerations
This document makes no requests of IANA.
11. Acknowledgements
TBC
12. References
Moussa & Akhavain Expires 14 December 2026 [Page 35]
Internet-Draft DAWN Gap Analysis June 2026
12.1. Normative References
[I-D.farrel-dawn-terminology]
Farrel, A., Yao, K., Schott, R., and N. Williams,
"Terminology for the Discovery of Agents, Workloads, and
Named Entities (DAWN)", Work in Progress, Internet-Draft,
draft-farrel-dawn-terminology-02, 4 June 2026,
<https://datatracker.ietf.org/doc/html/draft-farrel-dawn-
terminology-02>.
12.2. Informative References
[I-D.akhavain-moussa-dawn-problem-statement]
Akhavain, A., Moussa, H., and D. King, "Problem Statement
for the Discovery of Agents, Workloads, and Named Entities
(DAWN)", Work in Progress, Internet-Draft, draft-akhavain-
moussa-dawn-problem-statement-03, 4 June 2026,
<https://datatracker.ietf.org/doc/html/draft-akhavain-
moussa-dawn-problem-statement-03>.
[I-D.kay-dawn-use-cases]
King, D., Yao, K., and K. Adler, "Use Cases for the
Discovery of Agents, Workloads, and Named Entities", Work
in Progress, Internet-Draft, draft-kay-dawn-use-cases-00,
7 June 2026, <https://datatracker.ietf.org/doc/html/draft-
kay-dawn-use-cases-00>.
[I-D.king-dawn-requirements]
King, D. and A. Farrel, "Requirements for the Discovery of
Agents, Workloads, and Named Entities (DAWN)", Work in
Progress, Internet-Draft, draft-king-dawn-requirements-01,
28 April 2026, <https://datatracker.ietf.org/doc/html/
draft-king-dawn-requirements-01>.
[I-D.mozleywilliams-dnsop-dnsaid]
Mozley, J., Williams, N., Sarikaya, B., Schott, R., and J.
Damick, "DNS for AI Discovery", Work in Progress,
Internet-Draft, draft-mozleywilliams-dnsop-dnsaid-02, 27
May 2026, <https://datatracker.ietf.org/doc/html/draft-
mozleywilliams-dnsop-dnsaid-02>.
[RFC1123] Braden, R., Ed., "Requirements for Internet Hosts -
Application and Support", STD 3, RFC 1123,
DOI 10.17487/RFC1123, October 1989,
<https://www.rfc-editor.org/rfc/rfc1123>.
Moussa & Akhavain Expires 14 December 2026 [Page 36]
Internet-Draft DAWN Gap Analysis June 2026
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
DOI 10.17487/RFC6762, February 2013,
<https://www.rfc-editor.org/rfc/rfc6762>.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
<https://www.rfc-editor.org/rfc/rfc6763>.
[RFC7033] Jones, P., Salgueiro, G., Jones, M., and J. Smarr,
"WebFinger", RFC 7033, DOI 10.17487/RFC7033, September
2013, <https://www.rfc-editor.org/rfc/rfc7033>.
[RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers
(URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
<https://www.rfc-editor.org/rfc/rfc8615>.
[RFC9437] Rodriguez-Natal, A., Ermagan, V., Cabellos, A., Barkai,
S., and M. Boucadair, "Publish/Subscribe Functionality for
the Locator/ID Separation Protocol (LISP)", RFC 9437,
DOI 10.17487/RFC9437, August 2023,
<https://www.rfc-editor.org/rfc/rfc9437>.
[RFC9460] Schwartz, B., Bishop, M., and E. Nygren, "Service Binding
and Parameter Specification via the DNS (SVCB and HTTPS
Resource Records)", RFC 9460, DOI 10.17487/RFC9460,
November 2023, <https://www.rfc-editor.org/rfc/rfc9460>.
Authors' Addresses
Hesham Moussa
Huawei Technologies Canada
Canada
Email: hesham.moussa@huawei.com
Arashmid Akhavain
Huawei Technologies Canada
Canada
Email: arashmid.akhavain@huawei.com
Moussa & Akhavain Expires 14 December 2026 [Page 37]