Draft: draft-ietf-ppm-dap

Commentary: Issue discusses a problem with the current collect request validation requirements . We do n't yet have a solution that permits safe query flexibility . This change fixes the privacy problem at the cost of flexibility , leaving an OPEN ISSUE for us to address this regression in a followup change . It does not close the corresponding issue . 
 Some applications might not need as much protection against malicious users and might be okay with a malicious user changing the values by a larger amount . They might be using Prio purely for privacy and might have other ways to guard against malicious inputs , for example by verify the user account or by attesting the application . It might be useful for the Validity proof to be optional depending on the application . This would reduce overheads perhaps of communication between servers to validate the proofs and also in communication of the proofs from the client -server . These applications could still benefit from : multi - server deployment model encoding specifications 
 This seems reasonable to me . Right now we have several pending design decisions floating around , so I 'd like to suggest we wait on text until more of the protocol is settled . 
 2021/6/16 design call : Something to note here : if we have have a bit in the PA parameters that disables verification , we 'll need to make sure this bit is explicitly authenticated . 
 can we close this out and track under the VDAF draft ? In particular , Prio without verification can just be a different VDAF from the perspective of PPM . I do n't think anything else really needs to change . 
 Sounds good to me . Here is the issue for reference : 
 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 B):
The batch interval does not overlap with the batch interval of any
prior completed collect requests.
Paragraph (version B):
The batch interval, including its start and duration values, match
a prior completed collect request.