Change:
Historically, the Nonce included a time component. Now that the time component is split out & Nonce is effectively an opaque identifier, ReportID is clearer & more closely matches similar identifiers (TaskID, AggregationJobID, BatchID).
Note this PR includes a single wire-format change: had its fields reordered so that the comes first, since the ID is the primary identifier. I am happy to revert this part of the PR if folks would prefer a purely-editorial PR.
LGTM. Any thoughts on replacing and with a Nonce so then it has both?
I'm pretty happy leaving & as separate fields -- for practical purposes, IMO binds them together closely enough (along with the report extensions). Conceptually, DAP is changing such that the primary identifier for a report is its opaque ID (with this PR, called ). Previously, the primary identifier for a report was . The technical aspects of this change were made by cjpatton in his changes to introduce tasks. If we do decide to introduce a struct that is effectively , I'd prefer if it was called something other than -- while we do expect that this value is a "value to be used only once", it's no longer used as a nonce in any cryptographic operations. And I'd argue there's no better justification to call the report ID (or ) a nonce than, say, the aggregation job ID/batch ID/task ID. That is, IMO "report ID" more accurately names what this type is than "nonce" -- "nonce" is not technically incorrect, just less clear.
Currently, the DAP specification has a number of opaque values used to identify some DAP entity: (identifying a client report) (identifying a task) (identifying an aggregation job) (identifying a batch) 's name differs from the rest. I think this is because, historically, the nonce also included a time component. Now that the time component has been split out, I think we could rename to for clarity of purpose. Thoughts? (and I probably don't need to say this, but there is no reason to push this into DAP-02 -- it could easily land in DAP-03 instead.)
Yup, I think this is a good idea! I'm tempted to say let's stick this in 02, since it's editorial, but it's actually somewhat invasive because we use the term "nonce set" in so many places. If you want to send a PR, I'd review it. But we should make sure there's broad consensus before merging.
Nice change Yeah I think this is a big win :) good idea NAME

Discussion:
encrypted input share whose report ID is in this set rejects the report as described in early-input-share-validation. <del> [OPEN ISSUE: This has the potential to require aggreagtors to store </del> <ins> [OPEN ISSUE: This has the potential to require aggregators to store </ins> report ID sets indefinitely.  See issue#180.] A malicious aggregator may attempt to force a replay by replacing the

(See batch-validation.) However, Aggregators are also required to implement several per- <del> report checks that require retaining a number of data artificts.  For </del> <ins> report checks that require retaining a number of data artifacts.  For </ins> example, to detect replay attacks, it is necessary for each Aggregator to retain the set of report IDs of reports that have been aggregated for the task so far.  Depending on the task lifetime and