Meeting minutes
Repository: w3c/dpv
ghurlbot, harsh is coolharsh55
<ghurlbot> harsh, I already had that GitHub account for harsh
Item "Identity privacy attribute" added as AOB from jan
DPV presentation on DGA to EU DG CNECT
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
Other interest have also been expressed regarding Data Act, and groups such as OECD.
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
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.
jan: was there a discussion regarding something akin to a privacy dashboard to manage consent?
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
harsh: We should use these discussions to identify any directions or objectives that the group finds of interest and should work on
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.
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.
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.
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.
Implementing 27560 and 29184
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
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
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
… (the group specified several ayes with no nays and the proposal was accepted
… ghurlbot, get #90
<ghurlbot> Issue 90 Provide guidance for implementing ISO/IEC 27560 Consent Records using DPV (coolharsh55) documentation, use-case, application
harsh: ghurlbot, get #91
<ghurlbot> Issue 91 Provide guidance for implementing ISO/IEC 29184 Privacy Notice using DPV (coolharsh55)
Data Breach
harsh: Continuing from the previous discussion on data breach notifications and records.
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.
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.
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.
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.
… The group discussed alternatives and the difficulty in modelling these concepts. Any volunteer who can provide more guidance on this is welcome.
ISSUE: Represent Main Establishment as a concept
<ghurlbot> Issue 93 Representing Main Establishment as a concept (coolharsh55) concepts, help-wanted
harsh: Other information required includes scale of data subjects and processing activities, including member states for both - which can be represented using existing concepts.
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.
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.
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.
… 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.
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.
Next meeting
harsh: The next meeting will take place on 11 May at 14:00 WEST / 15:00 CEST
… 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
… Updates on DGA concepts will also be part of the agenda.
… ghurlbot, bye