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: https://github.com/openid/OpenID4VP/issues/65. It would be good to discuss in one of the WG calls.

[jogu]

Btw. this mechanism would prevent cross-device flows probably entirely: https://github.com/openid/OpenID4VP/issues/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?

[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?

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?

I believe you are right, #65 does not prevent cross-device. I must have confused something.

[David-Chadwick]

@awoie

Because cross-device flows are considered less secure than same-device flows.

I think that if a trust framework is present then this is not correct. Regardless of how the wallet learnt about the identity of the RP, this should not affect the operation of the trust framework. However if there is no trust framework available to the wallet, then all bets are off as to the identity and trustworthiness of the RP.

[tplooker]

This isn't a trust framework issue @David-Chadwick from a protocol security perspective there are different security properties associated to a cross device flow vs a same device flow. The wallet may want to block responding to a cross device flow because of this. A trust framework doesn't help here.

[David-Chadwick]

Please explain what the end result of these different security properties are, and then we can determine if this is a trust framework issue or not

[jogu]

The insecurities of cross devices flows (as described in https://www.ietf.org/archive/id/draft-ietf-oauth-cross-device-security-05.html ) are completely unrelated to the trust framework.

[David-Chadwick]

Sorry but I am struggling to see how the above IETF draft applies to the VP case. The wallet (as Authz server) is returning the VP token to the RP, so that the user can access a resource of the RP. The trust framework is used to determine if the RP is trusted enough to be sent the VP to it.

[jogu]

The RP is trusted in all these scenarios.

https://www.ietf.org/archive/id/draft-ietf-oauth-cross-device-security-05.html#section-5 might be the best place to start in that doc.

The issue is whether the session at the trusted RP that the credential is delivered to is the one the user intended or not. That's an issue that's unique to the cross device flows.

[David-Chadwick]

So if I am understanding you correctly, the user goes to an RP web site, X, on his laptop, and his smartphone scans in a displayed QR code which tells the wallet that the RP is Y. The user does not see that Y is different to X, but Y is trusted anyway, so the wallet sends the VP to Y, and then the user goes back to his laptop and gains access to the resources at X. Is this the problem you are trying to solve?

[jogu]

I don’t think you can describe the problem without using the word “attacker” at least once.

[jogu]

Something like this would be one example:

1. the user goes to a web site, X, on his laptop
2. his smartphone scans in a displayed QR code which is a valid request obtained from RP Y by the attacker
3. The user does not see that Y is different to X, but Y is trusted anyway, so the wallet sends the VP to Y
4. The attacker now has access to the resources at Y as the user

[David-Chadwick]

Accepted. What about an alternative scenario in which site X does not want to handle any user PII or get involved in data protection issues, so it uses a third party service Y to authorise users for it. In this case X tells the user that Y will be acting on its behalf so the user expects to send its VP to Y in order to gain access to X's resources. If you implement a feature to prevent cross device flows then you would be preventing this use case as well, wouldn't you?

[jogu]

I don't think anyone has come up with a way to block cross device flows that also prevents an attacker using a cross device flow, so the question of whether it would block a particular scenario is an unknown. :)

@awoie's suggestion blocks cross device for legitimate users but leaves it open for attackers to still use cross device, I'm not sure I see the utility in doing that.

[awoie]

I don't think anyone has come up with a way to block cross device flows that also prevents an attacker using a cross device flow, so the question of whether it would block a particular scenario is an unknown. :)

@awoie's suggestion blocks cross device for legitimate users but leaves it open for attackers to still use cross device, I'm not sure I see the utility in doing that.

Implementing #65 would at least help with managing the underlying risks:

• An RP that wants to mitigate session fixation/phishing could implement this feature
• A wallet requiring this risk mitigation would provide the HKDF salt in the redirect on their mobile phone/browser; without this salt, an attacker won't be able to trick the victim to present the credentials into the attacker's session.

It would not help with RPs that are intentionally malicious, e.g., user visits a malicious website accidentally, and the request itself is generated by the malicious RP.

@jogu would you agree?

[awoie]

I don't think anyone has come up with a way to block cross device flows that also prevents an attacker using a cross device flow, so the question of whether it would block a particular scenario is an unknown. :) @awoie's suggestion blocks cross device for legitimate users but leaves it open for attackers to still use cross device, I'm not sure I see the utility in doing that.

Implementing #65 would at least help with managing the underlying risks:

• An RP that wants to mitigate session fixation/phishing could implement this feature
• A wallet requiring this risk mitigation would provide the HKDF salt in the redirect on their mobile phone/browser; without this salt, an attacker won't be able to trick the victim to present the credentials into the attacker's session.

It would not help with RPs that are intentionally malicious, e.g., user visits a malicious website accidentally.

@jogu would you agree?

Under the assumption that the request is signed and cannot be tampered with.

[jogu]

A wallet requiring this risk mitigation would provide the HKDF salt in the redirect on their mobile phone/browser; without this salt, an attacker won't be able to trick the victim to present the credentials into the attacker's session.

I don't think this is always true, it very much depends how the RP is treating the flow and how we define 'session'. Only if the flow continues on the mobile device (rather than returning to the session potentially becoming to an attacker on a desktop) does it provide a benefit, and that same benefit can be achieved without this change.

It would not help with RPs that are intentionally malicious, e.g., user visits a malicious website accidentally, and the request itself is generated by the malicious RP.

It has some interesting properties, but I think fundamentally it has the same issue as the initial suggestion on this issue - it doesn't prevent an attacker from taking the url the user would be sent to by a genuine RP and embedding it into a QR code, so it doesn't prevent cross device flows nor as far as I can see make them more secure.

[awoie]

A wallet requiring this risk mitigation would provide the HKDF salt in the redirect on their mobile phone/browser; without this salt, an attacker won't be able to trick the victim to present the credentials into the attacker's session.

I don't think this is always true, it very much depends how the RP is treating the flow and how we define 'session'. Only if the flow continues on the mobile device (rather than returning to the session potentially becoming to an attacker on a desktop) does it provide a benefit, and that same benefit can be achieved without this change.

It would not help with RPs that are intentionally malicious, e.g., user visits a malicious website accidentally, and the request itself is generated by the malicious RP.

It has some interesting properties, but I think fundamentally it has the same issue as the initial suggestion on this issue - it doesn't prevent an attacker from taking the url the user would be sent to by a genuine RP and embedding it into a QR code, so it doesn't prevent cross device flows nor as far as I can see make them more secure.

I agree that an RP can implement the security considerations on response_code and have an equally secure flow compared to the HKDF proposal.

The difference is that those considerations are non-normative. An RP might implement equal measures using other parameters. A wallet would not know whether an RP implemented additional pre-cautions. Using the HKDF approach, imo, the wallet can actively orchestrate that, forcing RPs to implement those measures.

Also interested what @paulbastian thinks since he was part of the IETF118 session where we discussed this.

[jogu]

That flow definitely achieves something, but I'm not sure it's something that helps secure the cross device flow in particular (I think it helps make the RP implement some checks that benefit both same-device and cross-device).

I think I'm unclear what we actually want to achieve in this issue now. Updating the title of this ticket to reflect what the requirement we want to satisfy now is may help me understand.

[Sakurann]

if the wallet does not want to accept cross-device, the best option is probably not to allow the usage of camera in the app, so that the wallet cannot scan QR code at all (QR code is the only way to start a cross-device flow AFAIK). wallets that also support 18013-5 need to display the QR code, not to read it, so this should work.

regarding #65, the purpose of the mechanism proposed there was to eliminate lazy verifiers who do not do all the validation checks to be able to accept the credential by introducing a mechanism where verifier has to do the checks before being able to decrypt the credential. It was not about wallet knowing whether the flow is cross device or not..

not sure UX is a good way to address this as it won't take longer for the users to figure out that if they press "was not cross-device" button (or an equivalent happens) they can continue the flow even if in reality it was a cross-device flow.

[c2bo]

if the wallet does not want to accept cross-device, the best option is probably not to allow the usage of camera in the app, so that the wallet cannot scan QR code at all (QR code is the only way to start a cross-device flow AFAIK). wallets that also support 18013-5 need to display the QR code, not to read it, so this should work.

Couldn't you still scan the QR code with the default camera app and open the link from there which would invoke the wallet via registered custom URI scheme?

[Sakurann]

need to dig deeper, but i think you can turn off the feature to use the default camera app.

[jogu]

Couldn't you still scan the QR code with the default camera app and open the link from there which would invoke the wallet via registered custom URI scheme?

Yes, exactly, and the wallet would not be able to detect any difference between this case and the same device case.

[jogu]

I've marked this one as pending-close as I don't think we have any proposal on how we could practically do this.

When the browser API (which can securely do cross device flows) is in use it's not really an issue.

If anyone objects to closing please add a comment within 7 days as to practical actions we could take.

[awoie]

Agree that there is no good solution today. The browser API will fix this.

[jogu]

Closing as per previous comments.