Re: Discussion on concepts from the DGA extension

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,