Enhancing Privacy by Not Notifying Relying Party of Faulty Requests

[peppelinux]

Context

The current OpenID4VP specification outlines various error responses that a Wallet Instance may return to the Relying Party (Verifier) in case of faulty requests (Section 6.4. Error Response). These include errors like invalid_request, invalid_client, access_denied, and more specific errors related to presentation definitions and formats.

Suggestion

For privacy enhancement, it is suggested that the specification includes a recommendation or requirement that Wallet Instances should not notify the Relying Party of faulty requests in certain scenarios. This is to prevent any potential misuse of error responses that could exploited.

Justification

Faulty requests from a Relying Party could inadvertently reveal information about the user preferences or guessing Wallet Instance's vulnerabilities. By limiting the information returned in error responses, especially in cases where the request could be malformed or suspicious, we can enhance user privacy and reduce the risk of information leakage.

Proposed Change

Add a section or note in the Error Response (Section 6.4) to address the following:

• Recommend or require Wallet Instances to suppress error notifications to the Relying Party in specific scenarios where privacy concerns outweigh the benefits of detailed error reporting.
• Provide guidelines on which errors should be handled internally without notifying the Relying Party, focusing on scenarios that could lead to privacy risks.

This change aims to strike a balance between informative error handling for legitimate debugging purposes and privacy preservation for end-users.

[Sakurann]

Could you please provide more examples on specific scenarios where privacy concerns of the error response from the wallet (invalid_request, invalid_client, access_denied, etc) outweigh the benefits of the error message?

[jogu]

In general in OAuth2 it is a common choice not to redirect back to the oauth client in the case of invalid requests (i.e. the error is displayed to the user instead). There are various reasons for this, some inspired by https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics#section-4.11.2

That's probably a better thing to suggest in any privacy sensitive cases, and means a useful error could still be displayed to the user to aid in diagnosing failed flows.

[awoie]

In general in OAuth2 it is a common choice not to redirect back to the oauth client in the case of invalid requests (i.e. the error is displayed to the user instead). There are various reasons for this, some inspired by https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics#section-4.11.2

That's probably a better thing to suggest in any privacy sensitive cases, and means a useful error could still be displayed to the user to aid in diagnosing failed flows.

I guess this relates also to the following situation:

• A wallet receives a signed request object but trust validation fails, i.e., the public key to verify the signature does not match, or the client is generally untrusted. In that case, I would assume the wallet to not send an error response.

IMO, it would be good to add something to the privacy considerations section.

[Sakurann]

@martijnharing this issue is probably the most similar to what you have been bringing up

[martijnharing]

This issue indeed addresses it quite well. I would even go one step further and consider to remove all error codes that could potentially leak information unless providing that specific error can directly help in recovering a failed transaction. (while still ensuring that when it is used, it is not leaking any PII)

[jogu]

We recently added https://openid.github.io/OpenID4VP/openid-4-verifiable-presentations-wg-draft.html#section-15.4 which covers this but is specific to the DC API. Generalising is slightly so it applies to non-DC-API errors too may solve this issue?