Integrating Privacy Policies into Business Processes

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

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

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

BPMN Example 1

BPMN Example 2

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 • deﬁnes 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

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 eﬀect (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

Standards Overview

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

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

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

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

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>

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

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 ﬂows has also a Purposes element. relationship with one PROCESS.

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.

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

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

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

Policies Enforcement ACCESS veriﬁcation 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 veriﬁcation 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

Policies Enforcement DATA-GROUP veriﬁcation 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 veriﬁcation 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

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

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

http://bpex.blogspot.com	10
http://www.slideshare.net	3
http://bpex.blogspot.in	1

Integrating Privacy Policies into Business Processes

by Michele Chinosi on Nov 12, 2008

Accessibility

Categories

Tags

Upload Details

Usage Rights

3 Embeds 14

Statistics

Integrating Privacy Policies into Business Processes — Presentation Transcript