Change:
Similar to , it should not be possible for a share to be included in more than one batch. The timestamp currently gives us some way of ensuring that reports map to at most batch, but not a way of ensuring that reports aren't included two overlapping batch windows. It's not immediately clear if include a single report in two overlapping batch windows is a problem, or if a problem only arises when these windows are disjoint. We should probably clarify what are the inter-batch requirements here and what sort of replay prevention is required.
The aggregators (either the leader or helper) can prevent the collector from getting outputs from overlapping batches by remembering batch intervals. For example, suppose the leader responded successfully to a collect request for time interval . Then suppose that, some time later, the collector requests output shares for , where . The potential privacy violation occurs because the sets of reports in each batch are non-disjoint. To prevent this, the leader might respond to the second request with an error, or it might just include the reports in .
If aggregators are meant to use the report timestamp to protect against replay, then I think it needs to appear in the AEAD-ed message constructed by the client (i.e. ). Otherwise a leader could insert arbitrary timestamps into and trick helpers into exceeding privacy budgets or double counting inputs. Additionally, a batching client could insert arbitrary values into .
I created a PR that addresses this issue partially. What's left to do is allow multiple collect requests over the same batch, as required by the PDA protocol (e.g., Hits). I have an idea for how to do this, I'll follow up with a PR.
Closed by URL
LGTM -- thanks!

Discussion:
The type of each measurement. <del> The aggregation function to compute (e.g., sum, mean, etc.) and an optional aggregation parameter. </del> <ins> The aggregation function to compute (e.g., sum, mean, etc.). </ins> The set of aggregators and necessary cryptographic keying material to use.

"Report.encrypted_input_shares" is equal to the index of the aggregator in the task's "aggregator_endpoints" to which the AggregateInitializeReq is being sent.  The "agg_param" field is an <del> opaque, VDAF-specific aggregation parameter.  The "job_id" parameter contains the leader's chosen AggregationJobID. </del> <ins> opaque, VDAF-specific aggregation parameter provided during a collection flow.  The "job_id" parameter contains the leader's chosen AggregationJobID. [[OPEN ISSUE: Check that this handling of "agg_param" is appropriate when the definition of Poplar is done.]] </ins> Let "[aggregator]" denote the helper's API endpoint.  The leader sends a POST request to "[aggregator]/aggregate" with its

"batch_interval", the request's batch interval. "agg_param", an aggregation parameter for the VDAF being executed. <ins> This is the same value as in "AggregateInitializeReq" (see leader- init). </ins> Depending on the VDAF scheme and how the leader is configured, the leader and helper may already have prepared all the reports falling

"batch_interval" is the batch interval of the request. "agg_param", an aggregation parameter for the VDAF being executed. <ins> This is the same value as in "AggregateInitializeReq" (see leader- init) and in "CollectReq" (see collect-init). </ins> "report_count" is the number of reports included in the aggregation.