openid
Verifiable Presentation does not meet the minimum requirements for holder informed consent
Several governments have legislation requiring that data is not provided without obtaining informed consent from users. This requirement is not met by the VC or the OID4VC. It is proposed that the query be moved either to the front or altogether outside of the OID4VP document. A detail for this proposal is being developed as a report from Kantara. The current draft is contained in this doc. https://docs.google.com/document/d/1n7HobJ6QTsNld5rn1uuIiNw0A__L44ug/edit?usp=sharing&ouid=109794657323597753486&rtpof=true&sd=true
How exactly is data being provided without informed user consent in OpenID4VP? The Wallet receives an Authorization Request (which might also be signed and linked to a trust ecosystem to identify the RP within that ecosystem and allow a better informed decision by the user), gets user consent for the requested data and only then sends a response. Maybe I am misunderstanding your question, but I don't see a problem?
The EU is one of the jurisdictions where informed consent is required, and their recent letter to OIDF (which identified various gaps between legislation and the OID4VC/HAIP specs) did not identify any gaps in OID4VP in this area.
If you believe there is a gap, please be very specific about where it is and exactly what part is happening without user consent, ideally using specific example OID4VP queries and responses; I agree with Christian's above description of how user consent is obtained.
we tried to document the problem - here is part of the text from the EU - The purpose is designed to meet the desires of the verifier which includes compliance with local privacy requirements. The following wording is taken from the EU GDPR but should satisfy most jurisdictions. The EU website describes when data processing is allowed: “Data Protection under the GDPR” https://europa.eu/youreurope/business/dealing-with-customers/data-protection/data-protection-gdpr/index_en.htm EU data protection rules mean the data controller (aka verifier) should process data fairly and lawfully, for a “specified and legitimate purpose” and only process “the data necessary to fulfill this purpose”.
We just talked to someone that participated in the California hack-a-thon using VP - the user gets a url on their phone and must make a trust decision based on that - the phone does get a signature evaluation, but that just says that the sender owned the url. I have heard the the EU states will replace the CA system used in the CA/B browser TLS support. But experience does not indicate that will be even as good as the CA/B system. And there does not appear to be any redress POC as required.
The inclusion problem is separate - perhaps this should be a separate issue? I added this as #335
- Comatose, severely impaired or young child (Cognitively unable to Consent)
- Language issues (Communications limitations to give informed consent)
- Elderly parent that needs assistance (has become dependent; can delegate consent)
- Other emergency use cases like natural disasters like the North Carolina hurricane.
For those in other part of the world the ACM 2018 Code of Ethics and Professional Conduct would always apply "Only the minimum amount of personal information necessary should be collected in a system. The retention and disposal periods for that information should be clearly defined, enforced, and communicated to data subjects. Personal information gathered for a specific purpose should not be used for other purposes without the person's consent. Merged data collections can compromise privacy features present in the original collections. Therefore, computing professionals should take special care for privacy when merging data collections" https://www.acm.org/code-of-ethics if the spec is released as is i intend to report it to the ACM for action under the above statement.
Hi Tom
I have finding this very difficult to follow.
To try and clarify: you agree that user consent is happening, your doubt is to whether the consent is sufficiently informed?
How does moving text around in the standard or removing text from the standard ("It is proposed that the query be moved either to the front or altogether outside of the OID4VP document") solve any of the above issues?
we tried to document the problem - here is part of the text from the EU - The purpose is designed to meet the desires of the verifier which includes compliance with local privacy requirements. The following wording is taken from the EU GDPR but should satisfy most jurisdictions. The EU website describes when data processing is allowed: “Data Protection under the GDPR” https://europa.eu/youreurope/business/dealing-with-customers/data-protection/data-protection-gdpr/index_en.htm EU data protection rules mean the data controller (aka verifier) should process data fairly and lawfully, for a “specified and legitimate purpose” and only process “the data necessary to fulfill this purpose”.
We just talked to someone that participated in the California hack-a-thon using VP - the user gets a url on their phone and must make a trust decision based on that - the phone does get a signature evaluation, but that just says that the sender owned the url. I have heard the the EU states will replace the CA system used in the CA/B browser TLS support. But experience does not indicate that will be even as good as the CA/B system. And there does not appear to be any redress POC as required.
I would not mix how parts of a spec (basically a profile) was used in a hackathon with what options the spec provides. OpenID4VP supports different schemes for RP authentication which can go way beyond just proving ownership of a URL etc.
OpenID4VP provides a lot of different options and needs to be profiled depending on the requirements of the ecosystem (use-cases) that people are trying to build - the capabilities exist in the protocol, people just need to use them according to their requirements.
it seems you miss the point - the purpose for collecting data must (AFIK) be presented to the user before any response what-so-ever is made to the verifier.
Based on previous messages from the chairs i would not be at all surprised if ODI4VP chose to ignore this point. If you do chose to ignore this (as well as other signs) i strongly doubt that the standard will succeed. So i have tried to make my point super clear. If the point is not, please let me know.
Hi Tom
I have finding this very difficult to follow.
To try and clarify: you agree that user consent is happening, your doubt is to whether the consent is sufficiently informed?
How does moving text around in the standard or removing text from the standard ("It is proposed that the query be moved either to the front or altogether outside of the OID4VP document") solve any of the above issues?
moving it around is not the point - see above for the point
and have you seen this one? https://hub.ebsi.eu/vc-framework/trust-model/policies Digital identity wallets must ascertain the identity of Verifiers and determine whether these Verifiers possess the necessary authorisation or obligation to request Verifiable Credentials (VCs) or claims. I don't see how OID4VP provides that - all i see is a URL that the user must decide whether to trust. Granted the URL is signed by someone who can prove that the signer really controls the URL. Not sure how that fully informs the user to help decide whether to consent to sharing their data.
moving it around is not the point - see above for the point
I'm very confused then - what was the reason you proposed moving it around in the issue summary? Can we please limit the solutions suggested on this issue to solutions that solve the informed consent question you raised?
it seems you miss the point - the purpose for collecting data must (AFIK) be presented to the user before any response what-so-ever is made to the verifier.
It is not required to be presented by the wallet though (in GDPR it is definitely 100% okay and I believe actually required that the verifier presents it's purpose to the user and gathers consent itself, I believe a verifier cannot rely on consent gathered by a wallet), and there are good reasons for the wallet to avoid presenting it, see https://github.com/openid/OpenID4VP/issues/289 https://github.com/openid/OpenID4VP/issues/160 https://github.com/openid/OpenID4VP/issues/230 for some recent discussions on this topic.
For clarity though, OID4VP (using either query language) does allow a purpose to be conveyed to the wallet.
Digital identity wallets must ascertain the identity of Verifiers and determine whether these Verifiers possess the necessary authorisation or obligation to request Verifiable Credentials (VCs) or claims. I don't see how OID4VP provides that - all i see is a URL that the user must decide whether to trust.
This is provided via https://openid.github.io/OpenID4VP/openid-4-verifiable-presentations-wg-draft.html#name-client-identifier-scheme-an - for example when the Client Identifier is an OpenID Federation Entity Identifier the wallet can obtain metadata about the verifier (like a verified name / logo / etc) that has been asserted by a trusted entity.
There are ongoing discussions (there were some at IIW but I can't currently find an issue in openid4vp) about standardising ways to communicate the authorisation of third parties in terms of what credentials they might be authorised to collect, but for example the Italian government has already defined it's own way using OID4VP's existing extension points - however that topic of what a verifier is authorised to request is mostly unrelated to informed consent so we should not discuss it on this issue.
I do not intend to limit solutions to points. Their are reasons for moving it to the beginning which also need to be addressed. This is idea of breaking things to the smallest possible solution is one of the major problems with this approach.
The consent phase MUST appear before ANY response is sent from the Holder to the Verifier. The purpose of the query MUST be sent to the Holder's agent to cover the entire transactions. nb. the above is not meant to say that their is only one purpose or one transaction in a transmission.
Here is someone else's view on the approach taken by ODI4VP https://teachprivacy.com/cartoon-notice-and-choice/
Hi Tom
We already have dedicated issues on some of those points that have detailed discussions. You can contribute to those issues. The problems, particularly around "purpose", are far more nuanced than you are presenting, so the solutions you're proposing aren't actionable.
We are confident that OID4VP can be compliant with applicable laws, I've explained how, and several jurisdictions that are adopting OID4VP seem to agree with that, and you've not actually explicitly pointed out any laws that you believe it can't be compliant with, nor have you suggested concrete changes that solve all the issues you're raising.
Mike Jones has reminded me that OIDF has avoided trying to make legal cases and IANAL. So the one clear statement that you can bank on is that OID4VP is not ethical as describe in the the ACM policy. The original posting has an alternate view of a Query that addresses the issues.
Still the following might be of some interest to the members in the EU. https://commission.europa.eu/law/law-topic/data-protection/rules-business-and-organisations/principles-gdpr/what-information-must-be-given-individuals-whose-data-collected_en
(chair hat off)
Tom objected to WGLC on the grounds that this issue is unsolved: https://lists.openid.net/pipermail/openid-specs-digital-credentials-protocols/Week-of-Mon-20250414/000743.html
I've read back through this issue. There seem to be a number of questions I've asked Tom that I've not obviously got answers to, such as "To try and clarify: you agree that user consent is happening, your doubt is to whether the consent is sufficiently informed?". Being unable to narrow down exactly what Tom believes the problem is or isn't is significantly hampering figuring out if there's a problem that needs to be solve in the specification or not.
I think we've replied to every point Tom has raised, with the possible exception of not fully replying to this one:
Digital identity wallets must ascertain the identity of Verifiers and determine whether these Verifiers possess the necessary authorisation or obligation to request Verifiable Credentials (VCs) or claims.
I don't see how OID4VP provides that - all i see is a URL that the user must decide whether to trust.
I already explained that OID4VP provides for this via https://openid.github.io/OpenID4VP/openid-4-verifiable-presentations-wg-draft.html#name-client-identifier-prefix-an (for example, x509_san_dns defined there does not require the user to declare whether they trust a URL or not, it can be PKI certs that assert a trusted name for the verifier etc) but it's perhaps also worth sharing that the "possess the necessary authorisation or obligation to request Verifiable Credentials (VCs) or claims." part is being solved in an EU specific way, there was a presentation about this at the recent IIW:
https://docs.google.com/presentation/d/1s-MM27j4ZxACf0ecuVBGbuj8o4C5kr9g62jXeby0wso/edit#slide=id.g34994030800_0_349
My understanding of the current situation:
- Tom believes that OID4VP can be used in ways that are not compliant with laws such as EU GDPR / EUDI wallet regulations (a point that I believe there is agreement on, given many things are out of scope for OID4VP and defined by local ecosystem requirements/laws)
- Tom doesn't like the way verifier authentication was done at the California hackathon.
- Everyone (except for Tom?) seems to believes OID4VP can also be used in a way that is compliant with such laws
Is this a correct summary?
Tom believes that OID4VP can be used in ways that are not compliant with laws such as EU GDPR / EUDI wallet regulations (a point that I believe there is agreement on, given many things are out of scope for OID4VP and defined by local ecosystem requirements/laws)
With the Implementing Act 5b Registration of relying parties the EC addresses the missing peaces for verifier identification and the parts that need to be covered by the GDPR. OID4VP is allowing to pass such information with draft 26, so I see no problem with the informed consent. But it is a generic approach, so each eco system, like the EU, can define how informed consent can be realized. The practical approach for Europe is standardized by ETSI right now, and I think it fits better for this purpose than OIDF.
We challenged this approach with multiple experts from the security and privacy sector and I don't see any problems with the version that is planned to be made public. So I can confirm OID4VP can be used to comply with EU regulations.
From what i can gather from comments made in email and LinkedIn postings. There is agreement that OID4VP does not provide the information required for informed consent as defined in (eg) the GDPR. The work-around is to put the information into some vague thing called the ecosystem. Some of the European implementers are happy with that. I guess that should be made clear in scope as i certainly didn't understand that to be true in any ecosystem of which i am aware. I guess we need to write specs for ecosystems now too?
While I understand this attempt at a solution, i personally find it to be inadequate.
Let's look at the flow now. A user device receives a OID4VP with a query string. The query string goes to the device protocol handler. The protocol handler processes the string sufficiently to determine which app on the device might be able to handle the request based primarily on the query contents. Doesn't that mean the device and/or the protocol handler will need to determine if the ecosystem of the verifier and the app are part of the same ecosystem? What is the case where i use my US mDL to rent a car in the EU. What is the relevant ecosystem, mine or the EU? or is that a decision to be made in the ecosystem of the device handler?
I can't see how this could ever work. My proposal from the beginning of this process was to put the purpose first. I still think that is more likely to work, especially for interop.
There is agreement that OID4VP does not provide the information required for informed consent as defined in (eg) the GDPR.
OID4VP has the extension to allow to add different "informed consent" information, it does not force you to to use one specific approach. As described above the requirements from different eco systems can be respected with this approach.
What is the relevant ecosystem, mine or the EU
It is the EU with the GDPR, because your data is processed in the EU (independent if you are an EU citizen or not). At the point of the Authorization Request, the Relying Party/Verifier does not know who you are. So it MUST respect regulations like the eIDAS that is forcing it to use an access certificate. But it also has to respect possible other regulations to respect the rights of other non EU citizen.
Let's see it the other way around: I want to use my mDL from the EU in the US to rent a car. Since I am a EU citizen and the car company and is also targeting customers from the EU, it has to respect the GDPR, like giving me the chance for the "right to be forgotten". HOW this is implemented is out of scope of the regulation.
Offering a discovery service via the Wallet Metadata will leak private information by publishing the eco system the wallet is in. Conclusion: The Verifier has to respect all possible eco systems it wants to interact with during the Authorization Request.
It seems the issue is clear. I am just an engineer that believes in the KISS principle. There is a proposed alternative that meets the principle. It was proposed and rejected by Daniel when the VP was being formed, so this should not be news to anyone.
There is agreement that OID4VP does not provide the information required for informed consent as defined in (eg) the GDPR
I don't think this is accurate. I stated the situation accurately in my comment above.
It seems the issue is clear.
I cannot understand on what basis you are stating this. I have asked multiple clarifying questions that need a "yes" or "no" answer, and you've not answered them. Nothing is clear, particularly not the exact issue.
There is a proposed alternative that meets the principle.
There is no proposal I'm aware of. I'm only aware of a document (mentioned in the first comment) that bears no relationship to OID4VP and is quite significantly under defined, and there has been no proposal made that I'm aware of that the working group adopt this document, nor has any proposal being made as to how OID4VP could reference this document without introducing significant confusion and having duplicate information in queries or losing significant functionality.