Privacy Module Tool


Drop files here


No files provided..










About


Linked USDL

Linked USDL (initial version: Unified Service Description Language) was developed for describing business and software services using computer-readable and computer­‐understandable specifications to make them tradable on the web/Internet, by comprising modules (e.g. usdl-core) where each module targeting a specific aspect.

Alongside with the business specifications, privacy has a crucial role in the services description. Personal data agreement properties should describe the privacy categorization that is applied onto the data that are provided, shared and utilized within the service and provide answers to the following questions.

How are data categorized into information types?

Which data is exactly collected (detailed specification)?

Who can access these data (which information type)?

Which actions describe each actor purpose (related with the data utlization and processing)?


Privacy module for Linked USDL

Through the implementation of the privacy module tool, we focused on tackling the privacy questions mentioned above - by categorizing the data into two main types of information and extending the basic usdl-core module by defining new business roles that describe each actor's role and interaction with the data at hand.


Data are categorized into two main types of information.

General knowledge information (Regular Data)

Sensitive personal information (Sensitive Data).

Actors are the end users of the service and can be either human or computer entities.

Owners (the users that are the 'original'' data providers to the service)

Person of Interest

Authorised Person

System users (system users, including the service provider, are the entities that consist the system and their work is strictly related from it)

Third-party users (the users that do not belong in the organization/system, where the Rightful owners provide directly their information)

Third-party providers

Third-party end users

Authority/Regulator


Actions are the available tasks that Actors can perform on the Data classifications based on their business scope and restrictions.

accessDenied

analyzes

distributes

maintains

modifies

oversees

processes

provides

storages


In addition, custom annotations were created for modelling various concepts that can be applied on data actions with their respective values. To be more specific, the custom annotations focus on the security enhancement (labelled as "securityenhancement"), use intention (labelled as "useIntention") and retention period (labelled as "retentionPeriod").


Privacy Module Tool

The developed tool* leverages the SPARQL language in order to extract information from ontologies that are designed based on the above data, actors and actions categorization and present the entire model properties in a user-friendly format.


Cite

Please cite this work using:

@inproceedings{kapitsaki2018linked,
title={Linked USDL Privacy: Describing Privacy Policies for Services},
author={Kapitsaki, Georgia and Ioannou, Joseph and Cardoso, Jorge and Pedrinaci, Carlos},
booktitle={2018 IEEE International Conference on Web Services (ICWS)},
pages={50--57},
year={2018},
organization={IEEE}
}.


*The tool was developed as a partial fulfillment of the thesis requirements for the MSc Computer Science Degree at the University of Cyprus. It can be extended without prejudicing the rights of the original work's authors. Linked USDL Privacy module is available on GitHub repository


More


Build Prerequisites

Upon modification of any javascript (.js) file we need to bundle up (using Browserify) all dependencies that are referenced in the code, due to the fact that browsers dot not have the 'require' method defined by default. Along with Browserify, we need to install some additional packages that allow us to bundle, copy/move and export our javascript code.

For convenience, we created a couple grunt tasks that allow us to automate the process of installing additional node modules (including Browserify), bundling our modified javascript files, and export them into the 'build' directory that the index HTML file will fetch them from.

Node.js and Grunt javascript tools are required for this automation and need to be installed.


Build Commands

Once all the required tools are installed, we can perform the following commands from within the project directory.

> 'npm install' (first time only, installs all required node modules)

> 'grunt' (required after each change in .js files, all tasks will be executed)


Ontologies Configuration

The tool supports ontologies that were build based on Protégé. Prior running the tool against an ontology, a verification should be made that in the first line of the ontology file the prefix is referring the actual ontology file and not some other required one (by default Protégé does so).

A simple format of the required configuration is as follows.

  1. @prefix privacy-topography: <http://www.semanticweb.org/user/2017/2/privacy-topography#> .
  2. @prefix owl: <http://www.w3.org/2002/07/owl#> .
  3. @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
  4. @prefix xml: <http://www.w3.org/XML/1998/namespace> .
  5. @prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
  6. @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema##> .
  7. @prefix actors-topography: <http://www.semanticweb.org/user/2017/2/actors-topography#> .
  8. @prefix data-topography: <http://www.semanticweb.org/user/2017/2/data-topography#> .
  9. <http://www.semanticweb.org/user/2017/2/privacy-topography> rdf:type owl:Ontology .