The Scientific World Journal

The Scientific World Journal / 2014 / Article

Research Article | Open Access

Volume 2014 |Article ID 961659 | 10 pages | https://doi.org/10.1155/2014/961659

Obtaining P3P Privacy Policies for Composite Services

Academic Editor: Jesualdo Tomás Fernandez-Breis
Received12 Jan 2014
Revised22 Jun 2014
Accepted26 Jun 2014
Published13 Jul 2014

Abstract

With the development of web services technology, web services have changed from single to composite services. Privacy protection in composite services is becoming an important issue. P3P (platform for privacy preferences) is a privacy policy language which was designed for single web services. It enables service providers to express how they will deal with the privacy information of service consumers. In order to solve the problem that P3P cannot be applied to composite services directly, we propose a method to obtain P3P privacy policies for composite services. In this method, we present the definitions of Purpose, Recipient, and Retention elements as well as Optional and Required attributes for P3P policies of composite services. We also provide an instantiation to illustrate the feasibility of the method.

1. Introduction

Nowadays Internet has become one of the major ways for people to get services. More and more people are accustomed to using web services. And with the development of web services technology, web services have changed from single to composite services. Web service composition is an approach to build new composite services by combining existing services. It not only reuses existing web services to improve the efficiency of service development, but also satisfies service consumers’ multifunctional demands. However, whether services are single or composite, service consumers’ privacy information is inevitably collected by service providers. And it is hard for service consumers to control the disclosure of their privacy information. In order to prevent the privacy information from being misused, service providers are requested to publish their privacy policies. Based on the privacy policies published by service providers, service consumers are able to know what service providers will do with their privacy information.

P3P (platform for privacy preferences) [1] was released by World Wide Web Consortium (W3C) in April 2002. It provides a standard and machine-understandable privacy policy. W3C also designs APPEL (A P3P Preference Exchange Language) [2] which allows service consumers to specify their privacy preferences. A P3P user agent can compare the P3P policies of service providers with the privacy preferences of service consumers. The comparison results enable the service consumers to decide whether to use the services or not. Since P3P was originally designed for single services, it cannot be applied for composite services directly. A composite service may consist of several independent web services which are called member services. All these member services have their own P3P policies which may specify different privacy practices of the same private data. How to isolate these discrepancies is one challenge. How to obtain the P3P policy for a composite service consisting of several services is another challenge.

In this paper, we firstly present the definitions of Purpose, Recipient, and Retention elements as well as Optional and Required attributes for P3P policies of composite services. Secondly, based on these definitions, we obtain P3P privacy policies for composite services. Finally, we provide an instantiation to illustrate how to obtain a P3P privacy policy of a composite service concretely.

The rest of this paper is organized as follows. Section 2 describes the syntax of P3P privacy policy. Section 3 proposes a method to obtain P3P privacy policies for composite services by defining the Purpose, Recipient, and Retention elements as well as the Optional and Required attributes for P3P policies of composite services. A case study is presented to prove the feasibility of the method in Section 4. Related work is discussed in Section 5. Section 6 concludes the paper.

2. P3P Syntax

P3P privacy policies inform service consumers how service providers will deal with their privacy information. The overall structure of a P3P policy is shown in Algorithm 1. A P3P privacy policy is described by Policy consisting of an Entity element, an Access element, a Disputes-Group element, zero or more Extension elements, and one or more Statement elements. Entity gives a precise description of the legal entity making the representation of the privacy practices. Access indicates whether the site provides access to various kinds of information. Dispute-Group describes dispute resolution procedures that may be followed for disputes about a service’s privacy practices.

Policy{Entity, Access, Disputes-Group,
 Statement(s) {Purpose Required ,
       Recipient Required ,
       Retention,
       Data-Group{
       Data Optional
       Categories

Statement is the core of P3P privacy policy. It describes how a website collects and uses the private data of service consumers. Statement comprises Purpose, Recipient, Retention, and Data-Group elements. Purpose states for what purpose the private data of service consumers may be used. It has six predefined values such as current, admin, and develop. Recipient describes to whom the private data of service consumers will be exposed. Retention states how long the private data of service consumers will be retained by service providers. Data-Group contains a list of private data (Data element) of service consumers which may be collected by service providers and data categories (Categories element). Moreover, Data, Purpose, and Recipient are either optional or mandatory by taking an optional attribute called Optional for the former and Required for the latter two. The value of Optional is either no (default value) when the data must be collected or yes when the data is optional. The value of Required can be always (default value), opt-out, or opt-in. Always means the purpose/recipient is always needed. Opt-out means the data may be used for the purpose/may be distributed to the recipient unless the user requests that it not be used in this way. Opt-in means the data may be used for the purpose/may be distributed to the recipient only when the user affirmatively requests this use. Algorithm 2 shows an example P3P policy from http://www.walmart.com/ [3].

Policy{Entity (#business.name): walmart.com ,
   {Purpose: (current, contact [opt-in]),
     Recipient: (ours),
     Retention: (indefinitely),
     Data: (#user.login, #user.home-info)}
    Purpose: (current, develop [opt-in], contact [opt-in]),
      Recipient: (ours),
      Retention: (stated-purpose),
      Data: (#user.name, #user.login, #user.home-info)

3. P3P Policies in Composite Services

Web service composition uses web services, no matter single or composite, as fundamental elements to create new services. It not only reuses existing services but also improves the efficiency of service development. The application of service composition is supported by many techniques, such as BPEL [4] and WSDL [5]. BPEL specifies the internal business process of a composite service. WSDL describes the interfaces of member services. Through these interfaces, member services can be invoked. At present there are many existing approaches to service composition, some of which are abstract methods and some of which aim to be industry standards [69].

P3P is one of the structured privacy policy languages widely used in the world today [10, 11]. It specifies how service providers will deal with the privacy information of service consumers. However, P3P cannot be applied for composite services directly because it was originally designed for single services. There is a need to research on P3P privacy policies for composite services. Statement element states the way service providers will handle the privacy information of service consumers, which is a top concern to service consumers. Therefore, the main emphasis of our research on P3P privacy policies for composite services is the Statement element. And in a Statement, the major elements are Data, Purpose, Recipient, and Retention.

As a composite service consists of several member services, the service providers of these member services have their own P3P policies that may specify different privacy practices of the same private data. For example, a composite service called Service A is constituted of three single services, and the P3P privacy policies of these services are called Policy1, Policy2, and Policy3 as shown in Algorithms 3, 4, and 5. From Algorithms 3, 4, and 5 the Retention value of #user.name in Policy1 is indefinitely which means the data is retained for an indeterminate period of time while the Retention value of #user.name in Policy2 is stated-purpose which means the data is retained to meet the stated purpose. The Purpose value of #user.name in Policy1 is current while the Purpose value of #user.name in Policy2 is current and telemarketing. The Recipient value of #user.home-info in Policy2 is ours and unrelated while the Recipient value of #user.home-info in Policy3 is ours and same. In addition, the Optional value of #user.name in Policy1 is no which means the data must be collected while the Optional value of #user.name in Policy2 is yes which means the data is optional. Then what are the Purpose, Recipient, and Retention values of #user.name and #user.home-info in the P3P policy of Service A? What are the Optional values of #user.name and #user.home-info? In this connection, we define the values of Purpose, Recipient, and Retention elements as well as the values of Optional and Required attributes for the P3P privacy policies of composite services. Based on these definitions, we can obtain P3P privacy policies for composite services. It should be noted that the semantic associations of Purpose, Recipient, Retention, and Data in Statement are not changed all the time. That is to say, the corresponding relationships among Purpose, Recipient, Retention, and Data keep the same.

Policy1{Entity (#business.name): ,
Purpose: (current),
  Recipient: (ours),
  Retention: (indefinitely),
  Data: (#user.name)

Policy2{Entity (#business.name): ,
Purpose: (current, telemarketing),
    Recipient: (ours),
    Retention: (stated-purpose),
    Data: (#user.name [yes], #user.home-info)}
Purpose: (telemarketing),
    Recipient: (unrelated [opt-out]),
    Retention: (stated-purpose),
    Data: (#user.home-info)

Policy3{Entity (#business.name): ,
Purpose: (telemarketing),
   Recipient: (ours, same),
   Retention: (indefinitely),
   Data: (#user.home-info)

3.1. Purpose Definition

In Statement, Purpose indicates the intended use of privacy information. It has twelve predefined values such as current, admin, and develop. When several services are combined into a composite service, their functions have not changed. These services are just reused to form a more powerful service. So when a web service is turned from an independent service to a member service, the Purpose values in its privacy policy do not change. We define Purpose values of a Data element in privacy policy of composite service by the union of Purpose values of the Data element in privacy policies of member services. And if a Data element is not included in the privacy policy of a member service, we set the Purpose values of the Data element in the service’s privacy policy to be an empty set.

Definition 1. A composite service consists of member services. The sets of Purpose values of a Data element in privacy policies of member services are denoted by , noted as . The set of Purpose values of the Data element in privacy policy of composite service is denoted by , .
According to Definition 1, we can get the sets of Purpose values of Data elements in privacy policy of Service A:

3.2. Recipient Definition

In a P3P privacy policy, Recipient element has six predefined values which are ours, delivery, same, other-recipient, unrelated, and public. Ours refers to the service provider and/or a third party that processes data only on behalf of the service provider for the completion of the stated purposes. Delivery refers to legal entities performing delivery services that may use data for purposes other than completion of the stated purpose. Same represents legal entities that use the data on their own behalf under equable practices. Other-recipient represents legal entities that are constrained by and accountable to the original service provider but may use the data in a way not specified in the service provider’s practices. Unrelated represents legal entities whose data usage practices are not known by the original service provider. Public refers to public fora. In addition to ours and public, the other four predefined values represent a set of recipients, respectively. These recipients have been known explicitly by service providers. Therefore, delivery, same, other-recipient, and unrelated denote, respectively, the set of delivery services possibly following different practices, the set of legal entities following equable practices, the set of legal entities following different practices, and the set of legal entities whose data usage practices are not known. We define the six predefined values of Recipient element in privacy policies of composite services as follows.

Definition 2. A composite service consists of member services. If Recipient values of a Data element in privacy policies of member services include ours, the Recipient values of the Data element in privacy policy of composite service include ours as well.

Definition 3. A composite service consists of member services. The sets of delivery values of a Data element in privacy policies of member services are noted as  , . The set of delivery values of the Data element in privacy policy of composite service is denoted as , .
If a Data element is not included in privacy policy of a member service or Recipient values of the Data element in privacy policy of a member service do not include delivery, the set of delivery values in the service’s privacy policy is set to be an empty set.

Definition 4. A composite service consists of member services. The sets of same values of a Data element in privacy policies of member services are noted as . The set of same values of the Data element in privacy policy of composite service is denoted as , .
If a Data element is not included in privacy policy of a member service or Recipient values of the Data element in privacy policy of a member service do not include same, the set of same values in the service’s privacy policy is set to be an empty set.

Definition 5. A composite service consists of member services. The sets of other-recipient values of a Data element in privacy policies of member services are noted as . The set of other-recipient values of the Data element in privacy policy of composite service is denoted as , -.
If a Data element is not included in privacy policy of a member service or Recipient values of the Data element in privacy policy of a member service do not include other-recipient, the set of other-recipient values in the service’s privacy policy is set to be an empty set.

Definition 6. A composite service consists of member services. The sets of unrelated values of a Data element in privacy policies of member services are noted as . The set of unrelated values of the Data element in privacy policy of composite service is denoted as , .
If a Data element is not included in privacy policy of a member service or Recipient values of the Data element in privacy policy of a member service do not include unrelated, the set of unrelated values in the service’s privacy policy is set to be an empty set.

Definition 7. A composite service consists of member services. If Recipient values of a Data element in privacy policies of member services include public, the Recipient value of the Data element in privacy policy for composite service is public. And will be set.
According to Definitions 2~7, we can get Recipient values of Data elements in privacy policy of Service A as shown in Table 1. The Recipient value of #user.name in privacy policy of Service A is ours. The Recipient values of #user.home-info in privacy policy of Service A are ours, , and .


RecipientPolicy1Policy2Policy3PolicyA

Oursuser.nameIncludingIncludingNot includingIncluding
Deliveryuser.name
Sameuser.name
Other-recipientuser.name
Unrelateduser.name
Publicuser.nameNot includingNot includingNot includingNot

Oursuser.home-infoNot includingIncludingIncludingIncluding
Deliveryuser.home-info
Sameuser.home-info
Other-recipientuser.home-info
Unrelateduser.home-info
Publicuser.home-infoNot includingNot includingNot includingNot

3.3. Retention Definition

In P3P privacy policies, Retention element has five predefined values which are no-retention, stated-purpose, legal-requirement, business-practices, and indefinitely. No-retention means information is not retained for more than a brief period of time necessary to make use of it during the course of a single online interaction. Stated-purpose means information is retained to meet the stated purpose. Legal-requirement means information is retained to meet a stated purpose, but the retention period is longer because of a legal requirement or liability. Business-practices indicates information is retained under a service provider’s stated business practices. Indefinitely indicates information is retained for an indeterminate period of time. When the Retention value is stated-purpose, legal-requirement, or business-practices, service providers will give the specific destruction time. If the Retention value is no-retention, we set the retention time to be zero noted as 0. And if the Retention value is indefinitely, we set the retention time to be infinity noted as. We choose the longest retention time of a Data element in the privacy policies of member services as the retention time of the Data element in privacy policy of composite service. Moreover, we use specific time instead of stated-purpose, legal-requirement, and business-practices to represent Retention values in the privacy policies of composite services. And if a Data element is not included in privacy policy of a member service, we set the Retention value of the Data element in the service’s privacy policy to be null.

Definition 8. A composite service consists of member services. The specific time corresponding to the Retention values of a Data element in privacy policies of member services is denoted by , noted as . The Retention value of the Data element in privacy policy of composite service is denoted by . If . If , . If , .
The Retention values of #user.name and #user.home-info in privacy policies of member services are showed in Table 2. According to Definition 8, we can get Retention values of Data elements in privacy policy of Service A as follows:


Retention Policy1Policy2Policy3

20 daysNull
Null10 days

3.4. Attributes Definition

In a P3P privacy policy, Data, Purpose, and Recipient elements can take an optional attribute called Optional for the former and Required for the latter two. The Optional value is either no when the data is needed or yes when the data is optional. And if the Optional value of data is not explicitly specified, the Optional value of the data will take the default value (no). The Required value for Purpose elements can be always, opt-in, or opt-out. Always means the purpose is always required. Opt-in means data may be used for the purpose only when the user affirmatively requests this use. Opt-out means data may be used for the purpose unless the user requests that it not be used in this way. And if the Required value of a purpose is not explicitly specified, the Required value of the purpose will take the default value (Always). The Required value for Recipient elements with the exception of ours can be always, opt-in, or opt-out. Always means the recipient is always required. Opt-in means data may be distributed to the recipient only when the user affirmatively requests this use. Opt-out means data may be distributed to the recipient unless the user requests that it not be used in this way. And if the Required value of a recipient is not explicitly specified, the Required value of the recipient will take the default value (Always). We define the values of Optional and Required attributes in privacy policies of composite services as follows.

Definition 9. A composite service consists of member services. The Optional values of a Data element in privacy policies of member services are denoted by , noted as . The Optional value of the Data element in privacy policy of composite service is denoted by . If one of is no, then is no; otherwise is yes.
If a Data element is not included in privacy policy of a member service, the Optional value of the Data element in the service’s privacy policy is set to be null.

Definition 10. A composite service consists of member services. The Required values of a Purpose value in privacy policies of member services are denoted by Req, noted as . The Required value of the Purpose value in privacy policy of composite service is denoted by ReqCS. If one of is always, then ReqCS is always. If all of are opt-in, then ReqCS is opt-in. Otherwise ReqCS is opt-out.
If a Purpose value is not included in the privacy policy of a member service, the Optional value of the Purpose value in the service’s privacy policy is set to be null.

Definition 11. A composite service consists of member services. If a Recipient value is not ours or public, the Required value of the Recipient value in privacy policy of composite service is the same as the value in privacy policies of member services.
If a Recipient value is not included in privacy policies of member services, the Required value of the Recipient value in privacy policy of composite service is set to be null.

Definition 12. A composite service consists of member services. The Required value of public in privacy policies of member services is denoted by Red, noted as . The Required value of public in privacy policy of composite service is denoted by RedCS. If one of is always, then RedCS is always. If all of are opt-in, then RedCS is opt-in. Otherwise RedCS is opt-out.
If public is not included in privacy policy of a member service, the Required value of public in the service’s privacy policy is set to be null.
According to Definition 9, we can get Optional values of Data elements in privacy policy of Service A as shown in Table 3. The Optional value of #user.name in privacy policy of Service A is no. The Optional value of #user.home-info in privacy policy of Service A is no.
According to Definition 10, we can get Required values of Purpose values in privacy policy of Service A as shown in Table 4. The Required values of Purpose values in privacy policy of Service A are all always.
According to Definitions 11~12, we can get Required values of Recipient values in privacy policy of Service A as shown in Table 5. The Required value of in privacy policy of Service A is always. The Required value of in privacy policy of Service A is opt-out.
By Definitions 1~12, we have got the Purpose values, Recipient values, Retention values, and Optional values of Data elements in Service A as well as the Required values of Purpose and Recipient elements. On the basis of the semantic associations of Purpose, Recipient, Retention, and Data elements, we can obtain the P3P privacy policy for Service A as shown in Algorithm 6.


DataPolicy1Policy2Policy3PolicyA

User.nameNoYesNullNo
User.home-infoNullNoNoNo


PurposePolicy1Policy2Policy3PolicyA

CurrentAlwaysAlwaysNullAlways
TelemarketingNullAlwaysAlwaysAlways


RecipientPolicy1Policy2Policy3PolicyA

NullNullAlwaysAlways
NullOpt-outNullOpt-out

Policy{Entity (#business.name): ,
Purpose: (current, telemarketing),
    Recipient: (ours),
    Retention: (indefinitely),
    Data: (#user.name, #user.home-info)}
Purpose: (telemarketing),
    Recipient: ( , [opt-out]),
    Retention: (indefinitely),
    Data: (#user.home-info)

4. Case Study

Consider an online travel broker service named TravelBroker. The TravelBroker service consists of FlightBooking, HotelReservation, and Payment services. People can book plane tickets, reserve hotel rooms, and pay online through TravelBroker. The P3P privacy policies of FlightBooking service, HotelReservation service, and Payment service are called Policy1, Policy2, and Policy3, respectively, as shown in Algorithms 7, 8, and 9. Next we will show how to obtain P3P privacy policy for TravelBroker.

Policy1{Entity (#business.name): FlightBooking ,
Purpose: (current),
   Recipient: (ours),
   Retention: (legal-requirement),
   Data: (#user.IDCardNo)}
Purpose: (current, contact [opt-out]),
   Recipient: (ours, same),
   Retention: (legal-requirement),
   Data: (#user.Name, #user.Mobile)

Policy2{Entity (#business.name): HotelReservation ,
Purpose: (current),
  Recipient: (ours),
  Retention: (legal-requirement),
  Data: (#user.IDCardNo)}
Purpose: (current, contact [opt-in]),
  Recipient: (ours, unrelated [opt-out]),
  Retention: (indefinitely),
  Data: (#user.Name, #user.Mobile)

Policy3{Entity (#business.name): Payment ,
Purpose: (current),
 Recipient: (ours),
 Retention: (legal-requirement),
 Data: (#user.Name [yes], #user.Mobile, #user.BankCardNo)

According to Definition 1, we can get the sets of Purpose values of Data elements in privacy policy of TravelBroker:

According to Definitions 2~7, we can get Recipient values of Data elements in privacy policy of TravelBroker as shown in Table 6. The Recipient value of #user.IDCardNo in privacy policy of TravelBroker is ours. The Recipient values of #user. Name in privacy policy of TravelBroker are ours, , and . The Recipient values of #user.Mobile in privacy policy of TravelBroker are ours, , and . The Recipient value of #user.BankCardNo in privacy policy of TravelBroker is ours.


RecipientPolicy1Policy2Policy3PolicyCS

IncludingIncludingNot includingIncluding
Not includingNot includingNot includingNot

IncludingIncludingIncludingIncluding
Not includingNot includingNot includingNot

IncludingIncludingIncludingIncluding
Not includingNot includingNot includingNot

Not includingNot includingIncludingIncluding
Not includingNot includingNot includingNot

Table 7 shows the Retention values of #user.IDCardNo, #user.Name, #user.Mobile, and #user.BankCardNo in privacy policies of member services. According to Definition 8, we can get Retention values of Date elements in privacy policy of TravelBroker as follows:


RetentionPolicy1Policy2Policy3

1 month20 daysNull
1 month 2 months
1 month 2 months
NullNull1 month

According to Definition 9, we can get Optional values of Data elements in privacy policy of TravelBroker as shown in Table 8. The Optional value of #user.IDCardNo in privacy policy of TravelBroker is no. The Optional value of #user.Name in privacy policy of TravelBroker is no. The Optional value of #user.Mobile in privacy policy of TravelBroker is no. The Optional value of #user.BankCardNo in privacy policy of TravelBroker is no.


DataPolicy1Policy2Policy3PolicyCS

User.IDCardNoNoNoNullNo
User.NameNoNoYesNo
User.MobileNoNoNoNo
User.BankCardNoNullNullNoNo

According to Definition 10, we can get Required values of Purpose values in privacy policy of TravelBroker as shown in Table 9. The Required value of current in privacy policy of TravelBroker is always. The Required value of contact in privacy policy of TravelBroker is opt-out.


PurposePolicy1Policy2Policy3PolicyCS

CurrentAlwaysAlwaysAlwaysAlways
ContactOpt-outOpt-inNullOpt-out

According to Definitions 11~12, we can get Required values of Recipient values in privacy policy of TravelBroker as shown in Table 10. The Required value of in privacy policy of TravelBroker is always. The Required value of in privacy policy of TravelBroker is opt-out. The Required value of in privacy policy of TravelBroker is always. The Required value of in privacy policy of TravelBroker is opt-out.


RecipientPolicy1Policy2Policy3PolicyCS

AlwaysNullNullAlways
NullOpt-outNullOpt-out
AlwaysNullNullAlways
NullOpt-outNullOpt-out

By Definitions 1~12, we have got the Purpose values, Recipient values, Retention values, and Optional values of Data elements in TravelBroker as well as the Required values of Purpose and Recipient element. On the basis of the semantic associations of Purpose, Recipient, Retention, and Data elements, we can obtain the P3P privacy policy for TravelBroker as shown in Algorithm 10.

Policy{Entity (#business.name): TravelBroker ,
Purpose: (current),
  Recipient: (ours),
  Retention: (1 month),
  Data: (#user.IDCardNo, #user.BankCardNo)}
Purpose: (current, contact [opt-out]),
  Recipient: (ours, , [opt-out]),
  Retention: (indefinitely),
  Data: (#user.Name)}
Purpose: (current, contact [opt-out]),
  Recipient: (ours, , [opt-out]),
  Retention: (indefinitely),
  Data: (#user.Mobile)

When people enjoy the convenient, efficient, and flexible services on the Internet, their privacy information is inevitably collected by service providers. References [12, 13] assessed the risks of privacy abuse by game theory. The conclusion was that service providers tended to seek for undue interests by misusing and exposing users’ privacy information. In order to prevent users’ privacy information from being abused, service providers are asked to publish their privacy policies on their websites. P3P privacy policy has been used by more and more websites. By July 2003, 30% of the top 100 websites had used P3P. And 23% of the top 500 websites had used P3P [14].

Some scholars have researched on the semantics for P3P privacy policy and the relationships among several P3P privacy policies. The work from Hogben expressed P3P privacy policy formally by an OWL ontology [15]. This work had been written to the W3C Working Group Note. Yu et al. proposed data-centric formal semantics for P3P policies, which precisely and intuitively modeled the relationships between different components of P3P statements [16]. Agrawal et al. enunciated key privacy principles for privacy-aware database systems and proposed a strawman design for the database systems using purpose-centric base [17]. Boontawee Suntisrivaraporn and Khurat proposed semantics for P3P employing a data-purpose centric relational table [18]. They used an OWL ontology to systematically and precisely describe P3P privacy policy. In our previous work, we put forward data-recipient centric formal semantics for P3P policies, which supported the semantic conflict detection of P3P [19]. May et al. proposed two flexible policy relations derived from bisimulation in process calculi [20]. They illustrated the relations using examples from P3P. Nikolaos Papanikolaou et al. presented an approach to check for refinement between policies [21]. They automatically generated CSP models from P3P policies and then performed various tests using the FDR model checker.

With the wide application of web service composition, the protection of users’ privacy information in composite services attracts more and more attention. However, there are only a few scholars studying the application of P3P privacy policies in web service composition. Khurat et al. enhanced P3P to be able to support composite services, proposed a formal semantic for P3P employing a data-purpose centric relational table, and defined combining methods to obtain privacy policies of composite services [22]. However, due to the syntax of P3P being extended, P3P privacy policies of composite services generated by such methods could not be directly used to match with users’ privacy preferences. Our proposed method does not change the syntax of P3P. P3P privacy policies of composite services obtained by our method can match with users’ privacy preferences directly. Michele Chinosi and Trombetta checked whether a BPeX-represented business process was compliant with a P3P privacy policy by introducing a data model for BPMN and a corresponding XML-based representation called BPeX [23]. Li et al. proposed a graph-transformation based framework to check whether an internal business process adhered to the organizations’ P3P privacy policies [24]. Both [23, 24] applied P3P privacy policies in web service composition by business processes. However, they did not propose methods to obtain P3P privacy policies for composite services, yet assuming that P3P privacy policies of composite services had already existed. Our work proposes a method to obtain P3P privacy policies for composite services, which is the foundation of their work. Dong et al. presented an approach to implement privacy policy aggregation with P3P [10]. But they did not consider the internal relationship between Data elements and Purpose, Recipient, and Retention elements. In our work, we generate the Purpose, Recipient, and Retention values for each Data element, respectively, which avoids potential conflicts between Data elements and other elements.

6. Conclusions and Future Work

Privacy protection in composite services has become an important issue. P3P is an existing technology employed to protect privacy. In order to apply P3P directly to composite services, we propose a method to obtain P3P privacy policies for composite services in the paper. We present the definitions of Purpose, Recipient, and Retention elements as well as Optional and Required attributes for P3P policies of composite services in the method and provide an instantiation to demonstrate the feasibility of the method.

The base data schema of P3P is defined in a hierarchy. It will cause conflicts of data hierarchy constraints if the upper level data has more strict constraints than its lower level data. For example, #user.bdate is the higher level data relative to #user.bdate.ymd.year. If the Optional value of #user.bdate is yes, the Optional value of #user.bdate.ymd.year can be no or yes. But if the Optional value of #user.bdate is no, the Optional value of #user.bdate.ymd.year must be no. In this paper, there is no conflict of data hierarchy constraints in P3P privacy policies. So we do not consider the conflicts of data hierarchy constraints when obtaining P3P privacy policies for composite services. As future work, we plan to consider the conflicts of data hierarchy constraints and enhance our method to resolve it.

Conflict of Interests

The authors declare that there is no conflict of interests regarding the publication of this paper.

Acknowledgment

This work is supported by the National Natural Science Foundation of China (Grant no. 61272083).

References

  1. L. Cranor, M. Langheinrich, M. Marchiori et al., “The platform for privacy preferences 1.0 (P3P1. 0) specification,” W3C Recommendation, 2002. View at: Google Scholar
  2. L. Cranor, M. Langheinrich, and M. Marchiori, “A P3P preference exchange language 1.0 (APPEL1.0),” W3C Working Draft, 2000. View at: Google Scholar
  3. B. Suntisrivaraporn and A. Khurat, “Formalizing and reasoning with P3P policies using a semantic web ontology,” in Multi-Disciplinary Trends in Artificial Intelligence, vol. 7080 of Lecture Notes in Computer Science, pp. 87–99, Springer, Berlin, Germany, 2011. View at: Publisher Site | Google Scholar
  4. D. Jordan, J. Evdemon, A. Alves et al., “Web services business process execution language version 2.0,” OASIS Standard, vol. 11, 2007. View at: Google Scholar
  5. W3C Group, Web Services Description Language (WSDL1.1), 2001, http://www.w3.org/TR/wsdl.
  6. N. Milanovic and M. Malek, “Current solutions for Web service composition,” IEEE Internet Computing, vol. 8, no. 6, pp. 51–59, 2004. View at: Publisher Site | Google Scholar
  7. J. Zhai, Z. Shao, Y. Guo, and H. Zhang, “Novel web service selection model based on discrete group search,” The Scientific World Journal, vol. 2014, Article ID 460593, 6 pages, 2014. View at: Publisher Site | Google Scholar
  8. L. Chen, W. Ha, and G. Zhang, “Reliable execution based on CPN and skyline optimization for web service composition,” The Scientific World Journal, vol. 2013, Article ID 729769, 10 pages, 2013. View at: Publisher Site | Google Scholar
  9. C. Ke, Z. Huang, and M. Tang, “Supporting negotiation mechanism privacy authority method in cloud computing,” Knowledge-Based Systems, vol. 51, pp. 48–59, 2013. View at: Publisher Site | Google Scholar
  10. L. Dong, Y. Mu, W. Susilo, P. Wang, and J. Yan, “A privacy policy framework for service aggregation with P3P,” in Proceedings of the 6th International Conference on Internet and Web Applications and Services (ICIW '11), pp. 171–177, 2011. View at: Google Scholar
  11. Z. Jia, Z. Huang, S. Wang et al., “Detecting P3P privacy conflicts based on ontology,” Jorunal of Frontiers of Computer Science and Technology, vol. 7, no. 1, pp. 78–86, 2013. View at: Google Scholar
  12. L. Rajbhandari and E. A. Snekkenes, “Using game theory to analyze risk to privacy: an initial insight,” in Privacy and Identity Management for Life, pp. 41–51, Springer, Berlin, Germany, 2011. View at: Google Scholar
  13. S. Kokolakis, A. Kalliopi, and M. Karyda, “An analysis of privacy-related strategic choices of buyers and sellers in e-commerce transactions,” in Proceedings of the 16th Panhellenic Conference on Informatics (PCI '12), pp. 123–126, Piraeus, Greece, October 2012. View at: Publisher Site | Google Scholar
  14. L. F. Cranor, “P3P: making privacy policies more useful,” IEEE Security and Privacy, vol. 1, no. 6, pp. 50–55, 2003. View at: Publisher Site | Google Scholar
  15. G. Hogben, “P3P using the semantic web (OWL ontology, RDF policy and RDQL rules),” Working Group Note, W3C, 2004. View at: Google Scholar
  16. T. Yu, N. Li, and A. I. Antón, “A formal semantics for P3P,” in Proceedings of the Workshop on Secure Web Service, pp. 1–8, ACM, 2004. View at: Google Scholar
  17. R. Agrawal, J. Kiernan, R. Srikant, and Y. Xu, “Hippocratic databases,” in Proceedings of the 28th International Conference on Very Large Data Bases (VLDB '02), pp. 143–154, VLDB Endowment, 2002. View at: Google Scholar
  18. B. Suntisrivaraporn and A. Khurat, “Formalizing and reasoning with P3P policies using a semantic web ontology,” in Multi-Disciplinary Trends in Artificial Intelligence, pp. 87–99, Springer, Berlin, Germany, 2011. View at: Google Scholar
  19. Y. Sun, Z. Huang, G. Shen, and C. Ke, “Research on P3P formal semantics supporting conflict detection,” Journal of Frontiers of Computer Science and Technology, vol. 7, no. 10, pp. 905–915, 2013. View at: Google Scholar
  20. M. J. May, C. A. Gunter, I. Lee, and S. Zdancewic, “Strong and weak policy relations,” in Proceedings of the IEEE International Symposium on Policies for Distributed Systems and Networks (POLICY '09), pp. 33–36, London, UK, July 2009. View at: Publisher Site | Google Scholar
  21. N. Papanikolaou, S. Creese, and M. Goldsmith, “Refinement checking for privacy policies,” Science of Computer Programming, vol. 77, no. 10-11, pp. 1198–1209, 2012. View at: Publisher Site | Google Scholar | Zentralblatt MATH
  22. A. Khurat, D. Gollmann, and J. Abendroth, “A formal P3P semantics for composite services,” Lecture Notes in Computer Science, vol. 6358, pp. 113–131, 2010. View at: Publisher Site | Google Scholar
  23. M. Chinosi and A. Trombetta, “Integrating privacy policies into business processes,” Journal of Research and Practice in Information Technology, vol. 41, no. 2, pp. 155–170, 2009. View at: Google Scholar
  24. H. Y. Li, Y. H. Paik, and B. Benatallah, “Formal consistency verification between BPEL process and privacy policy,” in Proceedings of the 2006 International Conference on Privacy, Security and Trust: Bridge the Gap between PST Technologies and Business Services, article 26, ACM, 2006. View at: Google Scholar

Copyright © 2014 Yi Sun et al. This is an open access article distributed under the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.

615 Views | 320 Downloads | 1 Citation
 PDF  Download Citation  Citation
 Download other formatsMore
 Order printed copiesOrder

We are committed to sharing findings related to COVID-19 as quickly and safely as possible. Any author submitting a COVID-19 paper should notify us at help@hindawi.com to ensure their research is fast-tracked and made available on a preprint server as soon as possible. We will be providing unlimited waivers of publication charges for accepted articles related to COVID-19.