[OpenID4VP] Friendly MITM
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?
Comments (3)
-
-
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.
-
reporter - changed status to closed
Agree that " I don't see any current way of technically stopping this, only legal ways."
- Log in to comment
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.