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 D2.5 [[SPECIALD25]]. 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.

General Usage Policies

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

ObjectUnionOf( BasicPolicy₁ . . . BasicPolicy_n )

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 P_c complies with another policy P_s if and only if (Eq1) holds, that is, P_c ⊆ P_s. In OWL2 terminology, checking whether a general usage policy Pol₁ complies with another general usage policy Pol₂ 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( Pol₁ Pol₂ ).

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

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
        

Data Privacy Controls and Vocabularies

SPECIAL setup the W3C Data Privacy Vocabularies and Controls Community Group (DPVCG) in 2018, after organising a workshop for W3C on Data Privacy Controls and Vocabularies. The group launched on the 25th of May 2018, the official start date of the GDPR. The mission of the DPVCG is to develop a taxonomy of privacy terms, which include in particular terms from the new European General Data Protection Regulation (GDPR), such as a taxonomy of personal data as well as a classification of purposes (i.e., purposes for data collection), and events of disclosures, consent, and processing such personal data.

The vocabularies (and related ontologies) constituted one of the inputs for the development of the vocabularies of the DPVCG that constitute the reference vocabularies for SPECIAL's policy language.

In 2019, the group published two vocabularies:

1. Data Privacy Vocabulary v0.1, (2019)
2. DPVCG GDPR Legal Basis Vocabulary, (2019)

The group, which has its own home page on the W3C site, will continue even after the competion of the SPECIAL project, thus ensuring sustainability of project resources well beyond the project lifetime.

Extension for sticky policies

Policies governing data transfers may associate a sticky policy to the data being transferred (to specify the allowed usage of the data). This can be done by means of a suitable object property withStickyPolicy that qualifies the transfer operation.Here is an example of a transfer policy specifying a sticky policy, inspired by DTAG’s use case (namespaces are omitted to improve readability). The transfer policy allows to transfer personally identifiable location data to company X under the sticky policy <pol>, for the purpose of network quality improvement:

In this example, the auxiliary vocabularies need to be extended with three new classes: the class ex:ReartRate (as a subclass of svd:Health), ex:Profiling (a subclass of svpr:Analyze) and ex:Recommendation (a subclass of svpu:Marketing).

Here <pol> should be replaced with a policy written in SPECIAL’s language. Such policy may specify, for example, that the processing is Analyze and that it is carried out for the purpose of NetworkQualityImprovement, that there are no third-party recipients, et cetera.

Acknowledgements

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