[Openid-specs-ab] Issue #1797: [OID4VP 1_0-14] Direct POST - improving the security by defining the redirect after the direct_post (openid/connect)

[alen_horvat]

New issue 1797: [OID4VP 1_0-14] Direct POST - improving the security by defining the redirect after the direct_post
https://bitbucket.org/openid/connect/issues/1797/oid4vp-1_0-14-direct-post-improving-the

Alen Horvat:

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?

‌

HL sequence diagram: [https://www.plantuml.com/plantuml/txt/TP4nR\_8m48Rt\_8gRs9mWlc-AI0fYwTQKHdH1GYO-mCAntVCbWVxwEgbKbQ7R9NVF-vpEgy2Ik6jDalXOw4PxQHdUfJ7880CC3\_ztIFgaaSPEdoH50P6tIf82fzN\_taDH90Ci1VGvFDTr1V\_c2t04hrjed49OhZk-ED91idOMjlZHOU0oCgA48OSDeMG42Rig2\_fiipHD9q-rtWgZhmZQCf9iHZpA9l17LhsyrR0aL9gmuRGZK-xjnaN2igZl7dEGtXlTJFRi9ePX42T7hOYZQCSDrTvwmX21QUOGkcEhGuXb4LUPzVx0xehJHqB87TblzM8-XzWS8uhR\_VFlsuZouJONPX\_oB6kCZiuKRxBr1bD7vwmvFlrAdCKqnicRhD2g-6PV](https://www.plantuml.com/plantuml/txt/TP4nR_8m48Rt_8gRs9mWlc-AI0fYwTQKHdH1GYO-mCAntVCbWVxwEgbKbQ7R9NVF-vpEgy2Ik6jDalXOw4PxQHdUfJ7880CC3_ztIFgaaSPEdoH50P6tIf82fzN_taDH90Ci1VGvFDTr1V_c2t04hrjed49OhZk-ED91idOMjlZHOU0oCgA48OSDeMG42Rig2_fiipHD9q-rtWgZhmZQCf9iHZpA9l17LhsyrR0aL9gmuRGZK-xjnaN2igZl7dEGtXlTJFRi9ePX42T7hOYZQCSDrTvwmX21QUOGkcEhGuXb4LUPzVx0xehJHqB87TblzM8-XzWS8uhR_VFlsuZouJONPX_oB6kCZiuKRxBr1bD7vwmvFlrAdCKqnicRhD2g-6PV)

1. The client obtains an authorisation request \(to share one or more VCs\) - the request contains a nonce
2. Wallet constructs one or more VPs \(with nonce included\)
3. Wallet makes a direct POST to the Verifier’s endpoint
4. 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?