Meeting minutes
Clarity of Purposes
relevant emails - https://
Piero (from TRAPEZE) raised an issue regarding how Purposes are selected. The specific example relates to a banking use-case where purposes are i) maintain bank accounts, ii) execute payments, and iii) manage portfolios
For these, two purposes seem to be applicable - a) RequestedServiceProvision; and b) SellProductsToDataSubject
The issue is to offer clarity in how purposes are applicable or should be selected, and to see if there are overlaps between concepts which should be rectified.
The group discussed the general practices regarding purposes, where most real-life examples are vague and abstract intentionally, and therefore are a common source of ambiguity.
DPV can help with this by providing specific strong concepts that reduce ambiguity and assist in expressing use-cases in as much detail as possible.
For this, we discussed the use-case, and concluded with the following interpretation. The purpose should be `SellProductsToDataSubject` in case where the products are being marketed or provided to the data subject, but they have not been purchased or availed of yet. This means the products are not a service currently being provided (i.e. there is distinction between current and future). `SellProductsToDataSubject` is therefore applicable here.
In the case where a contract has been established, and this means a service is being provided by the bank to the customer, even if this involves charging money, the purpose is `RequestedServiceProvision` because of the agreement that states such service provision and data required.
The legal basis for Selling Products could be A.6-1f Legitimate Interest whereas for Requested Service Provision it would be A.6-1b Contract.
The group discussed the need to clarify such uses within the descriptions of purposes and offer as much clarity and example as is possible. For this, a sub-group will refine the purposes (harsh, georg, paul).
Exercising Rights
(continued from previous meeting)
reelvant email - https://
The group discussed the proposal to keep records of right exercises. The example only lists the part relevant to recording exercising activities.
The information for how to exercise a right, what data is needed, etc. is provided as part of the Right Exercise Point/Service concept.
The group discussed the examples, its practicality, and identifed aspects that are missing.
For cases where an action is delayed, we add the status `ActionDelayed`. For example, a Controller needs more time to fulfill the right exercised.
To specify duration associated with rights, we have the existing concepts. For example, information about right exercise means the duration is how long the activity will take.
Duration associated with action delayed means how much additional time it will take.
We will have to write these interpretations clearly in the spec.
We will also be collecting Justifications for different statuses, including those for NonFulfilment as well as Delays and other things associated with Right Exercises.
Our scope if limited to Right for now, and not other requests in general.
The framework being developed here is for generic rights, and is not specific to GDPR.
We will be establishing the base framework, and then creating specific extensions for GDPR's rights.
Georg and Paul will be creating a list of Justifications for rights related actions not being completed (in time or at all).
Harsh and Beatriz will be looking at creating specific GDPR rights concepts from the base concepts.
Next Meeting
We will be meeting again in 1 week, on NOV-02 13:00 WET / 14:00 CET.
Another item of note is the SEMIC conference regarding EU vocabularies that are relevant / tangential to DPV - https://
For us, vocabularies we have to align with include SEMIC vocabs https://