Locality in Agent Discovery

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 5 May 2027.¶

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. 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

The DAWN working group is chartered to specify how a client finds the minimum public discovery information about AI resources, such as AI agents, before interacting with them [DAWN-CH]. The charter names three settings:¶

• within a local network, e.g., discover all agents in this shop;¶
• within an organization, e.g., discover all agents available to employees within their employer's infrastructure;¶
• between cooperating parties with trust relationships over the public Internet, e.g., discover all agents of example.org.¶

One proposal for what the minimum contains, the MDI draft [CUI-MDI], applies one procedure to all three settings and concludes that a client needs the same information to use a result in each of them. This document does not depend on that conclusion, but it is a useful starting point: even if the minimum is the same, other things are not. Moving from local to remote discovery changes how much a client can learn, what it can assume, and how well it can check where the information came from, and these do not all change in the same direction. This document calls that the "locality gradient".¶

The document is meant as input to the architecture [ZHANG-FW] and to the work on the minimum information. Points that depend on the details of the MDI draft are collected in Section 5. The document proposes no protocol, wire format, or registry.¶

2. Background

Terminology follows [FARREL-TERM] (for example Discovering Entity, Discovered Entity, Discovery Scope, and Trust Indicator). Three other terms are used in a plain sense. Known context is what the client already knows when it reads a result, such as the scope it searched or the network it is attached to. A binding is the specification that carries discovery information over a particular mechanism, such as DNS-SD over mDNS. A serving system is whatever answers lookups, such as a DNS server, a registry, a catalog, or a responder on the local link; one outside the publisher's administrative domain is an intermediary.¶

The three settings differ as follows:¶

Local network:

Client and agent share a link or local scope. mDNS and DNS-SD [RFC6762] [RFC6763] work without configuration [JAKAB-ZERO]. Advertisements are not authenticated, so the agent is authenticated only when the client connects to it. Detailed metadata usually comes from connecting to the agent and doing its native handshake.¶

Organization:

Client and agent are in one administrative domain. The client learns where to look from its network attachment (for example, a domain received through DHCP, see Section 5.2 of [RFC8766]), and discovery may go through Discovery Proxies [RFC8766], SRP registration [RFC9665], or internal DNS zones [DUNBAR-INFRA]. Audience restrictions are applied to the lookup (for example, split-view DNS or a VPN), not carried in the result. Intermediaries can be authenticated only as themselves.¶

Cooperating parties:

Client and agent are in different administrative domains. Only what the publisher exposes is available, but DNSSEC-validated records and TLS-authenticated origins can tie information to the publisher's name [ZHANG-FW].¶

3. The Locality Gradient

This document talks about locality rather than trust. Locality is what actually changes from one setting to the next; trust follows from it. The charter also puts trust management and trust evaluation, beyond the secure exchange of discovery information, out of scope [DAWN-CH], so focusing on locality stays within that scope.¶

Three things change with locality.¶

How much a client can learn:

The minimum stays the same, but what a client can get at or just after discovery does not. On a local network, a client can connect to the agent and quickly get full metadata, current availability, and live state. Remotely, it usually has only what the publisher chose to expose, plus whatever a description endpoint (such as an agent card) gives it afterwards.¶

What a client can assume:

On a local network, a client may assume the result is "on its own side" because it shares the link or the same administrator. The client holds this assumption, based on its known context, meaning what it knows about where it is attached. The result does not carry it. Remotely, the client has no such assumption to fall back on.¶

How well the source can be checked:

This does not follow a simple local-to-remote trend. Under a cooperating party's domain, DNSSEC and TLS can tie values to the zone or origin. In an organization, values passed on by a Discovery Proxy or catalog can be tied only to that proxy or catalog. On a local link, mDNS gives no way to check the source at discovery time; the agent is authenticated only when the client connects to it. So there is a mismatch: clients tend to assume the most on the local network, where the source is hardest to check, and the least on the public Internet, where it is easiest.¶

The gradient comes from the environment, not from a flaw in DAWN's design. For the minimum information, it means the minimum is the same everywhere, but how much more a client can learn, and how much it can rely on that, depends on where the discovery happened.¶

4. Points for Discussion

This section lists points that follow from the locality gradient. They are offered as input, and feedback on whether they are useful is welcome. Section 5 relates them to the MDI draft.¶

5. Relation to the MDI Draft

This section collects the points that depend on the details of the MDI draft [CUI-MDI] (draft-cui-dawn-mdi-model-02), so that it can be updated if that draft changes. Section numbers refer to that version.¶

• Floor, not limit. The draft treats MDI as a short header. Information beyond the minimum is carried as Extensions (Section 8.3 names five kinds) or fetched through References, and Section 11 advises publishers to keep sensitive detail behind access-controlled references. This supports Section 4.1. Only those five kinds have a shared meaning; other Extensions are defined by a binding, a profile, or a future registry. Section 9 already requires each binding to say how integrity and origin are protected and which values come from the publisher or from a serving system. The open point is how a client sees that when one result mixes protection levels.¶
• Origin and provenance. In the draft, origin is a protection goal met by the binding, not an element of the result. Publisher scope comes from an authenticated property of the carrier, not from what the instance says about itself (Section 9), which agrees with the view in Section 4.2 that a locality claim in the result would be self-asserted. The draft also notes that a value taken from known context is no more trustworthy than that context (Section 10).¶
• Matching and choosing. The Stable Identifier is optional, and Section 8 says a binding can make it mandatory, for example for exchange between gateways or catalogs. Section 8.5 says that within one naming scope equal Stable Identifiers denote the same resource, and that a client reconciles instances by Freshness only among those whose integrity and origin it has verified; an unverified instance does not displace a verified one. Across naming scopes the draft makes no claim that two results are the same resource, which is the gap described in Section 4.3. Section 11 notes the correlation cost of a Stable Identifier.¶
• Integrity for unauthenticated advertisements. Section 13 asks how the charter's integrity requirement is met for such advertisements and lists the three answers given in Section 4.4.¶

6. What This Means for the DAWN Documents

The points above suggest the following.¶

• Minimum information. It could say how a client should treat a result whose values have different protection.¶
• Architecture. It could describe local, organizational, and remote results as different kinds of input, since their sources can be checked to different degrees. It could also cover how a client records where a result came from (Section 4.2), how it matches and chooses between results from different scopes (Section 4.3), and how referrals and iteration [DAWN-CH] fit in.¶
• Bindings. Each binding could show which values a serving system may generate or change and what protects each value, in a common form, so the uneven source checking is visible across bindings.¶
• Integrity and privacy. Integrity matters most where the source is hardest to check, and privacy matters most where detailed local information is easy to retrieve [IANNONE-PRIV].¶

7. IANA Considerations

This document has no IANA actions.¶

8. Security Considerations

This document changes no protocol and adds no mechanism. The points above relate to these threats for future work:¶

• Local spoofing: on a shared link, mDNS responses can be forged, so treating local results as more trustworthy can send clients to an attacker.¶
• Remote poisoning: forged or outdated remote records can send a client away from a legitimate local agent.¶
• Proxy or catalog substitution: values passed on or changed by Discovery Proxies or catalogs can be attributed only to that proxy or catalog.¶
• Mixed protection: where a binding protects only some values, a client may trust the others as much as the protected ones.¶
• Information exposure: detailed local information that is easy to retrieve raises privacy concerns [IANNONE-PRIV], and a mandatory stable identifier lets any observer correlate an entity across results.¶

Author's Address