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 issue 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 efficient and require standard XML technology, such as XPath.

1. Integrating Privacy Policies into
Business Processes
Michele Chinosi
joint work with Alberto Trombetta
Universit` degli Studi dell’Insubria (Italy)
a
michele.chinosi@uninsubria.it

2. BPMN
Business Process Modeling Notation
• graphical notation to model (represent) business processes
• developed by BPMI
• adopted as standard by OMG (2006: 1.0 – 2008: 1.1)
• standard for the “look” of a process
• provides a dictionary of standard shapes with particular meanings
• easily readable – reduces the learning curve

3. BPMN Elements Set
• Flow Objects
• Events
• Activities
• Gateways
• Connecting Objects
• Sequence Flows
• Message Flows
• Associations
• Swimlanes
• Pools
• Lanes
• Artifacts
• Data Objects
• Groups
• Text Annotations

4. BPMN Example 1

5. BPMN Example 2

6. P3P
The Platform for Privacy Preferences
• P3P enables Websites to express their privacy practices in a standard
format that can be automatically retrieved and easily interpreted by
user agents
• defines the syntax and semantics of P3P privacy policies
• it is an XML format for expressing a privacy policy
• users are informed of site practices
• users do not need to read the privacy policies
• November 2006: the P3P working group closed

7. P3P Structure Overview
P3P policies consist on a sequence of STATEMENT elements. Each
STATEMENT includes:
• PURPOSE: the aims for data processing (current, admin, contact,
telemarketing, . . . )
• RECIPIENT: the legal entity or domain where data may be
distributed (ours, same, public, . . . )
• RETENTION: the type of retention policy in effect (no-retention,
stated-purpose, legal-requirement, . . . )
• DATA-GROUP: describes the data to be transferred or inferred. It
includes one or more DATATYPE, used to describe the type of data
that a recipient collects.
• CONSEQUENCE and NON-IDENTIFIABLE are optional elements

8. Standards Overview

9. BPMN serializations
• BPMN has not an XML linearization
• The two closest formats are WS-BPEL and XPDL
WS-BPEL: Business Process Execution Language
• developed by BEA, IBM, Microsoft and adopted by OASIS as
standard
• execution language for the definition of web services orchestration
XPDL: XML Process Definition Language
• developed by WfMC (Workflow Management Coalition) starting
from 1998
• file format for storing and exchanging the process diagrams
• supports the BPMN elements set

10. WS-BPEL and XPDL disadvantages
WS-BPEL: Business Process Execution Language
• independent from BPMN
• less expressive than BPMN
• elements names and structure of the model are completely different
• no graphical support
XPDL: XML Process Definition Language
• lack of native referential integrity
• some elements names differ
• structure of the model is different from the BPMN one
• no execution allowed

11. BPeX
BPeX: Business Process eXtensions
• Built from scratch with a clear
conceptual model
• It supports all BPMN elements
and features
• It has an XML-Schema
serialization
• Static analysis and validation
• Constraints / Metrics /
Extensions

12. Motivating Example
The excerpt of the Google Privacy Policy for a web search requires:
• to collect #dynamic.[clickstream|http|searchtext|cookies]
to meet the stated purpose: performing searches, web site
administration, research and development; collected data will not be
shared
• to collect #dynamic.[http|searchtext] to perform
pseudo-analysis (to understand the interests of a visitor without
keeping any personal information), sharing data with other parties
not related with Google

13. The Example Privacy Policy written in P3P
<POLICIES> <POLICY name=quot;Google Example Policyquot;>
<ENTITY>
<EXTENSION> <p3p11:data-group>...</p3p11:data-group> </EXTENSION>
<DATA-GROUP> <DATA ref=quot;...quot;>for backward compatibility</DATA> </DATA-GROUP>
</ENTITY>
<ACCESS><nonident/></ACCESS>
<STATEMENT>
<PURPOSE><admin/><develop/></PURPOSE>
<RECIPIENT><ours/></RECIPIENT>
<RETENTION><stated-purpose/></RETENTION>
<DATA-GROUP>
<DATA ref=quot;#dynamic.clickstreamquot;/>
<DATA ref=quot;#dynamic.httpquot;/>
<DATA ref=quot;#dynamic.searchtextquot;/>
<DATA ref=quot;#dynamic.cookiesquot;/>
</DATA-GROUP>
</STATEMENT>
<STATEMENT>
<PURPOSE><pseudo-analysis/></PURPOSE>
<RECIPIENT><unrelated></RECIPIENT>
<RETENTION><stated-purpose/></RETENTION>
<DATA-GROUP>
<DATA ref=quot;#dynamic.httpquot;/>
<DATA ref=quot;#dynamic.searchtextquot;/>
</DATA-GROUP>
</STATEMENT>
</POLICY> </POLICIES>

14. P3P Representation in BPeX
Entity
<POOL>
<NAME>
<P3PExtension>
<Entity>
<orgname/>
...
</Entity>
</P3PExtension>
</NAME>
...
</POOL>

15. P3P Representation in BPeX
Access Purposes
<PROCESS>
<Categories
<P3PExtension>
IsP3PPurpose=[true|false]>
<ACCESS/>
... the purpose description ...
</P3PExtension>
</Categories>
...
</PROCESS>
Every Common Graphical Object
has a Categories attribute which
In BPMN each POOL having
can act as a container for the P3P
activities and flows has also a
Purposes element.
relationship with one PROCESS.

16. P3P Representation in BPeX
Data-Group
Recipient
<DATAOBJECT>
<NAME> <MESSAGEFLOW>
<P3PExtension> <TARGET P3PRecipient=[...]>
...P3P data-group... ...
</P3PExtension> </TARGET>
</NAME> </MESSAGEFLOW>
...
</DATAOBJECT>
P3P does not need to know the
target entity data, but only if the
P3P always, opt-in, opt-out can target has the same privacy policies
be mapped to BPMN DATAOBJECT or if it is the legal entity following
RequiredForStart attribute the practices and so on.

17. Checking Compliance
• Each BPMN POOL represents a P3P Entity
• First tests are between POOL attributes and POLICY/ENTITY and
POLICY/ACCESS attributes
• All other tests are performed for each P3P STATEMENT
• what kind of data the process works on
• how the process uses collected data
• with whom an entity shares collected data
• One POOL references one POLICY but may have more than one
STATEMENT

18. Checking Compliance
1 Policy with 4 Data-Ref elements, 3 Purposes, 2 Recipients
• Each STATEMENT must contains 1 Data-Group node and may have
more than one Purpose or Recipient
• Statement A: uses all the 4 Data-Ref as Data-Group for the
Purposes admin and develop sharing data with Recipient ours
• Statement B: uses only 2 of the Data-Ref as Data-Group for the
Purpose pseudo-analysis disclosing data to unrelated Recipients

19. Policies Enforcement
ENTITY verification
foreach ( Pool / Name PN ∈ BPD ) do { 1
if ( PN / P3PExtension / ENTITY == ∅) 2
then ‘‘ Error ’ ’ 3
elseif ( PN / P3PExtension / ENTITY = P3P : POLICY / ENTITY ) 4
then ‘‘ Error ’ ’; 5
else ‘‘OK ’ ’; } 6
• This check applies on every Pool (row 1)
• The first condition verifies the existence of the
P3PExtension/ENTITY nodes (row 2)
• The core of the algorithm compares the P3PExtension/ENTITY
subtree with the P3P:POLICY/ENTITY one (row 4)
if (// Pool / Name / P3PExtension / ENTITY ) 1
then fn : deep - equal (// Pool / Name / P3PExtension / ENTITY , 2
p3p : POLICIES / p3p : POLICY / p3p : ENTITY ) 3

20. Policies Enforcement
ACCESS verification
foreach ( Pool / Process PP ∈ BPD | PP = ∅) do { 1
if ( PP / P3PExtension / ACCESS == ∅) then ‘‘ Error ’ ’; 2
elseif ( PP / P3PExtension / ACCESS = P3P : POLICY / ACCESS ) 3
then ‘‘ Error ’ ’ 4
else ‘‘OK ’ ’; } 5
PURPOSES verification
CGO := C o m m o n G r a p h i c a l O b j e c t s ; 1
CGO ∗ := CGO ( Swimlanes , Group , TextAn notatio n ); 2
foreach ( Pool P ∈ BPD ) do { 3
foreach ( CGOElement ∈ CGO ∗ ) do { 4
if ( CGOElement / C a t e g o r i e s @ I s P 3 P P u r p o s e == ∅) 5
then ‘‘ Error ’ ’ 6
elseif ( CGOElement / Categories P3P : POLICY // PURPOSES ) 7
then ‘‘ Error ’ ’ 8
else ‘‘OK ’ ’; } } 9

21. Policies Enforcement
DATA-GROUP verification
foreach ( DATAOBJECT DO ∈ BPD ) do { 1
if ( DO / NAME / P3PExtension == ∅) then ‘‘ Error ’ ’ 2
elseif ( DO / NAME / P3PExtension 3
P3P : POLICY / STATEMENT / DATA - GROUP ) 4
then ‘‘ Error ’ ’ 5
else ‘‘OK ’ ’; } 6
RECIPIENT verification
foreach ( MESSAGEFLOW MF ∈ BPD ) do { 1
if ( MF / T a r g e t@ P 3 P R e c i p i e n t == ∅) then ‘‘ Error ’ ’ 2
elseif ( MFM / T a rg e t @ P 3 P R e c i p i e n t 3
P3P : POLICY / STATEMENT / RECIPIENT ) then ‘‘ Error ’ ’ 4
else ‘‘OK ’ ’; } 5

22. Conclusions
• We proposed a new XML-based notation called BPeX which can be
used as a BPMN serialization format
• We extended such representation with the support for P3P policies
• We plan to extend also the graphical representation with markers to
show elements which have privacy policies constraints
• We showed the feasibility to query the BPeX representation of a
BPD extended with P3P statements
• We showed some simple algorithms to check the compliance of a
business process towards a given privacy policy
• We used a clear and simple example to discuss our proposal,
showing also some code excerpts

23. Questions?
Michele Chinosi
michele.chinosi@uninsubria.it
http://bpex.sourceforge.net