-
Notifications
You must be signed in to change notification settings - Fork 27
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
merge master: fixes and meeting minutes
- fix broken link in README.md from #194 - minutes for 15, 22 OCT 2024 Merge branch 'master' into dev
- Loading branch information
Showing
8 changed files
with
313 additions
and
3 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,38 @@ | ||
| 14:54:20 <RRSAgent> RRSAgent has joined #dpvcg | ||
| 20:09:03 <harsh> Scribe: harshPandit | ||
| 20:09:23 <harsh> ScribeNick: harsh | ||
| 14:55:03 <harsh> repo: w3c/dpv | ||
| 14:55:13 <harsh> Meeting: DPVCG Meeting Call | ||
| 14:55:18 <harsh> Present: harshPandit, georgKrog, julianFlake, paulRyan, beatrizEsteves, delaramGolpayegani, julioHernandez | ||
| 14:55:18 <harsh> Regrets: tyttiRintamaki | ||
| 14:55:22 <harsh> Date: 15 OCT 2024 | ||
| 14:55:26 <harsh> Agenda: https://www.w3.org/events/meetings/0e21485e-d959-4f78-930a-bd66650adace/20241015T133000/ | ||
| 14:55:31 <harsh> Meeting minutes: https://w3id.org/dpv/meetings | ||
| 14:55:35 <harsh> purl for this meeting: https://w3id.org/dpv/meetings/meeting-2024-10-15 | ||
| 14:55:35 <harsh> Topic: Discrimination concepts | ||
| 20:10:04 <ghurlbot> https://github.com/w3c/dpv/issues/190 -> Issue 190 [Concept]: Discrimination Concepts in RISK (by coolharsh55) | ||
| 14:55:35 <harsh> harsh: We can use the existing discrimination law to get the concepts e.g. take from law e.g. Ireland has 8 concepts we can use https://www.citizensinformation.ie/en/employment/equality-in-work/equality-in-the-workplace/ | ||
| 14:55:35 <harsh> georgKrog: we should also map it to ECHR https://en.wikipedia.org/wiki/European_Convention_on_Human_Rights | ||
| 14:55:35 <harsh> Topic: Rights Impact concepts | ||
| 20:10:04 <ghurlbot> https://github.com/w3c/dpv/issues/184 -> Issue 184 Add Rights Impact concepts for each Right (by coolharsh55) | ||
| 14:55:35 <harsh> harsh: see if our impact categories e.g. delayed, denied make sense for each right e.g. non-discrimination and delayed doesn't make much sense ; so we provide some help to identify impacts on rights ; timeline is Nov end as the next release is planned for Dec | ||
| 14:55:35 <harsh> georgKrog: will need to read up on this to understand rights impacts | ||
| 14:55:35 <harsh> harsh: okay, so we can start with one concept representing impact to entire right / article and then have a hierarchy under it to model more specific impacts | ||
| 14:55:35 <harsh> georgKrog: looking at case law, e.g. the word used there is deterrent | ||
| 14:55:35 <harsh> harsh: impact concepts in GDPR | ||
| 14:55:35 <harsh> beatrizEsteves: for specific rights, also put in rights guide | ||
| 14:55:35 <harsh> harsh: in the previous call, the deadline mentioned as November end was based on DPV 2.1 being planned for a December release. Since we have a 6 month release cycle planned, it would be good to have some rights impacts concepts as the FRIA under AI Act is trending. | ||
| 14:55:35 <harsh> Topic: Legal Bases | ||
| 20:10:04 <ghurlbot> https://github.com/w3c/dpv/issues/111 -> Issue 111 Model information about legal bases (by coolharsh55) | ||
| 14:55:35 <harsh> harsh: Georg asked about power of attorney, but this is not considered in GDPR legal bases or other legal bases for consent. For contract, etc. this is also not a legal basis on its own - or I don't think we should get in to that level of detail just yet. | ||
| 14:55:35 <harsh> \ group discussed validity under GDPR for consent | ||
| 14:55:35 <harsh> harsh: concluding this, we need to make sure that DPV is capable for expressing consent given by parent - recording the relation / role | ||
| 14:55:35 <harsh> ACTION: ensure DPV can express role of parent/guardian for consent by delegation | ||
| 14:55:35 <harsh> Topic: Updates / Mentions | ||
| 14:55:35 <harsh> \ the following were discussed regarding updates | ||
| 14:55:35 <harsh> \ Proposed DPIA concepts in GDPR by Tytti https://github.com/w3c/dpv/issues/183 | ||
| 14:55:35 <harsh> \ Linking DPV concepts to GDPR (proposed by Prinon Das): https://github.com/w3c/dpv/issues/186 | ||
| 14:55:35 <harsh> \ Guide for Machine-Actionable Rights https://github.com/w3c/dpv/issues/191 | ||
| 14:55:35 <harsh> \ Alignment with ODRL https://github.com/w3c/dpv/issues/130 | ||
| 14:55:18 <harsh> Topic: Next Meeting | ||
| 16:03:29 <harsh> \ next meeting will be in 1 week on TUESDAY 22 October at 13:30 WEST / 14:40 CEST. Agenda will be selecting the next set of items/issues on GitHub with any updates on github/mailing list and AOB. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,46 @@ | ||
| 14:54:20 <RRSAgent> RRSAgent has joined #dpvcg | ||
| 20:09:03 <harsh> Scribe: harshPandit | ||
| 20:09:23 <harsh> ScribeNick: harsh | ||
| 14:55:03 <harsh> repo: w3c/dpv | ||
| 14:55:13 <harsh> Meeting: DPVCG Meeting Call | ||
| 14:55:18 <harsh> Present: harshPandit, georgKrog, paulRyan, julioHernandez, jesseWright, markLizar | ||
| 14:55:18 <harsh> Regrets: delaramGolpayegani, beatrizEsteves | ||
| 14:55:22 <harsh> Date: 22 OCT 2024 | ||
| 14:55:26 <harsh> Agenda: https://www.w3.org/events/meetings/0e21485e-d959-4f78-930a-bd66650adace/20241022T133000/ | ||
| 14:55:31 <harsh> Meeting minutes: https://w3id.org/dpv/meetings | ||
| 14:55:35 <harsh> purl for this meeting: https://w3id.org/dpv/meetings/meeting-2024-10-22 | ||
| 14:55:35 <harsh> \ 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 | ||
| 14:55:35 <harsh> Topic: Discrimination concepts | ||
| 20:10:04 <ghurlbot> https://github.com/w3c/dpv/issues/190 -> Issue 190 [Concept]: Discrimination Concepts in RISK (by coolharsh55) | ||
| 14:55:35 <harsh> harsh: found this nice resource that lists all the relevant legislations for discrimination https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:52020DC0565 - we can use this to model specific discrimination concepts and also create specific/separate workplace discrimination concepts such as /workplace discrimination based on sex/ to indicate the regulated area | ||
| 14:55:35 <harsh> \ group agreed to go ahead with this approach | ||
| 14:55:35 <harsh> Topic: Rights Impact concepts | ||
| 20:10:04 <ghurlbot> https://github.com/w3c/dpv/issues/184 -> Issue 184 Add Rights Impact concepts for each Right (by coolharsh55) | ||
| 14:55:35 <harsh> harsh: Added impact concepts for each GDPR right - see https://dev.dpvcg.org/2.1-dev/legal/eu/gdpr/#vocab-rights-impacts ; in addition to this, also tried to create more specific concepts for Art.13 information provided when data is collected from data subject - by using the RISK impact concepts e.g. denied, eroded, limited with definitions that contextualise it for Art.13 e.g. `A13Limited` is /not providing all required information/. | ||
| 14:55:35 <harsh> harsh: Also added impact concepts for each EU Fundamental Right - see https://dev.dpvcg.org/2.1-dev/legal/eu/rights/#vocab-impacts where in addition to each right having a corresponding impact concept, Art.8 right to data protection - also created impact category concepts e.g. denied, eroded, limited, and in addition also created specific concepts that represents parts of the right not being fulfilled e.g. right of access not provided, or data being processed without a valid legal basis. | ||
| 14:55:35 <harsh> 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. | ||
| 14:55:35 <harsh> 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? | ||
| 14:55:35 <harsh> 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. | ||
| 14:55:35 <harsh> 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 | ||
| 14:55:35 <harsh> 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 | ||
| 14:55:35 <harsh> 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 | ||
| 14:55:35 <harsh> 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 | ||
| 14:55:35 <harsh> 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 | ||
| 14:55:35 <harsh> georgKrog: and then for the unfulfilled step there is a justification which can be valid or invalid | ||
| 14:55:35 <harsh> 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 | ||
| 14:55:35 <harsh> 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 | ||
| 14:55:35 <harsh> georgKrog: agreed, then we have missing concepts for stating exactly what has been unfulfilled | ||
| 14:55:35 <harsh> 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? | ||
| 14:55:35 <harsh> 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`? | ||
| 14:55:35 <harsh> 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 | ||
| 14:55:35 <harsh> 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 | ||
| 14:55:35 <harsh> 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 | ||
| 14:55:35 <harsh> 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 | ||
| 14:55:35 <harsh> Topic: Updates / Mentions | ||
| 14:55:35 <harsh> \ the following were discussed regarding updates | ||
| 14:55:35 <harsh> \ Proposed DPIA concepts in GDPR by Tytti https://github.com/w3c/dpv/issues/183 - no updates | ||
| 14:55:35 <harsh> \ Linking DPV concepts to GDPR (proposed by Prinon Das): https://github.com/w3c/dpv/issues/186 - Prinon indicated he is not available until December. We will try to have a simple table in each regulation as we already have done the mapping when we created the concepts e.g. controller, perssonal data, etc. | ||
| 14:55:35 <harsh> \ Guide for Machine-Actionable Rights https://github.com/w3c/dpv/issues/191 - Beatriz has already added the HTML page, now we have to refine it. | ||
| 14:55:35 <harsh> \ Alignment with ODRL https://github.com/w3c/dpv/issues/130 - no updates | ||
| 14:55:18 <harsh> Topic: Next Meeting | ||
| 16:03:29 <harsh> \ 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. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.