Clarify what successfully processing a response means (direct_post)

This assumes response mode direct_post and the following clause in the OpenID 4 VP spec (Section 6.2)

If the Response Endpoint has successfully processed the request, it MUST respond with HTTPS status code 200.

The word successfully does a lot of the heavy lifting and is open for interpretation

Imagine the following: A wallet posts a response, the response is structurally correct and the submission requirements meet the definition. But, the verifier notices that the credential is expired, or claim values do not match the functional needs, etc, and for this (imaginary) case this is not acceptable.

I believe that there are two options here

1. Return 200 (w. redirect_uri)
2. Return 400 (w. an error response and redirect_uri (and potentially other attr to allow resubmit))

I believe it is reasonable to assume that the Wallet receives 400 from the Response Endpoint, allowing for the possibility to correct and re-submit with different credentials (or whatever the case may be). If 200 is always returned, it is more difficult to make the distinction between a success state and one that is not from the perspective of the Wallet. At least, this is what we have experienced during our implementation.

Review OpenID 4 VP Section 6.2 and the direct_post response behavior described in the issue. Clarify what “successfully processed” means when submissions are structurally valid but unacceptable to the verifier, and define when the Response Endpoint returns 200 or 400. Done means the specification provides unambiguous wallet-visible outcome semantics.