Verifiable Presentation does not meet the minimum requirements for holder informed consent

[TomCJones]

Several governments have legislation requiring that data is not provided without obtains 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

[c2bo]

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?

[jogu]

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.

[TomCJones]

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.

[TomCJones]

The inclusion problem is separate - perhaps this should be a separate issue? I added this as #335

1. Comatose, severely impaired or young child (Cognitively unable to Consent)
2. Language issues (Communications limitations to give informed consent)
3. Elderly parent that needs assistance (has become dependent; can delegate consent)
4. Other emergency use cases like natural disasters like the North Carolina hurricane.

[TomCJones]

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.

[jogu]

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?

[c2bo]

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.

[TomCJones]

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.

[TomCJones]

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.

[jogu]

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 #289 #160 #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.

[TomCJones]

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/

[jogu]

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.

[TomCJones]

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