[ready-for-PR] OID4VP session identification for same device flow

[David W Chadwick]

In the same device flow the RP sends the request for a VP to the browser which redirects it to the wallet. The request contains a redirect_uri for the wallet to return the vp_token to (via the browser). However, if the RP has several users (wallets) talking to it at once, the redirect location needs to know which wallet/session this response refers to. The RP can start to inspect the vp_token and find the nonce that is embedded in it. But what if the RP uses a backend verifier service that does all the VP/VC verification work for it? The RP simply needs to know which session (i.e. which nonce) this response applies to without digging into the vp_token to find it. Our implementors have suggested that the response should contain the nonce at the top level, as well as being buried in the vp_token somewhere. Two alternatives are suggested, which are the same as the suggestions in the response mode post issue#1717. The response can either have a header authz bearer token containing the nonce, or the response can in addition contain the nonce in an additional parameter “&nonce=<nonce value>”. The RP can indicate to the wallet which of these it prefers by either including the nonce as a query parameter of the redirect_uri (meaning it should be a parameter of the response) or saying nothing (meaning that it should be in the authz header bearer token).

[Joseph Heenan]

Isn’t this just a classic OAuth flow - so the RP can record the session in cookies (or other mechanisms for storing state)?

[David W Chadwick]

I don’t know as I am not a developer. But given that the redirect_uri can be to anywhere (I assume) then can cookies always be used?

[Joseph Heenan]

The redirect_uri is always back to the RP that originated the flow for security reasons, so cookies can always be used.

[Nikos Fotiou]

I believe this is what the “state” parameter is used for in oauth (and openid connect core) https://www.rfc-editor.org/rfc/rfc6749#section-4.1.1 (https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest)

[gffletch]

+1 for using the “state” parameter

[Torsten Lodderstedt]

+1 for using state for that purpose

[Joseph Heenan]

Just to check, are people:

1. Suggesting that a state parameter already exists in OID4VP
2. Suggesting that we add a state parameter?

I’m not convinced that ‘1' is true. Certainly state doesn’t seem to be mentioned anywhere, not even in the examples.

(PKCE very possibly deserves some kind of mention too, assuming that can/should be used when the response is returned from the token endpoint.)

[Torsten Lodderstedt]

I certainly mean (1). OpenID4VP is OAuth and thus already has state.

[David W Chadwick]

(1) is by implication, but not by explicitly stating it. (Cf. the confusion over the client_id in OID4VCI - again an implication that it was mandatory, but by not saying anything about it, an assumption was made that it could be omitted. The result now is to explicitly state that is it optional for the pre-auth flow.)

So I would suggest that we explicitly state (no pun intended) something about the ‘state’ parameter for both the same device and cross device flows.

[Torsten Lodderstedt]

that’s fine - we can mention it as kind of an implementation consideration

[Kristina Yasuda]

+1 to using state. we already use state for this kind of purpose, I would be pretty against externalizing nonce outside the holder’s signature.

[Michael Jones]

We discussed this on the 8-Dec-22 SIOP call. We suggest creating a PR to describe using state to achieve this.

[Kristina Yasuda]

PR #495

[Kristina Yasuda]

PR merged.