Privacy-Aware Role-Based Access Control (P-RBAC)

Ni et al. (Ni, et al. 2007) have defined the Privacy-Aware Role-Based Access Control (P-RBAC) model to support privacy related policies which are expressed as Permission Assignments (PA). Similar to RBAC in P-RBAC permissions are also assigned to roles and roles are assigned to users. However, the structure of a privacy permission in P-RBAC differs from the permission in RBAC. Along with the data and action it explicitly states the intended purpose, condition on

28

permission and obligation. The privacy policy is combined with the existing access control model and the formal definition of privacy-aware permission is also provided. Like RBAC the family of conceptual models of P-RBAC consist of core P-RBAC, hierarchical P-RBAC, and conditional P-RBAC. The hierarchical P-RBAC model introduces the notions of role hierarchy,

object hierarchy and purpose hierarchy. The conditional P-RBAC model allows thepolicy writer

to specify relations between different permission assignments; the notions of conflicting permission assignments and conflict detection algorithms are also provided. When a conflict is detected feedback is provided to the policy author to modify or discard the policy. Constrained natural language policies from policy authors are written with the SPARCLE policy workbench (which is a tool for authoring policy) and are transformed into P-RBAC permissions. Although these models theoretically associate data permissions with purpose, condition and obligation, the authors admit that they are too complex to implement practically. Qun Ni et al (Ni, Bertino and Lobo 2008) have defined the obligation model for P-RBAC, and have mentioned that the traditional policy based access control approach is not good enough for enforcing obligations as it can involve time interval, conditions as well as actions. The authors have also mentioned the features related to obligations. A language for specifying and handling obligations is proposed in (Li, Chen and Bertino 2012). These papers are discussed in detail later in Section 2.4.

Review of the model:

 Uses purposes with the permissions. The data subject can assign permissions and

those are matched with the requests and thus the data subject gets control over the access.

 Shows a way to write natural language policy rules by the user using a tool, thus policy

rules from the data subject can work as consents.

 Checks whether a request by a user for a data item is authorised by the permission and

thus it limits the uses and disclosure.

 With the enforcement of obligation it is possible to ensure that the data are deleted

after a certain event occurs.

 Does not address that data subjects can access the data. However, by assigning

permissions it is possible to ensure that.

 For enforcing obligations an obligation language is specified.

2.3.2.3 Privacy research of HP

HP has also worked on providing privacy of personal identity information by enforcing obligations. Mont (Mont 2004) has listed the different aspects that are required to deal with privacy obligations such as: validity period, event that triggers the obligations, enforceability of the obligation, target of the obligations and so on. He identifies the important issues that need to be considered for the management and enforcement of privacy obligations such as: modelling and representing privacy obligations, association of obligations to data, mapping obligations to data to name a few. Furthermore, this paper gives a high level design of the obligation management systems and provides a way of transmitting encrypted confidential data with obligations to other parties. Nevertheless, it only describes the obligations related to privacy and does not provide any uniform solution for integrating access control policies of the organisation with the privacy policies (set by the data subject). Mont et al. (Mont, Pearson and

29

Bramhall 2003 A) have proposed a way to obfuscate personal information to protect its content. Obfuscation of data is done using the sticky policies as the IBE encryption keys. Alteration of that key makes it impossible to generate the decryption key. The sticky policies are then associated with the obfuscated data. The receiver of the personal data needs to get the decryption key from the trusted authority (TA) and provides information to the TA as required by the disclosure policy. The trusted authority issues the decryption key only if the requester acknowledges compliance to the disclosure policies. Mont et al. (Mont and Thyne 2006) have described a privacy policy enforcement model with the technical details. In this model the requester's intent is checked against the purpose provided by the owner of the personal data to enforce privacy aware access control. No direct access to the databases is allowed in this model and the queries are analysed before using them for accessing databases. A working prototype has been integrated with HP Select Access, software for providing policy- based authentication and authorisation to web-based applications and web services. Mont et al. (Mont and Beato 2007) have presented an obligation management system that automatically derives related obligation policies from the privacy preferences provided by the users. This paper is reviewed in detail in Section 2.4.

Review of the model:

 Uses purposes with the preferences and the purposes are checked for authorising

access.

 Consent is taken in the form of preferences.

 Checks whether a request for a personal data item is authorised by the preferences of

the data subject and thus it limits the uses and disclosure.

 Accommodates a mechanism for obligation enforcement which also ensures data

deletion after the occurrence of certain event.

 Supports distributed enforcement by using a sticky policy paradigm.

2.3.2.4 Privacy research of EnCoRe

The Ensuring Consent and Revocation (EnCoRe) project (EnCoRe 2009) has worked towards the means for individuals to retain control over their personal data by providing and managing consent and revocation. By giving consent an individual gives permission to use personal data for specific purposes, under certain conditions. By performing revocation, on the other hand, s/he determines how personal data should be handled once it is disclosed. The key requirements and practical implications of handling consent and revocation are discussed in (Mont, et al. 2009). Consents define the privacy preferences and constraints on the personal data, how data should be used such as for a specific purpose and any obligation to be applied and so on. Revocation is a process by which an individual can modify or invalidate a previously given consent. A reference model for the management of consent and revocation is also provided. A consent and revocation policy is presented in (Agrafiotis, et al. 2010), which defines what consent preference a user can express and in what way he / she can revoke it. The privacy requirements and the related policies from different sources, such as legislation, organisation guidelines, user expectations and so on, are considered (Papanikolaou, et al. 2010). The authors have tried to find an intermediate representation of all the policies having different levels of abstraction so that it can embody all high level requirements and be translated into low level (machine executable) policies. Such a representation consists of syntax for conditions that need to be checked, syntax for immediate actions that need to be

30

performed if the conditions of a particular rule are met and syntax for obligations which the enterprise has if the given conditions are met. In (Mont, S. Pearson, et al. 2010) the authors have specified a hierarchy of policies based on the level of abstraction. Privacy policies of the laws and regulations constitute the top most layer since the requirements in these are presented in the most abstract form. In this hierarchy the low-level policies describe how privacy requirements are implemented; executable policy languages such as XACML belong to the lowest-level in the policy hierarchy. All the upper level policies eventually need to be translated into low-level policies for enforcing them. The preference of the data subject itself is treated as personal data. To protect access to the preferences of the data subject a complete separation of the decision making part of the authorisation system from the data access part is proposed in (Kounga, Mont and Bramhall 2010).

Review of the model:

 The user is given the option to modify or completely remove the previously given

consent which gives more control to the data subject over his/her personal data.

 Provides a way for verifying the compliance of the policies with the requirements.

 Accommodates mechanism for obligation enforcement.

 Plans to provide a user friendly interface in future.

 Conceptually includes access control policies from laws and regulations. However, it is

still lacking the practical implementation of the policies from law and they did not specify how these policies will be combined with the preferences of data subject and the organisation’s policy.

2.3.2.5 Platform for Privacy Preferences (P3P)

P3P (W3C 2002) has defined a machine interpretable format for websites to express their privacy practices in a standard format that can be retrieved automatically and interpreted easily by user agents. The notice and consent model of P3p allows websites to describe their privacy policies and users can read these and can choose to interact with the websites and thus provide their consent to the policies. P3P provides a human readable version of the policies, automated comparison of users’ preferences with the policies, reports if there is a mismatch as well as users’ preferences for viewing and changing policies. The limitation of P3P is that it just checks whether the users’ preferences match with the organisation’s stated privacy policies, it does not ensure whether the organisations actually enforce their stated privacy policies. It is notable that E-P3P (mentioned in Section 2.3.2.1) formalizes internal privacy practices of an enterprise while P3P formalizes advertised privacy promises.

Review of the model:

 Can use purposes with the preferences and the preferences along with purposes are

checked with the organisation’s stated privacy policies.

 Consent is taken in the form of preferences.

 Checks whether a user’s preferences match with the organisation’s stated privacy

policies. The data subject can assign, modify or completely remove preferences, but this model does not ensure the enforcement of the policy inside the enterprise and so does not actually provide control to the user.

 Provides a way for verifying the compliance of the policies with user preferences. But

does not provide a mechanism for verifying the compliance with the data protection requirements.

31

 Does not accommodate a mechanism for obligation enforcement.

 Provides a simple interface for obtaining users’ preferences.