Draft: draft-ietf-ppm-dap

Commentary: Based on . 
 can you please rebase ? Some of the changes we improved on in now appear here . 
 Rebased .
Paragraph (version A):
Prio3, which allows for aggregate statistics such as sum, mean,
histograms, etc.  This class of VDAFs is based on Prio CGB17 and
includes improvements described in BBCGGI19.
Paragraph (version A):
Poplar1, which allows for finding the most popular strings among a
collection of clients (e.g., the URL of their home page) as well
as counting the number of clients that hold a given string.  This
VDAF is the basis of the Poplar protocol of BBCGGI21, which is
designed to solve the heavy hitters problem in a privacy
preserving manner.
Paragraph (version A):
of the shares.
Paragraph (version A):
It allows the aggregators to compute the final output by first
aggregating up their measurements shares locally, then combining
the results to obtain the final output.
Paragraph (version A):
The overall system architecture is shown in pa-topology.
Paragraph (version B):
The protocol is executed by a large set of Clients and a small set of
servers.  Servers are referred to as "Aggregators".  Each Client's
input to the protocol is its measurement (or set of measurements,
e.g., counts of some user behavior).  Given the input set of
measurements "x_1, ..., x_n" held by "n" users, the goal of DAP is to
compute "y = F(p, x_1, ..., x_n)" for some function "F" while
revealing nothing else about the measurements.  We call "F" the
"aggregation function".
Paragraph (version B):
Prio3 (VDAF), which allows for aggregate statistics such as sum,
mean, histograms, etc.
Paragraph (version B):
Poplar1 (VDAF), which allows for finding the most popular strings
uploaded by a set of Clients (e.g., the URL of their home page) as
well as counting the number of Clients that hold a given string.
This VDAF is the basis of the Poplar protocol of BBCGGI21, which
is designed to solve the heavy hitters problem in a privacy
preserving manner.
Paragraph (version B):
Given only a subset of the input shares, it is impossible to
deduce the plaintext measurement from which they were generated.
Paragraph (version B):
It allows the Aggregators to compute the aggregation function by
first aggregating up their input shares locally into "aggregate
shares", then combining the aggregate shares into the aggregate
result.
Paragraph (version B):
The overall system architecture is shown in dap-topology.
Paragraph (version A):
The rate at which measurements can be taken, i.e., the "minimum
batch window".
Paragraph (version A):
These parameters are distributed out of band to the clients and to
the aggregators.  They are distributed by the collecting entity in
some authenticated form.  Each task is identified by a unique 32-byte
ID which is used to refer to it in protocol messages.
Paragraph (version A):
During the duration of the measurement, each client records its own
value(s), packages them up into a report, and sends them to the
leader.  Each share is separately encrypted for each aggregator so
that even though they pass through the leader, the leader is unable
to see or modify them.  Depending on the measurement, the client may
only send one report or may send many reports over time.
Paragraph (version A):
The leader distributes the shares to the helpers and orchestrates the
process of verifying them (see validating-inputs) and assembling them
into a final measurement for the collector.  Depending on the VDAF,
it may be possible to incrementally process each report as it comes
in, or may be necessary to wait until the entire batch of reports is
received.
Paragraph (version A):
An essential task of any data collection pipeline is ensuring that
the data being aggregated is "valid".  In DAP, input validation is
complicated by the fact that none of the entities other than the
client ever sees the values for individual clients.
Paragraph (version B):
The rate at which measurements can be taken, i.e., the "minimum
batch duration".
Paragraph (version B):
These parameters are distributed out of band to the Clients and to
the Aggregators.  They are distributed by the Collector in some
authenticated form.  Each task is identified by a unique 32-byte ID
which is used to refer to it in protocol messages.
Paragraph (version B):
During the duration of the task, each Client records its own
measurement value(s), packages them up into a report, and sends them
to the leader.  Each share is separately encrypted for each
Aggregator so that even though they pass through the Leader, the
Leader is unable to see or modify them.  Depending on the task, the
Client may only send one report or may send many reports over time.
Paragraph (version B):
The Leader distributes the shares to the Helpers and orchestrates the
process of verifying them (see validating-inputs) and assembling them
into a final aggregate result for the Collector.  Depending on the
VDAF, it may be possible to incrementally process each report as it
comes in, or may be necessary to wait until the entire batch of
reports is received.
Paragraph (version B):
An essential task of any data collection pipeline is ensuring that
the data being aggregated is "valid".  In DAP, input validation is
complicated by the fact that none of the entities other than the
Client ever sees that client's plaintext measurement.
Paragraph (version A):
The specific properties attested to in the proof vary depending on
the measurement being taken.  For instance, to measure the time the
user took performing a given task the proof might demonstrate that
the value reported was within a certain range (e.g., 0-60 seconds).
By contrast, to report which of a set of N options the user select,
the report might contain N integers and the proof would demonstrate
that N-1 were 0 and the other was 1.
Paragraph (version B):
The specific properties attested to in the proof vary depending on
the measurement being taken.  For instance, to measure the time the
user took performing a given task the proof might demonstrate that
the value reported was within a certain range (e.g., 0-60 seconds).
By contrast, to report which of a set of "N" options the user select,
the report might contain "N" integers and the proof would demonstrate
that "N-1" were "0" and the other was "1".