Clarify what successfully processing a response means (direct_post)

[javereec]

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.

[babisRoutis]

@javereec For me the issue is perhaps more generic.

Paragraph 6.2 Response Mode "direct_post" puts the emphasis on how to assemble a authorization request that uses direct_post response mode.

In addition to that, I was expecting to find a description of the newly introduced endpoint (for instance a paragraph titled Direct Post Endpoint), to be provided/implemented by the Verifier, with sub-paragraphs describing the request and the response of this end-point.

Especially for the error response (of this Direct Post endpoint), I agree with you that a description is absent from the spec, which practically means that if response is not 200 presentation stops.

With regards to re-submission, I see two possible problems:

• The URL of the Direct Post endpoint (communicated via response_uri), in general, is not static.
• In case of direct_post.jwt perhaps a fresh ephemeral key is required (communicated via verifier metadata within the auth request).

Perhaps, it is more easy to just re-execute the presentation instead of defining re-submission.

[jogu]

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).

I'm not sure I'm understanding what kind of flow is being thought about here. For example I would expect a wallet to check if a credential is expired before supplying it, so I wouldn't really expect a flow like this:

direct_post error -> check if credentials are expired -> get reissued credentials -> send credentials to wallet again type flow.

Or at least I think we would need to define a set of error codes that give the wallet a hint what to do? What errors did you define in your implementation?

[Sakurann]

I think there are multiple things here... I think one is "what to do if the verifier received a response and everything is correct at the protocol level, but something is wrong with the credential (for example, it is expired) so the verifier wants to ask the wallet to re-submit it" - i don't think there is a way to do so at the protocol level, and the best that the verifier can do is to start the flow from the beginning unfortunately..

I think another thing here is "better define validation rules and error codes for response (not just direct_post I think?)", which we should totally do.

[Sakurann]

@javereec to outline concrete proposal for a processing rules