Re: Discussion on concepts from the DGA extension

Hi.
I have gone through the concepts and left comments for discussion. 
Please take a look.
I think some of these concepts should be in core DPV or the relevant 
extension (e.g. TECH). We can put them in the "Non-DGA" separate tab 
while being discussed.

- Harsh

On 04/08/2023 20:36, beatriz.gesteves wrote:
> Hi all,
> 
> The DGA concepts are available at [1].
> 
> The Legal Basis (rows 56-62), Risk (rows 94-96), Technology (rows 
> 97-105), Rights (rows 106-108), Services and Register-related (rows 
> 109-122) concepts weren't reviewed by anyone yet, as far as I know.
> 
> Has anyone reviewed these concepts (or the previously discussed ones) or 
> wants to review them?
> 
> If so, please report back to the group via this thread or schedule a 
> meeting with me so we can go through it together and then I can report 
> back to the group.
> 
> Thanks!
> 
> Beatriz
> 
> [1] 
> https://docs.google.com/spreadsheets/d/18QTjsLriFLYphUc445CPYUa1lnNQvFC6D7u36IN1srs/edit?usp=sharing
> 
> 
> On 18-07-2023 20:02, Harshvardhan J. Pandit wrote:
> 
>> Hi.
>>
>> On 18/07/2023 15:16, beatriz.gesteves wrote:
>>
>>> --------
>>>
>>> Entities
>>>
>>> --------
>>>
>>> 1 - With regards to the labelling of the data intermediation service 
>>> providers, which are currently proposed to be labelled as 
>>> *DataIntermediationServiceProviderForDataHolder* and 
>>> *DataIntermediationServiceProviderForDataSubject*, we were wondering 
>>> if the correct phrasing is provider *for* data holder/subject or if 
>>> we should rephrase it to provider *on behalf of *data holder/subject, 
>>> similarly to GDPR's terminology where a data processor processes 
>>> personal data on behalf of the controller.
>>
>> That's too big to be practical. How about DataHolderDISP and 
>> DataSubjectDISP, where DISP is the shortened form of 
>> DataIntermediationServiceProvider.
>>
>> Further to this, "Service Provider" can be shortened to "Provider", 
>> since "Data Intermediation" is itself a type of Service. Which gives 
>> us another two alternatives: DataHolderIntermediationProvider and 
>> DataSubjectIntermediationProvider.
>>
>> As for the use of "for" vs "on behalf of" - I think the DGA uses "for" 
>> as in a service targeted or oriented towards use by. So this is what 
>> we should specify in the description.
>>
>>>
>>> 2 - Update the data user's definition from "An entity who has access 
>>> and the right to use personal or non-personal data for commercial or 
>>> non-commercial purposes" to "An entity who *receives and/or has 
>>> access to* personal or non-personal data for commercial or 
>>> non-commercial purposes"
>>
>> We should not deviate from the legal definitions. DGA Art.2-9 states: 
>> ‘data user’ means a natural or legal person who has *lawful access* to 
>> certain personal or non-personal data *and has the right*, including 
>> under Regulation (EU) 2016/679 in the case of personal data, *to use 
>> that data* for commercial or non-commercial purposes;" The key words 
>> here being "lawful access" and "right", and noting that there is 
>> nothing in there about receiving the data.
>>
>> Or we can just copy the definitions as they are from the DGA since we 
>> are modelling it exactly, and unlike DPV where we had to generalise 
>> concepts like Controller to not be GDPR exclusive.
>>
>>>
>>> 3 - We are missing a definition for "privacy sector body". In 
>>> addition, we have the "Sector" concept modelled in DPV, but there are 
>>> no concepts for "Public Sector" and "Private Sector". Is this 
>>> something that needs to be modelled within DPV?
>>
>> Yes, though DPV's notation of sector refers to area of operation 
>> rather than type of organisation. If I remember it correctly then 
>> there are effectively three types of sectors: Private - companies and 
>> like, Public - governmental services and like, Voluntary - non-profit 
>> or voluntary or charity and like. So these should be modelled as types 
>> of organisations as its only three concepts, and the Sector concept 
>> should be reserved for domain/area e.g. manufacturing or health - 
>> where controlled vocabularies like NACE exist and can be used.
>>
>>>
>>> 4 - The definition of "SME organisation" needs to be improved, which 
>>> may prove difficult as different sources mention a different number 
>>> of employees for it to be classified as an SME. In addition, 
>>> "micro-enterprise" can also be a concept to be considered to be 
>>> modelled as it mentioned in other acts (DORA,...).
>>
>> We shouldn't get into the legally strict definitions (within main 
>> DPV). So we model SMEOrganisation in DPV. If the DGA or DORA or 
>> anything else has a specific criteria - then that concept gets 
>> redefined as a subclass of the main DPV concept within the extension 
>> with the criteria in its description. This way, the implementer has 
>> the option to explicitly say generic SME or DGA-defined SME. This is 
>> also how we have defined the legal basis in DPV and GDPR.
>>
>>>
>>>
>>> ----------
>>>
>>> Purposes
>>>
>>> ----------
>>>
>>> 1 - @Harsh is there a source for the proposed 
>>> *MisusePreventionAndDetection* purpose? It would be nice to have an 
>>> example to understand where such a purpose would be properly used.
>>
>> I don't know an exact example, but in my mind reading Art.22-1a had 
>> something like the following: some data or control over it has been 
>> handed to the Data Altruism Org. (called DAO). along with information 
>> on what it is permitted to be used. The DAO now has to ensure two 
>> things: 1) any reuse of data is in accordance with the conditions the 
>> data was released under; 2) prevent 'misuse' of data, such as for 
>> fraudulent or illegal activities.
>>
>> In this, (1) can be achieved using policies, agreements, etc. with the 
>> data recipient, (2) can be achieved by protecting the data with access 
>> control etc. so that only the authorised (re-)users can access it. 
>> Within the DPV taxonomy, I suppose this would sit above the Fraud 
>> Prevention and Detection concept as 'Fraud' can be considered to be a 
>> specific form of 'Misuse'. To enable this, we would have to expand the 
>> definition of 'misuse' to not be limited to just data, but also 
>> applicable to tools, services, products, etc. - same as fraud.
>>
>>>
>>> 2 - Regarding the *SupportInformedConsentChoices* purpose, should we 
>>> modelled it as a more generic concept to cover choices not just 
>>> related with consent? For instance, changing the definition from 
>>> "Supporting individuals in understanding and making choices with 
>>> respect to informed consent" to "Supporting individuals in 
>>> understanding and making choices with respect to e.g. consent"?
>>
>> Yes.
>>
>> Breaking down the concept, we have "Providing Support" as a service, 
>> with the specific context in DGA being Art.2-15 where there are lots 
>> of different services.
>>
>> ‘services of data cooperatives’ means *data intermediation services* 
>> offered by an organisational structure constituted by data subjects, 
>> one-person undertakings or SMEs who are members of that structure, 
>> having as its main objectives to *support its members* in the 
>> *exercise of their rights* with respect to certain data, *including 
>> with regard to making informed choices before they consent* to data 
>> processing, to *exchange views on data processing purposes and 
>> conditions* that would best represent the interests of its members in 
>> relation to their data, and to *negotiate terms and conditions for 
>> data processing* on behalf of its members before giving permission to 
>> the processing of non-personal data or before they consent to the 
>> processing of personal data;
>>
>> So as types of 'Data Intermediation Services', we can have 'Support 
>> Exercise Of Rights' with its subtype 'Support Informed Consent', 
>> 'Support Exchange of Data Processing Views', and 'Support Negotiating 
>> Processing Terms'. In these, while aiming to fit the DGA's wording, I 
>> am also trying to think how to expand the description to other 
>> use-cases that might occur.
>>
>>>
>>>
>>> ------
>>>
>>> TOMs
>>>
>>> ------
>>>
>>> 1 - In addition to *CommercialConfidentialityAgreement* and 
>>> *StatisticalConfidentialityAgreement*, should we have a 
>>> *ConfidentialityAgreement* concept that can be reused for other types 
>>> of agreements?
>>
>> Yes, as the parent concept of the two.
>>
>>>
>>> 2 - How is the *DataTransferNotice* different from DPV's 
>>> *PrivacyNotice*? And do we also need a *ThirdCountryDataRequestNotice*?
>>
>> DataTransferNotice would be the information to be provided when data 
>> is being transferred, in most cases such notices would only be 
>> necessary when the transfer is to a third country. PrivacyNotice is 
>> the information to be provided to the data subject about the 
>> processing of their data, and may include the DataTransferNotice. So 
>> in DPV, DataTransferNotice would be a subtype of PrivacyNotice.
>>
>> In DGA, Art.5-9 uses DataTransferNotice from a Re-User to a Public 
>> Sector Body, and in certain cases also to Organisations or Data 
>> Subjects - where the entity has to give permission or consent for the 
>> transfer to proceed.
>>
>> We need ThirdCountryDataRequestNotice - it comes from DGA Art.31-5 
>> ("inform the data holder about the existence of a request of a 
>> third-country administrative authority to access its data"), and 
>> should be renamed to ThirdCountryAuthorityNotice. This information is 
>> not the same as what DataTransferNotice is about - there may not even 
>> be any transfer here if the data is already in the third country.
>>
>>>
>>> 3 - Introducing *LegalMeasure *implies restructuring the 
>>> *dpv:OrganisationalMeasure* taxonomy e.g. *LegalAgreement* should go 
>>> under *LegalMeasure*?
>>
>> Yes.
>>
>>>
>>> 4 - Change *PersonalDataReuseNotice* to *Consent**ReuseNotice* as 
>>> this notice is specifically related to consent.
>>
>> This comes from DGA Art.12-m.
>>
>> "...*informing* and, where appropriate, *advising* data subjects in a 
>> concise, transparent, intelligible and easily accessible manner about 
>> intended data uses by data users and standard terms and conditions 
>> attached to such uses before data subjects give consent;"
>>
>> If it is only informing, then the existing PrivacyNotice should 
>> suffice. I don't think we need a new separate concept here if we 
>> expand the definition of PrivacyNotice to also contain advice - there 
>> is nothing in any regulation that limits or prohibits such information 
>> being in a privacy notice. Since dpv:ConsentNotice is a subtype of 
>> PrivacyNotice - we also don't need to create the concept just for 
>> advice part.
>>
>>>
>>>
>>> More opinions are welcome on these and on the other terms, preferably 
>>> through the mailing list to have a record or directly in DPVCG's 
>>> meetings.
>>
>> To remind everyone: its fine to have discussions outside of these 
>> channels, but please report back a summary or the conclusions 
>> somewhere/anywhere - and then we link to it in the meeting minutes.
>>
>> Regards,

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

Received on Wednesday, 16 August 2023 06:59:10 UTC