Discovery of Agents With Names Y. Cui Internet-Draft Tsinghua University Intended status: Standards Track 30 October 2026 Expires: 3 May 2027 Resource Discovery in Cooperating Domains draft-cui-dawn-cooperating-discovery-00 Abstract 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 This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-cui-dawn-cooperating- discovery/. Discussion of this document takes place on the dawn Working Group mailing list (mailto:dawn@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/dawn/. Subscribe at https://www.ietf.org/mailman/listinfo/dawn/. 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/. Cui Expires 3 May 2027 [Page 1] Internet-Draft Cooperating Discovery October 2026 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 3 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Applicability and Non-Goals . . . . . . . . . . . . . . . 4 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 3. Discovery Model . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Scope and Authority . . . . . . . . . . . . . . . . . . . 5 3.2. Request Preservation . . . . . . . . . . . . . . . . . . 5 3.3. Coverage Meaning . . . . . . . . . . . . . . . . . . . . 6 4. HTTPS Binding . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Endpoint and Media . . . . . . . . . . . . . . . . . . . 7 4.2. Query Request . . . . . . . . . . . . . . . . . . . . . . 7 4.3. Query Response . . . . . . . . . . . . . . . . . . . . . 8 4.4. Errors and Compatibility . . . . . . . . . . . . . . . . 10 5. Minimum Discoverable Information . . . . . . . . . . . . . . 10 5.1. Record Structure . . . . . . . . . . . . . . . . . . . . 10 5.2. Endpoint Security Information . . . . . . . . . . . . . . 11 5.3. Record Validation and Reconciliation . . . . . . . . . . 12 6. Client Processing and Coverage Composition . . . . . . . . . 13 6.1. Budgets and Scheduling . . . . . . . . . . . . . . . . . 13 6.2. Repeated Branches and Cycles . . . . . . . . . . . . . . 14 6.3. Per-Scope Result . . . . . . . . . . . . . . . . . . . . 14 7. Example Operation . . . . . . . . . . . . . . . . . . . . . . 15 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 18 10. Operational and Caching Considerations . . . . . . . . . . . 18 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 Cui Expires 3 May 2027 [Page 2] Internet-Draft Cooperating Discovery October 2026 12. Relationship to Existing Work . . . . . . . . . . . . . . . . 19 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 13.1. Normative References . . . . . . . . . . . . . . . . . . 19 13.2. Informative References . . . . . . . . . . . . . . . . . 20 Appendix A. Open Issues . . . . . . . . . . . . . . . . . . . . 22 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 22 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 23 1. 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 [DAWN-CHARTER] 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. Cui Expires 3 May 2027 [Page 3] Internet-Draft Cooperating Discovery October 2026 1.1. 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. 2. 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 [RFC2119] [RFC8174] 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 [DAWN-TERMINOLOGY]. 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. Cui Expires 3 May 2027 [Page 4] Internet-Draft Cooperating Discovery October 2026 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. 3. Discovery Model 3.1. 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. 3.2. 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. Cui Expires 3 May 2027 [Page 5] Internet-Draft Cooperating Discovery October 2026 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. 3.3. 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. 4. HTTPS Binding Cui Expires 3 May 2027 [Page 6] Internet-Draft Cooperating Discovery October 2026 4.1. 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 [RFC9110], JSON [RFC8259], and TLS [RFC8446]. 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. 4.2. 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. Cui Expires 3 May 2027 [Page 7] Internet-Draft Cooperating Discovery October 2026 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. { "version": "1", "scopes": [ "https://supplier-b.example/scopes/customers", "https://supplier-c.example/scopes/customers" ], "match": { "service": "https://consortium.example/services/order-status" }, "page_size": 50 } 4.3. 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. Cui Expires 3 May 2027 [Page 8] Internet-Draft Cooperating Discovery October 2026 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. { "version": "1", "records": [], "referrals": [ { "endpoint": "https://directory-b.example/discovery", "scopes": ["https://supplier-b.example/scopes/customers"] }, { "endpoint": "https://directory-c.example/discovery", "scopes": ["https://supplier-c.example/scopes/customers"] } ], "coverage": [ { "scope": "https://supplier-b.example/scopes/customers", "state": "complete" }, { "scope": "https://supplier-c.example/scopes/customers", "state": "complete" } ] } 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. Cui Expires 3 May 2027 [Page 9] Internet-Draft Cooperating Discovery October 2026 4.4. 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 [RFC9457]. 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. 5. Minimum Discoverable Information 5.1. 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 Cui Expires 3 May 2027 [Page 10] Internet-Draft Cooperating Discovery October 2026 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 [RFC3339] 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 [MDI-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. 5.2. 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. Cui Expires 3 May 2027 [Page 11] Internet-Draft Cooperating Discovery October 2026 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 [RFC9728]. 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. 5.3. 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. Cui Expires 3 May 2027 [Page 12] Internet-Draft Cooperating Discovery October 2026 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. 6. Client Processing and Coverage Composition 6.1. 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. Cui Expires 3 May 2027 [Page 13] Internet-Draft Cooperating Discovery October 2026 6.2. 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. 6.3. 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. Cui Expires 3 May 2027 [Page 14] Internet-Draft Cooperating Discovery October 2026 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. 7. 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. Cui Expires 3 May 2027 [Page 15] Internet-Draft Cooperating Discovery October 2026 { "version": "1", "records": [ { "publisher": "https://supplier-b.example/", "id": "order-status-agent", "scopes": ["https://supplier-b.example/scopes/customers"], "entity_type": "agent", "services": [ "https://consortium.example/services/order-status" ], "endpoints": [ { "uri": "https://agents.supplier-b.example/order-status", "protocols": ["https://protocol.example/spec/v1"], "security": [ { "profile": "none", "parameters": {} } ] } ], "dynamic": true, "valid_until": "2026-10-30T08:05:00Z" } ], "referrals": [], "coverage": [ { "scope": "https://supplier-b.example/scopes/customers", "state": "complete" } ] } 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. Cui Expires 3 May 2027 [Page 16] Internet-Draft Cooperating Discovery October 2026 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. 8. 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. Cui Expires 3 May 2027 [Page 17] Internet-Draft Cooperating Discovery October 2026 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. 9. 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. 10. 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 [RFC9111]. 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. Cui Expires 3 May 2027 [Page 18] Internet-Draft Cooperating Discovery October 2026 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. 11. IANA Considerations This document makes no requests of IANA in this revision. 12. Relationship to Existing Work Agent Directory [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 [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 [DNS-AID] and common DNS parameters [COMMON-PARAMS] can bootstrap directory services. This document neither replaces them nor assumes their pointers identify this operation automatically. The DAWN framework [DAWN-FRAMEWORK] describes directory and mixed- mode discovery while leaving concrete interactions to other specifications. FAMS-P [FAMS-P] concerns gateway metadata synchronization; this operation does not define that synchronization. The DAWN requirements draft [DAWN-REQUIREMENTS] 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 [MDI-MODEL] supplies an encoding-neutral mapping target, not the JSON protocol specified here. All referenced individual drafts remain work in progress. 13. References 13.1. Normative References Cui Expires 3 May 2027 [Page 19] Internet-Draft Cooperating Discovery October 2026 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . [RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, . [RFC9111] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Caching", STD 98, RFC 9111, DOI 10.17487/RFC9111, June 2022, . [RFC9457] Nottingham, M., Wilde, E., and S. Dalal, "Problem Details for HTTP APIs", RFC 9457, DOI 10.17487/RFC9457, July 2023, . 13.2. Informative References [AGENT-DIRECTORY] Jimenez, J., "Agent Directory", Work in Progress, Internet-Draft, draft-jimenez-agent-directory-01, 8 May 2026, . [ARD] Bu, J., Guha, R. V., and S. Smith, "Agentic Resource Discovery Specification, Version 0.91", 26 August 2026, . Cui Expires 3 May 2027 [Page 20] Internet-Draft Cooperating Discovery October 2026 [COMMON-PARAMS] Brockners, F., Jakab, L., Williams, N., and J. Mozley, "Common Agent DNS Discovery Parameters", Work in Progress, Internet-Draft, draft-blwm-dawn-common-discovery- parameters-00, 27 October 2026, . [DAWN-CHARTER] Internet Engineering Task Force, "Discovery of Agents With Names (DAWN) Charter", 22 October 2026, . [DAWN-FRAMEWORK] Zhang, B., Dunbar, L., and Y. Yang, "A Framework for Agent Discovery in DAWN", Work in Progress, Internet-Draft, draft-zhang-dawn-agent-discovery-framework-09, 20 October 2026, . [DAWN-REQUIREMENTS] King, D. and A. Farrel, "Requirements for the Discovery of Agents With Names (DAWN)", Work in Progress, Internet- Draft, draft-king-dawn-requirements-02, 19 October 2026, . [DAWN-TERMINOLOGY] Farrel, A., Yao, K., Schott, R., and N. Williams, "Terminology for the Discovery of Agents With Names (DAWN)", Work in Progress, Internet-Draft, draft-farrel- dawn-terminology-06, 28 October 2026, . [DNS-AID] 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, . [FAMS-P] Zhang, B., "Federated Agent Metadata Synchronization Protocol (FAMS-P)", Work in Progress, Internet-Draft, draft-zhang-dawn-bgp-style-federated-discovery-00, 14 October 2026, . Cui Expires 3 May 2027 [Page 21] Internet-Draft Cooperating Discovery October 2026 [MDI-MODEL] Cui, Y., "An Information Model for Minimum Discoverable Information (MDI)", Work in Progress, Internet-Draft, draft-cui-dawn-mdi-model-00, 3 July 2026, . [RFC9728] Jones, M.B., Hunt, P., and A. Parecki, "OAuth 2.0 Protected Resource Metadata", RFC 9728, DOI 10.17487/RFC9728, April 2025, . Appendix A. 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. Cui Expires 3 May 2027 [Page 22] Internet-Draft Cooperating Discovery October 2026 Author's Address Yong Cui Tsinghua University Email: cuiyong@tsinghua.edu.cn Cui Expires 3 May 2027 [Page 23]