Integrating Privacy Policies into Business Processes

Michele Chinosi and Alberto Trombetta

Universit`a degli Studi dell’Insubria

Dipartimento di Informatica e Comunicazione

via Mazzini 5, 21100 Varese, Italy

Abstract. The increased interest around business processes management and

modeling techniques has brought many organizations to make signiﬁcant invest-

ments in business process modeling projects. One of the most recent proposal

for a new business process modeling technique is the Business Process Model-

ing Notation (BPMN). Often, the modeled business processes involve sensible

information whose disclosure is usually regulated by privacy policies. As such,

the interaction between business processes and privacy policies is a critical is-

sue worth to be investigated. Towards this end, we introduce a data model for

BPMN and a corresponding XML-based representation (called BPeX) which we

use to check whether a BPeX-represented business process is compliant with a

P3P privacy policy. Our checking procedures are very efﬁcient and require stan-

dard XML technology, such as XPath.

1 Introduction

The ever-increasing interest around business processes management and modeling tech-

niques has brought many organizationsto make signiﬁcant investments in business pro-

cess modeling efforts. The Business Process Management (BPM) has been identiﬁed

as one of the most important business priorities. The Workﬂow Management Coalition

(WfMC) deﬁnes BPM as a set of one or more linked procedures or activities which

collectively realize a business objective or policy goal, normally within the context of

an organizational structure deﬁning functional roles and relationships [1]. As such, it

introduces methods, tools and techniques to support the development and the analysis

of operational business processes. Inside this context, business process modeling tech-

niques and languages are of absolute relevance. Again, WfMC deﬁnes business process

modeling as the time period when manual and/or automated (workﬂow) descriptions

of a process are deﬁned and/or modiﬁed electronically [1]. One of the most recent pro-

posal for a business process modeling technique is Business Process Modeling Notation

(BPMN), adopted as standard by OMG [2].

The adoption of BPMN as a standard allows companies to deﬁne complex busi-

ness processes possibly encompassing different administrative boundaries and request-

ing non-public data whose access is regulated by security-driven policies. In particular,

privacy-related user data represent a relevant asset for companies and administrations.

As such, in the recent years, several efforts have been made in order to provide mech-

anisms for expressing (and in some cases, enforcing) privacy policies protecting such

Chinosi M. and Trombetta A. (2008).

Integrating Privacy Policies into Business Processes.

In Proceedings of the 6th International Workshop on Security in Information Systems, pages 13-25

DOI: 10.5220/0001743900130025

 SciTePress

data. One of the most well-known efforts in such direction is the P3P privacy policy

description language [3]. P3P permits to represent privacy policies in an XML tree,

basing on an XML-Schema model, which can be published by service providers to

give users the capability to check automatically if the policies accomplish with the user

preferences.

Therefore, it becomes a relevant, non-trivialissue to check whether a given complex

business process (describing how processes interact and what data items they access) is

compliant with a stated privacy policy (describing what processes are entitled to access

which data items, provided that the corresponding purposes and obligations have been

stated).

In this work we address the above mentioned issue by presenting a single frame-

work in which both a business process and a corresponding privacy policy can be ex-

pressed and the compliance of the former with respect to the latter can be checked.

We accomplish this by expressing both business processes and privacy policies in suit-

able XML formats and then proceed to check their compliance. We assume that privacy

policies are expressed in P3P format. Regarding business processes, we do not rely on

already disposable XML-based representations of BPMN, such as BPEL4WS [4] or

XPDL [5,6]. Both of them have disadvantages: BPEL4WS is strictly less expressive

than BPMN, since only one single business process can be represented, and only one

subset of BPMN elements can be deployed [7–9]. XPDL supports a larger fragment

of BPMN but it does not render properly the hierarchical logical relationships between

elements as well as it is not an executable language [5,6]. Thus, XPDL is not the best

way to represent BPDs if the goals are analysis, execution, extensions.

Hence, we present a new XML-oriented model, called BPeX, that faithfully de-

scribes all the relevant features of BPMN, such as the complete mapping of all the

elements provided by the speciﬁcations and a tree model which reﬂects the elements

dependencies and the hierarchical structure of diagrams. These features introduce some

useful capabilities such as the possibility to export and share the diagram with other

tools and to investigate processes to pinpoint bottle-neck or dead-locks (and conse-

quently to patch them).

Having presented in a single, coherent framework both business processes and pri-

vacy policies, we then deﬁne the procedures for checking the compliance of a BPeX-

based business process with respect to a P3P-based privacy policy. Such procedures,

relying on the uniﬁed XML-based format employed for business processes and privacy

policies are implemented using standard XML query languages, such as XPath.

2 Related Works

This paper starts from the ofﬁcial BPMN speciﬁcations as approved by OMG in 2006

and builds upon it. We don’t assume any formal semantics underlying BPMN [10–

12], rather we consider the semantics as it is presented in natural language in the OMG

documentation. We give for some elements a more formal deﬁnition in order to perform

some kind of queries and operations.

Other works about integrating privacy policies with business processes have been

published since 2002 [13–15] even though the ﬁrst work proposing an algorithm to

verify P3P policies on BPEL4WS tree was published in 2006 [16]. Moreover, in [17] an

approach to extract RBAC models from BPEL4WS processes for the role engineering

process is presented.

Due to space limitations, you can ﬁnd more detailed information about P3P and

BPMN on respective standard web-pages, [3] and [2]. For the same reason, we omit

in this work almost all the code and the pictures explaining our model. It is possible

to ﬁnd them in the corresponding project web site under SourceForge repository at

http://bpex.sourceforge.net. We will refer in this paper to the content pub-

lished there with [18]. On the same web-site you can also ﬁnd an extended version of

this paper.

3 BPeX: a BPMN XML Linearization

At the present moment, BPMN deﬁnes simply a graphical notation without an explicit

deﬁnition of the underlying meta model; that is, what are the basic elements composing

a business process and what are the relationships among them. Clearly, providing a

BPMN model is a ﬁrst, necessary step in order to precisely state what is the meaning

(or, more precisely, behavior) of a business process described as a BPMN diagram. As

such, it is an interesting problem in itself to deﬁne such a suitable, BP-oriented model

[10–12]. There are some research efforts aiming at the deﬁnition of a comprehensive

model representing all the main features of BPM, but all such efforts build upon existing

incomplete and/or inadequate formats. We have chosen a clean start by looking closely

into BPMN and building our model from scratch, thus obtaining a clear model natively

supporting all the relevant features of BPMN.

The result of our efforts is called BPeX and it is deﬁned in a top-down fashion. We

start pointing out all the different BPMN symbol families, we then proceed reﬁning

them through the deﬁnition of more precise symbol families, connected in a suitably

deﬁned hierarchy. Then, we add a representation of ﬂows, adopting the same method-

ology.

We provide an XML version of such a model, in order to obtain a complete schema

representing all the BPMN elements. The chosen hierarchical structure among BPMN

elements (and ﬂows) can be represented in a very natural way using XML-Schema.

With a slight abuse of notation we call BPeX both the model and its XML-based ver-

sion. In the following sections we will mention the BPeX features relevant for the

present framework, namely how to smoothly integrate in it information about privacy

policies. Any further information can be found at the BPeX project site [18].

Figure 1 shows a comparison between BPMN (as understood from the available

documentation) on Fig. 1(a) and our BPeX meta model on Fig. 1(b). As it is possible to

see, in BPeX model all the elements are connected to each other, while in the BPMN

speciﬁcations most of the elements are only referenced by an external numerical value

(represented graphically with dashed arrows) and, thus, they do not accomplish to rep-

resent the diagram structure. One of the most immediate advantages on using a full

hierarchical model is, e.g., the complexity on check what Lane an element (an Event,

an Activity or a Gateway) belongs to. Using BPMN model, one has to control the val-

ues of the Pool-Ref and the Lane-Ref attributes and search for the element ID inside the

(a) BPMN, as from original docu-

mentation

(b) BPeX model

Fig.1. A comparison between BPMN and BPeX hierarchical model representation.

Process element. Instead, using BPeX one has just to check whether the element node

is a child of the Lane node.

The Process element is depicted with a gray background and no black boundary be-

cause it does not have a graphical representation inside a BPD. As it is possible to no-

tice in Fig. 1(b), we also include into the model ﬂows speciﬁcations, represented with a

gray background, while in BPMN ﬂows are disconnected from any other element. This

makes them more context-free but it is not clear using XPDL where a modeler can use

them or where they are deﬁned.

Our model introduces some useful features like e.g. the hierarchical representation

of BPMN elements in a diagram and the feasibility of performing queries on XML

data. Our notation is fully compliant with XPDL graphical appearing notation and can

describe all the data interchange between processes like BPEL does. Using BPeX it is

easier to join together business processes and privacy policies, ﬁrstly because it can rep-

resent the whole set of BPMN elements. Secondly, it reproduces faithfully the diagram

structure without any loss of information. Thus, it is possible to ﬁnd the right position

to declare a policy statement keeping privacy policies and BPs structures unaltered.

This makes easier to analyze BPs (at different levels of granularity) to determine if they

comply with the given privacy policy. Further information can be found on project Web

page [18].

4 P3P Policy Enforcement

Currently, the main use of the P3P language is for web services providers, which can

host policies in their servers leaving users to opt, using the service provided or not.

Some browsers can access P3P policy document and warn users if a server policy does

not accomplish the users’ preferences.

BPMN (and BPeX, consequently) can easily be adopted to describe business pro-

cesses whose tasks have to follow a given privacy policy. Extending the BPeX model in

order to add P3P support permits users to test if a web-enabled business process is com-

pliant with a given privacy policy. For example, a web service provider which asks user

for a credit card number to perform a given task could be in contrast with the privacy

policy which does not allow to ask for a personal information.

Fig.2. BPMN representation of a user connecting to a search engine to perform a query.

In our approach, we will extend less as possible BPMN notation in order to keep the

main requirements unchanged. Notice that P3P does not implement a full privacy poli-

cies tuple unlike for example the RBAC model. This is because P3P is a web-oriented

standard. The main aspects we will use to extend BPMN notation are Entity, Purposes,

Access, Data-group and Recipient.

For some of these elements (Entity, Data-group) we will use BPMN native attribute,

extending the notation to better explain and represent the values of P3P elements. For

Access element we will add a new attribute to a BPMN Process element. For the other

elements we need to redeﬁne or tune BPMN elements modifying some attributes or

adding new ones. These modiﬁcations will be mapped also in BPeX to achieve a full

XML linearization of BPDs with P3P statements. We have developed also some simple

procedures to perform validation tests between BPeX and P3P policies trees. Some

examples will be shown in the following using W3C XPath queries.

4.1 Motivating Example

The example we introduce in this section sketches the environment we are interested

in. We start considering a web-oriented business process that we represent with BPMN.

Then we translate the BPD into a BPeX representation. In Section 4.2 we illustrate how

to integrate P3P policies and BPeX documents. Finally, we present some excerpts of

BPeX code enriched with privacy policies and the algorithms to enforce the process

policy.

For our running example we use a classical scenario of a user connecting to a search

engine to perform a query. For the sake of clarity, we opt for Google and its privacy

policies freely available on-line at Google Privacy Center

. Figure 2 shows the BPMN

model of the Business Process we choose to investigate and Listing 1.3 (available in

Appendix A) is part of its BPeX linearization. The text of the search engine privacy

policy has been taken from the on-line version and the Listing 1.4 (Appendix A) is

related to its P3P form.

4.2 P3P Representation Inside BPeX Code

We now summarize the formalisms we use to represent P3P clauses inside the BPeX

code, investigating more in detail as possible each correspondence.

http://www.google.com/privacypolicy.html

Entity. This element refers the legal entity making the representation of the privacy

practices. There are only two elements in BPMN that can be used to map the Entity:

the BPD and the Pool. We can not use the Process element because there may be Pools

without a related Process (Black Boxes). Nonetheless, also in these cases a Pool rep-

resents a subject involved in the BP. Between BPD and Pool elements we choose to

use the latter, because a BPD is a set of all the processes pertaining the BP, while a

Pool represents a single actor (i.e., a single Entity). P3P binds some values to be

present in a policy. A P3P Entity must hold the orgname attribute and one of the

following categories of information: postal, telephone, email, URI. For a sake

of simplicity we extend the Name attribute of Pools (i.e., Pool/Name) adding a new

sub-tree starting with the <P3PExension> node, father of an <Entity> node. The

Entity node imitates the P3P Entity nodes structure, with the same constraints. The

new node P3PExtension/Entity/orgnamesubstitute the old Pool Name. To add the

same P3P Entity subtree to the Pool/Name attribute makes easier to compare values

and enforces this policies element: there should be a direct correspondence between the

two nodes structures, as depicted in Figure 4 in the Appendix A. This is a true advantage

in using BPeX model respect to the original BPMN proposal, because with the latter it

is not possible to make a comparison node-to-node.

Access. The P3P Access element represents the ability of the individual to view iden-

tiﬁed data and address questions or concerns to the service provider [3]. In this case,

BPMN does not have an element near to the Access, but each Pool holding activities

and ﬂows has also a relationship with one Process. We add to Process element a new

attribute <P3PExtension>having as child the <ACCESS> element. Possible values

of <ACCESS> element are those provided by P3P standard.

Purposes. Every ‘Common Graphical Object’ (i.e., all the graphical objects that may

appear in a BPD) have a Categories attribute, deﬁned as follows: “The modeler

MAY add one or more deﬁned categories that can be used for purposes such as report-

ing and analysis”. Thus, the use of this element as a container for the P3P Purposes

element does not require any further adjustment unless a boolean attribute, named

IsP3PPurpose, to better deﬁne the purposes domain. All the BPMN elements ex-

cept for BPD and Process (that have not a graphical representation) have the Categories

attribute, so we can deﬁne, for every element, which purpose it is designed for.

Data-group. This is the most critical issue because P3P is very rich of details about data

while BPMN provides only an Artifact named DataObject to represent all kind of

data. To describe as good as possible the information exchanged through the activities

and the ﬂows of a BP we use the Name attribute of the DataObject element to specify

what kind of data an entity or an user is working on. As well as we have done to map En-

tity element into the Pool/Name attribute, we extend the DataObject/Name attribute

with a <P3PExtension> node, containing the trees provided by P3P Data-Group

element. In addiction, BPMN DataObjects have a RequiredForStart boolean at-

tribute, that can be used to map the P3P always, opt-in and opt-out values for

purposes and recipients.

Recipient. This element contains one or more recipients of collected data. It is the legal

entity, or domain, where data may be distributed. The mapping of the Recipient el-

ement is a bit more complex. The best place to attach the Recipient data is a Message

Flow (which represents the messages exchanged between different Pools – and, thus,

different Entities). Unfortunately MessageFlows do not have a direct attribute where to

specify the Recipient constraints. It is unnecessary to control messages exchanged in-

side the same Pool, between different Lanes: we suppose that an Entity can freely share

data with its ofﬁces or internal employees. Again, we are not interested to investigate

where data come from (typically, in BPMN diagrams, through Message Flows) – it is

the sender Entity which have to adhere to its privacy policy. We need to ensure that data

collected from an enterprise are the same of those declared in its privacy policy. What

we can not express in BPMN is the afﬁliation domain of the messages targets. P3P

does not need to know the target entity data, but only if the target, for example, has the

same privacy policies or if it is the legal entity following the practices, and so forth. To

add this kind of information, we extend the Target node of a Message Flow with

an attribute P3PRecipient expressing the P3P values provided for the Recipent

element.

5 The Compliance Checking Procedures

Our goal is to check whether a BPMN diagram, representing a web-enabled business

process, is compliant with a P3P privacy policy. Thus, as discussed in the previous sec-

tion, we have enriched the BPeX XML-based BPMN representation with some P3P-like

attributes. Now, we provide checking procedures in order to verify such compliance.

The tests we are interested in focus on the presence of the same attributes either in

BPeX and in P3P trees. P3P notation is not used to express the values collected for

each instance of the service provided. Thus, the tests will not cover the correspondence

between the values which can be performed only when a process has been executed

through log analysis or using a monitor.

We start assuming that each Pool represents an Entity, and thus we make the tests

on Entity and Access between the Pool attributes and respectively POLICY/ENTITY

and POLICY / ACCESS attributes. All the other tests are performed for each P3P

STATEMENT clause, and focus on: what kind of data the process works on, how the

process uses collected data, and with whom an entity shares collected data. In general

it is not true that every STATEMENT element corresponds to one single Pool: a Pool

references one Policy but it may have more than one Statement.

The diagram shown in Fig. 3 relates to our Google example: there is one Pol-

icy with altogether four Data-Ref elements, three Purposes and two different Recip-

ients. This example shows how different Statements can act using different triples

<Data-Groups, Purposes, Recipients>. P3P standard speciﬁes that each

Statement must hold one Data-Group node and may have more than one Purpose or Re-

cipient expressed. In our example, the Statement A uses all the four <DATA-REF> val-

ues as Data-Group for the Purposes <admin><develop>sharing data with Recipient

<ours>; the Statement B instead uses only two of the <DATA-REF>elements as Data-

Fig.3. Data-Groups, Purposes, Recipients relationships.

Group for the Purpose <pseudo-analysis>disclosing data to <unrelated>Re-

cipients.

For the Statements veriﬁcation we ensure ﬁrstly the correctness of the three ﬁelds

separately and then the accordance between them and against the referential P3P policy.

5.1 Policies Enforcement

We introduce nowa high level description of the checking procedures.For a sake of sim-

plicity, the procedures presented here do not consider the strings manipulation needed

to extract the P3P clauses from the attributes value. This aspect will be shown later on,

when we will illustrate an XPath implementation example of one of these procedures.

Considering that each one of the algorithms veriﬁes a different aspect of the policy,

then all of these have to be executed to enforce the privacy policy in its entirety. For a

matter of space, Access, Purposes, Data-Group and Recipient listings can be found in

Appendix A.

ENTITY Veriﬁcation. The Listing 1.1 shows the algorithm to enforce the policy of

a business process focusing on the Entity veriﬁcation. This control applies on every

Pool (row 1). The ﬁrst condition (row 2) veriﬁes if the P3PExtension node, child

of Pool/Name, exists: if not, an error occurs (moreover, this implies that the di-

agram is not compliant with BPMN speciﬁcations, because the new node Name /

P3PExtension / orgname corresponds to the original Name value). The core of

the algorithm comparesthe P3PExtension/ENTITYsubtree with the P3P:POLICY

/ ENTITY one (row 5) like in Fig. 4.

1foreach (Pool/Name PN ∈ BPD) do {

2if (PN/P3PExtension/ENTITY == ∅)

3then ‘‘Error’’

4elseif (PN/P3PExtension/ENTITY 6= P3P:POLICY/ENTITY)

5then ‘‘Error’’;

6else ‘‘OK’’; }

Listing 1.1. The ENTITY enforcement algorithm.

ACCESS Veriﬁcation. The Access veriﬁcation algorithm (see Listing 1.6) is quite sim-

ilar to the Entity one. It differs from the latter especially for the ﬁrst condition (row 1)

in which there is a check to assure that the Pool is not a Black Box: otherwise, it can

not have an Access attribute because the content of the Pool is hidden and users can not

access their data.

PURPOSES Veriﬁcation. In this case (see Listing 1.5), ﬁrstly we consider only a subset

of the all Common Graphical Objects. We argue that Swimlanes, Group and Text An-

notation can not have a related Purpose. Secondly, we check if the Categories element

has the required boolean attribute. Finally, we compare Categories children with all the

Purpose children. Notice that between POLICY and PURPOSES at row 7 there are two

slashes ‘//’ to show, using the XPath syntax, that Purposes nodes are not direct Policy

children but they are Policy descendants through the Statement node.

DATA-GROUP Veriﬁcation. Similarly to Entity and Access veriﬁcation, to enforce

Data-Group elements requires to check if the P3PExtension node has been declared and

successively if its values fall into the set of every Statement’s Data-Group (Listing 1.7).

RECIPIENT Veriﬁcation. To determine if MessageFlows are compliant with their re-

lated policies, it is necessary to control if the value of the P3PRecipient attribute is one

of those declared as policy Recipient.

Listings 1.5, 1.7 and 1.8 need to be executed at Statement level, while Listings 1.1

and 1.6 at Policy level. To enforce the whole process against a privacy policies, we

need to evaluate the latter once and the former for each Statement. If all test pass we

can claim that the process is compliant with the privacy policy.

For a matter of space, we give now only one example of XPath translation (List-

ing 1.2). The BPeX code (which represents the process) and the policy code are marked

with different namespaces. In the example we omit the bpex namespace for a reason of

space. We employ to compare two node-sets the XPath 2.0 function fn:deep-equal

which assesses whether two sequences are deep-equal to each other. To be deep-equal,

they must contain items that are pairwise deep-equal; and for two items to be deep-

equal, they must either be atomic values that compare equal, or nodes of the same kind,

with the same name, whose children are ‘deep-equal’. For a sake of simplicity this code

uses the P3P 1.0 node structure POLICIES/POLICY/ENTITY/DATA-GROUP.

1(//Pools/Name/P3PExtension/ENTITY)

2then fn:deep-equal(//Pools/Name/P3PExtension/ENTITY,

3p3p:POLICIES/p3p:POLICY/p3p:ENTITY)

4\vspace{-8mm}

Listing 1.2. The XPath version of the Entity algorithm.

6 Conclusions

In this paper, we proposed a new XML-based notation called BPeX allowing users to

represent all BPMN elements in a hierarchical tree-based structure. We introduced an

abstract representation of the BPeX notation, giving a close look to the data model rep-

resentation and to the ﬂow relationships. Then, we deﬁned the XML-Schema and the

XML linearizations of the BPeX data- and ﬂow-model. Finally, we extended BPeX no-

tation with the support for P3P policies. We showed the feasibility to query the BPeX

representation of a BPD extended with P3P statements, in order to verify its adherence

to a given P3P privacy policy speciﬁcation. Please, refer to project web-site for further

comparisons, case studies and related works.

References

1. WfMC: Workﬂow Management Coalition - Terminology & Glossary. On WfMC website

(1999) WFMC-TC-1011. http://www.wfmc.org/standards/docs.htm.

2. White, S.A.: Business Process Modeling Notation - OMG Final Adopted Speciﬁcation. On

BPMN website (2006) http://www.bpmn.org.

3. Cranor, L., Dobbs, B., Hogben, G., Marchiori, M., Schunter, M., et al.: The Platform for

Privacy Preferences 1.1 (P3P1.1) Speciﬁcation (2006) http://www.w3.org/TR/P3P11/.

4. Andrews, T., Curbera, F., Dholakia, H., Goland, Y., Klein, J., Leymann, F., Liu, K., Roller,

D., et al.: Business Process Execution Language for Web Services - Version 1.1. IBM

website (2003) http://www-128.ibm.com/developerworks/library/speciﬁcation/ws-bpel/.

5. WfMC: Process Deﬁnition Interface – XML Process Deﬁnition Language. WfMC website

(2005) WFMC-TC-1025. http://www.wfmc.org/standards/docs.htm.

6. Swenson, K.: The BPMN-XPDL-BPEL value chain. In blog “Go Flow” (2006)

http://kswenson.wordpress.com/2006/05/26/bpmn-xpdl-and-bpel/.

7. Recker, J., Mendling, J.: On the Translation between BPMN and BPEL: Conceptual Mis-

match between Process Modeling Languages. In: Proceedings 18th International Conference

on Advanced Information Systems Engineering. Proceedings of Workshops and Doctoral

Consortiums, Latour, Thibaud and Petit, Michael, Eds. (2006) 521–532

8. Ouyang, C., van der Aalst, W.M., Dumas, M., Hofstede, A.H.M.t.: From Business Process

Models to Process-oriented Software Systems: The BPMN to BPEL Way. Technical Report

BPM-06-27, BPM Center (2006) http://www.bpmcenter.org.

9. Ouyang, C., van der Aalst, W.M., Dumas, M., Hofstede, A.H.M.t.: Translating BPMN to

BPEL. Technical Report BPM-06-02, BPM Center (2006) http://www.bpmcenter.org.

10. Mendling, J., Neumann, G., N¨uttgens, M.: A Comparison of XML Interchange Formats

for Business Process Modelling. In Feltz, F., Oberweis, A., Otjacques, B., eds.: EMISA.

Volume 56 of LNI., GI (2004) 129–140

11. Mendling, J., de Laborda, C.P., Zdun, U.: Towards an Integrated BPM Schema: Control

Flow Heterogeneity of PNML and BPEL4WS. In Althoff, K.D., Dengel, A., Bergmann, R.,

Nick, M., Roth-Berghofer, T., eds.: Wissensmanagement (LNCS Volume). Volume 3782 of

Lecture Notes in Computer Science., Springer (2005) 570–579

12. Mendling, J., de Laborda, C.P., Zdun, U.: Towards Semantic Integration of XML-based

Business Process Models. In Althoff, K.D., Dengel, A., Bergmann, R., Nick, M., Roth-

Berghofer, T., eds.: Wissensmanagement, DFKI, Kaiserslautern (2005) 513–517

13. Karjoth, G., Schunter, M.: A Privacy Policy Model for Enterprises. In: CSFW, IEEE Com-

puter Society (2002) 271–281

14. Agrawal, R., Kiernan, J., Srikant, R., Xu, Y.: An XPath-based Preference Language for P3P.

In: 12th International World Wide Web Conference. (2003)

15. Bertino, E., Crampton, J., Paci, F.: Access Control and Authorization Constraints for WS-

BPEL. icws 0 (2006) 275–284

16. Li, Y.H., Paik, H.Y., Benatallah, B., Benbernou, S.: Formal Consistency Veriﬁcation between

BPEL process and Privacy Policy. In: Privacy Security Trust 2006 (PST 2006), McGraw Hill

(2006) 212–223

17. Mendling, J., Strembeck, M., Stermsek, G., Neumann, G.: An Approach to Extract RBAC

Models from BPEL4WS Processes. In: WETICE, IEEE Computer Society (2004) 81–86

18. BPeX Project Site: http://bpex.sourceforge.net (2005)

A Appendix

1<POOL ID=‘‘P001’’><NAME>Google</NAME>

2<LANE ID=‘‘L001’’><NAME>Google</NAME>

3<EVENT ID=‘‘E001’’ EventType=‘‘Start’’>

4<NONE/>

5</EVENT>

6<TASK ID=‘‘T001’’ Name=‘‘Receive request’’/>

7<TASK ID=‘‘T002’’ Name=‘‘Display form page’’/>

8<TASK ID=‘‘T003’’ Name=‘‘Receive query’’/>

9<TASK ID=‘‘T004’’ Name=‘‘Compute query’’/>

10<TASK ID=‘‘T005’’ Name=‘‘Display results page’’/>

11<EVENT ID=‘‘E002’’ EventType=‘‘End’’>

12<NONE/>

13</EVENT>

14</LANE>

15<SEQUENCEFLOW ID=‘‘SF001’’>

16<SOURCE>E001</SOURCE>

17<TARGET>T001</TARGET>

18</SEQUENCEFLOW>

19<SEQUENCEFLOW ID=‘‘SF002’’>

20<SOURCE>T001</SOURCE>

21<TARGET>T002</TARGET>

22</SEQUENCEFLOW>

23<SEQUENCEFLOW ID=‘‘SF003’’>

24<SOURCE>T002</SOURCE>

25<TARGET>T003</TARGET>

26</SEQUENCEFLOW>

27<SEQUENCEFLOW ID=‘‘SF004’’>

28<SOURCE>T003</SOURCE>

29<TARGET>T004</TARGET>

30</SEQUENCEFLOW>

31<SEQUENCEFLOW ID=‘‘SF005’’>

32<SOURCE>T004</SOURCE>

33<TARGET>T005</TARGET>

34</SEQUENCEFLOW>

35<SEQUENCEFLOW ID=‘‘SF006’’>

36<SOURCE>T005</SOURCE>

37<TARGET>E002</TARGET>

38</SEQUENCEFLOW>

39</POOL>

40<POOL ID=‘‘P002’’><NAME>User</NAME>

41</POOL>

42<MESSAGEFLOW ID=‘‘MF001’’>

43<SOURCE>P002</SOURCE>

44<TARGET>T001</TARGET>

45<MESSAGE>www.google.com</MESSAGE>

46</MESSAGEFLOW>

47<MESSAGEFLOW ID=‘‘MF002’’>

48<SOURCE>T002</SOURCE>

49<TARGET>P002</TARGET>

50<MESSAGE/>

51</MESSAGEFLOW>

52<MESSAGEFLOW ID=‘‘MF003’’>

53<SOURCE>P002</SOURCE>

54<TARGET>T003</TARGET>

55<MESSAGE>‘‘Shakespeare poems’’</MESSAGE>

56</MESSAGEFLOW>

57<MESSAGEFLOW ID=‘‘MF004’’>

58<SOURCE>T005</SOURCE>

59<TARGET>P002</TARGET>

60<MESSAGE/>

61</MESSAGEFLOW>

62</BPD>

Listing 1.3. The BPeX linearization of the BPMN diagram.

1xmlns="http://www.w3.org/2002/01/P3Pv1">

2<POLICY name="Google Example Policy"

3discuri="http://www.google.com/privacypolicy.html"

4xml:lang="en">

5<ENTITY>

6<EXTENSION>

7<p3p11:data-group>

8<p3p11:datatype>

9<p3p11:business>

10<p3p11:orgname>Google Inc.</p3p11:orgname>

11<p3p11:contact-info>

12<p3p11:postal>

13<p3p11:street>1600 Amph.Parkway</p3p11:street>

14<p3p11:city>Mountain View</p3p11:city>

15<p3p11:state>CA</p3p11:state>

16<p3p11:postalcode>94043</p3p11:postalcode>

17<p3p11:country>USA</p3p11:country>

18</p3p11:postal>

19</p3p11:contact-info>

20</p3p11:business>

21</p3p11:datatype>

22</p3p11:data-group>

23</EXTENSION>

24<DATA-GROUP>

25<DATA ref="...">for backward compatibility</DATA>

26</DATA-GROUP>

27</ENTITY>

28<ACCESS><nonident/></ACCESS>

29<STATEMENT>

30<PURPOSE><admin/><develop/></PURPOSE>

31<RECIPIENT><ours/></RECIPIENT>

32<RETENTION><stated-purpose/></RETENTION>

33<DATA-GROUP>

34<DATA ref="#dynamic.clickstream"/>

35<DATA ref="#dynamic.http"/>

36<DATA ref="#dynamic.searchtext"/>

37<DATA ref="#dynamic.cookies"/>

38</DATA-GROUP>

39</STATEMENT>

40<STATEMENT>

41<NON-IDENTIFIABLE/>

42<PURPOSE><pseudo-analysis/></PURPOSE>

43<RECIPIENT><unrelated></RECIPIENT>

44<RETENTION><stated-purpose/></RETENTION>

45<DATA-GROUP>

46<DATA ref="#dynamic.http"/>

47<DATA ref="#dynamic.searchtext"/>

48</DATA-GROUP>

49</STATEMENT>

50</POLICY>

51</POLICIES>

Listing 1.4. The P3P form of the Google Privacy Policy.

Fig.4. A comparison between P3P and BPeX Entity elements.

1CommonGraphicalObjects; CGO

∗

:= CGO \ (Swimlanes,

2Group, TextAnnotation); foreach (Pool P ∈ BPD) do {

3foreach (CGOElement ∈ CGO

∗

) do {

4if (CGOElement/Categories@IsP3PPurpose == ∅)

5then ‘‘Error’’

6elseif (CGOElement/Categories * P3P:POLICY//PURPOSES)

7then ‘‘Error’’

8else ‘‘OK’’; } }

Listing 1.5. The PURPOSES enforcement algorithm.

1foreach (Pool/Process PP ∈ BPD | PP 6= ∅) do {

2if (PP/P3PExtension/ACCESS == ∅) then ‘‘Error’’;

3elseif (PP/P3PExtension/ACCESS 6= P3P:POLICY/ACCESS)

4then ‘‘Error’’

5else ‘‘OK’’; }

Listing 1.6. The ACCESS algorithm.

1foreach (DATAOBJECT DO ∈ BPD) do {

2if (DO/NAME/P3PExtension == ∅) then ‘‘Error’’

3elseif (DO/NAME/P3PExtension *

4P3P:POLICY/STATEMENT/DATA-GROUP)

5then ‘‘Error’’

6else ‘‘OK’’; }

Listing 1.7. The DATA-GROUP enforcement algorithm.

1(MESSAGEFLOW MF ∈ BPD) do {

2if (MF/Target@P3PRecipient == ∅) then ‘‘Error’’

3elseif (MFM/Target@P3PRecipient *

4P3P:POLICY/STATEMENT/RECIPIENT) then ‘‘Error’’

5else ‘‘OK’’; }

Listing 1.8. The RECIPIENT enforcement algorithm.