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

Hi Mark, the MyData organisation is completely open and transparent so if there is anything you need over there feel free to go and grab it or ask questions in the Slack.

As I see it, MyData Operators (as organisations) are governed by the privacy and data protection regulations in the jurisdictions in which they operate; so have the same duties and obligations as any other organisation; plus some additional ones if they operate as intermediaries as defined in the Data Governance Act.

On the other side (empowered individuals); that is clearly wide open with no particular regulatory guidance in place. We are all assumed to be un-empowered data subjects with the rights that gives us; but nothing more than that.

Where I’m coming from is that DPV is a means through which empowered individuals can begin to point to specific things, in the knowledge that those things can easily be understood by, and relevant to, the organisations that hold data on them.

Cheers

Iain

> On 7 Sep 2023, at 03:18, Mark Lizar <mark@openconsent.com> wrote:
> 
> In response, and with an attempt to coalesce a thread towards consensus, it appears that the frictions being expressed here are due to a lack of digital governance context being indicated, and the reason why I asked if there is an operator PIA is specifically because  it is not clear, under which context data is controlled. 
> 
> In Data Protection law, this scope is on the enterprise / intermediaries action, but, if the individual controls the data, and services respect this control, then the context is not data protection, it is about data control., 
> 
> This is a different data governance context.  - Most of the friction is around clarity over which mode3 of data governance MyData operators are operating under.   If you could provide the latest documentation on the maydata operator framework, I would happily update my understanding of  the mydata framework in the context of the DGA. 
> 
> Of course, if I control my data, with my own records with a co-regulatory framework e.g. common-wealth 108+ framework this is significantly different, if an intermediary hosts all the recordds of processing actives  and decides what these are, which is currently the state of play,.   How is My Data Operators any different, where is the risk assement for making everyones day fields stnardized and open in a framework that does not conform to law an policy?  
> 
> Am I missing something thing ?   Please provide the latest MyData Operator Framework for Review, 
> 
> Kind Regards, 
> 
> Mark. 
> 
> 
> 
>> On Sep 6, 2023, at 1:23 PM, Harshvardhan Pandit <me@harshp.com> wrote:
>> 
>> Hi Joss.
>> 
>> The notion of Permission as a legal basis comes from the Data Governance Act for non-personal data. For personal data, one of the GDPR Art.6 legal basis is still required.
>> 
>> For permission under PSD3, it would most likely be contract or legal obligation as the EDPS states it is not consent.  The EDPS is repeating the term as it appears in PSD3, and clarifying its interpretation under GDPR as above. So if it is not a legal basis, then it is a required Organisational measure (GDPR terminology) - is how I interpret it.
>> 
>> 
>> 
>> - Harsh 
>> 
>> On Wed, 6 Sep 2023, at 10:53, Joss Langford wrote:
>>> Iain has correctly re-stated the single quote marks around  ‘ ‘permissions’ ’ that were part of the original citation from EDPS. If they are using this level of indirection on nomenclature, then it should warn us all that there is no easy path here.
>>>  
>>> For me, the focus on permissions within an organisational context also makes sense to me and is aligned on how we would use the term. However, I don’t draw a direct line from this to the concept being a legal basis for processing personal data. Surely, it can only be subset or alternative term for one or more existing bases under GDPR?
>>>  
>>> Joss
>>>  
>>>  
>>>  
>>> This message is private and confidential. If you have received this message in error, please notify us and remove it from your system.
>>> Coelition is a non-for-profit company limited by guarantee registered in England & Wales (8402657) 12th Floor 6 New Street Square, London, England, EC4A 3BF
>>>  
>>> From: Iain Henderson <iain@jlinc.com> 
>>> Sent: Wednesday, September 6, 2023 8:33 AM
>>> To: Harshvardhan J. Pandit <me@harshp.com>
>>> Cc: Data Privacy Vocabularies and Controls Community Group <public-dpvcg@w3.org>; Georg Philip Krog <georg@signatu.com>
>>> Subject: Re: Adding Permission, Consent, Opt-in, Opt-out
>>>  
>>> Thanks Harsh, yes I think we are looking at two different perspectives, albeit I’m agreeing with your original point in the email chain on the PSD3 use case that the word ‘permission’ should be carefully explained in DPV.
>>>  
>>> Yes, I think you are looking from the organisational perspective in DPV, and I from the individual side; but if we have done the job well then both parties should be able to point to the same term and derive the same meaning from it.
>>>  
>>> - `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
>>> 
>>>  
>>> Hope that helps.
>>>  
>>> Marc, re your point below; it is incorrect; MyData does not impose any such constraints in the operator model. Some of the operators use consent type frameworks; some information sharing agreements (contract law). Both are valid in the MyData Operator model.
>>>  
>>>  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? 
>>>  
>>> Iain
>>> 
>>> 
>>> On 5 Sep 2023, at 16:45, Harshvardhan J. Pandit <me@harshp.com <mailto:me@harshp.com>> wrote:
>>>  
>>> Hi. Thanks - it seems to me that we are looking at different perspectives. Mine is about how an organisation justifies its processing activities. Yours to me seems to be about how the individuals perceive its requests.
>>> 
>>> To clarify, DPV doesn't necessarily model concepts based on what the individual/user 'sees' - that's up to the implementation to decide what wording or phrasing best suits. So it can be consent, but if it makes it easier for users to understand 'permission' - then using 'permission' label instead of 'consent' is fine for that use-case.
>>> 
>>> What DPV focuses on is how the law requires information e.g. GDPR says you MUST justify using data with one of these (Art.6-1). Most of the other global regulations now follow the same model where a legal basis is required. In this, a 'Permission' when used as a legal basis is distinct from how a 'system' uses 'permissions' because it has legally defined requirements for where it can be used, how, etc. In effect, there are two different 'languages' - one for describing things in a way that is legally relevant i.e. what information must organisations keep in their records, and another one describing things in a way that is system/UX relevant i.e. how to describe what is being shown to the user. DPV is the former. We need another language to describe the latter - but this language will be limited to the use-cases it draws requirements from.
>>> 
>>> MyData dictionaries seem to 1) not contain information how they work with legal bases (which is okay); and 2) operate on the 'implementation' side where the 'permission' is a reduction from a legal basis that only specifies whether something can be done or not (true/false). So in this sense, MyData permissions are like the end-state indicator for whether some process is allowed or prohibited after a legal basis has been evaluated. E.g.
>>> 
>>> 1) if consent is given for Purpose X, then the permission for X is true.
>>> 2) if contract allows Purpose X, then the permission for X is true.
>>> 3) if legal obligation requires purpose X, then the permission for X is true.
>>> 
>>> Such 'technical uses' of 'permission' are 'lossy' because they do not contain information on what kind of permission it is, and their primary use is to describe if a process should be executed or not. But the word 'Permission' is still useful to denote IF used in the sense that you provide the users with a choice in either of the three cases. Hence the addition of 'Obtaining Permission' as an organisational measure so that it is compatible with what is legally required/allowed.
>>> 
>>> - Harsh
>>> 
>>> On 05/09/2023 15:34, Iain Henderson wrote:
>>> Yes, as I see it “permission’ is always the word that should be what the individual sees; but yes there are different types of permission that carry different rights and duties. So they do involve additional, specific processes; but they still create permissions. When individuals are managing hundreds of relationships, most of which don’t ’self clean’ then that simplification is the best option in my view.
>>> I’m see-ing ‘permission’ as being a sub-set of an agreement which would cover multiple permissions (themselves having differing types which would be visible at lower levels of detail/ through iconography).
>>> Might need more discussion.
>>> Cheers
>>> Iain
>>> On 5 Sep 2023, at 15:21, Harshvardhan J. Pandit <me@harshp.com <mailto:me@harshp.com>> wrote:
>>> 
>>> Hi.
>>> To summarise, some of these 'Permission' instances will be 'Consent'? As in 'Consent' is a special form of 'Permission'?
>>> IF yes, then I think we are in agreement.
>>> 
>>> Though the difference between Permission and Consent is important, because for Consent the 'simple' toggle/checkbox may not be sufficient - and why we need to distinguish the concepts.
>>> 
>>> I note that linguistically, it would be better to have 'Agreement' as the broader concept for 'Permission' as it would cover consent and contracts. And then, it would indicate to choose the most appropriate form of 'agreement' from the taxonomy - whether it be t&c, permission, or consent.
>>> 
>>> Regards,
>>> Harsh
>>> 
>>> On 05/09/2023 15:11, Iain Henderson 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.
>>> MyData Dictionary <https://dictionary.mydata.org/ <https://dictionary.mydata.org/>>
>>> dictionary.mydata.org <http://dictionary.mydata.org/> <http://dictionary.mydata.org/><https://dictionary.mydata.org/ <https://dictionary.mydata.org/>>
>>> <https://dictionary.mydata.org/ <https://dictionary.mydata.org/>>
>>> <https://dictionary.mydata.org/ <https://dictionary.mydata.org/>>
>>> MyData Dictionary <https://dictionary.mydata.org/perms/ <https://dictionary.mydata.org/perms/>>
>>> dictionary.mydata.org <http://dictionary.mydata.org/> <http://dictionary.mydata.org/><https://dictionary.mydata.org/perms/<https://dictionary.mydata.org/perms/>>
>>> <https://dictionary.mydata.org/perms/ <https://dictionary.mydata.org/perms/>>
>>> <https://dictionary.mydata.org/perms/ <https://dictionary.mydata.org/perms/ <https://dictionary.mydata.org/perms/%20%3chttps:/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 <mailto: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/
>>> 
>>> 
>>> --
>>> ---
>>> Harshvardhan J. Pandit, Ph.D
>>> Assistant Professor
>>> ADAPT Centre, Dublin City University
>>> https://harshp.com/ <https://harshp.com/>
>>> 
>>> -- 
>>> ---
>>> Harshvardhan J. Pandit, Ph.D
>>> Assistant Professor
>>> ADAPT Centre, Dublin City University
>>> https://harshp.com/
>