Resource Discovery in Cooperating Domains
draft-cui-dawn-cooperating-discovery-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Yong Cui | ||
| Last updated | 2026-10-30 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-cui-dawn-cooperating-discovery-00
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,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
<https://www.rfc-editor.org/rfc/rfc3339>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/rfc/rfc8259>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/rfc/rfc8446>.
[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/rfc/rfc9110>.
[RFC9111] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Caching", STD 98, RFC 9111,
DOI 10.17487/RFC9111, June 2022,
<https://www.rfc-editor.org/rfc/rfc9111>.
[RFC9457] Nottingham, M., Wilde, E., and S. Dalal, "Problem Details
for HTTP APIs", RFC 9457, DOI 10.17487/RFC9457, July 2023,
<https://www.rfc-editor.org/rfc/rfc9457>.
13.2. Informative References
[AGENT-DIRECTORY]
Jimenez, J., "Agent Directory", Work in Progress,
Internet-Draft, draft-jimenez-agent-directory-01, 8 May
2026, <https://datatracker.ietf.org/doc/html/draft-
jimenez-agent-directory-01>.
[ARD] Bu, J., Guha, R. V., and S. Smith, "Agentic Resource
Discovery Specification, Version 0.91", 26 August 2026,
<https://agenticresourcediscovery.org/spec/>.
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,
<https://datatracker.ietf.org/doc/html/draft-blwm-dawn-
common-discovery-parameters-00>.
[DAWN-CHARTER]
Internet Engineering Task Force, "Discovery of Agents With
Names (DAWN) Charter", 22 October 2026,
<https://datatracker.ietf.org/doc/charter-ietf-dawn/01/>.
[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, <https://datatracker.ietf.org/doc/html/draft-zhang-
dawn-agent-discovery-framework-09>.
[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,
<https://datatracker.ietf.org/doc/html/draft-king-dawn-
requirements-02>.
[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,
<https://datatracker.ietf.org/doc/html/draft-farrel-dawn-
terminology-06>.
[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, <https://datatracker.ietf.org/doc/html/draft-
mozleywilliams-dnsop-dnsaid-02>.
[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, <https://datatracker.ietf.org/doc/html/
draft-zhang-dawn-bgp-style-federated-discovery-00>.
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,
<https://datatracker.ietf.org/doc/html/draft-cui-dawn-mdi-
model-00>.
[RFC9728] Jones, M.B., Hunt, P., and A. Parecki, "OAuth 2.0
Protected Resource Metadata", RFC 9728,
DOI 10.17487/RFC9728, April 2025,
<https://www.rfc-editor.org/rfc/rfc9728>.
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]