I'm reading through the bidding and auction server document and I'm coming up short on the protocol interaction here.

The overall flow here is something like:

1. a seller initiates an auction in the browser
2. the browser gathers the information necessary for the auction, determines that this needs to be run on a server, so it bundles that data and encrypts it toward the server
3. the site receives the encrypted bundle, which it forwards to the server
4. the server executes the auction, which is a non-trivial action that we can gloss over in this case
5. the server returns a response, which is encrypted toward the browser (going back in time, it is obvious here that the browser needs to embed information in its encrypted blob so that the server can respond; the OHTTP mention now becomes clear)
6. the site receives the encrypted response and passes it to the browser
7. the browser decrypts the bundle and extracts the result that was generated by the server

The adAuctionHeaders parameter to a fetch seems to exist to tell the browser that this fetch includes one of these encrypted request blobs. Similarly, an Ad-Auction-Result field in a response seems to exist to tell the browser that this is a response to a specific encrypted request. Neither seems necessary.

If the browser initiates the interaction, then it can internally track the interactions it initiated and recognize responses to any open request it previously made.

Request-response matching is not something that the OHTTP encryption scheme includes, but it is fairly simple to add. A simple method would be to attach (and authenticate!) a request ID to requests, which the server is required to echo in responses. I don't see any reason to encrypt this identifier, because there should be a fresh key share used for each interaction that would make it impossible to misdirect a response. A misdirected response would simply fail to decrypt.

The only question is the scope over which a response might be recognized. It might be useful to have a short term memory that persists across same-origin navigations, but given the context, it might be possible to make the state ephemeral.