Re: Agenda for tomorrow's DPVCG call and some thoughts on strategy ahead

Hello all. Comments/replies are inline.

On 05/11/2018 09:50, Axel Polleres wrote:
> 4) Progress since last time (which we may not discuss in detail, but 
> rather table, discuss action items around:
>
>   * Discussion around categories of legitimation categories/lawfulness
>     of processing
>     https://lists.w3.org/Archives/Public/public-dpvcg/2018Oct/0027.html ->
>     I would like to task someone to summarize these and make a
>     proposal to the group we can discuss.
>
I have tried to summarise these as terms at 
https://www.w3.org/community/dpvcg/wiki/Legal_Basis along with a terms 
from two existing vocabularies. The proposal is to have a vocabulary of 
legal basis / lawfulness of processing terms which can be used to 
justify the processing or activities carried out.
>
>   * Elements of consent/competency questions for consent
>     https://lists.w3.org/Archives/Public/public-dpvcg/2018Oct/0025.html,
>     https://lists.w3.org/Archives/Public/public-dpvcg/2018Oct/0038.html ->
>     I would like to task someone to summarize these and make a
>     proposal to the group we can discuss, e.g. based on what we had in
>     the minutes last time:
>       o consent = agreement through an [affirmative action] at a
>         specific [time] with a [data controller] to specific
>         [processing] and [storage] of specific [data categories] for
>         specific [purpose] and [duration]
>       o which of these aspects are similarly relevant for other forms
>         of legitmation than consent?
>
1) Are processing and storage two separate actions/activities? Under the 
definition provided by the GDPR, Article 4(2), ‘processing’ means any 
operation or set of operations which is performed on personal data or on 
sets of personal data, whether or not by automated means, such as 
collection, recording, organisation, structuring, storage, adaptation or 
alteration, retrieval, consultation, use, disclosure by transmission, 
dissemination or otherwise making available, alignment or combination, 
restriction, erasure or destruction;

Where storage is defined as a 'type' of processing. I would therefore 
propose to specify storage as a category of processing. Some of the 
categories or types of processing have further information associated 
with them that we should model e.g. storage -> location, jurisdiction, 
duration OR sharing -> recipient.

I would also propose to add the terms from GDPR A4(2) under the 
types/categories of processing.

>   * Harsh's mail on collecting terms from vocabularies:
>     https://lists.w3.org/Archives/Public/public-dpvcg/2018Oct/0041.html,
>     https://www.w3.org/community/dpvcg/wiki/Taxonomy
>
In terms of scope, how much of these specified properties do we want to 
model? Because if we decide to include terms describing consent itself 
(data subject, duration, etc.), at what point does it become feasible to 
also define it as an ontology?

Conversely, should we agree on a set of questions that any such consent 
ontology should answer/describe? These would allow us to define the 
terms and let (individual) implementations be based on them.

>
> To this end, I would like to go - in tomorrow's call to go through the 
> Use Case Stakeholders
> https://www.w3.org/community/dpvcg/wiki/Use-Cases,_Requirements,_Vocabularies#Use-Cases
> and task them to add subections on top of each use cases to describe, 
> in bullet points, the aspects we agreed [1] (plus the means of 
> ligitmation discussed in [2] to focus on in each use case:
>
> 1. categories of *personal data* involved
> 2. *purposes* for personal data handling
> 3. different kinds of *processing *involved
> 4. data subjects, controllers, processors, and recipients involved
> 5. storage & security aspects:
>     * storage locations
>     * storage duration
>     * security measures (including e.g. anonymisation "levels", 
> pseudonymisation)
> 6. *means of legitimation* for personal data processing
>     e.g. consent, legitimate interest, etc. ...
These are only the use-cases added to the wiki. What about capturing 
use-cases in the 'wild'? E.g. adding arbitrary use-cases based on 
information publicly available via privacy policies. My argument here is 
towards making it possible to use these vocabularies to also describe 
terms/concepts in privacy policies if we can.
> "The current goal is to agree on first public drafts of minimal sets 
> of vocabularies to be finished by December 2018, with first stable 
> working drafts being reached latest on 25 May 2019."

Should we have a plan (now) on how to reach consensus on the drafts 
later in December?


Best,

-- 
---
Harshvardhan Pandit
PhD Researcher
ADAPT Centre
Trinity College Dublin