13:01:18 RRSAgent has joined #dpvcg 13:01:22 logging to https://www.w3.org/2023/05/04-dpvcg-irc 13:01:22 ghurlbot has joined #dpvcg 13:01:24 Scribe: harsh 13:01:26 repo: w3c/dpv 13:01:27 OK. 13:01:29 ghurlbot, harsh is coolharsh55 13:01:29 harsh, I already had that GitHub account for harsh 13:01:33 Meeting: DPVCG Meeting Call 13:01:36 Chair: harsh 13:02:43 Date: 04 MAY 2023 13:04:18 Agenda: https://www.w3.org/events/meetings/3417a73c-cac2-47a6-9d70-c332b8849ba2 13:07:14 Present: harsh, georg, paul, jan, delaram, markLizar 13:08:07 Item "Identity privacy attribute" added as AOB from jan 13:08:20 Topic: DPV presentation on DGA to EU DG CNECT 13:09:04 On Wednesday Georg and Harsh presented DPV and possibility to use it for DGA regarding 'legal vocabularies' and 'consent standardisation' based on ISO 27560 to the EU DG CNECT's group responsible for DGA 13:09:18 Present+: julian 13:09:52 Other interest have also been expressed regarding Data Act, and groups such as OECD. 13:12:45 jan: presented end of Oct to Policy Officer at EU DG CNECT G.1 unit (same as Georg and Harsh) where DPV as a common vocabulary was also mentioned 13:24:39 Present: beatriz 13:50:39 rigo has joined #dpvcg 14:53:25 georg: Apart from the information, relevant parts also include infrastructure to manage consent in a central manner where requests can be managed from different entities. 14:53:39 jan: was there a discussion regarding something akin to a privacy dashboard to manage consent? 14:54:10 harsh: I think it was implied in the discussion had, but we also had mentioned a central place to do this as it was logical to the alternative of having direct annoying interactions with data subjects 14:54:45 harsh: We should use these discussions to identify any directions or objectives that the group finds of interest and should work on 14:55:52 georg: we have solutions in terms of DPV and its uses, and the DG CNECT is looking for further engagement on topics related to consent standardisation. We did mention ISO 27560 and 29184 as existing standards which we want to combine with GDPR and DPV to provide actional machine-readable interoperable vocabularies. 14:56:37 georg: further to this discussion are then infrastructure details such as who will manage the consent for each entity and how it will work in practice. We are working with a Data Intermediary in Norway regarding consent management based on this. 14:57:29 jan: need to be careful in terms of standards, e.g. deciding what fields and how they are implemented in use-cases which can be varied and bog the group down into discussions or different directions. So a general caution about what implementation details are included or worked on. 14:59:12 harsh: noted, the group scope is clear in that we do not go into specific implementation details for use-cases, and work to first provide information requirements and at most specifications and guidelines. We are not developing technologies directly. 14:59:27 Topic: Implementing 27560 and 29184 15:00:08 harsh: previously, we had agreed to implement the ISO 27560 consent record using DPV and to formally provide a guidance document for implementing the standard by using a schema for DPV 15:00:49 harsh: in addition, based on discussions with DG CNECT, I also propose we should implement the ISO 29184 to provide both machine-readable and interoperable privacy notices as well as consent records 15:01:10 harsh: this ties in well with the DGA as well as the Commission's requirements for the implementation of DGA and its standardisation of terms, forms, and processes 15:01:28 (the group specified several ayes with no nays and the proposal was accepted 15:53:17 ghurlbot, get #90 15:53:17 https://github.com/w3c/dpv/issues/90 -> Issue 90 Provide guidance for implementing ISO/IEC 27560 Consent Records using DPV (coolharsh55) documentation, use-case, application 15:53:21 ghurlbot, get #91 15:53:21 https://github.com/w3c/dpv/issues/91 -> Issue 91 Provide guidance for implementing ISO/IEC 29184 Privacy Notice using DPV (coolharsh55) 15:54:05 Topic: Data Breach 15:54:15 Continuing from the previous discussion on data breach notifications and records. 15:55:11 harsh: analysing the DPC data breach reporting form is confusing as the information required is not uniform for different cases. For example, if a data controller is not in EU then no details about members states whose data subjects have been affected are asked, but if the controller is in EU then this question is asked. 15:56:14 harsh: an important gap in DPV is how to specify the main establishment of an organisation, as this is an important question in the form that determines the competent DPA for the case. We do not have this concept in DPV, and we need to provide it. 15:57:14 harsh: Other related concepts, such as non-main establishment (secondary establishment?) would also need to be provided. Modelling of this information is complicated and convoluted. For example, establishments are often indicated as being controllers, instead of the parent organisation. 15:58:28 harsh: One way to model these could be to provide properties for `hasMainEstablishment` and `hasSecondaryEstablishment` with the range being `Entity`. Then specifying the jurisdiction and location can be done using existing properties. 16:02:24 The group discussed alternatives and the difficulty in modelling these concepts. Any volunteer who can provide more guidance on this is welcome. 16:07:33 Issue: Represent Main Establishment as a concept 16:07:38 Cannot create issue. Error 500 16:08:42 Other information required includes scale of data subjects and processing activities, including member states for both - which can be represented using existing concepts. 16:09:55 harsh: when the main establishment is Ireland, DPC asks for justification explaining why this is so. This can be represented using `hasJustification` and an appropriate concept or message. Though how to associate this with the establishment information expressed is an open question. 16:11:40 harsh: Further in the list, when the list of data subjects are from other EU or EEA member states and there is a significant effect because of the data breach, the form provides some options which can be categorised as consequence as well as impacts, but also include conditions such as special category data and/or minor data subjects and separately scale of processing being significant. 16:12:13 harsh: We can model the consequences and impacts, but unsure about how to model the other information. We have concepts to model individual conditions, such as special category, but not their inclusion. 16:12:50 The group has mentioned the possibility of expressing these as risks. However, the information is about the processing activities rather than a risk being applicable by itself. 16:13:27 georg: then this information should be modelled as part of the processing activity, i.e. specifying there is personal data of special category and that the data subjects are children. This can be in the personal data handling instances for the data breach. 16:14:10 Topic: Next meeting 16:14:31 The next meeting will take place on 11 May at 14:00 WEST / 15:00 CEST 16:14:53 Agenda will be circulated later, and will include work from harsh regarding 27560 and 29184, continued discussion about data breaches 16:15:16 jan's AOB agenda about identity attributes and privacy will be taken up after jan has shared work on this, which may be in some weeks 16:15:31 Updates on DGA concepts will also be part of the agenda. 16:15:38 rrsagent, draft minutes v2 16:15:39 I have made the request to generate https://www.w3.org/2023/05/04-dpvcg-minutes.html harsh 16:15:47 rrsagent, set logs world-visible 16:16:39 ghurlbot, bye 16:16:39 ghurlbot has left #dpvcg 16:16:42 rrsagent, bye 16:16:42 I see no action items