Data Privacy Vocabulary Version 0.1

W3C Community Group Draft 22 April 2019

Editor:

Axel Polleres, Vienna University of Economics and Business

Contributors:

(In alphabetical order)

Bert Bos, W3C/ERCIM

Rob Brennan, Trinity College Dublin

Bud Bruegger, Unabhängige Landeszentrum für Datenschutz Schleswig-Holstein

Fajar J. Ekaputra, Vienna University of Technology

Javier D. Fernández, Vienna University of Economics and Business

Ramisa Gachpaz Hamed, Trinity College Dublin

Elmar Kiesling, Vienna University of Technology

Mark Lizar, OpenConsent/Kantara Initiative

Harshvardhan Pandit, Trinity College Dublin

Eva Schlehan, Unabhängige Landeszentrum für Datenschutz Schleswig-Holstein

Simon Steyskal, Siemens

Rigo Wenning, W3C/ERCIM

Abstract

The Data Privacy Vocabulary provides terms and attributes^[a] to annotate and categorize instances of legally compliant personal data handling according to the EU General Data Protection. This scope could be extended by later versions to other data and privacy protection regulations. The vocabulary provides terms to describe which personal data Categories are undergoing a specified kind of processing  by a specific data controller and/or transferred to some recipient for a particular purpose, based on a specific legal ground (e.g. consent, or other legal grounds such as legitimate interest, etc.), with specified technical and organisational measures and restrictions (e.g. storage locations and storage durations) in place.

Please Send Comments

This document was published by the Data Privacy Vocabularies and Controls Community Group (DPVCG) as a first public working draft. If you wish to make comments regarding this document, please send them to public-dpvcg@w3.org (archives). All comments are welcome.

Specifically, the DPVCG kindly requests proposals to extend its initial taxonomies by additional terms, where these are missing or need refinements in order to describe specific use cases of personal data handling. In order to propose/approve new terms, please include the following in your email:

• term - suggested URI/identifier
• class/property - is the suggested term a class or a property?    
• description - a natural language description of the term as to be included in the vocabulary to describe the term in an unambiguous manner.
• domain/range - for properties include information about domain and range
• superclasses/subclasses - for classes include (if applicable) information about known  sub-/ or superclasses.
• superproperties/subproperties - for properties include (if applicable) information about known  sub-/ or superproperties.
• related terms - include if applicable otherwise related terms from other vocabularies and explain how they are related (e.g. skos:broader/skos:narrower, rdfs:seeAlso).
• source - mention where the new term originates from (e.g. from a legal regulation or from an existing ontology, if possible with a link confirming the reference.

Table of Contents

Introduction

Namespaces

Base Vocabulary

Personal Data Categories

Purposes

Processing Categories

Technical and Organisational Measures

Legal Grounds

Recipients, Data Controllers, Data Subjects

Introduction

The Data Privacy Vocabulary provides terms and attributes^[b] to annotate and categorize instances of legally compliant personal data handling. In particular, the vocabulary provides extensible taxonomies of terms to describe these components, namely:

• Personal Data Categories
• Purposes
• Processing Categories
• Technical and Organisational Measures
• Legal Grounds
• Recipients, Data Controllers, Data Subjects

These concepts and terms should be usable to annontate Legal Personal data Handling in a machine-readable fashion, in terms of which personal data Categories are undergoing a specified kind of processing  by a specific data controller and/or transferred to some recipient for a particular purpose, based on a specific legal ground (e.g. consent, or other legal grounds such as legitimate interest, etc.), with specified technical and organisational measures and restrictions (e.g. storage locations and storage durations) in place.

Descriptions and respective annotations of Legal Personal data Handling could be used for instance to:

1. declare personal data handling policies,
2. declare consent to such a personal data handling policy (by a specific consent action),
3. transparently log/document specific personal data handling actions by a data controller, and finally
4. to support automated checking of legal compliances of data handling ex ante (before data handling is actually performed), or ex post (i.e. check compliance to a certain policy and/or consent )

ISSUE-2 should we do something like SPECIAL

Namespaces

We use the following RDF namespace for all terms defined in the DPVCG community group:

                dpv:        http://www.w3.org/ns/dpv#

Besides that, the present specification occasionally refers to the following external namespaces:

Base Vocabulary

The base vocabulary to describe Legal Personal data Handling provides terms to connect the terms defined in the other sub-taxonomies.

Classes

Properties

Class: dpv:PersonalDataHandling

• Status: proposed ( created: 04.04.2019 proposed by: Axel Polleres, Javier Ferenandez )
• Properties: dpv:hasPersonalDataCategorydpv:hasProcessingdpv:hasPurposedpv:hasRecipientdpv:hasTechnicalOrganisationalMeasuredpv:hasLegalBasisdpv:hasDataSubjectdpv:hasDataController
• Used with:

Class: dpv:PersonalDataCategory

• Status: proposed/accepted ( created: 04.04.2019 approved: 04.04.2019 proposed by: Harshvardhan Pandit, Axel Polleres )
• Used with: dpv:hasPersonalDataCategory

Class: dpv:Processing

• Status: proposed ( created: 04.04.2019 proposed by: Axel Polleres, Javier Ferenandez )
• Used with: dpv:hasProcessing

Class: dpv:Purpose

• Status: proposed ( created: 04.04.2019 proposed by: Axel Polleres, Javier Ferenandez )
• Used with: dpv:hasPurpose

Class: dpv:Recipient

• Status: proposed ( created: 04.04.2019 proposed by: Axel Polleres, Javier Ferenandez )
• Used with: dpv:hasRecipient

Class: dpv:TechnicalOrganisationalMeasure

Class: dpv:LegalBasis

Class: dpv:DataSubject

• Status: proposed ( created: 04.04.2019 proposed by: Axel Polleres, Javier Ferenandez )
• Used with: dpv:hasDataSubject

Class: dpv:DataController

Property: dpv:hasPersonalDataCategory

Property: dpv:hasProcessing

Property: dpv:hasPurpose

Property: dpv:hasRecipient

Property: dpv:hasTechnicalOrganisationalMeasure

Property: dpv:hasLegalBasis

Property: dpv:hasDataSubject

Property: dpv:hasDataController

dpv:Purpose rdfs:subClassOf [ onProperty rdfs:comment owl:someValuesFrom … ]  [c]^[d]

Moreover, purposes can be further restricted to  a specific context, for instance a specific business sector. At the moment, we recommend to specify this sector in terms of the EU NACE hierarchy, using the following URI-scheme.

dpv-nace:NACE-CODE

For instance, … add example

Alternative hierarchies for defining business sectors include NAICS (US) and ISIC (UN)^[e][f].

#import Purpose.html

Processing Categories

We understand the nature of processing as the "processing operation to likely result in a high risk”.

Start with the basic categories of https://github.com/dpvcg/processing (second diagram) and consider feedback of Bud regarding the high risk of Article 22:

• Evaluation or scoring

• Profiling
• Prediction^[g]

• Nature of Processing
• Systematic monitoring
• Matching or combining datasets

• From you
• From others

• processing that involves new technological or organisational solutions
• processing  that  “prevents  data  subjects  from  exercising  a right  or  using  a service  or  a contract”  (Article  22 and  recital 91)

Nature of Processing/Decision Making

• Procedure

• Fully-automated (no human intervention)
• Manual
• Semi-automated (possibility of human intervention)

• Transparency

• Deterministic (not blackbox)
• Machine-learning (black box)

monitoringDrivingBehaviour :hasProcessingType [

        :typeProcessing ;erasure;

        :isAutomatedDecM true;

        :isSystematicMonitoring true

]

        :Nature

                Procedure: fully-automated

                Transp: machine-learning

        :Context driving behavior

]

As for “derive” processing, we can have what we derive or just store in a different policy (that is, with data public life and processing derive, and in another policy we say collect sexual behavioral)

#import Processing.html

Technical and Organisational Measures

Taking into account the state of the art, the costs of implementation and the nature, scope, context and purposes of processing as well as the risk of varying likelihood and severity for the rights and freedoms of natural persons, the controller and the processor shall implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk. These include:

(a) the pseudonymisation and encryption of personal data;

(b) the ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services;

(c) the ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services;

(d) a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing.

For any of the declared Technical and organisational measures defined below, we provide an ObjectProperty, and for the values of these attributes (with the exception of Storage), we either allow a blank node with a single rdfs:comment^[h][i][j] to describe the measure, or a URI to a standard or best practice followed, i.e. a well-known identifier for that standard ot a URL where the respective document can describing the standard. In the future, we plan to provide a collection of URIs for identifying recommended standards and best practices.

In particular, in future versions of this document we might extend the vocabulary by an approved taxonomy of identifiers for such standards and best practices.

#import TechnicalOrganisationalMeasure.html

TODO: this needs to be moved to the spreadsheet:

• Technical Measures

• PseudonymisationEncryption^[k]

• EncryptionInRest
• EncryptionInTransfer
• Anonymization
• Pseudonymisation

• De-Identification^[l]
• Anonymisation

• AccessControlMethod
• AuthenticationProtocols

• E.g. OAuth

• Storage

• Duration (how long data is stored)
• Location (where data is stored)
• Deletion (how secure deletion is guaranteed)
• Restoration (regularity, and how long back)

• Organisational Measures

• AuthorisationProcedures (non-technical authorisation procedures: How is it described  on an organisational level, who gets access to the data)
• LegalAgreements

• NDAs?
• Contractual terms governing data handling within the data controller

• GuidelinesPrinciples (guidelines and principles regarding data handling that the data controller commits to)

• CodeOfConduct
• DesignStandards^[m] 
• Privacy by default

• RiskManagementProcedures (Data Protection Impact Assessments as per GDPR art 35, other Privacy Impact Assessments^[n], threat severity assessment https://www.cnil.fr/en/privacy-impact-assessment-pia)

• Privacy by design
• Regularity of checks/recertification?
• Staff training

• Certifications

• Certification/Seal

Legal Grounds

TODO: add rationale

#import LegalBasis.html

Consent

TODO: add rationale

#import Consent.html

Recipients, Data Controllers, Data Subjects

TODO: add rationale

#import RecipientsDataControllersDataSubjects.html