The internet can be seen as a standard means for a person to perform personal transactions such as online banking, travel reservations and job searches. These online service providers often require a certain amount of information, for instance name, address or credit card details. When giving this personal identiable information (PII), the user may be concerned about how this data will be used by the service and if data protection regulations are followed, for instance, will the service provider retain the information for a long period of time or will it be used by a third party?
In most cases this means that the data consumer's privacy policy is shown to the user as natural language text, and the user can accept it or not depending on her privacy preferences. Typically, if the user does not accept it, she is not allowed to proceed. This process should be automated to enable more complex interactions to take place, such as supporting the user in tracking the usage of her PII, facilitating enforcement of her privacy policy and dealing with more intricate cases, where the data exchanged comes from multiple sources, each one with its own privacy policy.
In the latter case, data must be aggregated as well as the privacy policy. To this extent, particularly relevant is the concept of sticky policy: privacy policies are strictly associated to a piece of data and should be composed whenever data aggregation happens. Expressing a condition for each piece of data, could be a means for data providers to declare how their personal information should be used. For instance, it may be specified that the information is not to be transferred to a third party or that it can be used for research purposes only. For example, a job applicant would like to create an electronic CV (eCV) that contains up-to-date information on her personal details (gender, age or race), work experience, academic qualifications and references. This personal information, could be entered either by the user or provided by other services such as a university, previous/current employers or an official entity, each of them containing corresponding privacy and access control constraints (e.g., not to be released for commercial purposes or for internal use only), expressed as privacy policies. The job applicant should be able to compose them in a single document with a single privacy policy, and be able to handle possible conflicts among policies.
On the other side, a job broker service may need to compose job offers from multiple sources and aggregate the corresponding policies. The aggregated policy may be simply the union of the source policies if they express non-conflicting conditions (e.g., one policy defines the purpose as research but it does not impose any condition on retention period) or, in case of conflicting conditions, more complex mechanisms may be needed. Even if privacy policy languages exist, such as P3P, EPAL or PRIME, they lack the notion of sticky policies or the complex composition of services or policies for resolving possible conicts.
Privacy Policy Composition Challenges
Within the Primelife European research project one of the scenarios exposed some challenges related to the policy composition on the data provider / consumer side. We provide here a short, non-exhaustive, list:
- Client Vs Server side: since the privacy policy on the server side is published to announce the way the data will be handled and the policy in the client side is stuck to the private data to describe how this data should be treated, it is important to distinguish between policies emanating from the client side and from the server side. Composing and enforcing such policies should be handled in a separate manner.
- Aggregation/Combination: the privacy policy engine must support aggregation of policies when multiple policies from different sources refer to a specific piece of data. Aggregation in this context refers to a combination of policies that refers to different data handling constraints not resulting in a conflict. In practice aggregation is
represented by a union of a set of policies. On the other hand, we call policy composition, when the policies refer to the same element and conict may arise.
- Trusted third-party: when the data consumer is composed of different services, then the data provider should be able to deal directly with the relevant trusted third-party (TTP) and not be obliged to divulge information unnecessarily. This TTP filters the relevant data that will be displayed to the server without any indication about the original dataset or the privacy policy.
- Negotiation: When the client or the server has a trade-off to make in order to achieve a transaction it is necessary to find a compromise between conflicting rules. For example, in the context of the scenario, the data producer may be willing to provide PII, if a criteria such as salary was above a certain threshold.
- Content-based condition: Policy condition may depend on the content of the data, e.g., data may be used for marketing purpose only if age, as reported on the CV, is greater than 21, or job level may be disclosed to third party only if less than a certain threshold. Such constraints are difficult to be addressed since they introduce an interaction between the data handling policy, which express how the data should be used, and the content of the data itself.
This work was carried out in collarboration with colleagues, Slim Trabelsi and Michele Bezzi and supported in part by the EU PrimeLife project, within the Seventh Framework Programme (FP7/2007-2013).
