Same-device / cross-device differentiation

[patatoid]

I recently implemented OID4VP and found it a great specification enabling identity traits management on top of SIOPV2. For both of those, I had to set at verifier configuration level a switch to define if the flow is same or cross-device which is outside of the flows and is defined for all the holders requesting that specific verifier.

Is there any way to define if the flow is same device or cross-device from the authorization request?

Or may I be mistaken somewhere?

[jogu]

There's nothing like this in the spec currently.

There was some discussion here: #134

Why does the verifier need to know? i.e. what does the verifier do differently if it thinks it's a cross device flow?

[patatoid]

I got it now, the response_mode parameter should be used within the authorization request which should route the verifier to the redirection in the case of same-device or the display of a QR code in the case of cross-device. There is nothing exogenous here.

My mistake may come from the fact that I first implemented siopv2, there were no notions of response_mode in the request and at that time I did not need cross-device. I think the response_mode parameter should also be quoted in siopv2 since it follows the same flow in that case.

Reading #134, I may replace the verifier response_mode configuration to help it restrict the cross-device flows for some verifiers. That said, I am not fully aware of the security issues cross-device may raise.

[bc-pi]

I am not fully aware of the security issues cross-device may raise.

I am also not fully aware of the security issues cross-device may raise but I do know enough to say that they are non-trivial.

[jogu]

I got it now, the response_mode parameter should be used within the authorization request which should route the verifier to the redirection in the case of same-device or the display of a QR code in the case of cross-device. There is nothing exogenous here.

The response_mode isn't really exclusive to cross-device, you can use it on same device too. The main reason for using direct_post (or direct_post.jwt) response_mode is if the response is too big to fit in a url in all cases (and responses with mdocs or multiple credentials in them do get large!). (direct_post can also over security benefits as it means the response doesn't pass through the browser, so can avoid the need to use encrypted responses in some security models.)

That said, I am not fully aware of the security issues cross-device may raise.

Cross device security isn't great for native oid4vp, using the browser API is a much better solution. Myself & Daniel did a talk about this at identiverse, though unfortunately they didn't record the slides... https://www.youtube.com/watch?v=NWZJHxch7Dk&list=PLpKq7xRiIHaTnED9dAIusB4ffM_b8iyM4&index=21

[patatoid]

The response_mode isn't really exclusive to cross-device, you can use it on same device too.

I took the response_mode as a discriminant to determine if the request is same device or cross device, am I wrong somewhere?

[jogu]

I took the response_mode as a discriminant to determine if the request is same device or cross device, am I wrong somewhere?

I'm a bit confused to be honest as to who is trying to detect a cross device flow and at what stage and for what reason?

There is no way for a wallet to know if a flow was initiated on the same device or another device.

For the most part, when a verifier receives the final response (e.g. gets a direct_post, returns a redirect_uri and then that redirect_uri is opened) the verifier can at least detect if this final response arrived in the same browser session the request was initially started from by checking if relevant cookies are present. Even then the lack of cookies doesn't mean it's a cross device flow, as it may have arrived on the same device but (for example) in a different browser.

[patatoid]

I saw the same device / cross device distinction made at the entry point of the oid4vp flow displaying a QR code or redirecting to the wallet as a response to the authorize step.

I'm a bit confused to be honest as to who is trying to detect a cross-device flow and at what stage and for what reason?

I think the flow is a two partite relationship between the wallet and the verifier. The point is to know if the verifier user-agent is on the same device as the wallet or if the wallet is on another device, for desktop user-agents for example. the final response should be to notify the wallet of the successful or not presentation.

If there are cookies, the configuration may be stateful which may not be intended in the flow, I am not sure if we should make use of them (I do not with my implementation).

[awoie]

I saw the same device / corss device distinction made at the entry point of the oid4vp flow displaying a QR code or redirecting to the wallet as a response to the authorize step.

I'm a bit confused to be honest as to who is trying to detect a cross-device flow and at what stage and for what reason?

I think the flow is a two partite relationship between the wallet and the verifier. The point is to know if the verifier user-agent is on the same device as the wallet or if the wallet is on another device, for desktop user-agents for example. the final response should be to notify the wallet of the successful or not presentation.

If there are cookies, the configuration may be stateful which may not be intended in the flow, I am not sure if we should make use of them (I do not with my implementation).

For the wallet, there is no way to detect whether they are in a cross-device flow. See #134 which should be closed already. The Browser API will fix the risks associated with cross-device and for now, the wallet has to trust the verifier implements all recommended OID4VP security considerations.

[patatoid]

I came back to the same / cross-device considerations implementing a demo wallet that is browser-based. When I trigger the same device flow, the redirection is made from the verifier to the wallet on the authorize step but comes to a dead-end since the wallet has no clues about the place to redirect the user after a successful presentation (I tested with SIOPV2).

I found a solution by displaying a target="_blank" link instead of the redirection in response to the authorize request, using SSE, the displayed authorize page can react to the successful presentation and redirect to the relying party in my case where the verifier is not the same application as the relying party.

Does anyone found other solutions to the dead-end problem?

[jogu]

We seem to be discussing similar issues again on #329 - I suggest closing this in favour of 329 as there doesn't seem to be any actionable suggested change to the specification here.

[Sakurann]

pending-close for 1 week.