Re: Discussion on concepts from the DGA extension

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 Tuesday, 18 July 2023 19:03:01 UTC