Change:
Removes some TODOs, clarifies why we have HpkeConfig collectorconfigstruct PPMParamUrl collectorurl, and amends collect protocol so that leader output shares are encrypted to collector's HPKE config. Several response structures no longer have or fields if the appropriate task (and hence and hence ) can be inferred from the request.
I want to address in this PR as well, so downgrading to draft for now.
NAME NAME This is ready; please review at your convenience.
Thank you for the review, NAME This picked up some merge conflicts so I will wait for all of NAME changes to land and then rebase.
You should be able to rebase now. I am mostly done.
Rebased, reordered, ready for re-review
This seems to be a dupe fo -- can we close?
Per discussion in the call today, I think this issue is about updating the various PDU definitions to allow for multiple helpers. For instance, currently has fields and , but it should instead have . is the more complex problem of extending the protocol to handle >1 helper, which probably involves more rounds of communication. I'm going to grab this issue because I ran into which I think is related, so I'll fix both.
Right now only the helper's output share for a batch of reports is encrypted to the collector. We previously agreed that all input shares should be encrypted to the corresponding aggregator (URL). It makes sense to encrypt the leader's output share for the same reasons we discussed there. Along the way, the message format should be made to accommodate multiple helpers, as we did for the input shares.
Fixed in . Making "the message format [...] accommodate multiple helpers" is specifically tracked in and resolved by .

Discussion:
"helper_url": The helper's endpoint URL. "collector_config": The HPKE configuration of the collector <del> (described in key-config).  [OPEN ISSUE: Maybe the collector's HPKE config should be carried by the collect request?] </del> <ins> (described in key-config).  Putting the collector's HPKE configuration directly in "struct PPMParam" absolves collectors of the burden of operating an HTTP server.  See #102 [1] for discussion. </ins> "batch_size": The batch size, i.e., the minimum number of reports that are aggregated into an output.

same PPM task.  [[OPEN ISSUE: And the same batch, right?]] Let "[helper]" denote "Param.helper_url", where "Param" is the PPM <del> parameters structure associated with"AggregateReq.task.id".  The </del> <ins> parameters structure associated with "AggregateReq.task.id".  The </ins> leader sends a POST request to "[helper]/aggregate" with the following message:

out-of-order sub-requests by ignoring any sub-request that does not follow the previous one (See anti-replay.) <del> The response consists of the helper's updated state and a sequence of </del> <ins> The response is an HTTP 200 OK with a body consisting of the helper's updated state and a sequence of </ins> , where the i-th sub-response corresponds to the i-th sub-request for each i.  The structure of each sub-response is specific to the PPM

public key: where "pk" is the HPKE public key encoded by the collector's HPKE key <del> configuration and "output_share" is its serialized output share. This encryption prevents the leader from learning the actual result, as it only has its own share and not the helper's share, which is encrypted for the collector. </del> <ins> configuration, "server_role" is the role of the server ("0x01" for the leader and "0x00" for the helper) and "output_share" is the serialized "OutputShare".  "task_id", "batch_start" and "batch_end" are obtained from the "OutputShareReq".  This encryption prevents the leader from learning the actual result, as it only has its own share and not the helper's share, which is encrypted for the collector. The helper response to the collector with HTTP status 200 OK and a body consisting of the following structure: </ins> <del> It responds with the following message: </del> <ins> "collector_hpke_config_id" is "collector_config.id" from the "Param" corresponding to "CollectReq.task_id". "enc" is the encapsulated HPKE context, used by the collector to decrypt the output share. "encrypted_output_share" is an encrypted "OutputShare", whose structure is given below. </ins> The leader uses the helper's output share response to respond to the collector's collect request (see pa-collect).

leader may already have computed the results and can return them immediately.  In either case, once the leader has obtained the helper's encrypted output share for the batch, it responds to the <del> collector's request with the CollectResp message: </del> <ins> collector's request with HTTP status 200 and a body consisting of a CollectResp message: </ins> [[OPEN ISSUE: What happens if this all takes a really long time.]] [TODO: Decide if and how the collector's request is authenticated.] <del> [[TODO: Define the fields]] </del> <ins> "leader_share" and "helper_share" are "EncryptedOutputShare"s as described in output-share-request, except that the "task_id", "batch_start", and "batch_end" used to encrypt the "OutputShare" are obtained from the "CollectReq". </ins> <del> [[OPEN ISSUE: change this to just have a list of shares </del> <ins> [[OPEN ISSUE: change CollectResp to just have a list of shares </ins> https://github.com/abetterinternet/prio-documents/issues/112]] [OPEN ISSUE: Describe how intra-protocol errors yield collect errors

participants know that at least one aggregator is defective, and it may be possible to identify the defector (i.e., if a majority of runs agree, and a single aggregator appears in every run that disagrees). <del> See #22 [1] for discussion. </del> <ins> See #22 [2] for discussion. </ins> 6.7.

10.1.  URIs <del> [1] https://github.com/abetterinternet/prio-documents/issues/22 </del> <ins> [1] https://github.com/abetterinternet/prio-documents/issues/102 [2] https://github.com/abetterinternet/prio-documents/issues/22 </ins>