Provenance-Aware Policy Definition and Execution - userpages

Provenance-Aware Policy Definition and Execution Christoph Ringelstein and Steffen Staab WeST - Institute for Web Science and Technologies University of Koblenz-Landau Universitaetsstrasse 1, 56070 Koblenz, Germany {cringel,staab}@uni-koblenz.de http://west.uni-koblenz.de

Abstract. The processing of data is often restricted by contractual and legal requirements for protecting privacy and IPRs. In the Internet, policies provide means to control how and by whom data is processed. Conditions of policies may depend on the previous processing of the data and thus on the temporal structure of processing histories. However, existing policy languages do not provide means to express the temporal aspects of such conditions. Thus, in this article we discuss how to connect policies and histories of data processing and how to address the temporal structure by mapping it to a graph structure.

1

Introduction

The Internet facilitates the distributed processing of data, e.g. the communication of data via a Web site or the processing via Web services and Web applications. The processing is controlled by means of contracts (e.g. service level agreements) and laws (e.g. privacy laws). In the Internet, we represent contracts and laws as policies that are statements of the goals for the behavior of a system [1]. Conditions of policies frequently depend on information about the environment (e.g. the receiver of a data transfer). However, often policies also depend on information about the data itself (e.g. the subject of a health record). Provenance information provides the information about the previous processing of data. By means of provenance information statements about properties of data can be made (e.g. has a health record been de-identified?) and about the flow of data (e.g. has the record been de-identified before it has been transferred?). However, existing policy languages are too weak to express policies based on provenance information. To overcome this weakness, we want to enable policy conditions to relate to the data and to the information about the data. Differently than most other domain knowledge representing environmental parameters, provenance information exhibits temporal structures that need to be represented and queried using expressions such as after or before. Developing a conceptually appropriate and easily implementable model is a problem that our approach addresses. Some policy languages support policies containing conditions based on the domain

knowledge part of provenance information (e.g. XACML [2] or Rei [3]). However, they lack a specification of how to specify or access the temporal structure of provenance information and including such temporal domain knowledge into purely declarative yet efficiently implementable languages such as Datalog constitutes a non-trivial challenge. To target these issues, one has to collect and provide provenance information first. In closed environments, the information can be collected with various existing logging mechanisms and can be accessed by means of various, often proprietary, solutions. However, as soon as processes span multiple organizations and data is transferred across organizational boundaries, one has to capture and provide the provenance information in a standardized manner. For this purpose, one may combine sticky logging [4], a distributed mechanism for collecting provenance information, with the open provenance model (OPM) [5] for representing provenance data in a standardized format. After providing the provenance, one must enable policy conditions to relate to provenance information and its temporal structure. Based on the open provenance model, we introduce a formal language that specifies the relation between policy condition and provenance information. We specify the language by means of an abstract syntax based on the syntactic structure of eXtensible Access Control Markup Language (XACML). We call our approach PAPEL: Provenance-Aware Policy definition and Execution Language. In PAPEL the complex temporal structure of processing histories is modeled as graph structure. In this article, PAPEL is presented using a run-through example. The complete definition of the syntax and formal semantics of PAPEL can be found in [6]. Finally, one has to address newly emerging privacy and IPR risks that arise by making provenance information accessible to policy engines. Such mechanisms must trade-off between the need to validate policy rules using provenance information and the requirement to protect privacy and IPRs, e.g. using log encryption [4]. Thus, the policy modeler should be enabled to freely choose between full or limited transparency of the forwarded provenance information. For achieving such flexibility, we introduce attributes and reduced facts. Together, they allow the policy modeler to disclose only an appropriate amount of confidential information to third parties.

About the Need to Connect Provenance and Policies Before we discuss the need to connect provenance and policies, we first introduce a small scenario that is based on our experiences in accessing confidential data (see figure 1). We will use the scenario through out the article as running example. Scenario: The Middle Rhine Hospital (mrh) is a local hospital that cooperates with research institutes. To this end, mrh shares health records of its patients with the research institutes. To track the processing of a patient’s health record 2

mrh collects the provenance of the health record. In addition, it demands research institutes to collect the provenance, too.

Fig. 1. Health Record Scenario.

A research institute of the University of Koblenz (ukob) requires data about actual patients for its research. To this end, it cooperates with the mrh. mrh forwards its patients’ health records to the research institute that can access the records on a server of the hospital via Internet. However, mrh does not allow the research institute to forward the data to any other organization: – (P1) ukob is allowed to process health records for research purposes. However, ukob is not allowed to transfer the health records of patients to other organizations. mrh requires the patients’ permissions before it is allowed to share the data. In addition, the patient permission has to be approved by a doctor: – (P2) The mrh demands that the sharing of health records is approved by the patient and the approval must be confirmed by a doctor before the record is accessed by ukob. Thus, the patients of mrh may choose if their data can be used for research or not (see step 3 in figure 1). The questions are provided in natural language, 3

e.g.: Do you allow the Middle Rhine Hospital to forward your health record to the University of Koblenz for research purposes? Yes / No. If patients permit the use, they may additionally demand that their data is only used after their names have been exchanged by pseudonyms. Jane Doe a patient of the mrh has specified a list of policies regarding her health record ( record JD) and the forwarding of the record to the research laboratory of ukob: – (P3) Jane Doe allows mrh to share her record for research purposes with ukob. – (P4) However, she demands that her record is transfered only after it has been de-identified. The record is de-identified1 by removing all data identifying the patient, like her name, her address, and other information that allows for connecting the health record with Jane Doe. The last part of the scenario, especially the policies P2 and P4, raises the following two issues regarding the sharing of health records: – (1) If ukob will access health records, the institute will need to know which actions are permitted or restricted. Because the allowed actions may depend on specific states of the processing history, ukob also requires the provenance information. – (2) The provenance information of a patient may contain personal information. Thus, the mrh wants to encrypt the provenance information before forwarding a record. At the same time the mrh has to ensure that the information needed to interpret the policies is still available without decryption. Based on these issues one can point out the following technical and organizational requirements: – Requirement ‘Availability’: The policies must be available to anybody accessing the associated data (see issue (1)). – Requirement ‘Expressiveness’: The used policy language must be able to express provenance based permissions and restrictions that support conditions based on temporal aspects of the history (see issue (1)). – Requirement ‘Accessibility’: The information required by policy conditions must be accessible even if confidential parts of the data and of the provenance information stay hidden (see issue (2)). In order to access policies such as specified in languages like XACML, one needs knowledge about the data, as stored in its provenance information, to address these issues and thus to meet the requirements. However, we first discuss provenance and policies in general before we connect both. 1

http://depts.washington.edu/clinres/clinicaltrialshandbook/1de-identified.html

4

About Provenance

Various monitoring mechanisms can be used to collect provenance information. We choose sticky logging [4] as depicted in Figure 1. Sticky Logging allows for attaching logs directly to the processed data and automatically forwards the logs along with the data. However, other approaches may also be employed, e.g. [7]. The provenance information must then be shared in an agreed upon format. One standard for provenance information is the Open Provenance Model (OPM) [5]. OPM defines the term processing as an action or series of actions performed on or caused by artifacts, and resulting in new artifacts. OPM [5] represents provenance of processing of data as graph structure. PAPEL represents the graph structure of OPM by the step primitive that represents single processing steps (see Definition 1). Definition 1 A processing step is defined as a 7-tuple with the following syntax: step (Data, Actors, InvolvedAgents, Category, Purpose, ID, PIDs) where: - Data is the artifact processed during the execution of the processing step, - Actors are the agents controlling the process, - InvolvedAgents are agents involved in a process that do not trigger the processing, - Category is the category of the processing step, - Purpose is the purpose of executing the processing step, - ID is the unique identifier of the processing step, and - PIDs are the unique identifiers of the directly preceding processing steps.

In OPM an artifact is defined as an immutable piece of state, which may have [..] a digital representation in a computer system and an agent is defined as a contextual entity acting as a catalyst of a process, enabling, facilitating, controlling, affecting its execution. An example of an involved agent in our running example is the ukob as receiver of the transfer of health records. The unique identifiers are specified as in OPM. From the relationships between the attributes ID and PIDs one can easily derive a partial order ≤S over the set of processing steps. The partial order constitutes a graph structure modeling the temporal structure of the processing history, whereby some actions may occur concurrently on different computer systems. Beside these constituents of OPM, the step primitive also specifies the Category and Purpose of a processing step. Both, the possible categories and the possible purposes are defined in a domain specific ontology.

5

Example 1: As depicted in Figure 1, the first processing step is the creation of the health record itself: Jane Doe is a patient of the mrh. The health record of Jane Doe is created by mrh. The purpose of the creation is treating Jane Doe as patient: step (record_JD, {mrh}, {}, create, patient_treatment, 1, {0}) This example and the following examples make use of the logical constants record JD, mrh, create and patient treatment which are defined in a domain ontology and corresponding databases provided by the Middle Rhine Hospital. For readability of the run-through example, we use integers to denote the identifiers though in general such a simplification is not possible. The information about the single processing steps is collected during the execution of a process and represents the processing history, which is defined as follows: Definition 2 A history H is defined as a set of processing steps, attribute assignments (see Definition 4) and reduced facts (see Definition 5). Be S the set of all processing steps and be A the set of all attribute assignments and be R the set of all reduced facts: H ⊆S∪A∪R Over each of the three sets S, A, and R a partial order exists (≤S , ≤A , and ≤R ). The transitive closure of the union of these order relations defines the global partial order ≤H over the elements of H (≤H = (≤S ∪ ≤A ∪ ≤R )∗ ). Not all elements of the history may be transferred to all other agents. A system owner may decide to disclose only partial provenance information to subsequent policy engines in the processing line in order to protect data or privacy. The reader will find more details on this in the corresponding section Protecting Privacy and IPRs, where we will also define attributes and reduced facts in detail. Next, however, we first want to explain the core of PAPEL, i.e. the aplication of policies on fully transparent provenance information.

About Policies To specify policies for inter-organizational exchange of data, PAPEL uses an existing policy language as starting point. PAPEL builds on concepts from the eXtensible Access Control Markup Language (XACML) [2], which is a standard defining an XML based policy framework. XACML supports three policy elements, i.e. permission (permit), restriction (deny) and obligation. XACML policies define rules by connecting a set of subjects (actors) with a set of targets (data) and by specifying the conditions of the rule. If the conditions are fulfilled, 6

XACML rules result in a given effect, which is permit or deny. In addition, a rule may require that certain obligations are met before a permission is granted. Policy rules (see Definition 3) are provided by the person concerned or IPR owner (see step 1 and 3 in figure 1). PAPEL2 models permissions as rules specifying which kinds of processing steps are permitted. Likewise, restrictions are modeled as rules specifying which processing steps are denied. Permissions are specified by means of permit rules and restrictions by means of deny rules (see Example 2). The rules consist of two parts: the name, which indicates the type of the policy (permit or deny), and the body of the rule, which defines the conditions, which are specified after the IF statement, and obligatory processing steps. The semantics of PAPEL define that all processing steps will be denied if not explicitly permitted. Denial can be used to overwrite or restrict the explicit permissions. Thus, conflicting permit and deny rules have to be interpreted as denial overwriting permissions. Definition 3 Policy rules are defined as a function permit : Φ 7→ {true, f alse} and deny : Φ 7→ {true, f alse}, where Φ is the set of all identifiers. The rules have the following syntax: permit (ID) IF Condition. deny (ID) IF Condition. where: - ID is the parameter to pass the identifier of a processing step that will be checked if it is permit or denied, and - Condition is the condition specifying whether an processing step is permitted or denied.

The parameter ID specifies the processing step that will be checked whether it is permitted or denied (e.g. permit (3) will check if the step with the identifier 3 is permitted). By using the variable parameter ID, the policy engine of an agent may match the condition of a rule against elements from the history known by this agent (see Example 2). The intuitive semantics of a condition is that it will be true for the corresponding ID, if the corresponding step, reduced fact or attribute assignment matches with the constraints formulated in the condition. In PAPEL conditions can be composed using the following logical operators: NOT, AND, OR, XOR and AFTER (see Example 4). Parentheses are used to specify the interpretation order of complex statements. By means of the AFTER construct one can access the partial order of the processing steps in the history and relate them to the status 2

See [6] for a detailed definition of syntax and semantics.

7

of the system at a particular point in time (in the subsequent section the reader will see a detailed example). Example 2: The policy P1 is created together with the creation of a health record (see processing step 1 in figure 1). This example formalizes P1 as a set of two rules: ukob is allowed to perform research on record JD . However, they are not allowed to transfer the data to any other entity: permit (ID) IF step (record_JD, {ukob}, _, _, research, ID, _). deny (ID) IF step (record_JD, {ukob}, _, transfer, _, ID, _). The Data parameter of the step primitive is set to record_JD, which is the unique identifier of Jane Doe’s health record. Thus, the two rules of policy P1 are directly connected to the health record of Jane Doe. The example uses unnamed variables indicated by _. The _ represents another unnamed variable each time it is used. An unnamed variable matches all possible values of its type.

Connecting Provenance and Policies Based on the modeling of provenance information and the specification of policies that disregard provenance information, one may now join the two and specify policies that take provenance information into account. To demonstrate the connection between policies and provenance information in PAPEL, we discuss the following specification of policy P4: Example 3: The patient demands that her health record record JD is transferred (step 6 of the scenario in figure 1) only after it has been de-identified (step 5): permit (ID) IF (step (record_JD, _, _, transfer, _, ID, _) AFTER step (record_JD, _, _, update, de-identify, _, _)). In this example, the first line of the policy refers to the current processing step involving record JD and referred to by the variable ID. a AFTER b specifies that the element a of the known history has to occur after the element b of the known history as specified by the partial order (≤H ). Thus, the second line in the example is refering to a step processing record JD and preceding ID. This example policy formulation would still allow for the possibility that record_JD was first de-identified, then re-identified and then transferred. If one wanted to rule out transfer steps in such a case one would have to add an explicit deny rule or query a variable status as allowed by the formulation of policies with attributes in the following. 8

Protecting Privacy and IPRs As stated above, the provenance information can be used as source of information about the processing history. However, the provenance information itself may contain sensitive data (e.g. the provenance information that the cancer medication has been adjusted). While full encryption of the provenance information (e.g. [4]) may render policy execution impossible, partial encryptions may trade-off between the need for checking policy compliance and security concerns (Requirement ‘Accessibility’). To this end, PAPEL introduces attributes as well as reduced facts. Attributes are used to specify provenance information that can be expressed by a value (e.g. de-identification status or modification counter). Thus, they can also be used to carry an attribute value over a set of processing steps in the history, until the attribute value is changed again. Definition 4 Attributes are defined as 4-tuples with the following syntax: attribute (Data, Name, Value, ID) where: -

Data is the data item the attribute belongs to, Name is the name of the attribute, Value is its assigned value, ID identifies the processing step.

The value of the attribute is assigned by the actor performing the processing step. The assignment is done according to the assignment rules defined by the creator of the policies. Each attribute has exactly one specific value at a time, possibly undefined. The latest setting of the attribute preceding a specific point in time specifies its value at this point in time (e.g. if the attribute de-identified is set to true in step 2 and not set again until step 6, it will still have the value true in step 6). If an attribute is set concurrently to different values, its value will be undefined at the point in time when the two concurrent histories join again. Example 4: This example illustrates the permit rule and the assignment rule required to implement policy P4 by means of the attribute de-identified of the record JD (see step 5 in figure 1). The policy rule of this example will grant the transfer of record_JD only, if it is not re-identified between the de-identification and the transfer steps: The patient demands that her record ( record JD) will transferred only if it is de-identified at the time of transfer:

9

permit(ID) IF (step (record_JD, _, _, transfer, _, ID, _) AND attribute (record_JD, de-identified, true, ID)). If the executed processing step de-identifies record JD, set the attribute named de-identified to true, and if the record is re-identified, set the attribute to false: assignment(ID) IF DO assignment(ID) IF DO

step (record_JD, _, _, _, de-identified, ID, _) set_attribute (de-identified, true, ID). step (record_JD, _, _, _, re-identified, ID, _) set_attribute (de-identified, false, ID).

However, attributes may not be expressive enough to provide all required information (e.g. has the last de-identification been performed by a specific actor?). To this end, someone who performs logging can use reduced facts in PAPEL. A reduced fact is a description of a processing step that is reduced to the necessary and contains only the required information. Differently than the full description, the information conveyed by the reduced fact must not be encrypted to not hamper querying the information. Definition 5 Reduced facts are defined as a 7-tuples with the following syntax: reduced_fact (Data, Actors, InvolvedAgents, Category, Purpose, ID, PIDs) where: - Data is the artifact processed during the execution of the processing step, - Actors are the agents controlling the process, - InvolvedAgents are agents involved in a process that do not trigger the processing, - Category is the category of the processing step, - Purpose is the purpose of executing the processing step, - ID is the unique identifier of the processing step, and - PIDs are the unique identifiers of the directly preceding processing steps. To protect data or privacy, the parameters Data, Actors, InvolvedAgents, Category, and Purpose can be set selectively to the special zero value hidden.

The parameters ID and PIDs must not be set to hidden. These two parameters are required to reproduce the (partial) order of processing steps. Example 5: The following example depicts the provenance information of a processing step of the department for nuclear medicine (see step 4 in figure 1): 10

The processing step updates the health record by adding a new cancer medication: step (record_JD, {nuclear_medicine}, {}, update, new_cancer_medication, 3, {2}) If this information is not relevant to the analysis of ukob, then mrh will encrypt the original information about the processing step and will provide reduced provenance information: reduced (record_JD, hidden, hidden, update, hidden, 3, {2})

Execution Semantics and Implementation The aim of PAPEL is to provide a syntax and semantics for policy conditions that can take the temporal structure of the processing history into account. The temporal structure results from state changes that occur with any processing step (e.g. setting of an attribute value). The two central challenges are, how to model the temporal structure and how to access specific states of the history (e.g. the value of the de-identified attribute before the last de-identification processing step). To express state changes a temporal semantics is required in general. PAPEL provides an intuitive syntax and semantics to express the temporal structure of a processing history including its state changes as a graph structure. Based on the chosen model, the processing history can be processed using first-order queries taking such state changes fully into account. Existing general-purpose policy languages, like XACML and Rei as well as any generalpurpose programming languages (e.g. Java or Datalog), can be used to implement PAPEL, but the conceptual difference between a general purpose policy language and a policy language that accesses state changes is a non-trivial one. Implementing PAPEL, we have demonstrated its feasibility. In the implementation the provenance information is provided as a database. To access the provenance information the implementation makes use of the database query language Datalog. We have chosen Datalog to provide a general, purely declarative implementation with a formal grounding. The implementation uses facts to specify the provenance information and rules to query it. The implementation is done by a mapping. Each PAPEL primitive is mapped to a Datalog fact with the same name. For each identifier in PAPEL (e.g. record JD) an unique atom in Datalog is created. For each policy rule in PAPEL a Datalog rule is created (see the Implementation Example below). Implementation Example: The following example depicts an implementation of policy P4 of our running example: 01: permit(ID) :- step(record_JD, _, _, transfer, _, ID, _), 02: attribute(record_JD, de-identify, true, ID).

11

To validate a set of policies in Datalog, the following preparation steps are required: (1) All Datalog rules required to specify syntactical elements are added to the database; (2) A Datalog fact is generated for each processing step, which is described by the provenance information. The facts are added to the database; (3) The Datalog rules specifying the policies are added to the database; (4) A Datalog fact specifying the processing step that should be performed is added to the database; and (5) Datalog fact is generated for each attribute assignment and added to the database. Finally, the database is queried if the processing step identified by the given ID will be allowed or not (see figure 1 step 6 and 7).

Related Work Many general purpose policy languages exist that might be applicable for our purpose. Thus, PAPEL is based on one of these existing languages. PAPEL makes use of the main policy elements ‘restriction’ (deny) and ‘permission’ (permit), as defined in the eXtensible Access Control Markup Language (XACML) [2]. Policies, which are based on complex environmental knowledge such as provenance information, can not easily be specified using XACML. Thus, PAPEL extends the expressiveness of XACML conditions to cover information about the processing history of data. As a foundation for more complex policy conditions we use the work of Kagal et al. [3]. They present a domain-centric and entity-centric policy language named Rei. Rei provides a mechanism for modeling of speech acts and delegation of policies. The conditions in Rei are specified by means of Prolog. However, Rei does not define how to model conditions based on provenance information. PAPEL extends the work of Rei by defining a formalism for conditions based on provenance information and by providing a model-theoretical semantics for the temporal structures and the state changes in [6]. New language primitives such as AFTER and assignment have been added in such parsimonious manner that PAPEL can be captured nicely in a purely declarative Datalog implementation. Related work in the area of temporal logic, linear temporal logic in particular, checks the compliance of histories with specified policies. For instance, Bauer et al. [8] describe access control policies that relate to histories of transactions using their policy language P T LT LF O . As P T LT LF O is a general purpose language, it does not define a specific semantics for provenance or data flows. However, P T LT LF O might probably be used to implement PAPEL. Other related work is the Web Services Policy 1.5 - Framework (WS-Policy) [9] that provides a model and syntax to specify policies about entities in a Web services-based system. As WS-Policy is used to specify policies about entities, e.g. Web services, and not about processed data, it is not in the target of the WS-Policy framework to model conditions based on provenance information. Table 1 gives an overview of this and further related work in the field of policy languages. The table compares the following properties of policy languages that are crucial for connecting policies and provenance information: In our example, mrh is required to associate its own and Jane Doe’s policies with her health 12

Casandra [12]

e-Wallet [13]

IFAudit [14]

PTLTL FO [8]

# Property 1 Linked to Individual Data Items X 2 Provenance Information X 3 Data flow Policies X 4 Access Control Policies X X X (1) X 5 Protection of Provenance Information X 6 Syntax Definition X X X X X 7 Formal Semantics X - X - (X) 8 Implementation X X X X X (1) WS-Policy provides data usage policies. (2) e-Wallet provides a formal policy processing algorithm.

XrML [11]

Rei [3]

WS-Policy [9]

EPAL [10]

XACML [2]

PAPEL

 Approach

record to make them available for ukob. To fulfill the Requirement ’Availability’, policies require to be associated with a specific data item (Property 1). In addition, mrh and Jane Doe must be able to express provenance-aware policies (Property 2). Thus, the Requirement ’Expressiveness’ asks for policy conditions that can relate to knowledge about the data, such as provenance information. Some scenarios require data flow (Property 3) and access control policies (Property 4) (e.g. in our example, mrh requires both access control and data flow control to express policy P1). Thus, we discuss, whether the policy languages allow for expressing data flow policies and/or access control policies. The availability of the provenance data (see Requirement ’Accessibility’) generates new risks for privacy and data protection. Thus, the policy language should be able to protect confidential provenance information (Property 5) (e.g. to maintain privacy and IPRs). Finally, the table gives an survey if the language has a syntax definition (Property 6), a formal semantics (Property 7) and an implementation (Property 8). The definition of the syntax and formal semantics of PAPEL as well as the description of its implementation is given in [6].

X X X X

X X X X

X X X (2) X

X X X X X

X X X -

Table 1. Related Work.

Hence, Table 1 shows that PAPEL provides an original and significant contribution by enlarging policy languages with provenance access. Naturally, many other dimensions may be relevant in different settings for policy definitions that are outside of the treatment in PAPEL but handled in these other paradigms, e.g.: Some policy languages define policies of actors (cf. [9]) or transactions (cf. [8]) not resources. In addition, other dimensions exist that are not treated by PAPEL but may be combined with PAPEL, e.g.: Some policy approaches provide methods to enforce policy compliance in closed environments, like organizations (cf. [10]) or data silos (cf. [13]). Other languages consider credentials 13

to gain access rights (cf. [11, 12]), support roles and role delegation (cf. [12]), or provide algorithms to identify violated policies (cf. [14]).

Conclusion Existing policy languages provide means to control how and by whom data is processed. The conditions of policies may depend on the previous processing of data. Such policies demand for controlling the process with respect to the history of the processing. However, existing policy languages do not specify how to access the temporal structure of provenance information and how to model state changes occuring in such historical data. To solve these issues, we have introduced PAPEL, a provenance-aware policy definition and execution language motivated by XACML and OPM. The aim of PAPEL is to provide a syntax and semantics for policy conditions that can take the temporal structures of processing histories into account. In addition, we have discussed how data protection can hamper the interpretation of policy conditions. We have presented means to validate compliance with given policies even if the required provenance information is confidential. Finally, we have demonstrated the feasibility of PAPEL by implementing PAPEL in Datalog.

Acknowledgment The basic idea of PAPEL has been motivated by discussion with Prof. Marianne Winslett and her working group. This work has been supported by the European projects Where eGovernment meets the eSociety (WeGov, FP7-248512) funded by the Information Society Technologies (IST) 7th Framework Programme.

References 1. Heather M. Hinton and E. Stewart Lee. The compatibility of policies. In CCS ’94: Proceedings of the 2nd ACM Conference on Computer and communications security, pages 258–269, New York, NY, USA, 1994. ACM. ISBN 0-89791-732-4. 2. eXtensible Access Control Markup Language (XACML) Version 2.0. Oasis standard, OASIS, February 2005. 3. Lalana Kagal, Tim Finin, and Anupam Joshi. A policy language for a pervasive computing environment. IEEE International Workshop on Policies for Distributed Systems and Networks, 0:63–75, 2003. 4. Christoph Ringelstein and Steffen Staab. DiALog: A Distributed Model for Capturing Provenance and Auditing Information. International Journal of Web Services Research (JWSR), 7(2), 2010. 5. Luc Moreau, Juliana Freire, Joe Futrelle, Robert McGrath, Jim Myers, and Patrick Paulson. The Open Provenance Model: An Overview. In Juliana Freire, David Koop, and Luc Moreau, editors, Provenance and Annotation of Data and Processes, volume 5272 of Lecture Notes in Computer Science, pages 323–326. Springer Berlin / Heidelberg, 2008. 10.1007/978-3-540-89965-53 1.

14

6. Christoph Ringelstein and Steffen Staab. PAPEL: A Language and Model for Provenance-Aware Policy Definition and Execution. In BPM 2010 - International Conference on Business Process Management, 2010. 7. P. M. Hallam-Baker and B. Behlendorf. Extended Log File Format. http://www.w3.org/TR/WD-logfile-960323.html, 1996. 8. Andreas Bauer, Rajeev Gor´e, and Alwen Tiu. A first-order policy language for historybased transaction monitoring. In Martin Leucker and Carroll Morgan, editors, ICTAC, volume 5684 of Lecture Notes in Computer Science, pages 96–111. Springer, 2009. ISBN 978-3-642-03465-7. 9. Web Services Policy 1.5 - Framework. W3c recommendation, W3C, September 2007. 10. P Ashley, S Hada, G Karjoth, C Powers, and M Schunter. Enterprise Privacy Authorization Language (EPAL 1.2). Submission to w3c, W3C, November 2003. 11. Xin Wang, Guillermo Lao, Thomas DeMartini, Hari Reddy, Mai Nguyen, and Edgar Valenzuela. Xrml – extensible rights markup language. In XMLSEC ’02: Proceedings of the 2002 ACM workshop on XML security, pages 71–79, New York, NY, USA, 2002. ACM. ISBN 1-58113-632-3. 12. Moritz Y. Becker and Peter Sewell. Cassandra: Distributed access control policies with tunable expressiveness. In POLICY ’04: Proceedings of the Fifth IEEE International Workshop on Policies for Distributed Systems and Networks, page 159, Washington, DC, USA, 2004. IEEE Computer Society. ISBN 0-7695-2141-X. 13. Fabien L. Gandon and Norman M. Sadeh. Semantic web technologies to reconcile privacy and context awareness. Journal of Web Semantics, 1(3):241–260, 2004. 14. Rafael Accorsi and Claus Wonnemann. Auditing workflow executions against dataflow policies. In BIS 2010: Proceedings of the 13th International Conference on Business Information Systems, pages 258–269, New York, NY, USA, 2010. ACM.

15