Enhancing Privacy by Not Notifying Relying Party of Faulty Requests
Nobody has claimed this yet.
- Dominant language
- Shell
- Stars
- 112
- Forks
- 38
- Avg merge
- 12d 19h
- Merged PRs (30d)
- 4
Description
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.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reading Section 6.4, Error Response, in the OpenID4VP specification and review the existing error cases. Determine which faulty-request scenarios warrant suppressing notifications and whether the text should recommend or require suppression. Done means the specification clearly defines the privacy-sensitive cases and the expected Wallet Instance behavior.
Written by the indexing model from the issue text.
Assessment
- Domain
- authentication, security
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100