Signed Requests and Replay Prevention

Issue #1807 resolved
Torsten Lodderstedt created an issue

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)

  1. Michael Jones

    I don’t understand why making a second request with the same parameters as the first constitutes an attack.

  2. Torsten Lodderstedt 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.

  3. Kristina Yasuda

    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

  4. Log in to comment