Locality in Agent Discovery

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 . 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 , 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 and to the work on the minimum information. Points that depend on the details of the MDI draft are collected in . The document proposes no protocol, wire format, or registry.

Background Terminology follows (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 work without configuration . 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 ), and discovery may go through Discovery Proxies , SRP registration , or internal DNS zones . 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 .

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

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. relates them to the MDI draft.

Extra Detail Beyond the Minimum A minimal remote result does not limit what local deployments can offer: a local client can connect and learn more, and a specification can carry small extra items alongside the minimum. Two things are worth watching. First, extra items help interoperability only if their meaning is agreed. If each mechanism defines its own, a client may understand an item from one mechanism and not the same item from another. Second, one result may mix values with different protection, for example a signed minimum next to unsigned local detail, and a client could trust all of them equally. The architecture could say how a client is expected to tell them apart.

Where a Result Came From A result may come from a local mDNS response, an organizational catalog, or a signed record fetched over the Internet, and these deserve different levels of confidence. The scope searched, the carrier used, and the network the client is attached to are all known context, so a client can work out where a result came from by itself, and the publisher does not need to say. For discussion: the architecture could describe a record that the client keeps for each result it gets. It would hold the scope searched, the carrier used, the serving system that answered, and whether each value was authenticated. Publishers would not publish this. A locality claim inside the result seems less useful, since whichever serving system sets it would be vouching for itself.

Matching and Choosing Between Local and Remote Results Local and remote discovery can find "the same" agent and return different endpoints, protocols, or freshness information. Before choosing between them, the client has to recognize that they describe the same agent. That is hard. Names only make sense within the scope where they are assigned (a link, a DNS domain), they can change (for example, when mDNS renames an instance after a conflict), and one resource can have several. A stable identifier for the resource helps within one scope, but a local result and a remote result will usually come from different scopes. Making such an identifier mandatory also lets any observer correlate the entity across results, which is a privacy cost. Choosing is harder. Preferring local results exposes clients to forged mDNS answers on shared links, and preferring remote results exposes them to poisoned or outdated records. One cautious policy is that a result with a verified source is not displaced by one without, but that says little about two unverified results, such as competing mDNS answers on a shared link. Feedback is welcome on whether the architecture should give guidance on choosing between results from different scopes, and on whether freshness alone is enough to decide.

Physical Proximity as a Sign of Trust Local discovery often assumes that being on the same link means a result can be trusted. In practice, proximity is usually just a stand-in for shared administrative control, and on shared networks such as public Wi-Fi it means very little. Since local advertisements carry no way to check their source, the agent is authenticated only when the client connects to it. One approach is to treat local scope only as a convenience for reaching agents, and to state trust explicitly. How the charter's integrity requirement is met for unauthenticated advertisements is a related open question. Three answers are possible: authenticating the agent at the follow-up connection, adding protection for the hop that delivers the information (such as a Discovery Proxy's DNSSEC signature), or protecting the advertisement back to its origin. The gradient suggests the answer may depend on the setting, since the second and third are available in some settings and not in others.

Relation to the MDI Draft This section collects the points that depend on the details of the MDI draft (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 . 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 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 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 .

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 (), how it matches and chooses between results from different scopes (), and how referrals and iteration 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 .

IANA Considerations This document has no IANA actions.

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 , and a mandatory stable identifier lets any observer correlate an entity across results.