Wallet Presentation Response Mixup

After receiving a presentation, the verifier sends back a 200 response according to "8.2. Response Mode "direct_post"":

If the Response URI has successfully processed the Authorization Response or Authorization Error Response, it MUST respond with an HTTP status code of 200 with Content-Type of application/json and a JSON object in the response body.

Two remarks can be given at this position:

1. Consider a wallet that has 2 protocol runs with the same verifier. The wallet (or browser, in the case of relayed requests) can use the same TLS session to communicate with the verifier for both requests. When the verifier returns a response (accepting or declining the authorization response) to any one of the requests, an attacker in control of the network can redirect it to or reuse it for any request using that same TLS session.
   A real-world example is the user choosing the wrong credential for the presentation, then returning to the credential selection page, and sending a second Authorization Response.

• Possible Mitigations:
  Introducing presentation tokens/nonces: freshly generated tokens/nonces are sent along with the (verifiable) presentation and must be returned by the verifier's response to the Authorization Response request.
  Adding session restrictions: add a requirement stating that the verifier may only accept one Authorization Response per session.

2. (lesser important) The mention of a mandatory response, to confirm the receiving and successful validation of the (verifiable) presentation, is missing outside the scope of "Response mode: direct post"

Start with OpenID4VP section 8.2, Response Mode direct_post, and trace the two protocol-run scenarios described in the issue. Compare the specification's response requirements with the proposed token/nonce and session restrictions; done means the mix-up risk and the missing response requirement have a settled specification change.