D3.8: Study on protocols with respect to identity and identification – an insight on network protocols and privacy-aware communication

Title: PRIVACY POLICY LANGUAGES AND PROTOCOLS

Privacy policy languages are designed to support organisations and end-users in managing their privacy policies and preferences. In particular they may help regarding some or all of the following steps: writing, reviewing, testing, approving, issuing, combining, analysing, modifying, withdrawing, retrieving and enforcing privacy policies (Moses 2004, Kumaraguru et al. 2007). The development of privacy policy languages, the specification of their syntax and semantics, and the interaction with ICT systems, e.g., protocols for negotiating and matching policies, belong to a highly dynamic field. Since 1997 when W3C started the development of the Platform for Privacy Preferences (P3P), a variety of languages and protocols have been proposed which are specifically designed to manage privacy policies or – even if their main objective was less privacy-specific, can be applied for data protection purposes as well.

This section gives an overview of today’s privacy policy languages which are categorised according to their main areas of use. Important properties are briefly discussed. Finally, upcoming work to standardise privacy policy languages and protocols is described. 

Categorisation of privacy policy languages

Each proposal of a new privacy policy language or an enhancement of existing one has entailed discussions on advantages and disadvantages comparing the new approach with selected related work. However, in each scientific paper usually only two or three different policy languages to be used in the area of data protection are compared so that it is hard to get a broader overview. 

The most comprehensive proposal for a categorisation was recently done by Kumaraguru, Cranor, Lobo and Calo who presented their research plan on the SOUPS (Symposium On Usable Privacy and Security) 2007 conference in July 2007 (Kumaraguru et al. 2007). The authors classified thirteen privacy policy languages according to their categorisation scheme which we extended in this deliverable (see ). Another categorisation, based on the analysis of four privacy policy languages, was proposed by Madsen, Casassa Mont and Wilton who used their results to position Liberty’s ID-WSF (Liberty Alliance 2007) as a privacy policy framework (Madsen, Casassa Mont, Wilton 2006). Also Anderson, who is active in XACML specification, compared several privacy policy languages to propose an own advantageous specification (Anderson 2005, Anderson 2005-2006, Anderson 2006). Further, in the area of semantic web, work is done on policy languages and their comparison (e.g., Tonti et al. 2003; Oldemilla 2007; Bonatti, Oldemilla 2007).

Combining the results from all that work, we enhanced the categorisation proposed by Kumaraguru et al. (Kumaraguru et al. 2007), see . The following sections will give more information on each listed privacy policy language and point to further references.

Table : Categorisation of privacy policy languages (based on Kumaraguru et al. 2007)

According to Kumaraguru et al., the following categories can be distinguished:

1. Sophisticated access control languages: These languages are based on access control languages, especially on Role Based Access Control (RBAC). Usually they implement security policies maintained by system administrators.

2. Enterprise privacy policy languages: These languages are used within an organisation to enforce what has been stated in their internal privacy policy. This category is sometimes regarded as part of the first category because it also deals with sophisticated access control. However, we list it as an additional category to demonstrate the difference between those languages which explicitly deal with data protection and privacy issues.

3. Web privacy policy languages: These languages represent standardised human-readable privacy policies from web sites formats which can be interpreted by machines.

4. Context sensitive languages: These languages take into account the context when interpreting the policy, e.g., in the semantic web. They can be used for providing personalised services.

In all cases where privacy policies are not only limited to the internal use within an organisation (as it is the case with Enterprise Privacy Policy Languages), the categories above can be separated into the user’s perspective (defining preferences on how to deal with the data) and the organisation’s perspective (defining promises on how to deal with the data). 

Sophisticated access control languages

Access control languages do not solve all problems related to privacy or data protection. In particular principles like data minimisation or transparency are not in the main focus of access control languages. However, Sophisticated access control languages can implement many other properties of data protection and privacy, in particular pre-defined settings on “who is allowed to access personal data under which conditions?”. 

The most prominent examples in this category are SAML (Ragouzis et al. 2006) and XACML (Moses 2005a; Moses 2005b). The examples listed in are briefly explained:

Open Digital Rights Language (ODRL) is a rights expression language for digital asset management and e-commerce. It aims at the Digital Rights Management (DRM) community and is proposed to be used for expressing right information over content (Iannella 2002). It provides mechanisms to support transparent use of digital resources in publishing, distributing and consuming of electronic publications, digital images, audio and movies, learning objects, computer software and other creations in digital form. ODRL has been accepted by the Open Mobile Alliance (OMA) as the standards rights expression language for all mobile content.

Security Assertion Markup Language (SAML) is an XML standard for exchanging authentication and authorisation data between security domains (Cantor et al. 2005). SAML addresses in particular the web single sign-on problem. SAML is being developed by the OASIS Security Services Technical Committee. The latest version is 2.0.

Web Services Policy Language (WSPL) is a subset of XACML, i.e., the XACML profile for web services. It enables negotiating policies between entities on the level of constraints and assertions (Moses 2003). WSPL is a Working Draft in the OASIS XACML Technical Committee.

WS-PolicyConstraints has been developed by Anderson as a subset of WSPL to overcome the disadvantage that WSPL conflicts with WS-Policy and WS-PolicyAttachment (Anderson 2005-2006). WS-PolicyConstraints is a domain-independent language for expressing constraints for a web services policy.

XML Access Control Language (XACL) is an XML-based language to specify security policies to be enforced on specific accesses to XML documents (Hada, Kudo 2000). XACL’s authorisation model is not restricted to granting or denying read, write, create or delete access, but these primitive actions can be combined with additional actions such as auditing, digital signature verification, encryption, and XSL transformations.

eXtensible Access Control Markup Language (XACML) is a widely adopted standard language for access control, authorisation, and privacy policies (Moses 200). With XACML both privacy and security policies can be expressed in a machine-readable format. It is used for enforcing privacy policies. XACML is being developed by the OASIS eXtensible Access Control Markup Language (XACML) Technical Committee. The current version is 2.0, version 3.0 is in preparation.

Enterprise privacy policy languages

Enterprise privacy policy languages have been proposed since 2000. They represent the internal policies of an enterprise and support it to perform the actions as stated in its privacy policy. Often these languages are more fine-grained than web privacy policy languages. 

The most prominent example in this category is EPAL. The examples listed in are briefly explained:

The Customer Profile Exchange (CPExchange) specification integrates online and offline customer data in an XML-based data model for use within various enterprise applications both on and off the web (Bohrer, Holland 2000). It does not only standardise data formats for facilitating easier information exchange across the entire network, but also specifies metadata for associating privacy controls to the data. Privacy declarations are defined in a privacy header of a CPExchange document. The privacy information model is based on P3P, extending the Working Draft version from October 2000. The CPExchange specification is available in version 1.0.

Declarative Privacy Authorization Language (DPAL) is a formal policy language that evaluates and enforces all statements in the DPAL policy – (unlike in EPAL where the evaluation may terminate mid-policy on the first match (Barth, Mitchell 2004). Thereby it enables both local reasoning and combination of policies by concatenating separate policies. Every EPAL policy can be translated into a DPAL policy.

Privacy Rights Markup Language (PRML) is an XML-based language that allows for the definition of objects and a mechanism for linking these objects together to form privacy declarations (Zero-Knowledge Systems 2001). Objects can be roles, operations, data groups, subjects, purposes, constraints, actions and transformations. A PRML declaration specifies that a role can do an operation on a data group belonging to a subject for a purpose if (optionally) certain constraints are satisfied. A collection of PRML declarations form the privacy policy. On top of usual access control features, PRML can specify that an action should take place immediately after a defined event or before another operation can occur.

Zero-Knowledge Systems took IBM to court because it claimed that EPAL uses mechanisms from PRML and the jointly developed Enterprise Privacy Markup Language (EPML). 

Platform for Enterprise Privacy Practices (E-P3P) defines the enterprise privacy enforcement system for enterprise-internal privacy policies (Ashley et al. 2002; Karjoth, Schunter, Waidner 2002). When personal data are processed, E-P3P can be used to ensure that data flows and usage practices of an enterprise comply with the privacy statement of the organisation. E-P3P is the predecessor of EPAL.

Enterprise Privacy Authorization Language (EPAL) is a formal language for expressing enterprise privacy policies to govern data handling practices in IT systems according to fine-grained positive and negative authorisation rights (Powers, Schunter 2003). An EPAL policy defines lists of hierarchies of data-categories, user-categories, and purposes, and sets of (privacy) actions, obligations, and conditions. With these elements, privacy authorisation rules are defined that allow or deny actions on data-categories by user-categories for certain purposes under certain conditions while mandating certain obligations. EPAL allows for general rules and exceptions.

EPAL was developed by IBM. Version 1.2 was submitted as a W3C standard in 2003, but stalled because of the lawsuit with Zero-Knowledge Systems concerning intellectual property regarding EPAL. 

Web privacy policy languages

Web privacy policy languages represent human-readable privacy policies on the web server’s side as well as the user’s privacy preferences in machine-readable formats.  

The most prominent example in this category is definitely P3P - on the user’s side by now not many preference languages are used in practice. The examples listed in are briefly explained:

The Platform for Privacy Preferences Project (P3P) enables web sites to express their privacy practices in a standard format that can be retrieved automatically and interpreted easily by user agents (Cranor 2002; Wenning, Schunter 2006). The user agents can show the content of the privacy policy in the desired natural language by interpreting the machine-readable form, i.e. in XML format. They can react automatically, e.g., by displaying warnings if the policy does not match the user’s preferences. P3P 1.0 became a W3C recommendation in 2002. Today the P3P 1.1 Specification is published as a Working Group Note to give P3P 1.1 a provisionally final state. The P3P web site lists current implementations of P3P user agents, proxies, server-side support tools as well as policy generators, editors and checkers. Among them are current browsers (Internet Explorer or Netscape) which at least partially support the interpretation of P3P policies.

Parallel to P3P 1.0, a language for expressing user’s preferences was developed: A P3P Preference Exchange Language (APPEL). The APPEL preference rules can be used by the user agent to decide (semi-)automatically regarding the acceptability of P3P policies (Langheinrich 2002; Cranor 2002).

XPath-based Preference Language (XPref) was proposed to overcome shortcomings of APPEL, in particular difficulties and ambiguities when writing APPEL preferences (Agrawal et al. 2003). Based on XML Path Language (XPath), XPref is as expressive as APPEL, but easier to handle.

Context sensitive languages

Context sensitive languages are in particular developed for and on top of semantic web technologies. They represent policies that take into consideration context information, e.g., for offering personalised services. 

As the proposed languages are still quite young, it is not clear which ones to highlight as the most prominent examples in this category. An overview on many of these languages is given by multiple publications and tutorials from Olmedilla (Olmedilla 2007; Bonatti, Oldemilla 2007). The examples listed in are briefly explained:

Geographic Location/Privacy (Geopriv) is an authorisation policy language for controlling access to location information (Schulzrinne, Tschofenig 2007). The privacy-relevant properties of this policy language are the condition elements specific to location information in order to restrict access based on the current location of the target as well as location-specific transformation elements to reduce the granularity of the returned location information. Geopriv is proposed as Internet-Draft, i.e., as a working document of the Internet Engineering Task Force (IETF), and work in progress.

KAoS provides a framework for specification, management, conflict resolution and enforcement of policies (Uszok et al. 2003, Olmedilla 2007). This framework also offers distributed policy interaction and support for dynamic policy changes. System administrators can profit from KAoS Administration Tool when writing their policies. A KAoS policy contains authorisations, constraints and obligations. It is bases on the Web Ontology Language (OWL).

The PeerTrust language for expressing access control policies is based on guarded distributed logic programs (Gavriloaie et al. 2004). Version 1.0 is based on Java/Prolog and offers trust negotiation capabilities for servers and clients, with facilities to import and reason about access control policies, digital credentials, and metadata about local resources requiring protection. In contrast to a few other approaches, the authors of Peer Trust assume that the access control rules should be protected against unauthorised access too. PeerTrust is developed and maintained by members of the WG on Policy Specification, Composition and Conformance of REWERSE - there are plans for a version 2.0.

Ponder is a language for specifying management and security policies for distributed systems (Damianou et al. 2001). Similar to KAoS, it deals with authorisation and obligation policies, but in addition it supports refrain and delegation policies. A key concept is the expression of organisational structures, e.g., relationship between different roles, in policies. Ponder can also be used for security management activities such as registration of users or logging and auditing events for dealing with access to critical resources or security violations. Although Ponder is aimed at distributed systems, it is not explicitly designed for semantic web technologies.

Protune (Provisional trust negotiation) is the trust negotiation framework of REWERSE (Bonatti, Olmedilla 2005). Its policy language is rule-based and supports sophisticated access control policies as well as credential release policies. Protune provides an automated trust negotiation mechanism among the involved peers. During negotiations, peers exchange credentials, declarations, and policy rules (including privacy preferences). Protune’s policy rules can be filtered, i.e., “sanitised”, before releasing it because they can contain sensitive data. There is a prototype implemented on top of PeerTrust. A more robust system is planned to be made publicly available on the Open Source software development web site Sourceforge.

Rei is a logic-based policy language which is named after the Japanese word for “universal” or “essence”, to indicate the universal applicability of the policy language (Kagal 2002). It is based on domain-specific ontologies expressed in OWL and provides, on top of access control, features like constraints and obligations also logic-like variables which offer higher flexibility. Further it includes mechanisms for conflict resolution and supports remote policy management.

Discussion

The list of privacy policy languages given in the previous sections can neither be exhaustive nor can the specifications be explained in depth. However, the brief descriptions show the variety in this area and demonstrate which research groups from different disciplines within computer science work on that topic. 

Further categorisation and comparison work has to be done to identify which policies and protocols best suit in different application contexts, legal environments or specific contexts. 

A methodology for categorisation, partially related to the one shown previously in , was proposed by Madsen et al. (Madsen, Casassa Mont, Wilton 2006). They classify privacy policies according to the scheme illustrated in ).

Table : Exemplary categorisation of privacy policies (based on Madsen et al. 2006)

Privacy relevant criteria for data handling policies are given by Ardagna et al. (Ardagna, De Capitani di Vimercati, Samarati 2006):

1. “Individual control. Users should be able to specify who can see what information about them and when.

2. Consent. Users should be able to give their explicit consent on how their personal data can be used.

3. Correction. Users should be able to access their personal information to modify it when needed.

4. Security. Adequate security mechanisms have to be applied, according to the sensitivity of the data collected.”

Casassa Mont lists further requirements, concentrating on handling of privacy obligations (Casassa Mont, 2006). 

Further criteria for semantic web policies are elaborated by Bonatti, Oldemilla and others (Bonatti et al. 2006; Bonatti, Oldemilla 2007).

The World Wide Web Consortium continues its work in the privacy policy area and has recently established an Interest Group on Policy Languages as part of the Privacy Activity (W3C 2007). This group is called PLING - Policy Languages Interest Group. Its objective is the discussion and coordination of policy languages and W3C’s metadata framework. Quoted from the charter of this Interest Group (W3C 2007):  

“The group will primarily focus on policy languages that are already specified and broadly address the privacy, access control, and obligation management areas; it is not expected to engage in the design of new policy or rule languages. The Interest Group will work towards identifying obstacles to a joint deployment of such languages, and suggest requirements and technological enablers that may help overcome such obstacles.” 

The described work shows that during the following years there will be further development in the area of privacy policies and their protocols. In addition there will be investments on interoperability of different policy languages and frameworks.