[OpenID4VP] Friendly MITM

[Kristina Yasuda]

Do we have a mechanism to prevent “friendly MITM“?

Verifier requested VP1, UserA does not have it, she forwards the entire request to the UserB. UserB creates a VP1 with correct nonce and audience and sends it back to UserA, UserA uses puts that VP1 inside a response and returns to the Verifier.

From the verifier perspective, all is good, right?

[David Waite]

I would expect any protection from ‘friendly’ attacks would be via trust of the ‘attendant’, e.g

• biometric verification by the requesting party’s agent in “attended” cases

• wallet implementations in the “unattended” cases

There are sometimes additional mitigations at the business level against friendly attacks as well - for instance, a ride sharing service who is worried about friends/relatives performing the background check in lieu of the actual risky driver being onboarded can attach ongoing payment (and tax reporting) to that identity.

We have some protocol-level mitigations with the anti-phishing properties of OAuth and OpenID Connect, however that is given up with response_mode=post and QR-based flows.

[David W Chadwick]

Friendly attacks are actually collusion. So they should not be described as friendly, but rather as fraudulent :-). As in the case of e.g. sharing my CC and PIN with my wife, the responsibility lies with the holder of the credential, and they will be liable. In your example, User B is liable and needs to be made aware of this. I don't see any current way of technically stopping this, only legal ways.

[Kristina Yasuda]

Agree that " I don't see any current way of technically stopping this, only legal ways."