[OID4VP 1_0-14] Direct POST - improving the security by defining the redirect after the direct_post
Issue #1797
resolved
Context: In many cases size of the VP will exceed the URL char limit, so one needs to use the direct post in the same-device flow. Direct post, as described in the current specification, lowers the security;
This issue is about a potential improvement of the: OpenID for VP; same-device flow with response_mode=direct_post
Question/Comment: is there any benefit in terms of security if we, after a direct_post, receive a token as a response (from the direct_post method) and perform a 302 redirect back to the verifier?
- The client obtains an authorisation request (to share one or more VCs) - the request contains a nonce
- Wallet constructs one or more VPs (with nonce included)
- Wallet makes a direct POST to the Verifier’s endpoint
- Wallet receives a “code” and “state” (or access token) as a response it can use to redirect to the Verifier’s website
Potential complication: how can the verifier know whether to expect a redirect or not?
Comments (3)
-
-
I also think this is a duplicate issue of
#1713. -
- changed status to resolved
PR #489 merged
- Log in to comment
This sounds similar to Pushed Authorization Response Mode
#1611idea.