Original text:
response.  The content type of each request is "application/octet- stream".  We assume that some transport layer security protocol (e.g., TLS or QUIC) is used between each pair of parties and that the <del> server is always authenticated. </del>  [TODO: Decide how to provide mutual authentication in leader-to- helper and collector-to-leader connections.  One option is to use 3.1.1. Each PA protocol is associated with a _PA task_ that specifies the <del> measurements that are to be collected: </del>  <del> The first field, "version" specifies the version of this document. The second field, "id", is an opaque identifier used by the clients, aggregators, and collector to uniquely identify the PA task at hand. We will call it the _task id_ in the remainder. [TODO: Decide how the "PATask" is configured.  Eventually this will be distributed, in an authenticated manner, from the collector to the other parties.  For now, we just assume this value is negotiated out- of-band.] 3.1.2. Associated to each task are the _PA Parameters_ encoded by the "PAParam" structure: "task": The PA task. "helper_url": The helpers endpoint URL. </del>  "collector_config": The HPKE configuration of the collector (described in hpke-config).  [OPEN ISSUE: Maybe the collector's "proto": The PA protocol, e.g., Prio or Hits.  The rest of the structure contains the protocol specific parameters. <del> [TODO: Decide how the "PAParam" is configured.  Like the task, this will need to be authenticated by the collector.] </del>  <del> [OPEN ISSUE: Is there just one PAParam for each PATask, or do we want to allow PAParam to change overtime?] </del>  <del> 3.1.3. </del>  Our protocol uses HPKE for public-key encryption I-D.irtf-cfrg-hpke. Each aggregator specifies the HPKE public key that clients use to 3.3.1. The client sends a GET request to <del> "[leader]/[version]/[task_id]/upload_start", where "[version] == PATask.version" and "[task_id] == PATask.id".  [TODO: Decide if adding the protocol version and task id to the URL is the right way to go.  Instead, we may want to make this a POST with a body that specifies the PATask.  (See issue#61.)] The leader respond with status 200 and the following message: </del>  The message includes the PA parameters the client will use to generate its report.  It also includes a protocol-specific message, either key config specifies a KEM, KDF, or AEAD algorithm the client doesn't recognize. <del> [OPEN ISSUE: Should the request URL encode the PA task?  This would </del>  be necessary if we make "upload_start" an idempotent GET per issue#48.] The payload is structured as follows: We sometimes refer to this message as the _report_. The message <del> contains the "task" fields of the previous request.  It also includes the time (in seconds since the beginning of UNIX time) at which the </del>  report was generated.  The rest of the message consists of the encrypted input shares, each of which has the following structure: The helper handles well-formed requests as follows.  (As usual, malformed requests are handled as described in pa-error-common- aborts.)  It first looks for the PA parameters "PAParam" for which <del> "PAAggregateReq.task.id == PAParam.task.id".  Next, it looks up the HPKE config and corresponding secret key associated with "PAAggregateReq.helper_hpke_config_id".  If not found, then it aborts and alerts the leader with "unrecognized key config".  [NOTE: In this situation, the leader has no choice but to abort.  This falls into the class of error scenarios that are addressable by running with multiple helpers.] </del>  [TODO: Don't require all sub-requests to pertain to the same HPKE config.] malformed payload, then the receiver aborts and alerts the peer with "unrecognized message". <del> Each POST request to an aggregator contains a "PATask".  If the </del>  aggregator does not recognize the task, i.e., it can't find a <del> "PAParam" for which "PATask.id == PAParam.task.id", then it aborts and alerts the peer with "unrecognized task". </del>  4.

Reviewer comments:
by removing the field from each of the protocol messages. Partially addresses by establishing that the task id is derived from the PA parameters for a task. We still need to specify this procedure.
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. NAME 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 JSON.
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 NAME 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.
This seems unnecessary.
The PATask is always the first bit of a protocol message, and the version is the first bit of the PATask. I figured it would be helpful to version each message because messages are carried by HTTP requests. There might be a simpler/better way to do this.
I don't think we should assume that's the case. If we want to have the version not determined at the URL level (a mistake, IMO) then we should have some sort of message wrapper that contains that, rather than overloading PATask.
I'm inclined to agree with NAME we're discussing versioning the whole API in , so PATask doesn't need to also provide version information. So, setting aside the question of message format versions, is there any value in maintaining a version on PATasks at the protocol level? I say no, because we want to be able to treat different PATasks completely independently and don't otherwise have any notion of a relationship between any two PATasks in the protocol.

Revised text:
response.  The content type of each request is "application/octet- stream".  We assume that some transport layer security protocol (e.g., TLS or QUIC) is used between each pair of parties and that the  <ins> server is authenticated. </ins> [TODO: Decide how to provide mutual authentication in leader-to- helper and collector-to-leader connections.  One option is to use 3.1.1. Each PA protocol is associated with a _PA task_ that specifies the  <ins> measurements that are to be collected.  Associated to each task is a set of _PA Parameters_, encoded by the following "PAParam" structure, which specify the protocol used to verify and aggregate the clients' measurements: </ins>  <ins> "helper_url": The helper's endpoint URL. </ins> "collector_config": The HPKE configuration of the collector (described in hpke-config).  [OPEN ISSUE: Maybe the collector's "proto": The PA protocol, e.g., Prio or Hits.  The rest of the structure contains the protocol specific parameters.  <ins> Each task has a unique _task id_ derived from the PA parameters: </ins>  <ins> The task id is derived using the following procedure.  [TODO: Specify derivation of the task ID.] </ins>  <ins> 3.1.2. </ins> Our protocol uses HPKE for public-key encryption I-D.irtf-cfrg-hpke. Each aggregator specifies the HPKE public key that clients use to 3.3.1. The client sends a GET request to  <ins> "[leader]/[version]/[task_id]/upload_start", where "[task_id] == PATaskID".  [TODO: Decide if adding the protocol version and task id to the URL is the right way to go.  Instead, we may want to make this a POST with a body that specifies the task id.  (See issue#61.)] The leader respond with status 200 and the following message: </ins> The message includes the PA parameters the client will use to generate its report.  It also includes a protocol-specific message, either key config specifies a KEM, KDF, or AEAD algorithm the client doesn't recognize.  <ins> [OPEN ISSUE: Should the request URL encode the task id?  This would </ins> be necessary if we make "upload_start" an idempotent GET per issue#48.] The payload is structured as follows: We sometimes refer to this message as the _report_. The message  <ins> contains the "task_id" of the previous request.  It also includes the time (in seconds since the beginning of UNIX time) at which the </ins> report was generated.  The rest of the message consists of the encrypted input shares, each of which has the following structure: The helper handles well-formed requests as follows.  (As usual, malformed requests are handled as described in pa-error-common- aborts.)  It first looks for the PA parameters "PAParam" for which  <ins> "PAAggregateReq.task_id" is equal to the task id derived from "PAParam".  Next, it looks up the HPKE config and corresponding secret key associated with "PAAggregateReq.helper_hpke_config_id". If not found, then it aborts and alerts the leader with "unrecognized key config".  [NOTE: In this situation, the leader has no choice but to abort.  This falls into the class of error scenarios that are addressable by running with multiple helpers.] </ins> [TODO: Don't require all sub-requests to pertain to the same HPKE config.] malformed payload, then the receiver aborts and alerts the peer with "unrecognized message".  <ins> Each POST request to an aggregator contains a "PATaskID".  If the </ins> aggregator does not recognize the task, i.e., it can't find a  <ins> "PAParam" for which the derived task id matches the "PATaskID", then it aborts and alerts the peer with "unrecognized task". </ins> 4.