Draft: draft-ietf-ppm-dap

Commentary: Based on ( merge that first ) . This is to match RFC 8446 . 
 We use dashes in enums : I 'm not sure how got on this kick ( might be my fault ! ) , but I would prefer underscores , mainly for consistency with RFC 8446 : anyone have a strong preference for dashes ? anyone object to landing this in DAP-02 ? 
 . The argument for consistency with RFC 8446 is good enough for me . think we could take this in draft-02 if we really wanted to , but since this change has no actual impact on implementations ( the enum variant names never appear in encoded messages ) , I think we could err on the side of allowing a reasonable span of time for discussion in the WG and do this in draft-03 . 
 We currently have an open issue for tracking the consensus protocol needed for this system to work . In working through this text , we should make note of what sort of synchronization we assume between different participants of the system . 
 In the 3/17 design call we agreed that for purposes of the design doc and probably the initial deployments of Prio , we would assume that shared parameters ( e.g. , arithmetic circuits , primes , aggregation identifiers ) would be exchanged between all parties ( i.e. , clients , aggregators , collector , leader ) before the start of the protocol over some unspecified secure channel . However , eventually , it should be possible for a client that wishes to use Prio to programmatically : discover participating servers ( i.e. , a directory of aggregators ) discover the capabilities of participating servers ( i.e. , what algorithms do they support for secret sharing or validity proofs or aggregations ? What optional protocol features do they support ? ) configure a Prio aggregation ( i.e. , select some number of aggregation servers , getting a unique handle , configuring field size , etc . ) 
 One thing that 's still TBD is how to choose the joint randomness . It could be as simple as having the leader choose a seed for a PRG and distributing it to the aggregators over secure channels . It could be as complicated as querying at some point after the shares are received by the aggregators . 
 To close the loop on this issue : the PDA parameters are distributed to all entities out - of - band .
Paragraph (version A):
The first query type, "time-interval", is designed to support
applications in which reports are collected over a long period of
time.  The Collector specifies a "batch interval" that determines the
time range for reports included in the batch.  For each report in the
batch, the time at which that report was generated (see upload-flow)
must fall within the batch interval specified by the Collector.
Paragraph (version B):
The first query type, "time_interval", is designed to support
applications in which reports are collected over a long period of
time.  The Collector specifies a "batch interval" that determines the
time range for reports included in the batch.  For each report in the
batch, the time at which that report was generated (see upload-flow)
must fall within the batch interval specified by the Collector.
Paragraph (version A):
The "fixed-size" query type is used to support applications in which
the Collector needs the ability to strictly control the sample size.
This is particularly important for controlling the amount of noise
added to reports by Clients (or added to aggregate shares by
Aggregators) in order to achieve differential privacy.
Paragraph (version B):
The "fixed_size" query type is used to support applications in which
the Collector needs the ability to strictly control the sample size.
This is particularly important for controlling the amount of noise
added to reports by Clients (or added to aggregate shares by
Aggregators) in order to achieve differential privacy.
Paragraph (version A):
For fixed-size tasks, the Leader specifies a "batch ID" that
determines the batch to which each report for this aggregation
job belongs.
Paragraph (version B):
For fixed_size tasks, the Leader specifies a "batch ID" that
determines the batch to which each report for this aggregation
job belongs.
Paragraph (version A):
where "sk" is the HPKE secret key, and "server_role" is the role of
the aggregator ("0x02" for the leader and "0x03" for the helper).  If
decryption fails, the aggregator marks the report share as invalid
with the error "hpke-decrypt-error".  Otherwise, it outputs the
resulting "input_share".
Paragraph (version B):
where "sk" is the HPKE secret key, and "server_role" is the role of
the aggregator ("0x02" for the leader and "0x03" for the helper).  If
decryption fails, the aggregator marks the report share as invalid
with the error "hpke_decrypt_error".  Otherwise, it outputs the
resulting "input_share".
Paragraph (version A):
Check if the report has never been aggregated but is contained by
a batch that has been collected.  If this check fails, the input
share MUST be marked as invalid with the error "batch-collected".
This prevents additional reports from being aggregated after its
batch has already been collected.
Paragraph (version A):
Check if the report has already been aggregated with this
aggregation parameter.  If this check fails, the input share MUST
be marked as invalid with the error "report-replayed".  This is
the case if the report was used in a previous aggregate request
and is therefore a replay.
Paragraph (version A):
For fixed-size tasks, the Aggregators need to ensure that each
batch is roughly the same size.  If the number of reports
aggregated for the current batch exceeds the maximum batch size
(per the task configuration), the Aggregator MAY mark the input
share as invalid with the error "batch-saturated".  Note that
this behavior is not strictly enforced here but during the
collect sub-protocol.  (See batch-validation.)  If both checks
succeed, the input share is not marked as invalid.
Paragraph (version A):
Check if the report's timestamp has passed its task's
"task_expiration" time, if so the Aggregator MAY mark the input
share as invalid with the error "task-expired".
Paragraph (version B):
Check if the report has never been aggregated but is contained by
a batch that has been collected.  If this check fails, the input
share MUST be marked as invalid with the error "batch_collected".
This prevents additional reports from being aggregated after its
batch has already been collected.
Paragraph (version B):
Check if the report has already been aggregated with this
aggregation parameter.  If this check fails, the input share MUST
be marked as invalid with the error "report_replayed".  This is
the case if the report was used in a previous aggregate request
and is therefore a replay.
Paragraph (version B):
For fixed_size tasks, the Aggregators need to ensure that each
batch is roughly the same size.  If the number of reports
aggregated for the current batch exceeds the maximum batch size
(per the task configuration), the Aggregator MAY mark the input
share as invalid with the error "batch_saturated".  Note that
this behavior is not strictly enforced here but during the
collect sub-protocol.  (See batch-validation.)  If both checks
succeed, the input share is not marked as invalid.
Paragraph (version B):
Check if the report's timestamp has passed its task's
"task_expiration" time, if so the Aggregator MAY mark the input
share as invalid with the error "task_expired".
Paragraph (version A):
If either step fails, the aggregator marks the report as invalid with
error "vdaf-prep-error".  Otherwise, the value "out" is interpreted
as follows.  If this is the last round of the VDAF, then "out" is the
aggregator's output share.  Otherwise, "out" is the pair
"(prep_state, prep_msg)".
Paragraph (version B):
If either step fails, the aggregator marks the report as invalid with
error "vdaf_prep_error".  Otherwise, the value "out" is interpreted
as follows.  If this is the last round of the VDAF, then "out" is the
aggregator's output share.  Otherwise, "out" is the pair
"(prep_state, prep_msg)".
Paragraph (version A):
Information used to bind the aggregate result to the query.  For
fixed-size tasks, this includes the batch ID assigned to the batch
by the Leader.  The indicated query type MUST match the task's
query type.
Paragraph (version B):
Information used to bind the aggregate result to the query.  For
fixed_size tasks, this includes the batch ID assigned to the batch
by the Leader.  The indicated query type MUST match the task's
query type.
Paragraph (version A):
For time-interval tasks, the request specifies the batch
interval.
Paragraph (version A):
For fixed-size tasks, the request specifies the batch ID.
Paragraph (version B):
For time_interval tasks, the request specifies the batch
interval.
Paragraph (version B):
For fixed_size tasks, the request specifies the batch ID.
Paragraph (version A):
For time-interval tasks, the batch selector is the batch interval
specified in the query.
Paragraph (version A):
For fixed-size tasks, the batch selector is the batch ID assigned
sent in the response.
Paragraph (version B):
For time_interval tasks, the batch selector is the batch interval
specified in the query.
Paragraph (version B):
For fixed_size tasks, the batch selector is the batch ID assigned
sent in the response.
Paragraph (version A):
Finally, the Aggregator checks that the batch does not contain a
report that was included in any previous batch.  If this batch
overlap check fails, then the Aggregator MUST abort with error of
type "batchOverlap".  For time-interval tasks, it is sufficient (but
not necessary) to check that the batch interval does not overlap with
the batch interval of any previous query.  If this batch interval
check fails, then the Aggregator MAY abort with error of type
"batchOverlap".
Paragraph (version B):
Finally, the Aggregator checks that the batch does not contain a
report that was included in any previous batch.  If this batch
overlap check fails, then the Aggregator MUST abort with error of
type "batchOverlap".  For time_interval tasks, it is sufficient (but
not necessary) to check that the batch interval does not overlap with
the batch interval of any previous query.  If this batch interval
check fails, then the Aggregator MAY abort with error of type
"batchOverlap".