]> Tsinghua University

cuiyong@tsinghua.edu.cn

Internet Discovery of Agents With Names DAWN resource discovery cooperating domains This document specifies a mechanism for resource discovery across cooperating administrative domains. It defines how discovery requests preserve their scope and constraints across referrals, how discovery services report coverage of requested scopes, and how clients combine results from multiple discovery branches. The mechanism enables clients to distinguish complete discovery results from incomplete operations, including cases involving unresolved referrals, pagination failures, and partial service failures. It relies on existing authentication, authorization, and trust arrangements and does not define open-ended Internet search, semantic matchmaking, resource invocation, registration, or directory synchronization. About This Document Status information for this document may be found at . Discussion of this document takes place on the dawn Working Group mailing list (), which is archived at . Subscribe at .

Introduction Cooperating organizations may independently publish discovery information about AI resources. A client can know the organizational context and the class of resource it needs without knowing every directory that contributes to the answer. Examples include finding customer-facing order services across approved suppliers, discovering tools available within a research consortium, and locating a named resource whose directory is operated by a hosting provider. The DAWN charter includes initial discovery between cooperating parties with existing trust relationships and allows iterative discovery through referrals and delegation. It considers DNS and mDNS as possible foundations for discovery mechanisms. Existing mechanisms may provide an initial discovery endpoint, while cooperating directories may return records directly, refer a client to another service, or aggregate information from multiple sources. This document specifies request-preservation, referral-processing, and coverage-composition rules for such directory queries, together with an HTTPS/JSON binding. It complements existing discovery and bootstrap mechanisms without defining new DNS records, directory synchronization, or membership management. A successful response from one discovery service does not necessarily indicate completion of the overall discovery operation. A service may return referrals that require further processing, and different branches may complete independently or fail for different reasons. Without explicit composition rules, a client may incorrectly treat an empty response as evidence that no matching resource exists, or discard valid results because another branch failed. This document addresses these cases by defining per-scope coverage statements and deterministic rules for combining them across discovery branches. This is an individual submission for discussion in DAWN. The operation, JSON binding, and coverage semantics specified here are proposals, not existing features of Agent Directory or a statement of working group consensus. Their suitability for a separate specification, rather than incorporation into an existing directory protocol, remains subject to review.

Applicability and Non-Goals The protocol applies within an organization and between a finite set of cooperating domains whose discovery services can be authenticated and authorized using existing arrangements. It does not require that all service URLs be statically configured. An existing, verifiable delegation arrangement can authorize a subsequently learned endpoint. A returned URL alone never establishes that arrangement. Scope selection, authorization, and resource matching are separate operations. A requested scope selects a published discovery collection; access to that collection remains subject to existing authorization. Matching uses exact identifiers, not interpretation of user intent. A scope can contain records from several organizations if its publisher is authorized to provide that collection. This document does not define a global index, semantic query language, resource ranking, entity identity management, credential issuance, trust evaluation, registration, synchronization, or communication after initial discovery. Discovery of an endpoint does not authorize its invocation. Capability information beyond the minimum needed for initial discovery is outside this protocol.

Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. This document uses discovery and Minimum Discoverable Information (MDI) in the sense of the DAWN terminology work . A discovering entity is called a client below. A discovery service is an authenticated HTTPS endpoint implementing this protocol. A scope identifier is an absolute HTTPS URI identifying a discovery collection under a publisher's administrative control. It is a collection identifier, not a new entity identity or credential. The URI need not be dereferenceable. Its definition, responsible publisher, and access policy are established by existing deployment arrangements. Two scope identifiers are equal only when their published strings are identical. The protocol does not infer scope containment from URI path prefixes or DNS suffixes. A query consists of a nonempty finite set of scope identifiers and zero or more exact-match constraints. A branch is a query to one endpoint under one applicable authorization context, including all its pages. An operation includes the root branch and all branches needed to answer its referrals. A coverage statement is a service's authenticated assertion about its responsibility for a scope; it is not proof that undisclosed resources do not exist.

Discovery Model

Scope and Authority A client begins with one or more scope identifiers and at least one discovery endpoint authorized to answer for those scopes. Configuration, an authenticated application context, or a separately specified DNS or HTTP bootstrap mechanism can supply the endpoint. This document defines neither a new DNS record nor a new well-known URI. An endpoint learned through DNS MUST NOT be assumed to implement this protocol solely because it supports HTTPS. Before sending a request, the client MUST establish both endpoint authentication and its authority to serve the requested scopes. This authority can follow from trusted configuration or an existing validated delegation mechanism. TLS authenticates a hostname; by itself it does not authorize that hostname to answer for an unrelated scope. A service's self-declared scope membership is insufficient. Several endpoints can contribute to a scope. The responsible service can partition its work locally and into referrals without creating new public scope identifiers for each partition. All referrals for a scope are required contributions to that response's coverage claim. Optional recommendations MUST NOT be encoded as referrals in this version.

Request Preservation The scope set in a referred request MUST be a nonempty subset of both the original scope set and the scopes assigned to that referral. All exact-match constraints MUST retain their original values. A referral MUST NOT expand the requested scopes, introduce new constraints, or weaken existing constraints. A service that cannot interpret a requested constraint MUST reject the request rather than silently broadening the query. If a service accepts a request but cannot complete discovery for an authorized scope, it MUST report incomplete coverage for that scope rather than claim complete coverage. The authorization context used at a referred endpoint can differ from the one used at the root. Existing policy MUST establish that it is applicable to the same logical caller and requested collection. Credentials MUST NOT be copied merely because requests belong to the same operation. Inability to obtain an applicable context makes the affected scopes incomplete.

Coverage Meaning Coverage is evaluated separately for each requested scope. A discovery service reports one of three states: complete, partial, or unknown. Complete means that the service asserts that its local response sequence, together with all required referrals, accounts for all matching records within its applicable authorized view. This assertion is conditional on successful pagination and completion of all required referrals. Partial means that the service knows that its response omits some required records or contributions. Unknown means that the service cannot determine whether all required records and contributions have been accounted for. A coverage statement expresses the service's responsibility and accounting status; it is not independent proof that no undisclosed resources exist. A complete claim requires a locally coherent enumerated view: concurrent updates MUST NOT silently cause omissions or duplicate identities that the client cannot reconcile. A service without such enumeration semantics MUST report partial or unknown. This does not require a transaction or synchronized snapshot across domains. Completed views at different services can correspond to different times. The applicable view is the view authorized for the requester, not the publisher's entire inventory. A service need not reveal excluded resources, hidden branches, or the reasons for their exclusion. Clients MUST NOT reinterpret a complete authorized view as proof of an organization's total resource population. A coverage statement applies only to the authorized view and enumeration associated with the current discovery operation. It does not establish that the same records will remain available or that no additional matching records will appear after the enumeration. Clients MUST NOT reuse a complete coverage statement as evidence of a complete result for a later discovery operation without obtaining a new or otherwise validly revalidated statement.

HTTPS Binding

Endpoint and Media An endpoint is an absolute HTTPS URI without userinfo or a fragment. Its path is deployment-specific. The endpoint accepts POST requests with Content-Type application/json and a JSON response selected using Accept: application/json. The operation is read-only despite using POST; servers MUST NOT register resources, invoke agents, or create authorization grants as a consequence of a query. This binding uses HTTP semantics , JSON , and TLS . Requests and responses MUST contain a version member identifying the protocol format. This specification defines version "1". The protocol version is independent of the Internet-Draft revision number. An absent or unsupported version MUST be treated as an incompatible request or response. Implementations MUST NOT silently reinterpret messages using another discovery protocol, and incompatible future revisions MUST use a different version value. Servers MUST reject duplicate JSON member names. Unrecognized request members, including unrecognized constraint names, MUST cause HTTP 400. Clients MUST reject responses with missing mandatory members, duplicate members, invalid types, or an unexpected version. Unknown response members MAY be ignored only when they do not alter this version's mandatory semantics. Future critical behavior requires explicit version support.

Query Request A request contains version, scopes, and optionally match, page_size, and cursor. scopes is a nonempty array of distinct scope identifiers, and its order has no meaning. match is an object containing zero or more of id, publisher, entity_type, service, and protocol. Each constraint is an exact-match condition, and multiple constraints are conjunctive. No wildcard, prefix matching, regular expression, ranking, or natural-language interpretation is defined. id matches the id member of a returned record, and publisher matches its publisher member. The combination of publisher and id identifies a record within the publisher's namespace. entity_type matches the record's entity_type member. service matches one of the record's service identifiers. protocol matches at least one protocol identifier associated with an endpoint. All comparisons use the published string values without semantic interpretation. publisher, service, and protocol are absolute URI identifiers, while id and entity_type follow the syntax defined for the corresponding record members. This document does not define a capability taxonomy or a protocol-name registry. page_size, when present, is a positive integer expressing a preferred upper bound on records in a page. A server MAY use a lower bound. cursor, when present, is an opaque nonempty string previously returned by the same endpoint for this query. Clients MUST NOT manufacture or interpret cursors. A server MUST reject malformed requests and unsupported matching constraints. A server that does not recognize a requested scope, or is not authorized to process it, MUST apply the existing deployment's authorization and error-handling policy without unnecessarily disclosing protected information. Once a request has been accepted, a server MAY return partial or unknown coverage for an authorized scope that cannot be fully processed because of an operational failure, while returning valid results for other scopes. Every accepted scope MUST have a corresponding coverage statement. A server MUST NOT claim complete coverage for a scope whose required contributions have not been accounted for. Servers MAY reject oversized requests using existing HTTP mechanisms.

Query Response A successful response uses HTTP 200 and contains version, records, referrals, and coverage. records and referrals are arrays, possibly empty. coverage contains exactly one object for each requested scope, with members scope and state. state is complete, partial, or unknown. No unrequested scope is permitted in coverage, a record's scopes, or a referral's scopes. An empty records array is not independently a negative discovery answer. An optional next_cursor identifies the next page. Its absence ends the local response sequence, not the entire operation. Each page can contain records and referrals. The coverage states MUST remain identical across the sequence; they describe the sequence rather than the page. A server that cannot continue that accounting MUST fail the sequence, not revise an earlier partial state into complete or silently restart it. The server MUST bind a cursor to the endpoint, authorization context, full scope set, constraints, and applicable enumerated view. A client continuing a cursor MUST repeat the original query and page_size unchanged, adding the cursor. Reuse with altered input MUST be rejected. An expired cursor SHOULD produce HTTP 409. An expired enumeration MUST NOT be resumed by silently starting a different view. A new query is a separate branch and does not erase the earlier failure. Each referral is an object with endpoint and scopes. endpoint identifies another query endpoint, not an agent, a description file, a token endpoint, or the current page. scopes is a nonempty subset of the request's scopes. The referral MUST NOT carry credentials or replacement constraints. Its endpoint remains subject to independent access and authority checks. The example's complete states are conditional on the two referrals. If one fails, only the corresponding scope loses complete status. A service MUST NOT make this claim unless existing authority and collection arrangements let it account for the indicated scopes.

Errors and Compatibility HTTP 400 indicates a malformed request, an unsupported protocol version, or an unsupported matching constraint. HTTP 401 and 403 retain their existing authentication and authorization meanings. Handling of unrecognized or unauthorized scopes MUST follow the deployment's access-control policy without unnecessarily revealing protected scope information. For an accepted request, inability to complete an authorized scope MAY be represented by partial or unknown coverage in an HTTP 200 response. HTTP 404 identifies an unavailable query endpoint and MUST NOT be interpreted as evidence that no matching resource exists. HTTP 409 can indicate that an enumeration can no longer be continued. HTTP 429 and 5xx indicate rate limiting and service failure. Error responses SHOULD use Problem Details . An empty successful response with missing coverage is malformed. A response from an ordinary Agent Directory lookup, ARD search, or an agent description is not a response to this operation. Clients MUST NOT silently reinterpret it as one. Adapters to existing protocols can implement this binding only if they preserve its constraints and can support the coverage and minimum-information claims they make. HTTP redirects do not constitute discovery referrals. Clients MAY follow a redirect only under their existing HTTP method, access, credential, and scope-authority policies. Every resulting request counts against the operation budget. A redirected POST MUST NOT be transformed into an unrelated lookup and treated as an equivalent query.

Minimum Discoverable Information

Record Structure Each record MUST include publisher, id, scopes, entity_type, services, endpoints, dynamic, and valid_until. publisher is an absolute HTTPS URI identifying the publishing authority's namespace. It is not a credential. Existing policy MUST associate the responding service with that publisher and the record's scopes; an arbitrary publisher string is not evidence of provenance. id is a nonempty opaque string unique within that publisher's namespace for the entity's lifetime. The pair (publisher, id), compared exactly as published, is the record key. scopes is a nonempty subset of the request's scopes. entity_type is agent, tool, service, catalog, or an absolute URI defining another type. services is a nonempty array of distinct absolute service identifier URIs. These identifiers convey only the offered service classes needed for initial discovery. Full capability schemas, negotiated contracts, and orchestration data MUST NOT be returned through this binding. endpoints is a nonempty array of objects, each containing uri, protocols, and security. uri is an absolute URI without userinfo or fragment. HTTPS resource endpoints MUST be supported by this binding; other URI schemes MAY be accepted when a client implements their existing specifications and local policy permits them. Resource endpoints are data and MUST NOT be contacted automatically while processing a discovery response. protocols is a nonempty array of distinct absolute protocol identifier URIs. The identifiers specify the protocols available at that endpoint; a record-level union MUST NOT replace this association. A protocol identifier is interpreted according to its referenced specification or prior deployment agreement. Its appearance does not authorize fetching it as executable content. dynamic is a Boolean indicating whether the advertised information can change during normal operation. valid_until is an RFC 3339 timestamp in UTC using the Z suffix. It MUST NOT exceed the validity of the underlying information or the authority to publish it. Static information still has a finite validity bound; dynamic=false does not mean indefinite validity. The record structure defined here is a protocol-specific binding of the encoding-neutral MDI information model , not a replacement for that model. The combination of publisher and id represents the entity identifier, entity_type represents the entity type, and endpoints provides reachability and associated communication protocol information. The services, security, dynamic, and valid_until members provide additional information required by this binding. Service and protocol identifiers require a common interpretation established by their defining specifications or deployment agreements. This binding does not define a full agent card, capability schema, or capability negotiation mechanism.

Endpoint Security Information security is a nonempty array of advertised security alternatives for an endpoint. Each alternative contains profile and parameters. profile is either the token none or an absolute URI identifying a security metadata profile. parameters is a JSON object whose contents are defined by the selected profile. The publisher MUST describe the security requirements applicable to the advertised endpoint. Security parameters MUST NOT contain passwords, private keys, access tokens, or other credentials. The profile value none indicates that the endpoint does not require application-layer authentication. An endpoint MUST NOT advertise this profile unless such access is permitted by the publisher's policy. When profile is none, parameters MUST be an empty object. The absence of application-layer authentication does not remove any requirement for transport security, endpoint validation, or client-side access policy. Other profile values MUST identify security metadata specifications or explicitly agreed deployment profiles. Such profiles MUST define the syntax and interpretation of their parameters and the checks required to validate the metadata. For example, an OAuth-based profile MAY reference protected resource metadata defined by . This document does not define a new OAuth authorization flow or establish trust in an authorization server merely because its information is returned by a discovery service. Clients MUST recognize the syntax and meaning of the none profile but MUST NOT infer its presence when it is not advertised. Clients MAY support additional security profiles. If no advertised profile is supported by a client, the client MUST NOT assume that unauthenticated access is permitted. An otherwise valid discovery record remains evidence of a discovered resource even when the client cannot use its advertised security mechanisms. The client MAY report that the resource is not usable for subsequent interaction without treating it as absent from the discovery result.

Record Validation and Reconciliation Clients MUST validate mandatory record members, scope membership, exact-match constraints, endpoint syntax, publisher authority, security metadata structure, and validity before accepting a discovery record. Clients MUST retain the responding discovery endpoint and applicable authorization context as local provenance. A syntactically valid record MUST NOT be discarded solely because the client does not support its advertised resource authentication mechanism. Such a record MAY be reported as discovered but not usable for subsequent interaction. A malformed matching record that cannot be safely interpreted prevents a complete negative discovery result for its affected scopes, while independently valid records MAY still be retained. Identical ids from different publishers MUST NOT be merged. Identical endpoint URIs do not establish entity equivalence. If the same record key is received with conflicting content and existing freshness information cannot resolve the conflict, the client MUST retain the conflict as an incomplete reason for the affected scopes instead of choosing arbitrarily. Exact duplicate records can be coalesced while retaining their sources. Before returning a final result, clients MUST recheck record expiry. Expired records MUST NOT support a current positive result or a complete result for affected scopes unless refreshed within the remaining budget. No capability-card dereference is necessary for MDI in this binding; mandatory supplemental-description indirection depth is zero. Optional richer description retrieval is outside this initial-discovery operation.

Client Processing and Coverage Composition

Budgets and Scheduling Before starting, clients MUST establish finite limits for elapsed time, HTTP requests, received bytes, and referral depth. The root branch has depth zero; a newly followed referral adds one. Pagination, authentication exchanges, redirects, and retries consume the same operation's request, byte, and time budgets and MUST NOT reset them. DNS resolution also consumes the elapsed-time budget and MUST be bounded by the resolver's applicable limits. The default maximum referral depth is eight. A client MAY configure a different finite maximum before starting an operation. The selected maximum MUST NOT increase during the operation. This defines a predictable local stopping rule, not a requirement that every client obtain identical partial results. Implementations SHOULD make the selected limits and limiting reason available to the calling application without disclosing credentials. Scheduling MAY be sequential or concurrent. Clients SHOULD interleave pages and referred branches so that one large directory does not indefinitely postpone all others. Whatever scheduling is chosen, unfinished work MUST remain visible in the final coverage state. A time or resource limit is incompleteness, not an empty complete answer.

Repeated Branches and Cycles A branch key consists of the endpoint URI, exact scope set, constraints, and a local identifier for the applicable authorization context. Cursors identify pages within a branch, not new branches. URI comparison MAY normalize scheme and DNS hostname case and the default HTTPS port; implementations MUST NOT assume arbitrary path or percent-encoding transformations preserve the operation. Clients MUST avoid executing an equivalent branch repeatedly. An edge back to an already registered branch does not by itself mean failure and MUST NOT create a recursive wait. The branch's outcome is reused; an existing failure cannot become success because another edge refers to it. An unmatched or changing query remains subject to finite budgets. Repeated cursors or a cursor sequence that does not advance constitute a pagination error. Coverage over a cycle is not established merely by removing duplicate edges. A cycle cannot manufacture authority or complete accounting. Complete local claims still require that every matching record is accounted for by some returned record or an independently accountable contribution. A service MUST NOT claim complete coverage solely because it forwards the same unresolved responsibility back to its caller. Clients MUST compute complete coverage as the least fixed point of the completion rules: fully read terminal branches with complete local coverage seed completion, and a nonterminal branch completes only after every relevant child branch completes. An unresolved cycle therefore yields unknown coverage for the affected scope; duplicate-edge removal alone cannot seed completion.

Per-Scope Result For each original scope, a client MUST compose the coverage reported by the root service with the outcomes of all required referral branches for that scope. The composed state is complete only if the root service reports complete, all local pages and required referral branches have completed successfully, all necessary discovery records have been validated, and no unresolved failure or omission remains.If a required contribution is known to be omitted or truncated, the composed state MUST be partial unless an unresolved contribution requires unknown coverage. If the outcome of a required contribution cannot be determined, the composed state MUST be unknown. An unknown dependency takes precedence over a partial result when both conditions occur. A partial or unknown statement from the root service MUST NOT be upgraded to complete solely because another branch succeeds. An operation can therefore be complete for one requested scope and incomplete for another. Useful records MUST NOT be discarded solely because a different branch fails. An application can stop after obtaining an explicitly identified entity, but it MUST distinguish that goal being satisfied from complete enumeration of the original scope set. This protocol defines no ranking or resource-selection algorithm. A client MAY report that no matching resource was found within a requested scope only when the composed coverage for that scope is complete and no valid matching record remains. An empty result with partial or unknown coverage MUST NOT be interpreted as proof that no matching resource exists. A negative discovery result is limited to the requested scope, exact-match constraints, authorized view, and enumeration associated with the operation. It does not establish the absence of resources outside that view or at a later time.

Example Operation Assume a consortium endpoint has existing authority to account for two customer scopes and the client has suitable access arrangements with its referred endpoints. The request and root response above assign one scope to each supplier directory. The supplier B endpoint returns the following record, no referrals, no next_cursor, and complete coverage for its scope. Its example view is received at 2026-10-30T08:00:00Z. The protocol.example URI represents an agreed example protocol identifier, not an existing agent protocol registration. The none token indicates an endpoint that permits access without application-layer authentication, as defined in this document. If supplier C times out, the client retains B's still-valid record and reports complete coverage for B and incomplete coverage for C. It cannot report an empty complete answer for C. If C instead returns no records, no referrals, no next_cursor, and a valid complete statement, the client can report no match in C's authorized customer view. Neither result states what resources C has withheld from that view. For pagination, suppose B returns next_cursor equal to p2. The client repeats its request to B with scopes restricted to B, the unchanged service constraint and page_size, and cursor equal to p2. No new referral depth is consumed. If p2 expires or any subsequent page cannot be obtained, B's scope is incomplete even though the earlier record remains usable until its own expiry.

Security Considerations The protocol relies on existing authentication and scope-authority arrangements. Clients MUST authenticate HTTPS services, validate authority for each requested scope, and apply the same checks to referrals and redirected endpoints. An authenticated service can lie about coverage; this protocol cannot prove that a publisher has disclosed all entitled records. Existing trust in the responsible publisher is part of the meaning of a coverage statement, not a trust-management mechanism introduced here. Clients MUST apply destination policy before connecting and again when actual resolved addresses or redirects change. Referrals can otherwise induce SSRF, DNS rebinding, access to private services, or disclosure to unrelated organizations. A learned endpoint is not permission to contact it. URI schemes other than HTTPS MUST NOT be used for discovery endpoints in this binding. Credentials, cookies, and client-certificate selection MUST remain target-specific. A referral MUST NOT automatically forward them. Existing OAuth resource and audience rules continue to apply. Security metadata can identify an authorization server but does not itself establish that server's trustworthiness or authorize sending it secrets. Resource authentication metadata and discovery-service authentication are distinct. TLS protects individual protocol exchanges but does not by itself provide end-to-end integrity protection for records passing through an aggregator. In cooperating-domain deployments, a client MAY rely on an aggregator's coverage and record assertions only when existing trust and delegation arrangements authorize that aggregator to make those assertions for the relevant scopes. Aggregators MUST NOT claim publisher authority they do not possess, extend record validity beyond the underlying information, or omit failed contributions while reporting complete coverage. When a deployment requires verification of the original publisher independently of an intermediary, an applicable existing content-integrity or signature mechanism MUST be used. This document does not define a new signature format or trust establishment protocol. Finite validity, authenticated live responses, bounded operations, and the no-store baseline limit exposure to stale data and uncontrolled replay. They do not defeat an authorized malicious service replaying still-valid content. Deployments requiring stronger replay resistance need an existing freshness or content-protection profile that provides it; this document does not claim such protection from a timestamp alone. Clients require a sufficiently accurate clock to enforce valid_until and MUST treat uncertain expiry conservatively. Services SHOULD enforce request-size, scope-count, record-count, and processing limits before performing downstream work. Aggregation MUST use cumulative downstream limits and preserve failures in its coverage statements. A service MUST NOT turn an authenticated query into unbounded fan-out. Servers SHOULD use existing rate limiting and reject work they cannot safely bound.

Privacy Considerations Scope identifiers, exact service queries, referrals, and coverage statements can disclose organizational relationships and interests. Clients SHOULD send queries only to services authorized to receive them. Services SHOULD minimize disclosed records and topology to the requester's view. No response is required to reveal excluded resources or the existence of unauthorized scopes. Requests can contain confidential identifiers. The POST binding avoids putting the query itself in a URL, but does not prevent server-side logging. Operators SHOULD minimize logs, restrict their retention and access, and avoid logging credentials, opaque cursor contents, or full response records unnecessarily.

Operational and Caching Considerations Servers MUST send Cache-Control: no-store on successful and error responses in this baseline binding. Clients and intermediaries MUST honor HTTP caching rules . Clients can retain records as explicit application state only within their validity, source, query, and authorization context; no-store does not license a separate shared cache of restricted records. A future cache profile must specify suitable cache keys, revalidation, and authorization-change handling. Deployments must document who defines each scope, which services can account for it, how endpoint delegation is validated, how records are withdrawn or expire, and how authorization changes affect active enumerations. This protocol does not create these policies. An operator unable to maintain complete accounting must use partial or unknown rather than claiming complete coverage.

IANA Considerations This document makes no requests of IANA in this revision.

Relationship to Existing Work Agent Directory defines HTTP registration, lookup, and pagination; it does not define its federation protocol. This proposal reuses the HTTP directory pattern but does not extend the semantics of an old lookup that can ignore unknown parameters. Whether the operation belongs in an AD extension is a coordination question, not a settled independent work item. ARD already defines client referrals and server aggregation. Those mechanisms are not claimed as new here. The proposed distinction is explicit finite scope preservation and composable per-scope coverage, including failure and unsupported-data handling. These semantics require a detailed comparison with ARD's actual request and response formats before adopting another protocol. DNS-AID and common DNS parameters can bootstrap directory services. This document neither replaces them nor assumes their pointers identify this operation automatically. The DAWN framework describes directory and mixed-mode discovery while leaving concrete interactions to other specifications. FAMS-P concerns gateway metadata synchronization; this operation does not define that synchronization. The DAWN requirements draft already identifies scope expression, referrals, and incomplete versus absent results. This document proposes wire behavior to realize those requirements; it does not claim to originate them. The MDI model supplies an encoding-neutral mapping target, not the JSON protocol specified here. All referenced individual drafts remain work in progress.

References Normative References This document defines a date and time format for use in Internet protocols that is a profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar. JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. This document defines a "problem detail" to carry machine-readable details of errors in HTTP response content to avoid the need to define new error response formats for HTTP APIs. This document obsoletes RFC 7807. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages. This document obsoletes RFC 7234. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This specification defines a metadata format that an OAuth 2.0 client or authorization server can use to obtain the information needed to interact with an OAuth 2.0 protected resource. Old Dog Consulting China Mobile Deutsche Telekom Infoblox The proliferation of distributed Artificial Intelligence (AI) systems and agents has created a need for interoperable mechanisms for components of AI systems to discover each other. This document defines terminology for Discovery of Agents With Names (DAWN), focusing on the terms necessary to describe the discovery of information about AI systems and resources (e.g., AI agents). The intention is that this common set of terms can be used by other documents related to DAWN and so achieve consistency of meaning across the space. Tsinghua University The Discovery of Agents, Workloads, and Named Entities (DAWN) terminology document defines Minimum Discoverable Information (MDI) as the minimum information an entity must provide to be discoverable, but does not define its field-level content. The DAWN requirements and problem-statement documents identify the need for a standardized minimum structure; in its absence, emerging discovery formats risk each defining its own minimal metadata, with descriptors that do not interoperate across organizational or protocol boundaries. This document proposes a small, encoding-neutral information model, in the sense of RFC 3444, for MDI: three mandatory elements, a short set of recommended and optional elements, and the minimal constraints that hold among them. It is a minimum common subset and a mapping target for richer descriptors -- not a new card format and not a discovery protocol. Ericsson This document defines the Agent Directory (AD), a service where agents register their identity, capabilities, and reachable endpoints and where clients discover them by capability. The AD adapts the Constrained RESTful Environments (CoRE) Resource Directory (RFC 9176) from constrained IoT devices to software agents, reusing its registration, lookup, and soft-state lifecycle model. The AD uses HTTP and JSON. MCP and A2A define how agents interact; this document defines how they are found. Infoblox, Inc. Infoblox, Inc. Unaffiliated Deutsche Telekom Amazon The document standardizes an approach for publishing AI agents in the Domain Name System (DNS) so that other agents can discover them. Discovery is then initiated based on one of three generic use cases, in increasing computational and latency cost: (1) the requestor knows both the organization and agent (2) the requestor knows the organization that provides a capability, but not the specific agent (3) the requestor knows the required capability, but not the organization or agent. Of these use cases only (1) and (2) are in scope for this document, although (3) can be derived from this specification. DNS for AI Discovery (DNS-AID) is designed so that, once a client has learned an organization's agents, subsequent transactions can utilize the first use case with the benefit of cacheable connectivity information that is learnable as an agentic skill. The mechanism uses Service Binding (SVCB) records for connectivity information and key meta data, a well known entry point using DNS-Based Service Discovery (DNS-SD) labels into an organization's agent index, and optionally DNS Security Extensions (DNSSEC) and DNS-Based Authentication of Named Entities (DANE) TLSA records for trust and security. DNS-AID provides consumers of agent services with a direct connection method for agentic workloads not mediated by a third party. Organizations can use the same approach across public and private networks networks, providing consistency and common operational models, including publishing agents that are hosted in service provider domains. This document introduces no new resource record types, opcodes, or response codes. Cisco Cisco Infoblox, Inc. Infoblox This document defines parameters for AI agents that would be used in DNS and mDNS discovery processes. It provides a set of common parameters for different DNS records to facilitate agents communicating over application layer protocols such as A2A or MCP. Pengcheng Laboratory Futurewei Sun Yat-sen University This document describes a two-layer reference architecture for discovering the minimum public information needed to reach AI agents. The Local Discovery Plane obtains discovery information within an administrative domain through mDNS/DNS-SD or infrastructure-assisted discovery. For cross-domain discovery, the Federation Plane uses publication of policy-approved information in authoritative DNS zones and on-demand resolution as its baseline; Federation Gateways apply export policy and validate and cache accepted results. The document also identifies optional functions that may complement this baseline where DNS publication and request-driven resolution do not meet deployment needs: recipient-specific sharing, proactive or multi-hop dissemination, and trusted aggregated directory queries. In mixed- mode deployments, DNS may bootstrap an endpoint that provides one of these additional functions. Pengcheng Laboratory This document specifies the Federated Agent Metadata Synchronization Protocol (FAMS-P), a normative protocol realization of the "BGP-like structured peering" federation mode (Mode B) defined in the two-layer DAWN discovery architecture (draft-zhang-dawn-agent-discovery- framework). FAMS-P is a peer-to-peer unicast protocol for synchronizing agent discovery metadata between Federation Gateways (FGWs) across administrative domains, in deployments where the preferred DNS delegation model does not meet operational requirements, such as closed trusted federations of approximately 2 to 200 sites. FAMS-P runs over mutually-authenticated TLS 1.3 sessions between peering gateways. It supports initial full metadata synchronization and incremental updates for agent online, offline, and change events. Each gateway maintains a local Federated Agent Directory (FAD). The protocol synchronizes only lightweight Federation Metadata Records (FMRs) — a concrete binding of the DAWN Minimum Discoverable Information (MDI) — and thus transfers only the minimum public discovery information permitted by the DAWN charter; richer capability retrieval is out of scope. The protocol defines complete message formats, a session state machine with connection collision resolution, timestamp-and-replay- protected conflict resolution, mandatory FMR origin signatures, time- to-live aging with bounded refresh jitter, and fine-grained per-peer export policy enforcement. Old Dog Consulting Old Dog Consulting The proliferation of distributed systems, Artificial Intelligence (AI) agents, and network services has created a need for interoperable mechanisms to discover entities across administrative and network boundaries. Entities may include AI agents, software services, and other named resources that need to be found and characterised before interaction can begin. This document defines the requirements for Discovery of Agents With Names (DAWN) and sets out the objectives that a discovery mechanism for such entities must satisfy. It describes what information must be discoverable, what properties a discovery mechanism needs to support, and what constraints apply to discovery in decentralised environments. This document does not specify any particular discovery protocol or solution. Internet Engineering Task Force

Open Issues

• Validate per-scope coverage composition with independently implemented clients and at least one cooperating-domain deployment. In particular, test overlapping referrals and cycles with unresolved accounting.
• Compare integrating this operation into AD or profiling ARD against retaining a separate binding. Avoid parallel protocols that differ only in field names.
• Define and validate at least one interoperable security metadata profile for authenticated resource endpoints using existing security standards. The none profile remains an optional indication of an endpoint that permits access without application-layer authentication.
• Coordinate minimum-information fields with the evolving DAWN requirements and MDI model, especially services, security parameters, and publisher authority.
• Specify and evaluate a content-protection profile if deployments require origin verification through untrusted intermediaries or stronger replay protection.
• Evaluate default depth and resource budgets, scope discovery through existing bootstrap mechanisms, and enumeration lifetime under authorization changes. No implementation or interoperability result is claimed in this revision.

Acknowledgments This proposal builds on discussions and individual contributions in DAWN concerning terminology, requirements, discovery architecture, minimum information, and directory mechanisms. No endorsement by the authors of those documents is implied.