Summary

  • Agent discovery can reveal organisational intent before an agent is selected: capability filters, geography, trust requirements, timing and repeated refinements may identify the planned task even when the query body is encrypted.
  • draft-iannone-dawn-privacy-considerations-00 usefully names surveillance, stored-data, correlation and identification risks, but it is an incomplete individual Internet-Draft whose DNS comparison, privacy-versus-auditability analysis, RFC 6973 questionnaire and several threats remain TBD.
  • Daniel Kade proposes a selection-disclosure budget covering query granularity, candidate-set floor, linkability window, participant separation, bootstrap path, result audience and retention. It is editorial guidance, not a DAWN or IETF requirement.

The first disclosure precedes the first interaction

Discovery is often drawn as a harmless arrow between intention and execution. A client knows what it needs, asks a directory which entities can satisfy the need, compares the answers and chooses one. Trust, authorization and task execution arrive later. This sequence makes discovery look like plumbing.

The proposed DAWN vocabulary makes the arrow much larger. Discoverable entities may be agents, workloads or named resources. Their properties can describe function, capability, protocol support, ownership, geography, jurisdiction and trust indicators. A machine-readable capability card can expose enough structure for software to narrow thousands of possibilities without prior relationships. That is the value of interoperable discovery. It is also why a discovery request is a compressed policy document.

A request for “translation” is broad. Add a language pair, a medical-data restriction, one attestation scheme, a European jurisdiction, a latency ceiling and immediate availability, and the request may describe a particular patient workflow. Ask again after removing the latency requirement, then again after changing jurisdiction, and the sequence reveals which constraint is negotiable. The selected agent is not needed to infer the underlying objective. The search path has already exposed it.

The DAWN requirements draft places selection mechanisms and policies outside its scope. That boundary is sensible for a requirements document that does not choose a protocol. But it does not make selection policy invisible. If a discovery service observes the attributes a client tests, the order in which it relaxes them, the candidates it receives and the time at which it asks, it can infer the policy that the document declines to specify.

This distinction is central. Discovery information can be authentic and the channel confidential while the act of discovery remains revealing. The privacy object is not only the query string. It is the join among who asked, what attributes were requested, how many candidates matched, which results were disclosed and when the sequence occurred.

An unfinished draft identifies the right problem

At the research cutoff, draft-iannone-dawn-privacy-considerations-00 was an active individual Internet-Draft dated 22 May 2026. Datatracker showed no RFC stream, responsible Area Director or telechat, and expressly warned that an individual draft has no formal standing as IETF consensus. That status is not a footnote. It determines how much authority the document can carry.

Revision 00 is candidly incomplete. Intrusion, misattribution, secondary use, disclosure and exclusion are marked TBD. So are the comparison with DNS privacy and the section titled “Privacy vs Auditability.” The RFC 6973 questionnaire is promised rather than answered, DAWN-specific mitigation categories are deferred and Security Considerations are TBD. None of those gaps should be silently filled by an article.

What exists is still valuable. The draft says a discovery substrate can become a surveillance point because an observer may see which agents query which capabilities, organisational interests, workload patterns and operational behaviour. It warns that stored query logs and interaction histories can expose workflows and enterprise operations. It identifies correlation across repeated searches and identification through organisation names, infrastructure ownership, operator identity or distinctive capability metadata.

The omissions clarify the commissioning question. A threat list does not yet tell an operator how much exposure is acceptable, how to test it or who may override the limit. The draft points at Private Information Retrieval as a possible building block, while explicitly leaving scale suitability for investigation. PIR may conceal which record a server returns. It does not by itself decide whether the query vocabulary is too specific, whether the result set is identifying, whether requests can be correlated by time or whether the client leaked itself while discovering keys and endpoints.

Encryption protects content, not the whole selection surface

Published IETF privacy work supplies useful comparisons precisely because each mechanism protects a different join.

RFC 9156’s DNS query-name minimisation does not merely encrypt a full name. It limits each authoritative server to the portion of the name needed at that step. The lesson for agent discovery is about granularity: do not reveal a complete desired capability profile when a coarser question can preserve a viable candidate set.

RFC 9230 separates an Oblivious DoH proxy from the target. The proxy sees the client connection but not the plaintext DNS question; the target sees the question but not the client address. RFC 9458 generalises this partition for HTTP. It also warns that message size, timing, key identifiers, connection behaviour and differential treatment can reduce the anonymity set. Encryption works because roles are separated and because neither party can quietly rebuild the join.

RFC 9540 goes one step earlier. A client needs to learn that an oblivious service exists and obtain a gateway key configuration. A direct key fetch can expose the client IP. A unique path, redirect or per-client key can restore linkability before the protected exchange begins. Privacy has a bootstrap dependency.

RFC 9576 makes a related point through Privacy Pass: issuance, attestation and redemption are separate contexts, and deployment choices determine whether parties can correlate them. RFC 9614 calls this privacy partitioning—separating who someone is from what they do—while warning that partitioning is not a panacea. RFC 7258 adds the governance baseline: pervasive observation of content or external characteristics is an attack regardless of whether the observer claims a benign motive.

These RFCs do not solve DAWN. They prevent a category error. “Encrypted discovery” says nothing about query minimisation, candidate-set size, role combination, bootstrap, repetition, retention or exceptional access unless those properties are separately specified.

The candidate set is a privacy boundary

An answer can disclose as much as a question. If a query returns one agent, the directory has revealed the likely counterparty before any selection record exists. If it returns two, a later network observation may resolve the ambiguity. If it returns hundreds but attaches detailed ownership, location, availability and trust metadata, the client learns a great deal about operators who may not know they were considered.

The DAWN requirements draft says entities should control what is public and what is restricted, and discovery should not disclose more than is necessary to determine whether interaction is appropriate. That principle needs an operational denominator. “Necessary” changes when a query is interactive, when attributes are requested in stages, when the requester is anonymous, when results are cached and when a security team can later reopen logs.

Candidate-set size is not a universal privacy score. Ten agents operated by one company may provide less diversity than three independent operators. A rare combination of attributes can fingerprint the requester even when fifty records match. A result floor nevertheless forces an important failure decision: if the directory cannot answer without isolating one entity or one requester, should it broaden the answer, defer the query, add delay or refuse?

That decision belongs in the protocol’s governance surface. Silent success transfers control to the index operator, which can decide how much intention to expose while the client receives only a technically valid result.

A selection-disclosure budget

Before deployment, an operator should publish a selection-disclosure budget. The budget is not a central audit trail and should not retain raw queries. It is a bounded policy statement defining what each participant is allowed to learn and how exceptions expire.

At minimum, it should name the permitted attribute classes and maximum granularity; a minimum candidate-set or anonymity floor; the behavior when the floor cannot be met; the window during which repeated requests may remain linkable; batching, padding or rotation rules; and the party that sees requester identity, plaintext intent, candidate membership and returned attributes. It should state non-collusion assumptions rather than hiding them inside an architecture diagram.

The budget must also cover the pre-query path: discovery of the directory, relay, gateway or key configuration. It should separate public, restricted and requester-specific result fields; set ceilings for raw-query and aggregate retention; identify the authority that can authorize emergency narrowing or re-identification; give that authority an expiry and review condition; and provide a correction route when stale attributes changed a result.

Evidence can remain privacy-preserving. An operator can publish distributions of result-set bands, refusal rates, attribute-class use, exception counts and retention compliance without releasing the search terms or candidate identities. Local, short-lived counters can prove that a floor was applied. Independent testing can issue synthetic queries and compare what each role observes. The objective is not to recreate the surveillance record in the name of accountability.

Sources

  1. Lu Heng — The Policy Mirror
  2. Lu Heng — Minimum Initial Specification, Localized Future Decision, Voluntary Adoption
  3. Lu Heng — Why BTW Media Exists
  4. DAWN Privacy Considerations, revision 00
  5. Datatracker document status
  6. Datatracker revision history
  7. DAWN problem statement, revision 02
  8. DAWN requirements, revision 01
  9. DAWN terminology, revision 01
  10. RFC 6973 — Privacy Considerations for Internet Protocols
  11. RFC 7258 — Pervasive Monitoring Is an Attack
  12. RFC 9156 — DNS Query Name Minimisation
  13. RFC 9230 — Oblivious DNS over HTTPS
  14. RFC 9458 — Oblivious HTTP
  15. RFC 9540 — Discovery of Oblivious Services
  16. RFC 9576 — The Privacy Pass Architecture
  17. RFC 9614 — Partitioning as an Architecture for Privacy