Add a mechanism for a wallet to detect cross-device flows

[awoie]

Wallets that want to actively reject cross-device flows have no reliable mechanism to detect whether the request was received from a cross-device channel. For example, a camera app on the mobile phone might scan a QR Code displayed on a desktop browser, invoking the wallet with an OID4VP authz request.

An easy solution might be that verifiers can include a dedicated parameter in the OID4VP authz request or request object to indicate the flow is cross-device. Wallets could then choose to reject the authz request based on the presence of the parameter.

[jogu]

It feels like a security control, and an additional parameter in an unsigned request doesn't feel appropriate due to the easy of adding/removing any additional parameter.

Even for a signed request it would be trivial to capture the url intended for a same-device flow and encode it into a qr code.

I'm not really sure there's a way to do this...

[peppelinux]

This issue could be addressed with a discovery page, where the RP asks to the user if the navigation is made with a smartphone or with a workstation/laptop

in this scenario the user would select the flow

this could be automatically inspected using Device Detector libraries for producing an hybrid approach, where the discovery page would have a timeout after which the automatic detection would automatically select the flow.

here an trivial wrapping of a device detection support: https://github.com/italia/eudi-wallet-it-python/blob/dev/pyeudiw/tools/mobile.py#L4

[awoie]

It feels like a security control, and an additional parameter in an unsigned request doesn't feel appropriate due to the easy of adding/removing any additional parameter.

Even for a signed request it would be trivial to capture the url intended for a same-device flow and encode it into a qr code.

I'm not really sure there's a way to do this...

If we assume the RP is trusted then it could help to include such a parameter in the request. It does not prevent cases where malicious parties are in the mix, I agree but that is not necessarily the goal of such a mechanism.

[awoie]

This issue could be addressed with a discovery page, where the RP asks to the user if the navigation is made with a smartphone or with a workstation/laptop

in this scenario the user would select the flow

this could be automatically inspected using Device Detector libraries for producing an hybrid approach, where the discovery page would have a timeout after which the automatic detection would automatically select the flow.

here an trivial wrapping of a device detection support: https://github.com/italia/eudi-wallet-it-python/blob/dev/pyeudiw/tools/mobile.py#L4

For this you would need an additional click, right? It would be good to have a mechanism that does not impact UX.

[peppelinux]

For this you would need an additional click, right? It would be good to have a mechanism that does not impact UX.

that's why I'd love to produce a page that say "Please select the device you're using, otherwise this will be automatically selected in the next 5 seconds ...". 5 seconds waiting removes the click.

Please share alternative vision and solution, this is still an open issue.

[awoie]

For this you would need an additional click, right? It would be good to have a mechanism that does not impact UX.

that's why I'd love to produce a page that say "Please select the device you're using, otherwise this will be automatically selected in the next 5 seconds ...". 5 seconds waiting removes the click.

Please share alternative vision and solution, this is still an open issue.

If the RP is trusted, we could include an additional parameter in the Authz Request. This obviously does not work in malicious RP scenarios which does not have to be the goal.

[awoie]

Btw. this mechanism would prevent cross-device flows probably entirely: #65. It would be good to discuss in one of the WG calls.

[jogu]

Btw. this mechanism would prevent cross-device flows probably entirely: #65. It would be good to discuss in one of the WG calls.

I don't see how it does, but I particularly don't see how it allows the wallet to reject cross device flows.

(It possibly prevents cross device flows with some RP architectures, but the RP can already prevent cross-device flows anyway?)

[awoie]

Btw. this mechanism would prevent cross-device flows probably entirely: #65. It would be good to discuss in one of the WG calls.

I don't see how it does, but I particularly don't see how it allows the wallet to reject cross device flows.

(It possibly prevents cross device flows with some RP architectures, but the RP can already prevent cross-device flows anyway?)

The RP always can but the wallet cannot detect whether it is in a cross-device flow. That is the issue.

[jogu]

Agreed, but I don't see how the proposal in #65 would allow the wallet to detect cross device.

[awoie]

Agreed, but I don't see how the proposal in #65 would allow the wallet to detect cross device.

IMO, it would prevent cross-device, and the wallet would be able to actively orchestrate that by providing the HKDF components. Perhaps I'm missing something?

[David-Chadwick]

@awoie This might seem like a silly question, but why would a wallet want to prevent a cross device flow? After all the user is in control of their wallet and decides which credentials to present to which RP.

[awoie]

@awoie This might seem like a silly question, but why would a wallet want to prevent a cross device flow? After all the user is in control of their wallet and decides which credentials to present to which RP.

Because cross-device flows are considered less secure than same-device flows. A wallet might generally reject such requests based on their threat protection levels. But at the moment the wallet has no way of detecting or actively preventing cross-device. I'm not saying cross-device flows are not useful in a lot of cases.

[jogu]

Agreed, but I don't see how the proposal in #65 would allow the wallet to detect cross device.

IMO, it would prevent cross-device, and the wallet would be able to actively orchestrate that by providing the HKDF components. Perhaps I'm missing something?

So I think you're saying not that the wallet can detect it's cross device, but that the RP won't be able to decrypt, if the wallet is sufficiently strict about what redirect_uri it allows to be returned ?

My belief is it doesn't prevent the RP from implementing cross devices flows. The verifier could still make the flow work; all it has to do is use the response_code to retrieve the response?