This document specifies usage policy language of SPECIAL. The usage policy language is meant to express both the data subjects’ consent and the data usage policies of data controllers in formal terms, understandable by a computer, so as to automatically verify that the usage of personal data complies with data subjects’ consent.

The ontology defined in this document is publicly available at http://www.specialprivacy.eu/langs/usage-policy.

This specification was published by the SPECIAL H2020 EU project. It is not a W3C Standard nor is it on the W3C Standards Track.

To participate in the development of this specification, please contact Sabrina Kirrane, the scientific coordinator of the SPECIAL H2020 EU project. If you have questions, want to suggest a feature, or raise an issue, please send a mail to the special-contact@ercim.eu contact.

Introduction

The upcoming European General Data Protection Regulation (GDPR) brings new challenges for companies, who must provide transparency with respect to personal data processing and sharing within their organisations. Additionally companies must be able to demonstrate that their systems and their business processes comply with usage constraints specified by data subjects.

This document presents the SPECIAL usage policy language developed within the SPECIAL EU H2020 project, which can be used to represent the consent provided by data subjects, and to verify that the real usage of personal data complies with data subjects’ consent.

What is a Usage Policy?

Conceptually, a usage policy is meant to specify aset of authorized operations. According to the GDPR, these policies shall specify clearly which data are collected, what is the purpose of the collection, what processing will be performed, and whether or not the data will be shared with others. Usage policies can consist then of the following five elements, referred to as the minimum core model (MCM):

That is, in abstract, mathematical terms a usage policy is just a set of tuples like:

<data item,purpose,operation,storage,recipient>

, which will be called authorizations, each of which specifies a permitted operation.

A data subject’s consent comprises a usage policy; the authorizations contained in that policy are the operations allowed by the data subject. Dually, the usage policy enforced by a data controller contains the operations that are permitted within the data controller’s organization.

Therefore, the usage policy adopted by the data controller (call it Pc) complies with the usage policy in the data subject’s consent (call it Ps) if and only if all the authorizations in Pc are also authorized by Ps, that is, Pc complies with Ps if and only if

Pc ⊆ Ps (Eq1)

Now we have to define a policy language where this kind of policies can be modelled precisely and unambiguously, possibly by representing large sets of authorizations (tuples) in a concise way. Such policy language should be equipped with an inference engine capable of checking reliably and exhaustively whether policy containments such as (Eq1) hold, whenever Pc and Ps are expressed with the policy language. These are the goals of the next sections.

Audience and scope

This document describes the SPECIAL usage policy language. It is aimed at companies wishing to express both the data subjects’ consent and the data usage policies of data controllers in formal terms. Mechanics of cross-format translation from other formats are not covered here.

Document conventions and namespaces

SPECIAL’s usage policies are encoded in OWL2 [[owl2-primer]]. The sets of aforementioned authorizations that conceptually constitute the policy are naturally represented by OWL2 classes, and single authorizations by class instances. In the following we illustrate the language and provide some examples. The full grammar of policy expressions in BNF format is provided in the BNF Section. The namespace for the SPECIAL Usage Policy Language is spl=http://www.specialprivacy.eu/langs/usage-policy#. A SPECIAL authorization is represented with a class spl:Authorization.

The namespace for the SPECIAL Policy Log Vocabulary is http://www.specialprivacy.eu/langs/splog#. We write triples in this document in the OWL functional syntax [[owl2-syntax]], which is less verbose, using the following namespace prefixes:

PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX spl: <http://www.specialprivacy.eu/langs/usage-policy#>
PREFIX svd: <http://www.specialprivacy.eu/vocabs/data#>
PREFIX svpr: <http://www.specialprivacy.eu/vocabs/processing#>
PREFIX svpu: <http://www.specialprivacy.eu/vocabs/purpose#>
PREFIX svr: <http://www.specialprivacy.eu/vocabs/recipients#>
PREFIX svl: <http://www.specialprivacy.eu/vocabs/locations#>
PREFIX svdu: <http://www.specialprivacy.eu/vocabs/duration#>

The SPECIAL’s Usage Policy Language

Basic Usage Policies

A usage policy is composed of one or more basic usage policies, each of which is an OWL 2 expression of the form (Eq2):

ObjectIntersectionOf( 
    ObjectSomeValuesFrom(spl:hasData SomeDataCategory)
    ObjectSomeValuesFrom(spl:hasProcessing SomeProcessing)
    ObjectSomeValuesFrom(spl:hasPurpose SomePurpose) 
    ObjectSomeValuesFrom(spl:hasRecipient SomeRecipient)
    ObjectSomeValuesFrom(spl:hasStorage SomeStorage)
)    

The important parts in this expression are the policy’s attributes highlighted in bold; the policy author shall decide for each of them a suitable range, that in the above text is highlighted in italics. The above policy authorizes all the operations that

  1. fall within the specified SomeProcessing category,
  2. operate only on data that belong to SomeData category,
  3. have any purpose covered by the SomePurpose category,
  4. disclose the results to any member(s) of the SomeRecipient category,
  5. store the results in any place belonging to the SomeStorage category.

Therefore, SPECIAL encodes the set of all authorizations that have (at least) the specified attributes, which match the minimum core model (MCM). SPECIAL defines auxiliary vocabularies providing a set of minimum classes for SomeDataCategory, SomeProcessing, SomePurpose, SomeRecipient, based on the elaboration of concrete policies for the SPECIAL pilots, feedback from all SPECIAL partners, and similar terms in related vocabularies (in particular, P3P [[P3P]] for data categories, purposes and recipients, and ODRL [[[odrl-model]]] for processing).

The following table shows a basic description of each category and concrete examples. The full specification can be found at the SPECIAL Deliverable 2.1 [[SPECIALD21]]. Note that these vocabularies try to cover initial use cases, and further terms may have to be added to the current lists to cover the particular needs of policy authors. Storage location
Table 1. SPECIAL auxiliary vocabularies for usage policies
Category Namespace #Classes Concepts Superclass
Data svd 27 svd:Activity, svd:Anonymized, svd:AudiovisualActivity, svd:Computer, svd:Content, svd:Demographic, svd:Derived, svd:Financial, svd:Government, svd:Health, svd:Interactive, svd:Judicial, svd:Location, svd:Navigation, svd:Online, svd:OnlineActivity, svd:Physical, svd:PhysicalActivity, svd:Political, svd:Preference, svd:Profile, svd:Purchase, svd:Social, svd:State, svd:Statistical, svd:TelecomActivity, svd:UniqueId, spl:AnyData
Processing svpr 9 svpr:Aggregate, svpr:Analyze, svpr:Anonymize, svpr:Collect, svpr:Copy, svpr:Derive, svpr:Move, svpr:Query, svpr:Transfer spl:AnyProcessing
Purpose svpu 31 svpu:Account, svpu:Admin, svpu:AnyContact, svpu:Arts, svpu:AuxPurpose, svpu:Browsing, svpu:Charity, svpu:Communicate, svpu:Current, svpu:Custom, svpu:Delivery, svpu:Develop, svpu:Downloads, svpu:Education, svpu:Feedback, svpu:Finmgt, svpu:Gambling, svpu:Gaming, svpu:Government, svpu:Health, svpu:Historical, svpu:Login, svpu:Marketing, svpu:News, svpu:OtherContact, svpu:Payment, svpu:Sales, svpu:Search, svpu:State, svpu:Tailoring, svpu:Telemarketing spl:AnyPurpose
Recipient svr 6 svr:Delivery, svr:OtherRecipient, svr:Ours, svr:Public, svr:Same, svr:Unrelated spl:AnyRecipient
svl 7 svl:ControllerServer, svl:EU, svl:EULike, svl:ThirdCountries, svl:OurServers, svl:ProcessorServers, svl:ThirdParty spl:AnyLocation
Storage duration svdu 4 svdu:BusinessPractices, svdu:Indefinitely, svdu:LegalRequirement, svdu:StatedPurpose spl:AnyDuration

General Usage Policies

A general usage policy may contain any number of basic policies as in (Eq3):

ObjectUnionOf( BasicPolicy1 . . . BasicPolicyn )

where each BasicPolicy i is of the form (Eq2). The resulting policy is conceptually the union of all the authorizations supported by the basic policies, that is, an operation is authorized by the general policy if and only if the operation is authorized by at least one of its basic policies.

For instance, the following general usage policy states that personal data can only be used for non-commercial purposes and shall neither be stored nor disclosed to third parties, while pseudonymised data can be used freely (where SPECIAL auxiliary vocabularies define the terms PersonalData, NonCommercial, PseudonymizedData).

Note that general policies whose basic policies differ only in one attribute can be factorized using a logical equivalence (ObjectUnionOf) supported by OWL 2. The following example shows this feature, stating that the data can refer to NavigationData or LocationData.

Storage Expressions

The hasStorage policy attribute is a structured object itself, with two attributes, and is specified as follows (Eq3):

ObjectIntersectionOf(
    ObjectSomeValuesFrom(spl:hasLocation SomeLocation)
    ObjectSomeValuesFrom(spl:hasDuration SomeDuration)
    DataSomeValuesFrom(spl:durationInDays Interval)
)
        

In this expression, SomeLocation and SomeDuration are expressed in terms of the corresponding storage location and duration auxiliary vocabularies. It is not necessary to include in the policy both hasDuration and durationInDays. However at least one of them should be specified. The Interval limiting storage duration in days is expressed with the integer facets of OWL2, that is (Eq4):

DatatypeRestriction( xsd:integer
xsd:minInclusive min duration          (optional)
xsd:maxInclusive max duration          (optional)
)

In this expression, min and max durations follow the syntax of xsd:integer. Note that here we are choosing days as the finest granularity for the shake of simplicity, but any standard mapping from dates to integers could be used, e.g. the one used in Unix-like systems.

Compliance Checking

Recall that a policy Pc complies with another policy Ps if and only if (Eq1) holds, that is, Pc ⊆ Ps. In OWL2 terminology, checking whether a general usage policy Pol1 complies with another general usage policy Pol2 amounts to checking whether the following axiom is entailed (implied) by the combined ontology O containing the SPECIAL policy language ontology plus the aforementioned auxiliary vocabularies:

SubClassOf( Pol1 Pol2 ).

Further details of the compliance checking mechanism can be found in the SPECIAL Deliverable D2.4 [[SPECIALD24]]

SPECIAL’s Usage Policy Language Grammar

The complete syntax of usage policies is specified by the following BNF grammar:

UsagePolicy :=’ObjectUnionOf’ ’(’ BasicUsagePolicy BasicUsagePolicy { BasicUsagePolicy } ’)’
            | BasicUsagePolicy
BasicUsagePolicy :=’ObjectIntersectionOf’ ’(’ Data Purpose Processing Recipients Storage ’)’
Data :=’ObjectSomeValueFrom’ ’(’ ’spl:hasData’ DataExpression ’)’
Purpose :=’ObjectSomeValueFrom’ ’(’ ’spl:hasPurpose’ PurposeExpression ’)’
Processing :=’ObjectSomeValueFrom’ ’(’ ’spl:hasProcessing’ ProcessingExpression ’)’
Recipients :=’ObjectSomeValueFrom’ ’(’ ’spl:hasRecipient’ RecipientExpression ’)’
Storage :=’ObjectSomeValueFrom’ ’(’ ’spl:hasStorage’ StorageExpression ’)’
DataExpression :=’spl:AnyData’ | DataVocabExpression
PurposeExpression :=’spl:AnyPurpose’ | PurposeVocabExpression
ProcessingExpression :=’spl:AnyProcessing’ | ProcessingVocabExpression
RecipientsExpression :=’spl:AnyRecipient’ | ’spl:Null’ | RecipientVocabExpression
StorageExpression :=’spl:AnyStorage’ | ’spl:Null’ |
                    ’ObjectIntersectionOf’ ’(’ Location Duration ’)’
Location :=’ObjectSomeValueFrom’ ’(’ ’spl:hasLocation’ LocationExpression ’)’
Duration :=’ObjectSomeValueFrom’ ’(’ ’spl:hasDuration’ DurationExpression ’)’
            | ’DataSomeValueFrom’ ’(’ ’spl:durationInDays’ IntervalExpression ’)’
LocationExpression :=’spl:AnyLocation’ | LocationVocabExpression
DurationExpression :=’spl:AnyDuration’ | DurationVocabExpression
IntervalExpression :=’DatatypeRestriction’ ’(’ ’xsd:integer’ LowerBound UpperBound ’)’
LowerBound :=’xsd:minInclusive’ IntegerLiteral
UpperBound :=’xsd:maxInclusive’ IntegerLiteral
IntegerLiteral := stringOfDigits ’^^’ ’xsd:integer’
stringOfDigits := a sequence of digits enclosed in a pair of " (U+22)
DataVocabExpression := as specified in Table 1
PurposeVocabExpression := as specified in Table 1
ProcessingVocabExpression := as specified in Table 1
RecipientVocabExpression := as specified in Table 1
LocationVocabExpression := as specified in the Storage section
DurationVocabExpression := as specified in the Storage section
        

Acknowledgements

The work is supported by the European Union's Horizon 2020 research and innovation programme under grant 731601 (SPECIAL).