Contract No.: 285248 Strategic Objective

15.5Main Interactions

15.5.1Architecture

Block Diagram

Every actor in this figure is running an instance of the Data Handling GE combined with their web application

Sequence Diagram

This sequence diagram reflects the use case depicted above. This explanation keeps the same concepts, focusing on detailing the main execution steps, however the numeration of the sequence diagram does not reflect exactly the one of written in the Use Case. Data Subject and Data Controller are distinguished instances of the Data Handling GE.

1. 
   Encrypt Data: 'This step is optional'. Before storing the data to protect with PPL, the data subject has the possibility to ecrypt the data with the Identity Based Encryption Module. The Data Subject uses the identity of the delegates as public key to encrypt the data.
   
2. 
   Store Data: The data subject can use PPL to safely store her data. During this storage phase, the data subject attaches a sticky policy containing usage and access control constraints related to her (encrypted) data.
   
3. 
   Request Data: The data controller requests the data to the PPL engine. If the Data controller is entitled to access this data, the PLL engine send her the (encrypted) data.
   
4. 
   Request private key: if the data provided by the PPL to the data controller is encrypted, the Data controller has to ask for a private key related to his identity (an identity can be for example an e-mail address). The PPL-IBE can send the private key embedded into a X509 certificate, or in a String mode (non protected).
   
5. 
   Decrypt the Data: If the data requested is encrypted, the data controller uses the private key provided by the PPL-IBE in order to decrypt the data.
   

15.6Basic Design Principles

The Data Handling GE permits to protect information according to a specific privacy policy. The Data Handling GE safeguards data, storing them together with the respective privacy policies. Any access to the protected resources can happen only declaring explicitly its purposes (using again a description encoded in a privacy policy). The Data Handling GE evaluates the two policies (data and access requests), and transmits the requested information if and only if the policies match.

15.6.1Detailed Specifications

The following is a list of Open Specifications linked to this Generic Enabler. Specifications labeled as "PRELIMINARY" are considered stable but subject to minor changes derived from lessons learned during last interactions of the development of a first reference implementation planned for the current Major Release of FI-WARE.

Open API Specifications

• 
  FIWARE.OpenSpecification.Security.DataHandlingGE.Open RESTful API Specification
  

15.7Appendix

15.7.1References

EC Data Protection directive	http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:31995L0046:EN:HTML
PPL	http://www.primelife.eu/results/documents/153-534d
XACML	http://xml.coverpages.org/xacml.html

15.8Architecture Description of the Accountability Feature

15.8.1Copyright

• 
  Copyright © 2014 by SAP, Inria
  

15.8.2Legal Notice

Please check the following Legal Notice to understand the rights to use these specifications.

15.8.3Overview

The Accountability Feature is an extension to the Data Handling GE (see its overview above). It consists of a log analyser that analyses PPL data usage logs and checks their compliance against joint (sticky) policies. Accountability of the data controller towards data subjects is realised by forcing the data controller to demonstrate, through mechanised compliance, that data handling proceeded accordingly to predefined rules.

Target usage

The Accountability Feature, used in conjunction with the Data Handling GE (see its target usage above) increases the trust of users about their privacy by providing them with strong guarantees and transparency about the actual processing of their personal data. The log analyser could be used by an accredited third party on behalf of a data subject.

15.8.4Basic Concepts

Relevant Concepts and Ideas

Accountability

In the Article 29 Working Party^[1] Opinion on the principle of accountability, the principle of accountability is defined as showing how responsibility is exercised and making this verifiable. From a legal perspective, accountability refers to obligations of a party (here, the data controller) with respect to another (here, the data subject) in terms of justification and demonstration with respect to a norm.

Here the goal is to increase the balance of power between those two entities. In particular, concerning data protection, our goal is to put in place effective measures to ensure compliance with privacy policies (both official regulations and the policies declared by the data controller). In fact, there is a need to record information reflecting the actual execution of the system (through logs) and to prove compliance, in order to enable effective, external audits.

Compliance Check of a PPL Log

This diagram depicts the interaction of the Accountability Analyzer, which implements the Accountability Feature, with its environment. The Data Subjects owns PII.

1. 
   The Data Controller and the Data Subject agree (by automated matching performed by the PPL engine) on a joint agreement called Sticky Policy.
   
2. 
   The Data Subject then provides his PII to the Data Controller. Data handling operations generate, via the PPL Logger, a trace of data handling events (the log).
   
3. 
   The Accountability Analyzer takes as input both the log and Sticky Policy and performs a compliance check based on the semantics of PPL. The Analyzer then concludes whether the sequence of events was compliant with the Sticky Policy, or whether it breached it.
   

15.8.5Main Interactions

The main interaction between this Feature and the Data Handling Generic Enabler is the use of the Feature to analyse traces of data handling events (logs) generated by the Data Handling Generic Enabler. The Feature takes as input a set of PPL log files: both the logs from the Event Handler, and the logs from the MySQL database. It checks their compliance against the relevant Sticky Policy and outputs a conclusion about the compliance of the data handling with the initially defined Sticky Policy.

The feature does not use APIs but a single executable, loganalyser, which takes as a parameter a PiiId (an integer).

15.8.6Basic Design Principles

The Accountability Feature checks data handling logs against corresponding Sticky Policies. The logs must be in the format produced by the PPL engine, unaltered. Sticky Policies are stored in XML files. The Accountability Feature's main component, the Analyzer, inspects the log and concludes that it is either compliant or non-compliant with the sticky policy.

In terms of design, the Analyzer parses log files and policies, and outputs its result according to predefined compliance semantics.

15.8.7Appendix

References

Article 29 Opinion on accountability

http://ec.europa.eu/justice/policies/privacy/docs/wpdocs/2010/wp173_en.pdf

1. 
   ↑ The group of representatives of European data protection authorities.
   

Download 1.78 Mb.

Share with your friends: