ensuring consecutive openid4vp requests are opened in the same wallet

[Sakurann]

I think it is related to a PR 175 and especially a discussion here

QES use-case in LSP POTENTIAL has a use-case where they want to do two consecutive requests that need to end up in the same wallet (can be two openid4vp requests of openid4vp and siopv2).

The original thinking was the user enters their mobile number on a webpage and then the wallet gets a notification and the user continues there. which is possible and can happen outside the protocol steps, but it does not solve the problem of "the same wallet" since there is no deeplink for the second openid4vp/siopv2 request that will guarantee the same wallet as in step 1 will open.

One way to really solve this problem could be, in the response to the first request, return wallet's deeplink, that can be used to formulate a second request, targeting it to a specific wallet. Is this feasible? has anyone faced similar questions?

[jogu]

Intuitively returning the wallet's deeplink seems like an obvious solution if custom schemes are in use to invoke the wallet. I think it probably leaks information about the user (which wallet they are using) so the verifier probably needs to explicitly request this and the wallet collect user consent for sharing it.

If the browser API is being used to invoke the wallet I'm not sure it's a good solution and it might be preferable if the browser API can return an opaque & ephemeral wallet identifier with credentials, that can be used in a subsequent invocation of the API.

[Sakurann]

Here is a sequence diagram that is envisioned in QES use-case

[jogu]

Interesting. I think it may be as much 'same credential' as it is 'same wallet'? For the browser API cases we probably want to ask the browser people what they'd be comfortable with. As I mentioned in my previous comment I'm not sure returning a deep link is a good solution when the browser API is in use as it means the user gets a potentially very different user experience for the second invocation of the wallet which may confuse them.

[Sakurann]

what if browser API is not used in which case returning deeplink feels like a natural option? i think these implementers are looking into using vanilla openid4vp.

and for browser api, it will probably be two consecutive browser API calls, if necessary - not the best UX, but also not the worst probably.

[jogu]

Yes, if using custom schemes deep link feels right like I said above:

Intuitively returning the wallet's deeplink seems like an obvious solution if custom schemes are in use to invoke the wallet. I think it probably leaks information about the user (which wallet they are using) so the verifier probably needs to explicitly request this and the wallet collect user consent for sharing it.