OpenID4VP

OpenID4VP copied to clipboard

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

Original Reporter: KristinaYasuda

Add/fill in privacy considerations sections in OID4VC specs

Imported from AB/Connect bitbucket - Original Commenter: mh67df3w

We could start with OECD Privacy guidance availale at https://legalinstruments.oecd.org/en/instruments/OECD-LEGAL-0188

‌

The high level set of principles from that document are:

• Collection Limitation
• Data Quality
• Purpose Specification
• Use Limitation
• Security Safeguards
• Openness
• Individual Participation
• Accountability

‌

Imported from AB/Connect bitbucket - Original Commenter: KristinaYasuda

thank you! the challenge is always how to translate these principles into the requirements relevant at the protocol level.

If the WG is supportive that far at least I'm happy to have a go at taking those to a more practical & relevant level

probably would be good to enhance privacy session before ID3, just like we did for VCI ID1

a lot of privacy considerations lie within credential format layer and not protocol layer. at the protocol layer, we can cover the following:

• selective disclosure
  • query language allows for selective disclosure
  • credential formats support selective disclosure
• unlinkability
  • presented credentials can be ephemeral
• unobservability
  • wallet can have multiple architectures: wallet can be built without wallet backend where no request goes through the backend

A lot of it also pertains to the processing at the wallet and the verifier, which are not protocol matters strictly speaking. However, having looked at the VCI spec, the privacy consideration section is talking about those so I am contemplating up to which aspect to cover.

I don't think I can do justice to (un)observability so not sure I'm going to even attempt...

#506 has some discussion of selective disclosure and unlinkability and a bit of intro context

Thanks @bc-pi . Incorporated at least part of it (I think I used all the text but hey, it is 2:30 AM here.) Some unobservability text as well. Some sections may not be relevant for this document, but they need to be considered as a combined system. Also, note that I am assuming that the purpose is kept in DCQL. If it goes away, some text needs to change as well. Some of them may become irrelevant.

My first cut version before going to bed.

15. Privacy Considerations

The OpenID for Verifiable Presentations protocol introduces new data flows and metadata exchanges which require careful attention to privacy. This section outlines key privacy considerations implementers, Wallet providers, and Verifiers must account for to mitigate the risks of data leakage, user tracking, and other privacy harms that are relevant to the protocol so that implementers can take this as input to produce privacy risk analysis. 

15.1. User Consent and Choice

• Wallets MUST obtain explicit, informed consent from the End-User before releasing any Verifiable Credential or Presentation to a Verifier.

• The Wallet SHOULD display the purpose and requested claims clearly, especially when transaction_data or claim_sets are used to express sensitive queries.

• If an error prevents the Wallet from honoring a request (e.g., missing credentials or mismatched claim values), the Wallet SHOULD inform the user in a privacy-preserving way.

15.2. Purpose legitimacy and specification

• The verifier ensures that the purposes are sufficiently specific and are communicated before the time the information is collected. For example, it is shown before the presentation request is sent or is sent in the request to the wallet. In the latter case, the wallet communicates them with the user before the user can make their choice. 

• The verifier MUST ensure that the purpose complies with applicable law and relies on a permissible legal basis. 

15.3. Collection limitation

15.3.1 Selective Disclosure

• Implementers SHOULD leverage the support for selective disclosure in credential formats (e.g., SD-JWT VC, AnonCreds) to limit the release of unnecessary claims. 

• The DCQL helps facilitate selective disclosure by allowing the Verifier to specify the claims it is interested in, allowing the Wallet to disclose only the claims that are relevant to the Verifier's request. 

• Some credential formats support selective disclosure and a salted-hash based approach is one common approach. 

• Note that the nature of the issuer of the credential may leak unnecessary information such as nationality or state of residence.

15.3.2 Strictly Necessary

• Verifiers MUST design queries that request only the minimal set of claims and credentials needed to fulfill the specified purposes. DCQL helps facilitate this. 

15.3.3 Claim Value Filtering

• Wallets SHOULD suppress claims from the response if their values do not match the requested values filter, unless user consent overrides this.

15.3.4 No Fingerprinting

• Verifier SHOULD NOT attempt to fingerprint the wallets to track the user's visits. 

15.3.5 No Data Collection or Monitoring

• Wallet providers are prohibited from collecting or monitoring data about how users interact with their wallets, digital IDs, or stored documents. This means providers cannot track user behavior or transactions

15.4. Data minimization

15.4.1. Wallet to verifier communication

• HTTP Headers: Wallets SHOULD only send the minimal amount of information possible, and in particular, without any HTTP headers identifying the software used for the request (e.g., HTTP libraries or their versions) when retrieving a request_uri or sending to response_uri to reduce the risk of fingerprinting and End-User tracking. 

• No unauthorized PII: Wallets MUST NOT include any personally identifiable information (PII) in HTTP requests to Verifiers unless explicitly required for the flow and authorized by the user. 

• No unauthorized request to Request URI: If no End-User interaction is required before sending the request to Request URI, it is easy for a malicious verifier to obtain the wallet capabilities from all visitors of a website on a large scale and in an automated fashion. Even without personally identifiable information (PII) this can reveal some information about End-Users, like their nationality (e.g., a Wallet with special capabilities only used in one EU member state). Mandatory End-User interaction before sending the request, like clicking a button, unlocking the wallet or even just showing a screen of the app, can make this less attractive/likely to being exploited.

• Unlinkability: Wallet can use ephemeral credentials only to achieve cross-session unlinkability. Wallet can use different instances of credentials to different verifiers to achieve cross-verifier unlinkability. Considerable discourse regarding unlinkability in salted-hash based selective disclosure mechanisms is provided in [@?I-D.ietf-oauth-selective-disclosure-jwt, section 10.1]. One technique mentioned to achieve some important unlinkability properties is the use of batch issuance, which is supported in [@?OpenID4VCI], with individual credentials being presented only once.

• No excessive data: If the verifier requests unusually large amounts of data, the wallet should warn the user and potentially stop processing. 

• Passive outsider unobservability: All communications between Wallets and Verifiers should be encrypted either by the transport layer or application layer so that the payload of the communication is unobservable by a passive outsider. 

15.4.2. Error Responses

• Components handling Authorization Requests (e.g., browser extensions or fallback components) MUST ensure that the user is informed and consents before sending an wallet_unavailable error response.

• Error responses SHOULD avoid including sensitive or detailed contextual information that could be used to infer user data.

15.4.3. Request URI and Trust Relationships

• Wallets operating within a trust framework SHOULD validate that the request_uri is properly associated with the client_id and authorized for the request.

• Untrusted or unrecognized request_uri endpoints SHOULD be rejected or require user confirmation before proceeding.

15.4.4. Trust in Issuers and Online Resolution

• Mechanisms that rely on online resolution to validate issuers (e.g., OpenID Federation or ETSI TL lookups) introduce potential tracking vectors.

• Wallets SHOULD prefer self-contained verification whenever possible. If online resolution is required, Wallets MUST only access trusted URLs and avoid transmitting any PII in the request.

• Ecosystems MUST carefully evaluate the privacy impact of the chosen trust establishment mechanism.

15.5. Use, retention and disclosure limitation

15.5.1. Unobservability by Wallets

• No Data Collection or Monitoring: Wallet providers are prohibited from collecting or monitoring data about how users interact with their wallets, digital IDs, or stored documents. This means providers cannot track user behavior or transactions. 

• User-Only Visibility: Only the user can view their transaction history and data within the wallet. Even issuers of digital documents (e.g., IDs or licenses) are not informed when these documents are used. 

• Prevention of Profiling and Tracking: The wallet's design incorporates data minimization principles, ensuring that only essential information is shared during interactions. This limits opportunities for profiling or linking user activities across different services

15.4.2. Verifiers

Verifier should

• limit the use, retention and disclosure of PII to that which is necessary in order to fulfil specific, explicit and legitimate purposes communicated to the user;

• retain PII only as long as necessary to fulfil the stated purpose or as long as it is valid; and

• lock any PII when and for as long as the stated purposes have expired, but where applicable laws require retention. 

15.6 Accuracy and quality

• Verifiers ensure that the PII processed is accurate, complete, up-to-date (unless there is a legitimate basis for keeping outdated data), adequate and relevant for the purpose of use. This could be achieved by only accepting credentials from trusted issuers and checking the issuance and expiry date. 

• If making changes to the already collected and stored data, the verifier should make sure that the new presentation is about the same user. 

• Verifiers should establish a means to detect status change (e.g. revocation) of the obtained credentials through the OpenID4VP protocol. (e.g., through StatusList.) 

15.7 Openness, transparency and notice

• Wallet should keep track of the verifiers’ privacy notices and make them readily available to the user. 

• Wallet should make its privacy notices readily available to the user. 

• A privacy notice should at least include: 

  • the specified PII required for the specified purpose;

  • the specified purpose for PII collection;

  • the specified processing (including collection, communication and storage mechanisms);

  • the types of authorized natural persons who will access the PII and to whom the PII can be transferred; and

  • the specified PII retention and disposal requirements.

15.8. Individual participation and access

Wallets should

• provide access to the user of the list of verifiers that presentations were made, including date, purses and claims;  and

• enable the user to revoke the use or deletion of data stored at the verifier. 

15.9. Accountability

Both wallet providers and verifiers should

• document and communicate as appropriate all privacy-related policies, procedures and practices, including what options in the protocols are used. 

Verifier should 

• sign the request so that it will not be able to repudiate the request; and

• be able to demonstrate compliance with the policies by producing evidence. 

15.10. Information security

• Wallet providers and verifiers should choose the options in the protocols described in this document so that the data in transit is integrity, confidentiality and availability protected. 

• Both Wallet providers and verifiers should be protecting PII under its authority with appropriate controls at the operational, functional and strategic level to ensure the integrity, confidentiality and availability of the PII, and protect it against risks such as unauthorized access, destruction, use, modification, disclosure or loss throughout the whole of its life cycle;

15.11. Privacy compliance

Wallet providers and verifiers should:

• Conduct periodic audits to verify and demonstrate that their processing meets privacy safeguarding requirements;

• Implement appropriate internal controls and independent supervision mechanisms to ensure compliance with relevant privacy laws and their security, data protection, and privacy policies; and

• Develop and maintain privacy risk assessments to evaluate whether programs and services involving personal identifiable information comply with data protection and privacy requirements.

Just removed the point on presentation_definition_uri as they were removed from the draft now.

@Sakurann @jogu let me know when I should turn it into a PR.

thank you! @sakimura please turn this into a PR already - that's the only way to make sure it goes into Final 1.0 to meet timelines

I will do so once Brian's PR is merged. Otherwise, it is going to conflict.

@sakimura Brian's PR is merged now.

Thanks I create a new PR now.

2025年4月7日(月) 10:07 Joseph Heenan @.***>:

@sakimura https://github.com/sakimura Brian's PR is merged now.

— Reply to this email directly, view it on GitHub https://github.com/openid/OpenID4VP/issues/24#issuecomment-2781792909, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABFENYZCC45GYTQPRUNZV32YHFWTAVCNFSM6AAAAABY6JR5ZOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDOOBRG44TEOJQHE . You are receiving this because you were mentioned.Message ID: @.***> [image: jogu]jogu left a comment (openid/OpenID4VP#24) https://github.com/openid/OpenID4VP/issues/24#issuecomment-2781792909

@sakimura https://github.com/sakimura Brian's PR is merged now.

— Reply to this email directly, view it on GitHub https://github.com/openid/OpenID4VP/issues/24#issuecomment-2781792909, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABFENYZCC45GYTQPRUNZV32YHFWTAVCNFSM6AAAAABY6JR5ZOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDOOBRG44TEOJQHE . You are receiving this because you were mentioned.Message ID: @.***>