Ioannis Agrafiotis
email: ioannis.agrafiotis@cs.ox.ac.uk

Sadie Creese
email: sadie.creese@cs.ox.ac.uk

Michael Goldsmith
email: michael.goldsmith@cs.ox.ac.uk

Formalising Requirements for a Biobank case study using a Logic for Consent and Revocation

In this paper we focus on formalising privacy requirements for the Oxford Radcliffe Biobank (ORB) case study that has emerged within the EnCoRe project. We express the requirements using a logic designed for reasoning about the dynamics of privacy and specifically for capturing the lifecycle of consent and revocation (C&R) controls that a user may invoke. We demonstrate how to tackle ambiguities uncovered in the formalisation and to bridge the gap between user requirements for personal data privacy and system level policy languages effectively.

Introduction

It is evident that there is an ever-growing amount of personal information shared by individuals over the Internet in order to obtain as users access to various products and services. However, the number of incidents of unexpected uses of such information is increasing and individuals have practically no control over their data. Innovative applications such as Web 2.0 and cloud computing raise the complexity of handling personal data effectively, and provide new challenges for privacy advocates.

This paper is inspired by work undertaken in the EnCoRe project 1 . The purpose of EnCoRe [9] is to build a system which will enable enterprises to collect and handle personal data while providing the individuals with the appropriate C&R mechanisms [START_REF] Agrafiotis | Reaching for informed revocation: Shutting off the tap on personal data[END_REF] to control the flow of their data, together with a way of ensuring that these mechanisms are effective.

In this paper we present and apply the novelties of the logic that occurred from addressing the ambiguities created when formal methods are applied for verification of the privacy properties of a system [START_REF] Agrafiotis | Applying formal methods to detect and resolve ambiguities in privacy requirements[END_REF] and our aim is to verify that no more ambiguities are created when applying the logic on a different context. We formalise the requirements of the EnCoRe system operating in a Biobank environment, using a logic for consent and revocation [START_REF] Agrafiotis | The logic of consent and revocation[END_REF]. The requirements of the system were elicited by analysing the system currently in place and by conducting several focus groups to gain a better understanding of the system's environment. In the second section of this paper we provide a synopsis of the C&R logic, in the third we describe the case study and in the fourth we discuss the requirements in more detail and express them in a formal notation. There is a progressive increase in the level of complexity of the formal notations. We begin by presenting the options that the patients may choose from when they donate their samples to the Biobank, then we demonstrate how these options are captured by the policies that the Biobank has in place and how an administrator could create new policies and we conclude by formalising different use cases of possible actions that could occur in the Biobank's system, named Sapphire. Finally, we outline the conclusion and indicate some opportunities for future work.

Related work

To set this work in context, the application of formal methods to privacy mainly focuses on translating privacy policies which are mostly written in natural language, into machine readable formats [START_REF] Tschantz | Formal methods for privacy[END_REF]. Languages like P3P [START_REF] Cranor | Web privacy with P3P[END_REF] and EPAL [START_REF] Ashley | Enterprise privacy authorization language (epal)[END_REF] are examples of these. Barth et al [START_REF] Barth | Privacy and contextual integrity: Framework and applications[END_REF] designed a logic for managing the dissemination of information based on Nissenbaum's theory of privacy as 'contextual integrity' [START_REF] Nissenbaum | Privacy as contextual integrity[END_REF]; this logic describes how different roles are allocated to people according to context and sets constraints on how people in these roles exchange data. They applied this logic to privacy policies such as Health Insurance Portability and Accountability Act (HIPAA) [START_REF] Barth | Privacy and contextual integrity: Framework and applications[END_REF] and the Children's Online Privacy Protection Act [START_REF] Barth | Privacy and contextual integrity: Framework and applications[END_REF]. Further research includes formal frameworks for privacy preferences such as SecPAL, that has been developed by Becker et al. [START_REF] Becker | A framework for privacy preferences and data-handling policies[END_REF]. However, none of these methods handle consent while they completely neglect the notion of revocation. Only the work presented in SecPAL could be complimentary to the logic presented in this paper. SecPAL handles the negotiation of policies and credentials between two parties, while in C&R logic we handle the lifecycle of users' C&R options, after a successful negotiation.

There is a general lack of work specifically addressing the processes of C&R in the context of personal data. While the concept of consent has been studied extensively in the social sciences [START_REF] Whitley | Information privacy consent and the 'control' of personal data[END_REF], leading to work on the necessity, meaning and consequences of informed consent [START_REF] Whitley | Perceptions of government technology, surveillance and privacy: the UK identity cards scheme[END_REF], few computer scientists have given the mechanics of such processes due attention.

Logic for C&R

We have formalised the C&R processes in terms of a simple Hoare Logic [START_REF] Agrafiotis | The logic of consent and revocation[END_REF]. We define a set of rights for principals that pertain to specific data δ. We identify a set of actions requested by principals in the system. These actions can be performed only when the involved principals have the adequate rights, and when completed can either affect the rights of the principals or create obligations for principals in the system, or both.

The rules for the logic are given in the form of Hoare triples, as follows:

{pre-condition} action(a, b, δ) {post-condition}
where a is the person that invokes the action and b is the person that will execute the action.

The precondition is a Boolean combination of (statements about) rights, which must be satisfied before the action can be performed. Every time the action is performed the state of the system changes from the one described in the pre-condition to the one described in the post-condition. The new state of the system is a combination of new rights and possibly also obligations. An obligation is a higher-order predicate that allows us to record the necessity of further actions consequent on the one just performed.

The state of the system is a specified set of principals (which could increase or decrease according to the performed actions) and a relation R that allocates rights to each principal of the system. In the initial state of the system, the only rights are those of the data subject who possesses full rights over the data; by definition, the data subject is the person whose data is being processed and inherently possesses all the rights that are defined in the logic. The data controller who is the person that will process the data has initially no rights at all on the data. The state of the system also records other variables such as time, notification constraints, etc.

In a previous publication we applied the simple version of the logic to an Employee case study [START_REF] Agrafiotis | Applying formal methods to detect and resolve ambiguities in privacy requirements[END_REF]. That exercise resulted in an enriched version of the logic, expressive enough to address ambiguities created either by the complex notion of privacy or by the translation of natural into formal language [START_REF] Agrafiotis | Applying formal methods to detect and resolve ambiguities in privacy requirements[END_REF]. In this paper we apply the extended logic that derived from the first formalisation, and our aim is to formalise a Biobank case study without any further ambiguities, than those identified and addressed in [START_REF] Agrafiotis | Applying formal methods to detect and resolve ambiguities in privacy requirements[END_REF].

In the extended logic, the state additionally includes consent variables and the actions correspond to smaller steps than in the simple logic used in our first attempt. Moving to a refined model we are able to offer finer granularity by introducing consent variables into the actions and model the intermediate states of the actions by refining them, by discriminating on who is performing an action (the data subject or the data controller) and by inserting new actions to evolve a small-step semantics. Although we are exhaustive in capturing all the actions that may be triggered in the system, we do not claim to be exhaustive when capturing the consent variables. On the contrary, new variables could be added and defined to enrich the logic's expressiveness and to capture the environment where the logic is deployed. It is not the purpose of the paper to illustrate the full range of actions, rights and variables available in the logic; thus, only those actions, rights and variables that will be used for the formalisation of the case study will be explained in the relevant section.

Description of the case study

The Oxford Radcliffe Biobank (ORB) is a "resource of tissue and blood samples donated by patients for use in medical research" [11]. As a result, the ORB collects and stores samples in accordance with regulatory requirements and provides fair access to researchers in order to improve diagnosis and treatment, and ultimately patient care. The ORB case study offers interesting issues in terms of managing C&R controls in a context where sensitive information is handled, legislation imposes strict controls and patients' requests need to be addressed.

We identify a number of use cases that provide an overview of the environment where the system will be implemented and we have elicited from these a list of requirements to explore the implications of invoking C&R controls. The use cases that are formalised in this paper are:

-The EnCoRe IT administrator creates C&R options that will be presented to the patient both for the sample and the data. -The EnCoRe IT administrator creates ORB privacy access control policies.

-The EnCoRe IT administrator creates ORB privacy obligation policies.

-The EnCoRe IT administrator sets CR default choices.

-The data subject (patient) or ORB technician makes CR choices for specific study/studies. -The ORB technician is registering a sample and/or personal data in a spreadsheet.

Formalisation of the use cases

In this section we apply the logic to the use cases and we provide evidence that no more ambiguities emerge. In the formalisations below we use the letter a to denote the patients of the ORB, the letter b to denote the ORB itself and the letter c to denote a researcher. We list in a hierarchy the data handled in this case study by creating three different domains in order to capture generic requirements (delete all data about my sample) by applying a single action to more that one datum, in a similar rationale to the one described in [START_REF] Bonatti | A component-based architecture for secure data publication[END_REF]. Each datum δ can only be allocated in one domain. With the letter δ we will generally refer to all data that may exist in this case study. We create three different domains and all δ data that may occur will belong only to one of these domains. With the letter δ 1 we denote the physical sample, with δ 2 the data derived from the sample and any measurements undertaken in the Biobank regarding the sample and with δ 3 we denote any personal data of the patient such as demographic data, name etc.

The EnCoRe IT administrator creates C&R options that will be presented to the patient

In this use case the administrator writes the set of C&R options to be offered to the patients. The options derived from the current consent form that the patient needs to sign before the donation of the sample to ORB, and from the results of the focus groups. We describe only the actions available that could be triggered in the system.

Based on the analysis of the focus groups, the options available to the patients concern the purpose for which the sample is given, the notification process and the ability to revoke and delete, the data created from the sample and the request for the distraction of the sample. Thus, the patient may give consent to the Biobank to store, process and share the data, constrain these choices by specifying the purpose of use and the parties that the data/sample will and will not be shared with. Furthermore, the patient could set notification preferences. It is not clear yet whether there will be an option allowing the patient to delegate consent to next of kin or update some of her/his data.

Define the options for sharing data with researchers The first option that a patient may express is to allow the Biobank to share the sample to researchers and provide restrictions regarding the purpose of the research, the background of the researchers and the duration of consent. This is formalised as:

grant * (a, b, δ, Φ)
where Φ = destination:Π ∧ ¬π ∧ purpose:u ∧ time duration:t ∧ times processed:t * and Π ⊆ {Pharmaceutical, University} , π ⊆ {Insurance Companies}and p ⊆ {teaching, cancer research, DNA}, t ⊆ {One year -40 years} and t * ⊆ {One time -100 times}. Notice that we use the letter δ for data, thus the options refer to all the available data. We could provide more options to the patient to choose from and apply these options only for a specific domain of data e.g the purpose for which the sample will be used for.

With this formalisation the patient may choose to share data with researchers working in university laboratories, with researchers working for pharmaceutical enterprises but not with researchers working for insurance companies. Furthermore, they could control the purpose of the research and choose to share their data with researchers for teaching purposes, for cancer research, and to allow or forbid DNA analysis. The variable Π includes the parties that the ORB is allowed to share data with, the variable π the parties that the ORB is not allowed to share data with and the variable u describes the purposes for which data may be shared. The ORB may also provide the option to the patient to choose the duration of consent and how many times the data/sample may be processed.

Define revocation and deletion options

We distinguish four different classes of revocation symmetrical to what the patients give consent to. 2 These options could affect the Biobank, the researcher or both and could be enabled either with a prospective or a retrospective effect. The options for prospective revocation that a patient may ask for are presented below:

-Revoke permission to process sample /data from the Biobank after the Biobank has finished processing it. The option of revoking consent and destroying/deleting the sample/data is formalised below. Whether the revocation is retrospective or prospective is defined by the value of the variable p. If the variable is true the revocation is retrospective, otherwise the revocation is prospective.

With the option below, the patient revokes the right to process the data/sample from ORB. If the Biobank is in the process of transferring the sample/data to other researchers they should withdraw it. Samples and data shared to researchers previous to that action are not influenced. The option is formalised as:

revoke(a, b, Φ, δ)

where Φ = currently processed : p and p = {true} With the option below, the patient revokes from ORB the right to share data/sample. If the Biobank is in the process of transferring the sample/data to other researchers they should withdraw it. Samples and data shared to researchers previous to that action are not influenced.The option is formalised as:

revoke * (a, b, Φ, δ)

where Φ = currently processed : p and p = {true} With the option below, the patient revokes from ORB the right to process the data/sample and cascades these changes to the researcher. Samples and data shared to researchers prior to that option should not be processed further. The option is formalised as: revoke † (a, b, Φ, δ)

where Φ = currently processed : p and p = {true} =⇒ obligation . With this option the sample/data that is stored to ORB is deleted/destroyed. The researchers that have acquired samples/data prior to that action should delete that as well.

delete † (a, b, δ 2 , Φ * )

where Φ * = disposal:x/wedgecurrently processed : p and x ⊆ {Destroy sample, delete data}and p = {true} =⇒ obligation. We describe a retrospective revocation as the patient wishes to revoke rights while the data is currently processed by inserting the variable p. We have introduced the variable x to provide the patient with the opportunity to decide either to destroy the sample or to delete the data that derived from that sample. Some of the revocation actions create obligations and all of them require actions to happen in the future before the patient may invoke them. For example, a patient cannot revoke permission from researchers to process their sample unless the Biobank has initially shared their sample with them.

Change of consent

The patient may also decide to change his initial consent. In this formalisation we capture the change of restrictions in the patient's initial consent. For example, changing the time allowed to process data to 5 months:

change * (a, b, δ, Φ)
where Φ = use by:t and t = 150.

Set notification options There is also the option for a patient to be notified under certain conditions. setnotify(a, b, δ, Φ)

where Φ = notify-how:n * ∧notify-what:n † and n * ⊆ {e-mail, general practitioner, ORB website} and n † ⊆ {results of the research, implication for health, new research, sample dispatched to researcher, sample destroyed} In this formalisation the patient may choose to be notified either by e-mail, or via their General Practitioner (GP) or via the ORB's website. Furthermore, the patient may choose to be notified when the results of the research are published, if the researchers by examining the sample identified that there could be further implications to her/his health, when the sample is dispatched for research or when it is destroyed.

EnCoRe IT administrator creates ORB privacy access control policies

In order to create ORB privacy access control policies the administrator needs to: (1) define, or select one of the templates offered by EnCoRe, and (2) deploy them into the system. The privacy policies will be created from the allowed actions and the variables that will provide further constrains and information regarding the implementation of those actions. The suggested policies for the ORB case study are: In the logic all the actions and the variables create a policy. The policy describes how the system will cope with each action and each variable and the patients' choices will define the values of the variables.Thus, the option of grant * (a, b, δ, Φ)

where Φ = destination:Π ∧ ¬π ∧ purpose:p ∧ time duration:t ∧ times processed:t * and Π ⊆ {Pharmaceutical, University} , π ⊆ {Insurance companies}and p ⊆ {teaching, cancer research, DNA}, t ⊆ {One year -40 years} and t * ⊆ {One time -100 times} is converted into an EnCoRe policy as: I {consent} for ORB to {share} my sample for {teaching, cancer research, DNA} to {Pharmaceutical, University} and not to {Insurance Companies} for the next {100 years} or being processed {100} times.

Each of the actions described in the previous section will create a separate policy with the same rationale. Some of the options include obligations which will be formalised in the section below.

The EnCoRe IT administrator creates ORB privacy obligation policies

To create ORB privacy obligation policies the administrator defines a set of obligation policy templates (and/or uses the templates offered by EnCoRe).

The privacy obligation policies are perceived in two different ways in the Hoare Logic:

-Those created to ensure that upon completion of an action, another action will be triggered in the future (notification requirements, delete data after 5 years). -Those created by the obligation of a data controller to request further action from third parties with whom data has been shared, for the initial action to be completed (request to propagate C&R changes to all parties that process data).

The form of obligation policies for notification requirements is:

1. I {consent/do not consent/revoke consent} for ORB to contact me about my data or sample via {e-mail, phone, post, GP} when {my sample is shared, results of the research have gone public}.

The option for notification formalised as:

setnotify(a, b, δ, Φ)
where Φ = notify-how:n * ∧notify-what:n † and n * ⊆ {e-mail, general practitioner, ORB website} and n † ⊆ {results of the research, implication for health, new research, sample dispatched to researcher, sample destroyed} will be converted into an obligation policy as: I {consent} for ORB to contact me about my data or sample via {e-mail, general practitioner, ORB website} when {results of the research are finalised, implication for health, new research, sample dispatched to researcher, sample destroyed}.

The EnCoRe IT administrator sets CR default choices To set the default C&R choices the administrator accesses the EnCoRe "admin tool" box that propagates configuration changes to required components.

{aOδ 2 ∧ bR † Φδ 2 } grant 1 (a, b, Φ, δ 2 ) {bLδ 2 ∧ bP δ 2 ∧ bSδ 2 ∧ bRΦδ 2 }
where Φ = destination:Π∧¬π∧purpose:p∧time duration:t∧times processed:t * and Π ⊆ {Pharmaceutical, University} , π ⊆ {Insurance Companies}and p ⊆ {teaching, cancer research, DNA}, t ⊆ {One year -40 years} and t * ⊆ {One time -100 times} and δ 3 is data regarding the patient's profile (registration number, further information)

The data subject (patient) or ORB technician makes CR choices for specific study/studies)

For specific studies the data concern a sample only. We could also introduce a new variable to denote that the patient is participating in a study and he/she should acquire more options regarding for example the purpose of the sample.

{aOδ 1 ∧ bR † Φδ 1 } grant 1 (a, b, Φ, δ 1 ) {bLδ 1 ∧ bP δ 1 ∧ bSδ 1 ∧ bRΦδ 1 }
where Φ = destination:Π ∧ ¬π ∧ purpose:p ∧ time duration:t ∧ times processed:t * and Π ⊆ {Team that consults me} , π ⊆ {Anyone else}and p ⊆ {DNA}, t ⊆ {One year -40 years} and t * ⊆ {One time} and δ 3 is data regarding the patient's profile (registration number, further information)

Patient registration When a new patient (data subject) registers, or more likely an authorised ORB employee is acting on his behalf by interacting with the ORB's system (Sapphire), it will assign a new patient ID, and then a new ID all linked to the new trial. This action is formalised as: The patient may also choose to set notification requests.

{aOδ 3 ∧ bR † Φδ 3 } grant 1 (a, b, Φ, δ 3 , ) {bLδ 3 ∧ bP δ 3 ∧ bSδ 3 ∧

The data subject (patient) or ORB technician changes CR choices for specific study/studies

In this use case the ORB technician logs into Sapphire and changes on the patient's behalf her/his choices.

{aOδ 1 ∧ bR † Φ δ 1 ∧ bRΦδ 1 } change(a, b, Φ, Φ , δ 1 ) {¬bRΦδ 1 ∧ bRΦ δ 1 }
where Φ = destination:Π ∧ ¬π ∧ purpose:p ∧ time duration:t ∧ times processed:t * and Π ⊆ {University} and p ⊆ {DNA}, t ⊆ {One year} and t * ⊆ {One time} =⇒ obligation. With the action above the patient chooses to change her/his consent regarding the sample and to limit the parties having access to it, the duration of consent and the times that it is allowed to be processed. This action implies an obligation because when the existing consent is no longer valid the patient should choose to delete his/her sample or to change his consent.

Tissue sample collection, data and C&R choices entry

When the sample is collected by the ORB, the patient expresses specific consent and revocation choices that should be enforced and respected by the ORB and any researcher that may acquire the sample. In the above formalisation the patient donates a sample to the ORB. The pre-condition declares that the donor of the sample is also the owner of the sample (aOδ), and that the ORB must be willing to accept their C&R choices (bR † δΦ, which will presumably be automatic, unless there are some forbidden combinations of tick-boxes on the form). The sample is then registered in the ORB. As a result in the post condition the ORB has stored the sample (bLδ) and it may process it (bP δ), share it (bSδ) but must always respect the restrictions the patient has imposed. In this case, the sample may only be shared with the university laboratories, specifically for cancer research purposes and DNA analysis.

The ORB technician is registering a sample and/or personal data in a spreadsheet

In this use case, the ORB is sharing data about a sample with a researcher in digital form. A researcher requests measurements of data from a sample and the Biobank provides the data in a spreadsheet. This is personal data, so all the controls that a patient may have imposed on the sample should be passed on.

{bSδ ∧ bRδΦ ∧ c ∈ ∪Φ.destination ∧ Φ * ≤ Φ ∧ cR † δΦ * } grant(b, c, δ, Φ * ) {cLδ ∧ cP δ ∧ cRδΦ * ∧
bN aδ setnotify(a, b, δ, Φ ) true ∧ bN aδ ∧ aN † δ ∧ "shared" ∈ ∪Φ.reason for notification

∧"e -mail" ∈ ∪Φ.means of notification ∀c.notify(b, a, δ, "shared", "e -mail") true :} : where Φ * = purpose : p and p={cancer research}. Note that we make use of a different action that only allows the researcher to process the data but not to share it. Also, all the controls that are appropriate for the right to process are cascaded to the researcher. Furthermore, as the patient had set notification requirements, an e-mail is sent to notify the patient that the data has been shared with the researcher.

The focus groups highlighted the importance of notification in such cases. If there are notification choices then there is an obligation triggered for the data controller to notify the patient. It is crucial to make a decision that will determine the strategy of notification. Possible options could be notification by e-mail, using a link on the Biobank's website pointing to the published papers of the researchers, or requesting the contribution of the patient's GP.

There will also be cases where the consent will not be specific enough for the Biobank to determine whether the sample should be shared or not. Therefore, the consent will be then implied. The patient could decide whether to be informed in such cases. Thus, depending on her/his choices she/he might choose to allow such sharing by default or to be asked for approval. However, the focus groups with researchers also pointed out that any notification may disturb the patients and their family.

Conclusion and future work

In a volatile environment, constantly changing due to innovations such as cloud computing, individuals disclose more personal data than ever. While these innovations allow them to acquire access to a number of services and products, the control they may have over their personal information is declining. The implications of such lack of control are profound when sensitive data and more specific medical data is handled by data controllers.

In this paper we have formalised requirements for a Biobank case study by applying a logic designed to handle C&R controls. We illustrate how diverse mechanisms of C&R may allow donors of the ORB to express their preferences and acquire control of their samples and data. Furthermore, with the formalisation of the requirements for such a system we effectively validated that patient choices are unambiguously described in order to be translated into privacy policies and enforced into the system.

Various avenues for future work could be followed. We intend to validate the C&R logic in a different real-world case study, namely the Identity Assurance Program organised by the UK cabinet office, in order to enhance our confidence in the general applicability of the logic. Subsequent research could apply the logic to translating privacy policies and form a strategy to resolve policy conflicts.

-

  Revoke permission to share sample/data from the Biobank after the Biobank has finished processing it. -Revoke permission to process sample/data both from the Biobank and the researchers after the completion of the research. -Destroy the sample/ Delete data Based on the same rationale, the different options of retrospective revocation offered are: -Revoke permission to process sample /data from the Biobank before the Biobank has finished processing it. -Revoke permission to share sample/data from the Biobank before the Biobank has finished processing it. -Revoke permission to process sample/data both from the Biobank and the researchers before the completion of the research. -Destroy the sample/ Delete data

  {aOδ ∧ bR † δΦ} grant * (a, b, δ, Φ) {bLδ ∧ bP δ ∧ bSδ ∧ bRδΦ} where Φ = destination : Π ∧purposep and Π = {University} and p = {cancer research, DNA} =⇒ obligation.

  1. I {consent/revoke consent} for ORB to {collect/store/use} my personal data for { any research (provided it has been approved by ORB and met all ethical standards of research); DNA specific research; selected clinical trials [list]; not at all} with access by {the research team that contacts me; pharmaceutical companies; others} (subject to time constraints/notification constraints). 2. I {consent/do not consent/revoke consent} for ORB to {collect/store/use} my {sample and associated digital representations} for {Specified purpose} (subject to time constraints/notification constraints) 3. I {consent/do not consent/revoke consent} for ORB to share my sample (or its digital representations) for {Specified purpose} to {direct contacts of the researcher, anyone} . 4. I {consent/do not consent/revoke consent} for ORB to share data for {any research (provided it has been approved by ORB and met all ethical standards of research); selected clinical trials [list]; only the research team that contacts me}

  bRΦδ 3 } where Φ = destination:Π ∧ ¬π ∧ purpose:p ∧ time duration:t ∧ times processed:t * and Π ⊆ {Pharmaceutical, University} , π ⊆ {Insurance Companies}and p ⊆ {teaching, cancer research, DNA}, t ⊆ {One year -40 years} and t * ⊆ {One time -100 times} and δ 3 is data regarding the patient's profile (registration number, further information)During tissue sample collection and data entry This use case is very similar to the one described in the section above, with the difference that before locally storing (in Sapphire) the data subject's sample, the ORB technician is asked to define preferences for the new sample added. When an ORB technician collects a sample, he logs onto Sapphire, selects the Samples tab and clicks Add Sample. He then fills in the required Sample details on the Sample Data Entry Page. If the sample has already been received, the status of the sample is set to 'Received'.{aOδ 1 ∧ bR † Φδ 1 } grant 1 (a, b, Φ, δ 1 ) {bLδ 1 ∧ bP δ 1 ∧ bSδ 1 ∧ bRΦδ 1 }where Φ = destination:Π ∧ ¬π ∧ purpose:p ∧ time duration:t ∧ times processed:t * and Π ⊆ {Pharmaceutical, University} , π ⊆ {Insurance Companies}and p ⊆ {teaching, cancer research, DNA}, t ⊆ {One year -40 years} and t * ⊆ {One time -100 times} Because it is a sample for trial we may want to introduce further variables to better describe the purpose of the research, such as DNA purposes.

There are four different types of consent formalised in the logic, namely consent to store data, consent to process, consent to share one step further, consent to share transitively. Thus there are four types of revocation formalised in the logic symmetrical to those of consent, namely deletion of data, revocation of processing, revocation of sharing one step further, revocation of sharing transitively.

 [START_REF] Agrafiotis | Reaching for informed revocation: Shutting off the tap on personal data[END_REF]The EnCoRe project [9] is an interdisciplinary research project, a collaboration between UK industry and academia, partially funded by the UK Technology Strategy Board (TP/12/NS/P0501A), the UK Engineering and Physical Sciences Research Council and the UK Economic and Social Research Council (EP/G002541/


Kaniz Fatema

David W Chadwick

Brendan Van Alsenoy
email: brendan.vanalsenoy@law.kuleuven.be

Extracting Access Control and Conflict Resolution Policies from European Data Protection Law

Keywords: Legal PDP, Legal Access Control Policy, Conflict Resolution Policy, EU Data Protection Directive

. A Legal Policy Decision Point (PDP) is constructed with a legal access control policy to provide automated decisions based on the relevant legal provisions. The legal conflict resolution policy is configured into a Master PDP to make sure that the legal access control policy gets priority over access control policies provided by other authorities i.e. the data subject, the data issuer and the data controller. We describe how clauses of the Directive are converted into access control rules based on attributes of the subject, action, resource and environment. There are currently some limitations in the conversion process, since the majority of provisions requires additional interpretation by humans. These provisions cannot be converted into deterministic rules for the PDP. Other provisions do allow for the extraction of PDP rules but need to be tailored to the application environment before they are configured into the Legal PDP.

Introduction

Although there are a number of legal instruments aiming to protect the personal data of individuals [1, [START_REF]OECD, Privacy and Personal Data Control[END_REF][START_REF]HIPAA 1996 privacy and Security Rules[END_REF][6][START_REF]Privacy Act[END_REF], the proper enforcement of these laws is often lacking. If the access control rules contained in these laws could be integrated in authorization infrastructures, this would arguably make the enforcement of data protection requirements more efficient and effective.

The use of policy based systems to protect personal data based on access control policies not new [START_REF] Karjoth | Privacy-enabled services for enterprises[END_REF][START_REF] Mont | Dealing with Privacy Obligations: Important Aspects and Technical Approaches[END_REF][START_REF] Ardagna | PrimeLife Policy Language[END_REF][START_REF] Trabelsi | PPL Engine: A Symmetric Architecture for Privacy Policy Handling[END_REF]. When developing a privacy preserving systems, it is important to keep in mind both the rights of the data subject as well as the legitimate interests of others. This balance of rights is critical and other researches, when designing policy based authorization systems to protect the privacy of personal data, have often overlooked this matter and focused primarily on the policy of the data subject [START_REF] Karjoth | Privacy-enabled services for enterprises[END_REF][START_REF] Mont | Dealing with Privacy Obligations: Important Aspects and Technical Approaches[END_REF]. In comparison, we have attempted to support this balance by building multiple policy decision points (PDPs) into the authorization system so that all the stakeholders can express their own independent policies [START_REF] Chadwick | An advanced policy based authorisation infrastructure[END_REF]. The system is designed to include access control polices and conflict resolution polices [START_REF] Fatema | A Multi-privacy Policy Enforcement System[END_REF] from different authors, possibly written in different policy languages (such as XACMLv2 [START_REF]OASIS XACML 2.0. eXtensible Access Control Markup Language (XACML) Version 2.0[END_REF], XACMLv3 [START_REF]OASIS XACML 3.0. eXtensible Access Control Markup Language (XACML) Version 3[END_REF], PERMIS [START_REF] Chadwick | PERMIS: a modular authorization infrastructure[END_REF], P3P [START_REF]W3C: The Platform for Privacy Preferences 1[END_REF] and so on) and these policies will be enforced in separate PDPs. Their decisions will then be combined by a Master PDP using the most appropriate conflict resolution policy.

For each item of personal data we consider policies may be written by up to four different types of authors: the law (the access control rules extracted from legislation will form a Legal PDP), the data issuer (e.g. for a degree certificate the university is the issuer, whilst for a personal diary the data subject is the issuer), the data subject (i.e. the individual to whom the data relates), and the data controller (i.e. the organization that is legally responsible for the personal data processing). When the controller's (or processor's) system receives a request to access a data item, it first retrieves all the policies related to the data item. The conflict resolution policies are prioritized in the order of law, issuer, data subject and controller. The policy which has the highest priority and is applicable to the current request is used by the Master PDP to resolve any conflicting decisions from the access control policies of the various authors.

The issuer's and subject's policies will always travel with the data as it moves across organizational boundaries. The controller's policy may or may not be transferred, since there might be a contract between the receiver (controller or processor) and sending controller which ensures that the receiver's policy shall be configured correctly. Alternatively, a subset of the sending controller's policy might be sent and merged with that of the receiver. The legal policy will not travel with the data if the data stays within the same jurisdiction (assuming the authorization system in the same jurisdiction has the same Legal PDP), but if the data is transferred to a foreign jurisdiction then it will be transferred. How foreign and local legal policies should interact and which should take precedence is still a matter for further study, since at the moment the rules for this are too complex to automate. We do not address this issue in the current paper, except that our Legal PDP can restrict the transfer of personal data to jurisdictions which do not have adequate legal protection unless the transfer is permitted by another lawful basis.

The main contribution of this paper is to present the rights of different groups of users to access any personal data as specified in the EU Data Protection Directive (EDPD), and to convert as many of these rights as possible into the rules of both an access control policy (held in a Legal PDP) and a conflict resolution policy (held in a Master PDP) so that automated and independent legally compliant decisions can be obtained. To our knowledge no other authorization system has such an integrated system. Having a separate Legal PDP and Master PDP is necessary to ensure that certain legal policies take priority over all other policies so that the rights provided by the law are not overridden.

The rest of this paper is structured as follows. Section 2 discusses related works; Section 3 describes the various steps of the methodology. Section 4 describes the validation test results and finally section 5 presents the limitations and conclusions.

The Enterprise Privacy Authorization Language (EPAL) [START_REF] Ashley | Enterprise Privacy Authorization Language (EPAL 1.2)[END_REF] is a privacy language that helps policy writers to define terms, conditions and rules to protect customers' personal information. However, it does not provide the ability to express statements that need to be enforced by multiple policies or for the logical combination of policies. The NEURONA [START_REF] Casellas | Ontology-Enhanced Legal Decision-Support Tools: The NEURONA Data Protection Compliance Application[END_REF][START_REF] Casellas | Ontology Semantics for Data Privacy Compliance: The NEURONA Project[END_REF] project developed a data protection application based on the Spanish data protection requirements that offer reports regarding the correct application of security measures to files containing personal data. If a file contains personal data but does not comply with the adequate level of security this is classified as an erroneous file by their ontology. They provide a semi-automated way to determine whether some aspects of the current state of a company's personal data files might not comply with the established set of regulations. Travis et al. [START_REF] Breaux | Analyzing Regulatory Rules for Privacy and Security Requirements[END_REF][START_REF] Breaux | A Systematic Method for Acquiring Regulatory Requirements: A Frame-Based Approach[END_REF][START_REF] Breaux | Analyzing Goal Semantics for Rights, Permissions and Obligations[END_REF][START_REF] Kiyavitskaya | Automating the Extraction of Rights and Obligations for Regulatory Compliance[END_REF] worked to automate the derivation of security requirements from regulations. They applied their method to the HIPAA regulations, but there is insufficient assessment of its applicability to other regulations [START_REF] Breaux | Analyzing Regulatory Rules for Privacy and Security Requirements[END_REF]. Furthermore there are limitations in their method such as relying upon a specific format of regulatory texts, and relying on the analyst's skills [START_REF] Breaux | A Systematic Method for Acquiring Regulatory Requirements: A Frame-Based Approach[END_REF]. In comparison, our work is based on an analysis and extraction of rules from the EDPD and converting these into executable policies so that automated decisions can be returned from a Master PDP.

Methodology

The methodology that we used to extract access control and conflict resolution rules from the EDPD [1] consists of seven procedural steps described below.

Step 1. Identifying provisions of the EDPD related to access control

The EDPD consists of seven chapters and 34 articles. We considered only those provisions which are directly related to access control. A provision is directly related to access control if it pertains directly to the access, collection, blocking or transfer of personal data.The general rules for the lawful processing of personal data are provided in chapter 2. The legitimate bases on which personal data can be processed are mentioned in Article 7. The legitimate bases on which sensitive personal data can be processed are mentioned in article 8. The information to be provided to the data subject while collecting or processing personal data is described in articles 10 and 11. Article 12 sets for the rights of the data subject with regards to the processing of his/her personal data, namely the rights of access, notice, rectification or blocking. The potential exemptions and restrictions to these rights are provided in article 13. The conditions under which personal data can be transferred to third countries are mentioned in articles 25 and 26; whilst article 28 describes the rights of supervisory authorities who is responsible for monitoring the application of their national data protection legislation.

Step 2. Extracting the Legal Access Control Policy

The provisions related to access control were examined one by one to assess whether they could (at least in part) be converted into rules that could be enforced automatically. Only the rules that are capable of giving an independent access control decision were kept i.e. the rules that are capable of saying who is allowed to perform which action on personal data under what conditions, or under what conditions personal data can be accessed. A provision was discarded if i) no access control rule can be extracted or ii) the extracted rule requires human judgment which cannot be easily translated into a deterministic rule, so that a fully automated enforcement is not possible. For example, article 6.1 (a) says "personal data must be processed fairly and lawfully" -this rule on its own is too vague to form an access control rule. Later in article 7 the criteria for making data processing legitimate are described, some of which can be converted into access control rules. For instance, article 7(a) states that "personal data may be processed only if the data subject has unambiguously given his consent". In our proposed system the data subject provides his/her consent in the form of the subject's privacy policy which says who may access his/her data for what purposes.

Article 6.2 states that "It shall be for the controller to ensure that paragraph 1 is complied with." This rule places responsibility on the controller to ensure that the EDPD is followed, but it does not form an access control rule itself. Article 8.2 (b) states that "processing is necessary for the purposes of carrying out the obligations and specific rights of the controller in the field of employment law insofar as it is authorized by national law providing for adequate safeguards" which is too complex to convert into an access control rule as it would for instance require encoding of all the employment laws. Article 12(b) states that "as appropriate the rectification, erasure or blocking of data the processing of which does not comply with the provisions of this Directive" is not possible to convert into an automated rule as it requires human judgement to evaluate whether the processing complies with the Directive. Article 12 (c) requires that third parties to whom data were disclosed be notified of any rectification, erasure or blocking carried out in compliance with article 12 (b). This rule is not feasible to present as an access control rule, but rather requires an update mechanism to satisfy the condition. After completing step 2 a total of 21 natural language rules were obtained.

The obligation to "Log the request" has been added only to the rules in which the actions may not have an immediate effect. For example, a data update request from the data subject may not take immediate effect if the controller needs to verify the accuracy or any other condition of the data.

Table 1. The Natural Language and Formalized Rules 1.

Natural language rule: If the requested purpose of processing does not match with the original purpose of data collection or is not for a historical purpose/statistical purpose / scientific purpose OR the validity time of data is before the requested time then deny the request. [From articles 6.1 (b) and 6.1 (e).] Natural language rule: A data subject can send data update requests for his/her personal data.[From article 6.1 (d) and article 12 (b).It is not possible to make an access control rule to verify which data are inaccurate or incompatible with regard to the purposes they were collected. However, this rule ensures that the data subject can send a data update request if he/she finds that the data is not accurate and the controller can either delete or update the data after judging the validity of the subject's request. The complete enforcement of this legal rule therefore requires human judgment.] Formalized elements for both ACR and CRR: Subject: Data Subject Resource: Personal Data Action: DataUpdateRequest Formalised elements for ACR: Effect: Permit Obligation: Log the request. Formalised elements for CRR: Effect: Permit Obligation: use DCA=grantOverrides

3.

Natural language rule: A data subject can submit a policy / update a policy for his/her personal data.

[From articles 7 (a) and 8. 2 (a), by submitting and updating a policy the data subject can give or update or revoke his/her consent] Formalized elements for both ACR and CRR: Subject: Data Subject Resource: Personal Data Action: SubmitPolicy/ UpdatePolicy Formalised elements for ACR: Effect: Permit Formalised elements for CRR: Effect: Permit Obligation: use DCA=grantOverrides

4.

Natural language rule: If the purpose of data processing is performance of a contract and both the data subject and the requester are parties to the contract then grant access to the resource mentioned in the contract.

5.

Natural language rule: Entities with a specific role (e.g. social security authority) can access a specific resource type (e.g., personal data related to pensions) and if the purpose is the performance of a task of public interest (e.g., social security administration) or an exercise of official authority. [From article 7 (e). The roles and resource types in the rule will need to be configured in light of the application and the national legislation.]

9.

Natural language rule: Medical professionals can BTG (break the glass) to medical data for purpose of medical diagnosis/ the provision of care and treatment / preventive medicine. [From articles 7 (d) and 8.2 (c). Break the glass is the ability to override access controls in case of emergency in order to gain access to data which is normally denied to the requester. This rule is an example of accessing personal data to save the vital interest of the data subject.] Formalized elements for both ACR and CRR: Subject: Medical Professional Resource: Medical Data Action: Read / Write Condition: RequestedPurpose = medical diagnosis/ the provision of care and treatment / preventive medicine. Formalised elements for ACR: Effect: BTG Formalised elements for CRR: Effect: Permit, Obligation: use DCA=grantOverrides. [START_REF] Ardagna | PrimeLife Policy Language[END_REF].

Natural language rule: The data subject can send "Object to Processing" with an obligation to log the request.

12.

Natural language rule: Anyone can transfer personal data from public register. [From article 26.1 (f)] Formalized elements for both ACR and CRR: Subject:Anyone Resource: personal data in public register Action: Transfer to Country=X Condition: value of X = one of the non EU/EEA country not having adequate level of protection Formalised elements for ACR: Effect: Permit Formalised elements for CRR: Effect: Permit, Obligation: use DCA=grantOverrides.

13.

Natural language rule: Personal data can be transferred to a non EU/EEA country not having an adequate level of protection if the subject unambiguously consents to the transfer OR if the purpose is performance of contract and the parties of contract are data subject and controller OR the parties of contract are controller and third party and contract's beneficiary is the data subject OR there is a transfer mandate; otherwise deny the transfer." [The rules are executed in order, so the rule b will only be executed when the conditions of a is not satisfied]

14.

Natural language rule: The Supervisory Authority can access and collect personal data for the performance of supervisory duties.

15.

Natural language rule: The Supervisory Authority can order the blocking/erasing /destruction of data, or impose a temporary ban on the processing or impose a definitive ban on processing. [From article 28.3] Formalized elements for both ACR and CRR: Subject Supervisory Authority Resource: Personal data Action: Order to block/ Order to erase / Order to destruct / Impose temporary ban/ impose definitive ban Condition: RequestedPurpose= performance of supervisory duties Formalised elements for ACR: Effect: Permit Obligation: LogTheOrder Formalised elements for CRR: Effect: Permit, Obligation: use DCA=grantOverrides.

Step 3. Refining the Access Control Rules

The natural language rules from step 2 were refined during this step by eliminating redundancy and duplication and by joining the rules together (if possible) to reduce their number. For example, the rule to deny an access if the purposes don't match with the original purposes of collection and the rule of denying an access if the request is made after the validity time is over are combined to form one rule. The two rules that allow/deny access to personal data by the data subject are combined together and the five rules that allow/deny the transfer of personal data to another country are combined to form a single rule. This left fifteen rules which are shown in Table 1. The order of rules is also determined at this step. For example, while combining the rules to allow/deny access to the data subject, the more specific rules that restrict the access are placed before the rule that grants access to the data subject. This ordering makes sure that the data subject can get access only when the conditions for which restrictions apply are false.

Step 4. Formalizing the Access Control Rules

In this step each of the natural language rules was formalized in the form of an Access Control Rule (ACR) and a Conflict Resolution Rule (CRR) as follows: Each legal ACR rule has a matching CRR to make sure the legal rule gets precedence over any other author's rules. The difference between the CRR and its corresponding ACR is that the effect of the CRR is always Permit and the obligational ways returns the DCA that is applicable. If an ACR has an effect of Deny, the corresponding DCA is denyOverrides and if an ACR has an effect of Permit the corresponding DCA is grantOverrides. If the ACR has an effect of BTG, the CRR's DCA is grantOverrides, since a grant from another PDP should not require the requester to first break the glass before gaining access. The formalization of ACRs and CRRs is provided in Table1.

Step 5. Attribute determination

For automated execution of these rules in an attribute based access control (ABAC) system [START_REF]Security Frameworks for open systems: Access control framework" PERMIS, Standalone authorization Server[END_REF] we need to determine the attributes of each of the elements in the rules. Four different types of attribute are used in constructing the policy rules. 1. Subject attributes 2. Action attributes 3. Resource attributes 4. Environment attributes. Subject attributes identify the users who are to be granted or denied access. Action attributes describe the action that is being controlled. Resource attributes describe the protected resource. In this case they are the metadata which describes the personal data being protected, and comprise attributes such as: resource type, data owner/issuer, data subject, date of creation etc. Environmental attributes describe the context in which the rule applies, such as time of day, location etc. These four types of attribute are also used to describe a user's request to access a resource, and are passed to the PDP in the request context by the application. PDPs compare the attributes of the user's request with those of the rules to determine whether access should be granted or not. We assume that the application is capable of storing the resource and its metadata securely, and retrieving the resource attributes and passing them to the Master PDP in the request context when a request for accessing that resource is received.

o The data subject is determined based on his/her set of identifying attributes (such as name and address, e-mail address, NI number, NHS Number etc.) given at the time the personal data is submitted or during the registration of the subject with the controller for a service. These identifying attributes become part of the resource's metadata. The Legal PDP checks if these identifying attributes match those of the requester (passed with the request context as subject attributes) to determine whether the requester is the data subject or not for the requested resource. In the current implementation the following sets of uniquely identifying attributes are used:{name and address}, {e-mail address}, or {NHS Number}, but these sets are configurable and can be changed and extended as needed by the application. The data subject should be able to choose any of these set of attributes to identify her/himself.

o ResourceType is a resource attribute that holds the type of the data, such as medical record, and is placed as a metadata of the resource by the issuer of the data. Only the issuer of the data can modify the ResourceType of that data. An ontology is needed to classify the different types of personal data, and an ontology mapping server (e.g. as described in [START_REF] Fatema | A Multi-privacy Policy Enforcement System[END_REF]) may be used to hold the data classification ontology and be able to determine whether a resource type is a type of personal data or not. The ontology server may also determine the relationship among these data types. For example, all the medical data types are subclasses of personal data. The rules for personal data will therefore be applicable to medical data but not the other way around.

o PurposeOfCollection (mentioned in rule 1 of Table 1) is another resource metadata attribute that states the set of purposes for which the data was collected from the data subject. It is set by the application when the data is first collected from the data subject. The Legal PDP matches this set with the RequestedPurpose(s) stated by the requester in the request context.

o ValidityTime (mentioned in rule 1 of Table 1) is another resource metadata attribute collected from the issuer or data subject. A default value can also be set by the controller if the issuer or data subject does not provide a value for it. The controller will need to mention the default validity time of the data when collecting it. The Legal PDP matches the time of the access request (passed as an environment attribute of the request context) with the ValidityTime of the requested data.

o Treating medical professional (mentioned in rule 8 of Table 1) is identified by an identifying attribute stored in the medical record of the patient (as a part of the metadata). The value of this attribute must match that of the equivalent attribute of the requester, in order for the requester to be identified as the treating medical professional. The name of this attribute is configurable in the legal policy.

o Medical Professional/ Supervisory Authority are Role attributes (mentioned in rules 5, 8, 9, 14 and 15 of Table 1) provided by trusted Attribute Authorities. Who are the trusted authorities for which roles depends upon the application, and these are configurable values in the legal policy.

o LegalObjection (mentioned in the rule 7 of Table 1) is a Boolean attribute of a resource (metadata) which are used to flag personal data which is not accessible to the data subject because of national legislation which contains an exception to the data subject's right of access (e.g., a doctor may have the ability to invoke a therapeutic exception to prevent the patient from accessing certain information). These attributes can only be issued by the designated (trusted) authorities.

o Data Access Mandate/ Data Transfer Mandate (mentioned in rules 6 and 13 of Table 1) are credentials which can only be obtained by a requester following the appropriate legal procedure. Conceptually these are treated as subject attributes in the policy, so that if a requester possesses the appropriate mandate attribute he/she inherits the permissions assigned to the mandate (the Data Access Mandate is assigned for allowing access to personal data and the Data Transfer Mandate is assigned for allowing the transfer of personal data). These legal mandates are issued by various trusted Attribute Authorities and both the trusted authorities and mandate types are configurable to suit the application. The requester (or the Attribute Authority) presents the Mandate to the application which will either verify it using a Credential Validation Service and pass the valid attribute to the PDP as a subject attribute, or pass it to the PDP as a subject credential for the latter to verify.

o PartyOfContract and SubjectOfContract (mentioned in rules 4 and 13 of Table 1) are attributes of a contract. A contract is hypothesised to be a digitally signed XML document which has an element called PartyOfContract containing the IDs of the people who are parties to the contract, and an element called SubjectOfContract containing the ID of the data subject. When a requester wants to access a subject's personal data for a purpose related to performance of the contract s/he will present the contract to the system. The ID of the data subject will be matched with the attributes in the contract. If both the requester and the subject are parties of the contract then access will be granted. If both the requester and the controller are parties of the contract and the data subject is the subject of the contract, then access will be granted. For validating contracts, a new trusted component called a Contract Validation Service (ConVS) is added to the system. To be able to access a data item based on a contract the requested data item should be mentioned in the contract. Therefore, in the contract along with the ID of the data subject (as a SubjectOfContract) the ResourceType is mentioned. If the requested resource's ResourceType and ID of the Data Subject mentioned in the metadata of the resource do not match with the ResourceType and the ID of the SubjectOfContract mentioned in the contract the access will not be granted based on contract.

o SubjectConsentsToTransferTo (mentioned in rule 13 of Table 1)is an environment attribute set by the application to the ID of the requester when a data subject consents to transfer his/her personal data to a requester. A requester can send a request for consent (via the application) to the data subject for transferring his/her personal data. If the data subject agrees to the transfer s/he can give his/her consent via the application (e.g. by clicking a button or ticking a box). This consent will be stored by the application and when the requester requests the data this consent (in the form of SubjectConsentsToTransferTo environment attribute) is appended to the request context by the application.

Steps 6 and 7. Implementation and Validation

The legal ACP (Access Control Policy) and legal CRP (Conflict Resolution Policy) containing the ACRs and CRRs have been converted into machine executable policies using both the XACML and PERMIS policy languages. For the construction of the CRP the format presented in [START_REF] Fatema | A Multi-privacy Policy Enforcement System[END_REF] is followed. All the CRPs are inserted in order into a Master PDP with the precedence of law, issuer, data subject and controller. When the first executed condition is satisfied by a request context a Grant decision is returned along with an obligation to use the enclosed DCA which is used to combine the various decisions returned by the Legal, issuer's, data subject's and controller's PDPs. The current implementation of the system can be downloaded from [24].

The authorization server is initialized with a configured Legal PDP, controller's PDP and Master PDP (containing a set of CRPs). Data subjects' access control policies are dynamically inserted into the system as sticky policies when the subjects' personal data is first received. Likewise a data issuer's access control policy may also be received as a sticky policy along with the data, unless the data controller or data subject is also the data issuer. In the former case the issuer's policy will be created when the data is created locally, in the latter case there won't be an issuer's policy. On the receipt of an authorization decision request, the authorization server retrieves the issuer's and the subject's sticky policies based on the requested resource id. A limitation of the current implementation is that it cannot dynamically process sticky conflict resolution policies.

Validation is performed by loading the XML implementation of legal policies into two PDPs -the Master PDP which determines and enforces the applicable DCA for each access request, and the Legal PDP which returns the legal decision for the request. These PDPs are then combined with the subject's, issuer's and controller's PDPs as appropriate. A set of test cases were generated in which various parties make different requests to access different personal data items. Comparison is done to see if the machine generated decisions and the human computed (correct) decisions are the same.

Validation Test Results

In order to validate the system two different sets of scenarios were developed: medical and employment. Here we only describe a subset of the medical scenario. Patient Mr. M registers with the Kent Health Centre and completes a registration form. He also gives his policy for access to his data, namely: Researchers are allowed to view my medical data for the purpose of medical research if the data is anonymized. His conflict resolution policy is: if a request is for my personal data DCA=denyOverrides. In addition the controller's policies say: 1. Administrative Officers can read and write administrative data (such as the contact information of patients, and which doctor is treating which patient etc.) but can't access the medical data. 2. Financial Officers can read the billing and payment information but can't read the medical data or administrative data. 3. Medical professionals can't access the billing and payment information or the patient's financial information. The controller's CRR says, for the request of any data the DCA is grantOverrides. Each resource has a unique RID and each resource consists of data and meta data. When creating data about a subject, the issuer mentions his ID (it can be a Role instead) for identifying himself and also mentions his access control policy saying 1. Only the issuer of the data can change the metadata such as the ResourceType. 2. Medical Professional can issue LegalObjection if there is a therapeutic exception which means that if the Medical Professional thinks that seeing the medical record may cause any mental or physical harm to the patient then s/he can issue a LegalObjection to stop the data subject from seeing the record. An inbuilt issuer CRR says that if the requester is the issuer and the resource=metadata then DCA=grantOverrides. An issuer is identified by the ID s/he provides when s/he first issues the data.

Mr. M goes for treatment to Dr. D at the Kent Health Center. When Dr. D tries to access Mr. M's medical data the Legal CRP returns grantOverrides and the Legal PDP returns Grant (based on rule 8 of Table 1) and so the final decision is Grant. Mr. M then has an X-ray. Dr. D enters the preliminary results into the Mr. M's record, and again the Legal PDP grants access as before. Dr. D decides to refer the patient to a lung specialist Dr. S at a London Hospital. Mr. M goes to Dr. S at the London hospital, who tries to access Mr. M's record at the Kent Health Center. The Legal CRP returns grantOverrides and the Legal PDP returns decision BTG (based on rule 9) and the other PDPs return notApplicable as they don't have any policy regarding the request. BTG is the final decision which is meant to be used for exceptional situations only. Dr. S suggests that Mr. M changes his policy at the Kent Health Center to allow Dr. S to access his medical data in future without having to break the glass. Mr. M requests the Kent Health Center to update his access control policy. The Legal CRP returns grantOverrides as the data subject is requesting to update his policy and the Legal PDP returns Grant (based on rule 3), so Mr. M changes his policy to allow Dr. S at the London hospital to access his medical record. The next time Dr. S tries to access the medical record the Legal CRP returns grantOverrides and the Legal PDP returns BTG as before, while Mr. M's PDP returns Grant; so the final decision is Grant and Dr. S can read the medical record straight way.

Mr. M is suspected of having an illness of which Dr. S suspects that if Mr. M knows this it would be harmful for him to know that at the moment, so he issues LegalObjection=True for the metadata of this medical data to protect the data subject from a serious harm. This is granted due to the issuer ACR and CRR. Now Mr. M requests to view all his medical data. The application goes through each record asking if Mr. M can read the record. The Metadata of this specific medical record of Mr. M will have. The Legal CRP returns denyOverrides and the Legal PDP returns decision Deny for this record (based on rule7.a) and Grant for the other records (based on rule 7.b), so Mr. M does not learn of this specific illness.

An administrative officer tries to read the Medical record of Mr. M. The Legal CRP and Issuer CRP do not have any CRR matching the request context so the DataSubject's CRP returns denyOverrides. The Legal, issuer and Mr. M's PDPs return notApplicable, whilst the controller's PDP returns Deny so the final decision is Deny.

A researcher wants to access the medical data of Mr. M for medical research at the Kent Health Centre. The DCA is denyOverrides by the DataSubject's CRP. The Legal, issuer and controller PDPs return notApplicable, Mr. M's PDP returns Grant with an obligation to anonymise the data. If the obligation can be fulfilled by the application then a Grant decision (according to the algorithm of denyOverrides [START_REF] Fatema | A Multi-privacy Policy Enforcement System[END_REF]) is returned along with the anonymised data. If the obligation can't be fulfilled a Deny decision is returned.

Conclusion and future work

We have presented a system that incorporates a Legal PDP and legal conflict resolution rules into an authorization server to enforce several of the rights and obligations outlined in the EDPD. The main advantage of having a separate Legal PDP is that it can automatically enforce certain legal provisions and allows administrators to see what these rules are. Having separate conflict resolution rules enforced by a Master PDP ensures that no other PDP can override the decisions of the Legal PDP. However, both the current design and implementation have their limitations. The Legal PDP does not completely capture all the legal constrains due to the complexity and nature of some of its rules. Some conditions are extremely complex to automate and some decisions are highly dependent on human judgment and/or intervention, so these cannot be automated. For instance, if a data subject exercises his right of deletion or blocking of data on the basis that the data was obtained unlawfully, human intervention is necessary in order to determine whether this is in fact the case. Furthermore, how foreign and local legal policies should interact and which should take precedence is still a matter for further study, since at the moment the rules for this are too complex to automate. The proposed approach is therefore an initial proof of concept only. Several requirements may be far more complex in practice than are presented here, due to the divergences of national or sector specific laws from the European Directive. In a future contribution we aim to develop rules which can better accommodate this greater complexity.

  Formalized elements for both ACR and CRR: Subject: Anyone Resource: Personal Data Action: Read Condition: NOT (RequestedPurpose = PurposeOfCollection OR RequestedPurpose = historical purpose OR RequestedPurpose = statistical purpose OR RequestedPurpose =scientific purpose) OR validity time earlier than the requested time. Formalised elements for ACR: Effect: Deny Formalised elements for CRR: Effect: Permit Obligation: use DCA=denyOverrides 2.

  [From article 7 (b) and 15.2 (a)] Formalized elements for both ACR and CRR: Subject: Anyone Resource: Personal Data Action: Read/Write Condition: RequestedPurpose = performance of contract AND PartyOfContract= Data Subject AND PartyOfContract= Requester, AND requested resource = resource specified in contract Formalised elements for ACR:Effect: Permit Formalised elements for CRR: Effect: Permit Obligation: use DCA=grantOverrides

8 .

 8 Formalized elements for both ACR and CRR: Subject: Role X ResourceType: Y Action: Read Condition:RequestedPurpose = performance of a task of public interest OR RequestedPurpose = exercise of official authority Formalised elements for ACR: Effect: Permit Formalised elements for CRR: Effect: Permit Obligation: use DCA=grantOverrides 6. Natural language rule: Anyone with a Data Access Mandate can access the personal data. [From articles 7 (c), 8.2 (e) and 8.4]. See also section 3.5. Formalized elements for both ACR and CRR: Subject : Anyone Resource : Personal Data Action: Access Condition: DataAccessMandate=true Formalised elements for ACR: Effect: Permit Formalised elements for CRR: Effect: Permit Obligation: use DCA=grantOverrides 7. Natural language rule: A data subject can read his/her personal data if there is no legal objection within national legislation [From art. 12 and 13.1] a. Formalized elements for both ACR and CRR: Subject : Data Subject Resource: Personal Data Action: Read Condition: LegalObjection = true Formalised elements for ACR: Effect: Deny Formalised elements for CRR: Effect: Permit, Obligation: use DCA=denyOverrides. b. Formalized elements for both ACR and CRR: Subject: Data Subject Resource: Personal Data Action: Read Formalised elements for ACR: Effect: Grant Formalised elements for CRR: Effect: Permit, Obligation: use DCA=grantOverrides. [The rules will be executed in order, so that rule b will only be true if the condition of rules a is false or missing] Natural language rule: The treating Medical Professional can Read/Write medical data for the purpose of preventive medicine, medical diagnosis, prevention of care or treatment or the management of health care service. [From article 8.3] Formalized elements for both ACR and CRR: Subject: Medical Professional Resource : Medical Data Action: Read / Write Condition: Medical Professional = a treating Medical Professional of the patient AND RequestedPurpose = medical diagnosis/ the provision of care and treatment / preventive medicine. Formalised elements for ACR: Effect: Permit Formalised elements for CRR: Effect: Permit, Obligation: use DCA=grantOverrides.

  [From article 12 (b), 14 (b) and 15.1] Formalized elements for both ACR and CRR: Subject: Data Subject Resource: Personal Data Action: Object to Processing Formalised elements for ACR: Effect: permit, Obligation: Log the request Formalised elements for CRR: Effect: Permit, Obligation: use DCA=grantOverrides. 11. Natural language rule: Medical Professional can BTG to transfer medical data to a non EU/EEA country not having an adequate level of protection. [From article 26.1 (e)] Formalized elements for both ACR and CRR: Subject: Medical Professional Resource: Medical Data Action: Transfer to Country=X Condition: value of X = non EU/EEA country not having adequate level of protection Formalised elements for ACR: Effect: BTG Formalised elements for CRR: Effect: Permit, Obligation: use DCA=grantOverrides.

  [from article 26.1 (a), (b), (c), (d), 26.2 and 25.4] a. Formalized elements for both ACR and CRR: Subject: Anyone Resource: Personal data Action: transfer to country=X Condition: value of X = (one of the non EU countries OR countries not having adequate level of protection) AND(value of SubjectConsentsToTransferTo= ID of requester OR (RequestedPurpose = performance of a contract AND ((PartyOfContract=Data Subject AND PartyOfContract= controller) OR (PartyOfContract=controller AND SubjectOfContract=dataSubject AND BeneficiaryOfContract=Data Subject))) OR DataTransferMandate= true) Formalised elements for ACR: Effect: Permit Formalised elements for CRR: Effect: Permit, Obligation: use DCA=grantOverrides. b. Formalized elements for both ACR and CRR: Subject: Anyone Resource: Personal data Action: transfer to country = X Condition: value of to "country X" ≠ one of the countries in the list of allowed countries Formalised elements for ACR: Effect: Deny Formalised elements for CRR: Effect: Permit, Obligation: use DCA=denyOverrides.

  [From article 28.3] Formalized elements for both ACR and CRR: Subject: Supervisory Authority Resource: Personal data Action: Access/ Collect Condition: RequestedPurpose= performance of supervisory duties Formalised elements for ACR: Effect: Permit Formalised elements for CRR: Effect: Permit, Obligation: use DCA=grantOverrides.

  ACR -Subject: (who) Resource: (which data item) Action: (what action) Condition: (under what conditions) Effect: (Permit, Deny or BTG 1 ) Optional Obligation: (subject to these actions being carried out); CRR -Subject: (who) Resource: (which data item) Action: (what action) Condition: (under what conditions) Effect: (Permit) Obligation: (Decision Combining Algorithm (DCA) to be returned).

Break the Glass means that the requester is not normally allowed to access the resource, but if they deem it to be an emergency situation, they can override the access controls and access the resource, in the full knowledge that their actions will be monitored and they will be answerable for them to a higher authority.