Re: Adding Permission, Consent, Opt-in, Opt-out

Obviously DPV, there is a lot behind this particular topic.

The MyData model is an intermediary service model, where services are in-between people and need to be trusted with out standardised transparency or consent.  The MyData  Operator, model invents its on intermediaries rather use existing mature standards and privacy laws.  Is it true Iain, that rather than using notice and consent, it uses information sharing agreements and contracts?

I do not think we are taking about the same thing.  Regulated transparency and consent, the individual can use notice and consent  record (or receipts) which in effect are records of processing activities, Art 30,  to effectively cut out the intermediaries and managed digital relationships /  services and the providing of their own data directly so as to be complaint with GDPR and the DataGovernance Act.

The model proposed does have similarities to the one specified in Regulation Iain.    It is very similar to in structure for grating systems permissions, with explicit consent, directed consent and altruistic consent.   Although, permissions are not bound by the legal justification they are bound to the purpose and context, with receipts held by the Individual this  decentralise data governance and management and presents a transformative change in which the individual is in control and empowered.

The point and original call to action for MyData effort was for my data  to be under my control and only shared with my explicit consent, to cut out the intermediaries, so people can make real and meaningful choices about who benefits from their data and why,  it was not to just replace intermediaries we have today with sharing agreements and contracts over permissions that people need to manage ontop of consent.    Also, your dictionary is opens up the individual, not service provider, which is really alarming, an issue brought to MyData Operators Group,  in which these privacy risks were not considered or  mitigated.   (Is there a PIA or anything along these lines for the MyData Intermediary program that we can see ? )


Best Regards,

Mark


On Sep 5, 2023, at 10:11 AM, Iain Henderson <iain@jlinc.com> wrote:

My take would be that ‘Permission’ is a good word that sits on the side of the individual, can easily be explained; and amounts to a yes/ no flag at a point in time. Individuals do not have the time nor the inclination to understand the various nuances beyond that.

Then, on the organisational side, there should be a mapping between each data related permission granted or withdrawn by an individual and one of the GDPR/ DPV legal bases for data processing.

That model then allows us to build out a large and extensible list of permissions that can be standardised over time (some already are); so that when an individual says ‘I give you permission to do XXX with YYY data’ then both parties can be referring to the same thing. That allows us to move beyond each and every organisation having a different way to say ‘would you like to subscribe to our newsletter’ for example.

You can see a start point for that approach to using Permissions at the MyData Dictionary, which is the start of a core, open personal data model as seen from the individual perspective.

Implementation example attached with some standardisable permissions.

<https://dictionary.mydata.org/>
MyData Dictionary<https://dictionary.mydata.org/>
dictionary.mydata.org<https://dictionary.mydata.org/>
[X]<https://dictionary.mydata.org/>


<https://dictionary.mydata.org/perms/>
MyData Dictionary<https://dictionary.mydata.org/perms/>
dictionary.mydata.org<https://dictionary.mydata.org/perms/>
[X]<https://dictionary.mydata.org/perms/>


Happy to discuss further if useful.

Cheers

Iain

 [Screenshot 2023-09-05 at 15.10.14.png]


On 4 Sep 2023, at 18:41, Harshvardhan J. Pandit <me@harshp.com> wrote:

Hi.
Currently we have no way to specify "permission" of the data subject without the legal basis being consent - as required by the PSD3 use-case below.

---

https://edps.europa.eu/press-publications/press-news/press-releases/2023/financial-and-payment-services-use-personal-data-should-remain-proportionate-and-fair_en


"The EDPS welcomes the efforts made to ensure the Proposals’ consistency with the General Data Protection Regulation (GDPR).  Both Proposals should specify that the granting of ‘permissions’ to access financial data does not equate to giving consent under the GDPR. Likewise, all processing of personal data following a request to access an individual’s financial data must have an appropriate legal basis under the GDPR."

---

My proposal is as follows:


- `Consent`: is already a legal basis, and is the individual's permission (based on validity criteria e.g. information in notice)
- `Permission`: will be added as a legal basis (exact term TBD), and is an affirmative action in order to initiate or continue a process; this makes consent a type of permission with specific additional requirements

- `ObtainPermission`: an organisational measure that asks for permission in order to start or continue a process
- `AddressObjection`: an organisational measure that addresses an objection before starting or while continuing a process

- `ProvideOptIn`: an organisational measure that provides the ability to someone else to initiate the process i.e. to opt into the process
- `ProvideOptOut`: an organisational measure that provides the ability to someone else to stop the process i.e. to opt out of the process

---

Confusion questions:

1) Permission (legal basis) vs Obtaining Permission (TOMs) - a legal basis is a process providing a justification for enabling something which is regulated or required by law, and where the law determines where it can be used and its validity. An Organisational Measure is determined by the Organisation in terms of how and where it is used. Therefore, if the permission is legally required, then it is a legal basis, and if it is the organisation's decision - then it is a TOMs. We have to use different terms - i.e. "Obtaining Permission" for one of these (I chose TOMs) - to distinguish the concepts.

2) Permission vs Consent: Permission can be by the data subject or another entity, and can be for personal data or non-personal data. Permission for personal data does not necessarily mean consent e.g. in the above statement by EDPS, it is clearly stated thus. Consent is a type of Permission however - "prior permission" to be more specific. But we should not get into the pedantic modelling of this within DPV. What matters is that users can issue permissions without it being 'consent' (under GDPR).

3) Obtaining Permission vs Providing Opt-in: These two reflect two different perspectives with the same end result of the (e.g.) user deciding when to start a process. Permission is asking the user if they want to permit. Opt-in is giving the ability for the user to decide - whenever they want to - whether they want to start a process. A checkbox or dialog asking if it is okay to do something is obtaining a permission rather than an opt-in. A dialog or checkbox asking if you would like to use the beta version is an opt-in rather than a permission. So the phrasing and intent matters in choosing the correct term.

These concepts have obvious overlaps, but my intent here is to point out that if defined in the manner above - they have their distinctions and uses from being distinguished. Their common use has led to confusion about their usage, which is definitely not helped with idiotic uses such as "opt-in consent" or its evil counterpart - "opt-out consent". For DPV, these concepts should be defined precisely as their legal meaning rather than the technical haphazard interpretations. In the end, no harms will come to pass if someone uses "Obtaining Permission" instead of "Providing Opt-in", but having the ability to accurately represent the term of choice would certainly help.

---

NOTE1: No DPVCG meeting this THU SEP-07. Next meeting is on THU SEP-14.
NOTE2: There are two major proposals which will be implemented on SEP-30. Please see https://lists.w3.org/Archives/Public/public-dpvcg/2023Aug/0015.html


Regards,
--
---
Harshvardhan J. Pandit, Ph.D
Assistant Professor
ADAPT Centre, Dublin City University
https://harshp.com/