Wiki · Concept · Last reviewed June 25, 2026

Distributed Aggregation Protocol

The Distributed Aggregation Protocol is an IETF privacy-preserving measurement protocol for collecting aggregate statistics without exposing individual measurements to one collecting server.

Category: Concept Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: privacy-preserving measurement, aggregation, telemetry, standards, surveillance

Definition

The Distributed Aggregation Protocol, or DAP, is an Internet-Draft from the IETF Privacy Preserving Measurement working group. Draft version 18, dated May 11, 2026, describes a multi-party protocol for collecting aggregate data without revealing any individual contributor's data. The IETF datatracker listed the draft as an active Internet-Draft with working group consensus waiting for write-up when reviewed for this page.

DAP is not a general anonymity tool, a consent system, or a guarantee that a measurement is socially acceptable. It is plumbing for a narrower question: how can many clients submit measurements so that the collector gets an aggregate statistic while the aggregators do not see each client's value in the clear?

The cryptographic layer is supplied by Verifiable Distributed Aggregation Functions, or VDAFs. The CFRG VDAF draft describes them as multi-party protocols for aggregate statistics over user measurements. It specifies Prio3 for general-purpose aggregation and Poplar1 for heavy hitters, while relying on the condition that at least one aggregation server executes honestly.

Mechanism

DAP has four main roles. Clients take measurements and report them to aggregators. A collector wants the aggregate result. A leader receives reports from clients and coordinates the protocol. A helper assists the leader with computation. The protocol is designed around many clients and two aggregation servers, so privacy depends on split trust rather than one all-seeing analytics server.

At a high level, each client shards a measurement into shares, encrypts report shares for the leader and helper, and uploads the report to the leader. During aggregation, the leader and helper verify reports through the selected VDAF and accumulate output shares. During collection, the aggregators send encrypted aggregate shares to the collector, which unshards them into the aggregate result.

A DAP task defines parameters such as the VDAF, batching rules, query mode, minimum batch size, and time boundaries. The DAP draft warns that batches that are too small can reveal information about individual measurements, and says implementations should opt out of tasks whose minimum batch size is too small.

Agent Context

DAP matters for AI Agent Observability because agent systems produce telemetry: tool success, failure rates, latency, safety interventions, refusal categories, browser actions, and workflow outcomes. Operators may want aggregate measurement without creating a central archive of person-level prompts, files, actions, or errors.

A DAP-style design can reduce raw telemetry exposure, but it does not decide which agent metrics should be collected. If an AI browser, coding assistant, or workplace agent contributes reports, the audit trail still needs to identify the task, collector, metric definition, aggregation servers, batch policy, retention, and downstream decision.

Governance Use

A governed DAP deployment should record the collector, leader, helper, client population, VDAF, task ID, task lifetime, minimum batch size, batch mode, query type, report schema, HPKE configuration, authentication method, proxy or OHTTP layer if used, retention period, and purpose of the aggregate. It should also say who can create tasks and who can change their privacy parameters.

The Taskprov extension draft shows why task binding matters. It specifies a way to bind task parameters to execution and to advertise task configuration in-band. Its security section treats the author as untrusted for privacy purposes, which is the right governance instinct: configuration can become a fingerprinting or weakening channel.

Limits

DAP protects against one important failure: collecting individual measurements and aggregating them later on a single server. It does not prevent bad metrics, small populations, coercive telemetry, biased measurement definitions, or harmful aggregate decisions. It also does not remove metadata exposure unless the surrounding deployment handles network identifiers, authentication, timing, and task uniqueness carefully.

The status limit is also important. The DAP and VDAF sources reviewed here are Internet-Drafts, not final RFCs. A related 2026 draft proposes DAP extensions for the Attribution API, but that draft explicitly says Internet-Drafts are work in progress. Pages and audits should therefore name the exact draft version used.

Review Record

Source Discipline

Claims about DAP roles, report upload, aggregation, collection, batch size, and protocol status should cite the DAP Internet-Draft and IETF PPM datatracker. Claims about Prio3, Poplar1, and the honest-aggregator condition should cite the CFRG VDAF draft. Claims about task binding should cite the Taskprov draft. Claims about real deployments require operator evidence.

Spiralist Reading

Spiralism reads DAP as a useful restraint on measurement hunger. It says: if the institution only needs the aggregate, do not collect the person first and promise to forget later. But aggregation is not absolution. The social question remains: which crowd is being measured, by whom, for what decision, and who can contest the metric before it becomes policy?

Sources

Return to Wiki