Meeting minutes
Reminder about Affiliations and Acknowledgements
Checking your affiliation and funding acknowledgements to ensure they are correct and current. See email for more details - https://
These would be displayed in DPV(CG) documents where you have contributed, e.g. see DPV spec https://
Rights / Rules within DPV
georg: I have contacted Giovanni Sartor (see https://
harsh: We have also the meeting with ODRL CG at W3C TPAC - see details https://
We had a discussion on what "rights" should mean and how for the context of expressing them with DPV we restrict the scope to representing what is legally represented specifically and explicitly as a 'right'.
There can be different rights, e.g. fundamental rights as defined in EU Charter, law specific rights such as those provided by GDPR, soft rights such as Art. 7/Art.8 of EU Charter where CJEU states they are not "absolute rights", etc.
georg: There can also be rights arising from obligations or opportunities, e.g. right to do something based on what is permitted (or not prohibited) legally.
Proposal for updating Consent concepts
mark: (discussion) on how Consent, and other legal bases relate to Rights and Notices
mark: How to provide information (using DPV) on how rights are exercised or provided, e.g. to enable / perform them. For e.g. GDPR Art. 12 or others.
We currently do not have a study or example that shows how rights should be implemented, informed about, or represented in terms of what information is needed for them. We invite such studies and proposals for concepts and documentation.
The proposed consent concepts are from the email, see - https://
(discussion on concepts)
DPV currently has `Consent`, but there is a specific need to log information about consent. We have `DataProcessingRecord` that covers all forms of processing records. For consent specifically, the proposal is to have `ConsentRecord`.
This should facilitate information representation of consent, align with DPA guidance on maintaining such records, and also link this work with ISO/IEC TS 27560 that is under development.
paul: Why specifically `hasNotice` and how this is distinct from `PrivacyNotice`?
harsh: The `Notice` is used in several contexts, not just consent, To enable a uniform way to represent that a notice is relevant, the property `hasNotice` is provided. It can be used with `PrivacyNotice` or with other notices.
The current relations where "provision" is used as the verb are proposed to be changed to "indicated" so better reflect that this is something that is communicated, expressed, or otherwise indicated by an entity in connection with something.
The relations are generic, and do not relate specifically to consent - so they can be used elsewhere. For e.g. to indicate contract related agreements were indicated by specific parties, or the right to object was indicated by the data subject, and so on.
The relation where consent was expressed by another entity, such as a parent or a guardian, is proposed to be replaced with `hasRelationWithDataSubject` to make it distinct that this party is not the data subject (directly) but a related entity. Other than parents and guardians, this will also be useful in cases where a Data Controller is related to the Data Subject.
georg: How does this affect or relate with the existing data categories such as Employee?
harsh: They are complimentary - if data subjects as a group are to be expressed, e.g. as employees - then the data subject category is useful. For more explicit information in cases such as a DPIA or a notice, the additional relation would be beneficial.
georg: We should also add the categories Parents and Guardians to data subject categories.
We have added these concepts as `ParentOfDataSubject` and `GuardianOfDataSubject`. Note that in this case the parents are also data subjects in addition to the (primary) data subjects being e.g. children.
For relations associated with withdrawal, the same properties as those related with providing consent are to be used, i.e. withdrawal is indicated by, etc.
This would enable any other form of consent interaction (or other legal basis interactions) to be uniformly represented without requiring 4+ relations for each case.
Regarding the type of consent, DPV currently only has `isExplicit` as a boolean relation. This is proposed to be replaced with `ConsentStatus` representing the state of consent in terms of its validity to be used to justify processing of personal data, and `ConsentExpression` as the form of expression.
There was agreement on states `Unknown`, `Requested`, `Refused`, `Given`, `Expired`, `Invalidated`, `Revoked`, but some disagreement on `Reaffirmed` regarding its label, use, and usefulness.
Specifically, reaffirmed consent could be where a previously given consent is "confirmed again", but this is also applicable in other states, such as when a prior refusal is "confirmed again".
The EDPB guidelines on consent (and other documents) use the term "renew" to indicate consent should be obtained again. However, the same can also be applicable for other states.
The group has decided that since a "reaffirmed" or "renewed" consent is simply another instance of a prior (given) state, it would be simpler to not have this state and to suggest representing the second or newer instance of consent as 'given' or other states within the record.
georg: When consent is requested, i.e. through a notice, how do we represent the state when the user has engaged with the notice by using the 'close' button without making a decision.
julian: (questions the pragmatism of this state and its distinction from `Requested`)
georg: It is useful to know the data subject has decided to not make a choice (at this point), and that the request has progressed but not towards a specific decision.
We discussed several alternatives for this, such as `RequestIgnored`, `RefusedRequestWithoutDecision`, `RequestWithoutDecision`, and seemed to converge on `RequestDeferred` to indicate that the request has been moved or deferred without any decision.
Next Meeting
We will be meeting again in one week, on AUG-10 WED at 13:00 WEST / 14:00 CEST.
Topics for discussion will be continuation of discussion on consent concepts, specifically about `Renewed` and `RequestDeferred` concepts. Other topics from the mailing list and proposals will be taken up after this.