Change:
Issue discusses a problem with the current collect request validation requirements. We don'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: the multi-server deployment model AFE 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.
NAME 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 don't think anything else really needs to change.
Sounds good to me. Here is the issue for reference: URL
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.

Discussion:
the aggregator MUST abort and alert the peer with "batchLifetimeExceeded". <ins> Finally, the aggregator checks that the batch interval defined by the collect request satisfies one of the conditions: The batch interval does not overlap with the batch interval of any prior completed collect requests. The batch interval, including its start and duration values, match a prior completed collect request. [[OPEN ISSUE: #195 tracks how we might relax this constraint to allow for more collect query flexibility.  As of now, this is quite rigid and doesn't give the collector much room for mistakes.]] </ins> 4.4.6. Using a client-provided report multiple times within a single batch,