Distributed Aggregation Protocol (DAP) Report Binding Extensions

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/.¶

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 11 January 2026.¶

Copyright Notice

Copyright (c) 2025 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

The core Distributed Aggregation Protocol (DAP) [DAP] is suited to a deployment model where reports are submitted directly to the leader as they are generated.¶

DAP report extensions can be used to enable alternative deployment models and approaches. This document defines a set of extensions to enable two key changes to how DAP is used:¶

• A operating mode where an intermediary is responsible for gathering reports and performing batch submissions for aggregation.¶

• A operating mode where DAP is part of a differentially-private system where the differential privacy mechanism is applied as part of the aggregation process.¶

No changes are needed to enable batched report submission in DAP. The challenge is that DAP assumes that clients know all the details of the aggregation task when generating reports. The late_binding report extension (Section 3) loosens this requirement, allowing the intermediary to make some choices about task configuration without coordinating with clients.¶

One consequence of late binding is the scope of anti-replay protections needs to much broader. For this, scoping report extensions (Section 5) are defined to help constrain the scope of reports over which replay protection operates.¶

For differential privacy, its effective implementation depends on being able to limit contributions from participants, or set bounds on sensitivity. The basic mechanism that DAP uses to cap contributions is record anti-replay. Aggregators are responsible for ensuring that the same report cannot be aggregated more than once. An honest participant will contribute a limited number of reports and can rely on at least one aggregator preventing each report from being used multiple times.¶

The default configuration of DAP also depends on having differential privacy configuration known to clients when reports are generated. Clients need to know the parameters of the differential privacy mechanism that is configured so that they can properly account for any privacy loss. This can limit the applicability of the protocol outside of certain narrow patterns.¶

This document defines extensions to DAP that allow reports to be bound to a specific amount of differential privacy budget expenditure (Section 4). For cases where the DAP aggregators are responsible for applying the differential privacy mechanism -- namely the addition of noise -- this ensures that clients can depend on the correct amount of noise being applied.¶

For a differentially-private system, scoping extensions (Section 5) can be essential. Scoping constraints can be used to ensure that contributions from different contexts are not combined in a way that would cause sensitivity bounds to be exceeded.¶

This document also defines a task provisioning extension (see Section 3.3 of [TASKPROV]) that lists the report extensions that need to included in every report. These task extensions also set constraints on the value of those report extensions.¶

2. Conventions and Definitions

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.¶

3. Late Task Binding

DAP presently requires that a client be aware of the task that it is contributing to. The identity of the task is bound to each report through the inclusion of the task ID in the call to the sharding function of the Verifiable Distributed Aggregation Function (VDAF); see Section 5.1 of [VDAF].¶

The late_binding report extension (codepoint 0xTBD) is an empty extension. The late_binding report extension signals to aggregators that a report was not bound to a specific task when it was created.¶

Late task binding might be useful when reports are collected by an intermediary. The client that generates the report in this case might be unaware of how the report will ultimately be aggregated. This allows the intermediary to defer the creation of a task until it has determined the necessary parameters for the task.¶

When sharding and protecting reports, the task ID is replaced with a the fixed, 32-byte sequence of b13e8440f1cdb4da51eed3967e0a2652d27f5005bc35f751daf188b4b746708b (in hex). Specifically, this includes the task_id that is passed to the Vdaf.shard function and is encoded in the InputShareAad struct; see Section 4.5.2 of [DAP].¶

Removing the binding of reports to tasks means that a report might be aggregated across any task that permits the use of this extension. This carries two risks:¶

• The report might contribute to the spoiling of the output of the task it is redirected to.¶

• The preparation of the report for the wrong task might leak information.¶

Binding reports to tasks is defense against attacks that misdirect reports to unintended tasks, including those configured with weaker security margins. The best defense against spoiling is to ensure that all tasks that use this are configured with roughly equivalent security margins. Spoiling of results through misdirection is then safeguarded by the verification that is performed at the preparation phase of the VDAF.¶

TODO: We might need to bind encryption/decryption to a specific VDAF configuration. We could do that using the task ID, like in [TASKPROV].¶

Misdirecting reports this way can still lead to limited spoiling of tasks, within the bounds permitted for a single task. However, any entity that can perform such redirection is potentially able to effect the same outcome more effectively through entirely falsified reports.¶

Enforcing anti-replay for tasks that are configured to accept reports with this extension cannot be applied on a per-task scope. A single anti-replay state MUST be used for all reports that include the late_binding report extension.¶

This could increase the cost of meeting anti-replay requirements. The intent with this extension is that additional constraints, such as one or more of the scoping extensions (see Section 5), will be used to make it more feasible for an aggregator to comply with anti-replay requirements.¶

4. Privacy Budget Consumption

The gathering of reports can be modeled as the expenditure of privacy budget by a client. That is, clients treat the creation of a report from private information as a limited release of information.¶

Total privacy loss in this case is determined by the combination of two factors:¶

• How the report is aggregated.¶

• How many reports are produced.¶

If aggregation includes the application of an appropriate differential privacy mechanism (that is, added noise; see [DWORK], [DAP-DP], and Section 8.5 of [DAP]), the client might rely on an understanding of that mechanism to model privacy loss. However, without finer controls, clients need to attribute a fixed privacy loss to each report. Consequently, the client needs to limit the number of reports it generates.¶

A budget ensures that the total privacy loss can be bounded while providing more flexibility in how reports are constructed. Privacy loss associated with any report (or information release) can be adjusted. Importantly, the amount of noise added to aggregates is based on the expended budget. In general, spending more privacy budget means that less noise is needed to maintain the same level of privacy; conversely, spending less budget means more noise.¶

A budget might be specified in terms of a metric (like the epsilon parameter in (ε, δ)-differential privacy) that is expended with each information release.¶

For example, for an overall budget of ε=10 might be split four ways: (0.5, 1.5, 2, 6). Noise might then be added, drawing from a distribution with a width inversely proportional to the budget spent; that is, a distribution with a standard deviation proportional to 2, 2/3, 1/2, and 1/6 respectively.¶

This extension gives clients the ability to manage privacy budget expenditure. By binding the amount of budget spent to each report, the client can transfer responsibility for applying differential privacy to the aggregation service. The addition of noise by the aggregation service can ensure a better trade-off between the amount of added noise and privacy parameters.¶

5. Scoping Extensions

The DAP report extensions in this section might be used to either constrain the use of reports for tasks that are configured with matching values or group reports for the purposes of detecting duplicates.¶

Including additional scoping information can also ensure that reports do not get reused outside of their intended scope.¶

This section defines report extensions that carry requester identity (Section 5.1) and report partition (Section 5.2).¶

6. Task Configuration Extensions

DAP tasks that are created with the DAP task configuration extension [TASKPROV] can set constraints on the reports that are accepted for a task.¶

enum {
  task_budget (0xTBD),
  single_requester (0xTBD),
  (2^16-1)
} TaskprovExtensionType;

Task provisioning extensions are defined that govern the use of the privacy_budget (Section 4) and requester_identity (Section 5.1) report extensions. These task provisioning extensions ensure that reports submitted to the task include the corresponding report extensions and that reports with invalid values are rejected.¶

7. Security Considerations

Security factors specific to each extension is enumerated in the respective sections: Section 3, Section 5.1, Section 5.2, and Section 4.¶

Use of DAP is subject to the security considerations of DAP (Section 8 of [DAP]) and the VDAF that is in use (Section 9 of [VDAF].¶

8. IANA Considerations

This document registers report extensions in the "Report Extension Identifiers" registry established in Section 9.2.2 of [DAP].¶

New report extension registrations are tabulated in Table 1.¶

This document registers task provisioning extensions in the "Taskbind Extensions" registry established in Section 7.2 of [TASKPROV].¶

New task provisioning extensions are tabulated in Table 2.¶

9. References

Acknowledgments

Roxana Geambesu noted that a binding to requester identity (Section 5.1) was an important component of a robust differential privacy system design. David Cook provided useful feedback about the design and document.¶

Author's Address