Signed Requests and Replay Prevention

[OIDF-automation]

Imported from AB/Connect bitbucket: https://bitbucket.org/openid/connect/issues/1807

Original Reporter: tlodderstedt

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.

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: mbj

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

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: tlodderstedt

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.

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: KristinaYasuda

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

‌

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: KristinaYasuda

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

[awoie]

Related to #52 #59

[Sakurann]

PR #59 introduced wallet nonce, so closing as resolved. cc @tlodderstedt @jogu