jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-pda-protocol

Commentary: One possible extension would be an opaque blob to carry client attestation information ( for ) , if desired . The current set is empty , but I suspect we 'll need freedom to extend here as this gets used without totally changing the protocol version . If folks are generally supportive of this , it should probably land after , which touches and renames PDAUploadReq to PDAReport . 
 Both ( 1 ) and ( 2 ) are external to the protocol . The purpose of extensions is to allow whatever mechanism exists for addressing them to be bound to the report , as is done here . This is done in the change . This is not meant to close the attestation issue . It 's meant to give us the mechanics to address it later . 
 Right you are . What threw me off was the following statement : The " then these extensions are required to be echoed ... " makes it sound as if they 're not echoed , which they are . I 'm happy with this PR modulo fixing this statement .
Paragraph (version B):
"extensions" is a list of extensions to be included in the Upload
flow; see upload-extensions.
Paragraph (version B):
"extension_type" indicates the type of extension, and
"extension_data" contains information specific to the extension.
Paragraph (version A):
The "time" and "jitter" fields have the same value as those in the
report uploaded by the client.  Similarly, the "helper_share" field
is the helper's encrypted input share as it appeared in the report.
[OPEN ISSUE: We usually only need to send this in the first aggregate
request.  Shall we exclude it in subsequent requests somehow?]  The
remainder of the structure is dedicated to the protocol-specific
request parameters.
Paragraph (version B):
The "time", "jitter", and "extensions" fields have the same value as
those in the report uploaded by the client.  Similarly, the
"helper_share" field is the helper's encrypted input share as it
appeared in the report.  [OPEN ISSUE: We usually only need to send
this in the first aggregate request.  Shall we exclude it in
subsequent requests somehow?]  The remainder of the structure is
dedicated to the protocol-specific request parameters.
Draft: draft-pda-protocol

Commentary: Differential privacy can protect against attacks where a portion of the input data is known a priori , or when the size of a batch is small . This PR adds DP as an optional mitigation for PDA deployments and lists where it helps mitigate various threats . Additionally : Removes a false statement that revealing user input does not compromise other users ' privacy . This is not necessarily the case ( e.g. imagine if the batch size is 2 or if many users reveal their input ) . Removes a statement that clients revealing their inputs is outside the threat model ( is this still relevant ? )
Paragraph (version A):
Optionally, PDA deployments can choose to ensure their output F
achieves differential privacy SV16.  A simple approach would require
the aggregators to add two-sided noise (e.g. sampled from a two-sided
geometric distribution) to outputs.  Since each aggregator is adding
noise independently, privacy can be guaranteed even if all but one of
the aggregators is malicious.  Differential privacy is a strong
privacy definition, and protects users in extreme circumstances: Even
if an adversary has prior knowledge of every input in a batch except
for one, that one record is still protected.
Paragraph (version B):
Optionally, PDA deployments can choose to ensure their output F
achieves differential privacy SV16.  A simple approach would require
the aggregators to add two-sided noise (e.g. sampled from a two-sided
geometric distribution) to outputs.  Since each aggregator is adding
noise independently, privacy can be guaranteed even if all but one of
the aggregators is malicious.  Differential privacy is a strong
privacy definition, and protects users in extreme circumstances: Even
if an adversary has prior knowledge of every input in a batch except
for one, that one record is still formally protected.
Draft: draft-pda-protocol

Commentary: I a clarification that the nonce is random . IMO the question of who randomly generates the nonce goes with the question of how participants agree upon PDAParams , which is to say it 's outside the protocol . 
 On the 2021/7/7 design call we decided that the ID should be derived deterministically from the serialized PAParam by , for example , hashing it . This solves a few problems simultaneously . This settles the question of whether there should be 1:1 correspondence between a task ID and the parameters used for that task . brought up an interesting question , which is how to make the task ID unique when two different data collection tasks use the same parameters . Thoughts ? 
 The consensus here is to do SHA-256 over the PDAParams structure and use that as the 32 byte PDATaskID . However , hashing a protocol message requires us to decide on a canonical representation of a protocol message , which I think forces us to decide how to encode messages on the wire . I filed for that question . I 'll proceed with a PR for this issue on the assumption that we 'll pick  . 
 As I mentioned there , the assumption would be that we 're adopting TLS ' binary encoding . If so , in TLS notation , you would write as the hash of , which itself is a serialized data structure . 
 All we require is that each PAParam have some unique value , right ? A random nonce would probably suffice . r.e . the encoding , yes , let 's stick with TLS 's wire format as suggests . 
 Yes , my thinking was that we would just stick 16 bytes of random data in ( a UUID 's worth ) . I agree that we should stick with TLS binary encoding . 
 Approved , with the following suggestion : Let 's leave a [ TODO : ... ] comment under the definition of for clarifying how it should be chosen .
Paragraph (version B):
"nonce": A unique sequence of bytes used to ensure that two
otherwise identical "PDAParam" instances will have distinct
"PDATaskID"s.  It is RECOMMENDED that this be set to a random
16-byte string derived from a cryptographically secure pseurandom
number generator.
Paragraph (version B):
Where "SHA-256" is as specified in FIPS180-4.
Draft: draft-pda-protocol

Commentary: Updating authors ' comments 
 Rebased and squashed .
Paragraph (version A):
The collector has chosen an HPKE key pair.
Paragraph (version A):
Each helper has chosen an HPKE key pair.
Paragraph (version A):
Each helper has chosen a key for an AEAD scheme.
Paragraph (version B):
The collector has chosen an HPKE configuration and corresponding
secret key.
Paragraph (version B):
The helper has chosen an HPKE configuration and corresponding
secret key.
Paragraph (version A):
After the client uploads a report to the leader, the leader and
helper verify in zero knowledge that the input is valid.  The exact
procedure for doing so is protocol specific, but all protocols have
the same basic structure.  In particular, the protocol is comprised
of a sequence of _aggregate requests_ from the leader to the helper.
At the end of this procedure, the leader and helper will have have
aggregated a set of valid client inputs.
Paragraph (version B):
After the client uploads a report to the leader, the leader and
helper verify in zero knowledge that the input is valid.  The exact
procedure for doing so is protocol specific, but all protocols have
the same basic structure.  In particular, the protocol is comprised
of a sequence of _aggregate requests_ from the leader to the helper.
At the end of this procedure, the leader and helper will have have
aggregated a set of valid client inputs (though not necessarily a
complete batch).
Draft: draft-pda-protocol

Commentary: Partially addresses . ( We also need to decide if / how to allow a particular PA protocol to use multiple helpers for privacy . ) Right now , multiple helpers are used for redundancy in case one of the helpers dropped out . This removes this mechanism from the core protocol . 
 Squashed and rebased . 
 That 's a good idea , 
  ... Do we need to decide . Per our discussion on Wednesday , if the clients learn this out of band then we wo n't need this field at all because clients will get it separately and helpers do n't need to know what the other helpers are , right ? 
 My takeaway is that the parameters must contain all input needed to run the protocol , including the helpers . And all of this is configured out of band . You could punt everything except for the cryptographic goop out of the parameters structure , forcing clients to know the leader and helper and get their public keys out of band as well , which would be fine . It 's just different . I think both work just fine , but I lean towards having params specify everything . It just seems simpler to me . That said ... making public key discovery part of the client upload protocol here is more complex , I think . So , . 
 Squashed . 
 LGTM . Multiple helpers " for privacy " seems like it 's inherently a per - protocol thing ( Prio supports it ,  does not ) . If and when we decide to address that , should we move this to the protocol - specific slot in PAParam ?
Paragraph (version A):
"helper_urls": The helpers' endpoint URLs.
Paragraph (version B):
"helper_url": The helpers endpoint URL.
Paragraph (version A):
If the set of supported helpers is empty, then the client aborts and
alerts the leader with "no supported helpers".  Otherwise, for each
supported helper the client issues a POST request to
"[leader]/upload_finish" with a payload constructed as described
below.
Draft: draft-pda-protocol

Commentary: In we did away with the requirement for interaction between the client and leader . This PR resolves the issue by making the upload start request an idempotent GET . 
 Based on this week 's design call ( 2021/7/7 ) , " upload start " is likely going away altogether .
Paragraph (version A):
The "task" field corresponds to the PA task for which a report will
be generated.
Draft: draft-pda-protocol

Commentary: The design document discusses " reports " which are a group of measurements being submitted to a DPA instantiation . There should be an entry in the " Terminology " section that explicitly defines a report and how it relates to " measurements " and " inputs " . 
 Thanks for putting the list back in alphabetical order , too !
Paragraph (version A):
Input: The original data emitted by a client, before any
encryption or secret sharing scheme is applied.  This may include
multiple measurements.
Paragraph (version B):
Input: The measurement (or measurements) emitted by a client,
before any encryption or secret sharing scheme is applied.
Paragraph (version B):
Report: Uploaded to the leader from the client.  A report contains
the secret-shared and encrypted input and proof.