Meeting minutes
Repository: w3c/dpv
Meeting minutes: https://
purl for this meeting: https://
georgKrog: presented DPV to organisations in Tanzania who want to use it for their data protection regulations, also workgin on India; will share the jurisdictional concepts for these to enable using DPV for these use-cases
Discrimination concepts
<ghurlbot> Issue 190 [Concept]: Discrimination Concepts in RISK (by coolharsh55)
harsh: found this nice resource that lists all the relevant legislations for discrimination https://
group agreed to go ahead with this approach
Rights Impact concepts
<ghurlbot> Issue 184 Add Rights Impact concepts for each Right (by coolharsh55)
harsh: Added impact concepts for each GDPR right - see https://A13Limited is not providing all required information.
harsh: Also added impact concepts for each EU Fundamental Right - see https://
harsh: This represents three approaches - Approach 1 is where we simply model one impact concept corresponding to each right; Approach 2 is where we expand on this one concept with more specific impact categories e.g. denied, limited, and so on; Approach 3 is where we also model specific aspects of the right that are not fulfilled e.g. invalid legal basis or right of access for Art.8 mentioned earlier. Each approach builds on top of the previous one and gives more concepts, but also makes it more complex.
georgKrog: how would these be used? Who is using these? Thinking of how the data subject would use these for rights exercise. What sort of a tool would use these concepts? The information is difficult to understand on its own as it directly relates to the legal specifics. How to represent what caused these impacts?
harsh: This is a complicated situation as we aren't modelling one particular use-case but supporting many use-cases e.g. rights exercise, impact assessments, risk assessments, internal audits, external compliance investigations, and so on. Therefore, each rights impact concept can tick multiple boxes based on the situation e.g. if some information is not provided, modelling it directly as an impact might not be appropriate as it could still be part of the ongoing correspondence between data subject and controller - and if it is the conclusion then the choice has to be made whether it counts as right denial or limitation or obstruction - so multiple boxes can be ticked.
paulRyan: see the value in doing this, but it won't be easy as there is a lot of information and it has to support the practical use-cases
georgKrog: lets think of how an auditor or an authority will see or use this; let's take an example where the information provided is difficult to understand - this is not the same as not providing the information or only providing limited information
paulRyan: there will be records of each activity undertaken for the right, which the auditor or authority will ask for, and then assess whether it meets the requirements of the regulation
harsh: yes, agree with that - the order in my perspective is as follows: first the applicable rights are identified e.g. we have the legal basis x rights mapping table to help with this; then for each right there is a corresponding requirement that must be identified to be fulfilled e.g. provide information or data; then for each requirement it is to be assessed whether it has been completed or not; and then for each unfulfilled requirement the impact has to be identified from our impact category; then the assessment has to be made whether this counts as a violation of the right and therefore there is some decision or penalty
harsh: based on this, we have concepts for rights, we have concepts for impacts - so both ends are covered, but the middle parts where the specific requirements to fulfil a right are missing, and the various ways in which there can be an unfulfillment of that right is also missing. So from Georg's example, we can see that there is not a one-to-one correspondence between rights requirement fulfillment steps and potential causes of unfulfillment - which means we should have a separate list of concepts
georgKrog: and then for the unfulfilled step there is a justification which can be valid or invalid
paulRyan: two more use-cases - first where an ID is not supplied for the right and therefore the right request is denied and the data subject went to the authority who then approached and asked for the record; and second where the data rectification could not be fulfilled due to potential issues - in both cases there was a record of the interaction and then after the investigation there were additional steps taken to complete the rights process where needed
harsh: good examples, this means from the data subject's perspective it is better to state directly that some step has not been fulfilled rather than jumping directly to violation or denial of a right, similarly from the controller's perspective it is better to list what step could not be fulfilled with the justification and then state whether the right was unfulfilled as the conclusion, and from the authority's perspective they assess this record of interaction and decide whether this counts as a right obstruction or violation or something else or nothing
georgKrog: agreed, then we have missing concepts for stating exactly what has been unfulfilled
harsh: okay, then we have an action here to create these missing concepts to represent what must be fulfilled for the right, and then what are the potential unfulfillment cases which can lead to an impact on rights. At the moment, I have included both as impacts e.g. in Art.8 EU-RIGHTS. To separate these, what should we call these?
harsh: Should these non-impact concepts (e.g. information not provided for A.13) be moved to a Consenquences for Rights separate list, and then we have impacts on rights as including only the impact categories (e.g. violated)? We can name these RightFulfilmentRisk and RightImpact?
julianFlake: possibly yes this would work, but there must be a way to simplify this as it is getting complex and even if the expressiveness is needed it can be confusing and difficult to use
harsh: agreed - though not sure how to simplify this as we are not only modelling rights impact assessments but also risk assessments in general; open to suggestions
georgKrog: CJEU case controllers must document which processors and subprocessors it uses; the GDPR risk based approach does not include not documenting information - so we should aim to provide as much documentation as is practically required
harsh: okay, so I will implement this discussion and circulate an email explaining the arrangement so that we have time to look at this before the next meeting
Updates / Mentions
the following were discussed regarding updates
Proposed DPIA concepts in GDPR by Tytti w3c/
Linking DPV concepts to GDPR (proposed by Prinon Das): w3c/
Guide for Machine-Actionable Rights w3c/
Alignment with ODRL w3c/
Next Meeting
next meeting will be in 1 week on TUESDAY 29 October at 13:30 WEST / 14:40 CEST. Agenda will be discrimination and rights impact topics updates, AIRO/VAIR integration from Delaram, selecting the next set of items/issues on GitHub with any updates on github/mailing list and AOB.