openid
Clarify error cases for Authorization Response processing
Clause 8.2 (Response Mode "direct_post") states that
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.
Clarify what happens if the response is not successfully processed.
Clarify what is expected for "direct_post.jwt"
those errors are defined in this section, right? https://openid.github.io/OpenID4VP/openid-4-verifiable-presentations-wg-draft.html#section-8.5
It seems to me that 8.5 defines errors the wallet can return. My question was about errors the Verifier would return when he cannot process the Authorization Response or Authorization Error Response sent by the wallet. The spec mentions only the success case (HTTP 200) and only for direct_post (clause 8.2). How about error cases and cases for other modes (e.g. direct_post.jwt)?
How about error cases and
https://github.com/openid/OpenID4VP/issues/137 is kind of relevant. The verifier may well want to return a 'success' response with a redirect_uri so that the verifier is brought back to the foreground on the user's device and can perhaps fall back to a non-VC based "please photograph your physical driving license" route.
Nobody has so far pointed out any cases where we want the wallet to do something specific as a result of an error from the direct_post endpoint - are you thinking of any of these? If there aren't any of those then it's not really necessary (or at least not urgent) to define the error response for interoperability purposes.
cases for other modes (e.g. direct_post.jwt)?
The direct_post.jwt section builds on top of the direct_post one and I don't think there's any reason for this behaviour to differ between the two.
The issue you pointed is relevant indeed. I see that people assume 400 would be returned in an error case. This should not be assumed but specified. I do not have a specific workflow in mind, that would depend on what went wrong with the response. But there must be some information that goes back to the user after he sends a presentation, the flow cannot just be interrupted like that in an error case. Since the wallet will interact with various verifiers, that is an interoperability issue for me and has consequences on what is displayed to the user.
Regarding direct_post.jwt, I do not agree it is build on top of direct_post. direct_post is clause 8.2 while encrypted responses are clause 8.3 (and 8.3.1). Sometimes in 8.3.1 there are references to 8.2 so this means that everything in 8.2 does not automatically apply. But I do not see something specifically for success / error cases at the verifier side so this is really not clear to me. If we want the same behavior for the verifier in both modes, maybe we could say so explicitly in 8.3.1 or put these explanations in 8.1 saying they apply to both modes.
The issue you pointed is relevant indeed. I see that people assume 400 would be returned in an error case. This should not be assumed but specified. I do not have a specific workflow in mind, that would depend on what went wrong with the response. But there must be some information that goes back to the user after he sends a presentation, the flow cannot just be interrupted like that in an error case. Since the wallet will interact with various verifiers, that is an interoperability issue for me and has consequences on what is displayed to the user.
I think in general (as is kind of hinted at in #137 but we didn't reach a full conclusion) that displaying things to the user is generally the responsibility of the verifier even in the expected unhappy path flows and that the verifier should return a successful response with a redirect_uri if it needs the wallet to redirect back to the verifier so that the verifier can (for example) tell the user what went wrong.
The cases where the wallet would get an error back are I think cases more like "something is broken at the verifier and I can't process this response right now".
I think it would be useful to add your input onto #137, I think we can probably close this issue?
Regarding direct_post.jwt, I do not agree it is build on top of direct_post. direct_post is clause 8.2 while encrypted responses are clause 8.3 (and 8.3.1). Sometimes in 8.3.1 there are references to 8.2 so this means that everything in 8.2 does not automatically apply. But I do not see something specifically for success / error cases at the verifier side so this is really not clear to me. If we want the same behavior for the verifier in both modes, maybe we could say so explicitly in 8.3.1 or put these explanations in 8.1 saying they apply to both modes.
It starts "This specification also defines a new Response Mode direct_post.jwt, which allows for encryption to be used with Response Mode direct_post defined in Section 8.2.". It's clearly building on top of 8.2 and the behaviour is all the same as 8.2 except for the body of the http request having "request=
@jogu I believe that we could indeed tweak a little bit the introduction of that section. I suggest something like "This specification defines a new Response Mode direct_post.jwt, which allows for encryption to be used on top of the Response Mode direct_post defined in Section 8.2. This means that all mechanisms described in 8.2 apply unless specified otherwise."