-
assigned issue to
Signed Requests and Replay Prevention
Signed requests (according to JAR) do not contain a server (wallet) provided nonce. This bears the risk of an attacker replaying such a request in order to impersonate a legit verifier. If the message signature is used to authenticate the client (and present information to the user based on that), the attacker could utilize the request to exfiltrate PII.
In classical OAuth, this risk is mitigated by pre-configured redirect URIs bound to a certain client. With custom schemes and even claimed URLs (on Android), the redirect URI does not longer prevent such attacks. Encrypted responses would be another option, if authentic public keys are used.
I suggest to conduct an analysis whether the original security model of signed request is still appropriate for OpenID4VP.
Comments (7)
-
reporter -
I don’t understand why making a second request with the same parameters as the first constitutes an attack.
-
- changed status to open
-
reporter if the request is sent by an attacker on a different device where the attacker is able to capture the response, the attacker can impersonate the legitimate client. In our context this means, the attacker can trick the user into releasing credentials/claims.
-
SIOP call - WG was looking for more clarification on what is the attack: some comments here:
https://lists.openid.net/pipermail/openid-specs-ab/2023-February/009711.html
-
if the request is signed, the attacker replaying the request cannot change where the response from the wallet is going, so that mitigates the attach you are trying to prevent, right?
so yes, i think it makes sense either to 1/ have a pre-registered combination of client_id and redirect_uri or 2/ have a signed request with means to identify/trust the verifier (even if it is displaying the verifier’s domain to the user and asking the user to consent).
at least above is the conclusion of the discussions in ISO - might be worth having a clarification text
-
- changed status to resolved
Migrated to GitHub
- Log in to comment