Multiple parallel requests

[troyronda]

As discussed in the EDV WG call, we would like to create and update several documents to a backing EDV from a Web Wallet while minimizing user visible latency (and server overhead). In general terms, we want to perform those operations in bulk.

The authorization scheme is ZCAPs and HTTP signatures. i.e., each HTTP call to the EDV is signed. The Web Wallet runs in the browser and leverages a KMS server to protect signing keys.

Solutions Discussed:

• Explicit bulk API in EDV.
• "Simulate" (see below).

The explicit Bulk API addresses the problem by reducing the number of calls (and, hence, signatures, round-trips, and overhead). The EDV server is also explicitly aware of the bulk nature of the operations (and may choose to more directly treat them as bulk to its own backend).

Without an explicit Bulk API, the mentioned strategy is:

• Require HTTP/2 to leverage multiplexing to the EDV server (implying that the client should parallelize the HTTP calls that it knows should be done in bulk).
• Ensure that each individual HTTP Signature can be created quickly. In the discussion, the example was to use an ephemeral ed25519 signing key in the Web Wallet running in the browser.

This non-explicit strategy also raises the topic about handling the requirement for HTTP/2 in the spec.

[dmitrizagidulin]

Discussed on the May 27, 2021 call.

Next steps: Issue stays open (as long as the 'at risk' link mentions it, in the spec).

Question: How should the group decide, long-term, whether a batch API is necessary, or if the parallel request use case can be solved in other ways?

• Need performance data (write performance using batch API, vs using parallel writes)
• It may be that some implementations will want to implement a /batch API anyway

[DRK3]

Another item to discuss eventually is the operation syntax