Conflicts in Inter-prise EPAL Policies

Sitaraman Lakshminarayanan
TechDemocracy LLC
Iselin, NJ, USA
L_Sitaraman@yahoo.com

Rajesh Ramamoorthy
Skinder Strauss Associates
Newark, NJ, USA
Rajesh_ramamoorthy@yahoo.com

Patrick C. K. Hung
Commonwealth Scientific and Industrial Research Organization (CSIRO)
GPO Box 664, Canberra ACT 2601, Australia
Patrick.Hung@csiro.au

The objective of this paper is to state the missinginformation with examples and table it for discussion. The existing EPAL text allows Enterprise policies to be enforced within an enterprise (Intra-Prise) but not between enterprises (Inter-Prise).

EPAL

Enterprise Privacy Authorization Language (EPAL) [1] goes beyond an application and lays out a standard to protect customers' privacy enterprise wide. The example stated in section 2.1 of EPAL specification [2] clearly describes that the "input" to the application or enterprise could be from various sources but still the customer information should be protected as per global Eenterprise policy and is not just application specific. This gives control over privacy policy enterprise-wide. The enterprise privacy policy defines a set of rules. "Each rule can allow a set of data users to perform an action in a set of action on a category in a set of category for any purpose in a set of purposes"[3]. In addition to the rule, the EPAL could specify "set of obligations that should be implemented upon successful completion of the specified action and the rules might have to satisfy certain conditions before performing the action". Such an enterprise policy holds good for Intra-prise; however, when it comes to exchanging EPAL between enterprises or between applications, it is required to consider more issuesneeds extra information to complete the loop.

Missing Information

All applications within an enterprise should adhere to its privacy policies and it could happen without much problem. However, conflicts may arises when two different enterprises with conflicting privacy policies engaged in business transactionsdata exchange.  In such a case, we propose that the data subject(s) privacy information of the customer should be protected as per the initiator's privacy"enterprise policy of the sender / owner" and but not as per the receiver's privacy "enterprise policyof the recipient / user".

An Illustrative Example

Let us consider an the example of a customer applyingobtaining for a "Ccredit Ccard" from "Bank-A". This involves the customer and "Bank-A". Bank-A may have to obtain the customer's credit report obtained from a Credit Rating Agency (CRA) for processing the applicationto issue the credit card. In this case, Tthe CRA is the third party to this businesse transaction. Due to the privacy actHowever, customers can also obtain  get atheir own credit report directly from CRA's web site. In this scenario, Ddata received through both channels are stored internally and the data may also be used by other applications in CRA.

The privacy policy (e.g.,in our case it is EPAL) for both "Bank-A" and CRA are shownlooks as follows:.

Privacy policy of CRA

Privacy Policy of "Bank-A"

Conflicting Scenario

Note: The data shared by CRA with its business partners might actually belong to "Bank-A".

Conflicts in Inter-prise Privacy Policiescommunication

Companies have to conform to the rules (EPAL/P3P) when they interact and exchange data even though the policies are different. In a B2B environment, where the privacy policies (EPAL) are enforced, we propose that the customer information should be protected as per the initiator's privacy policy butof "the originator " and not as per the receiver's privacy policyof "the recipient". Thus, we extend the enterprise privacy policies in (EPAL) for this inter-prise environment discussed in the following sectionsshould be exchanged effectively.

Action and Purposes in EPAL

In EPAL, the XML elements "Action" and "Purpose" explain what action will be taken on the data that is collected for the specifiedaid purpose(s). An "Allow" from the EPAL authority gives a green signal to perform the "aAction" in addition to satisfying the "Conditions" and obeying the "Obligations". Here is an example of EPAL policy for obtaining the Bank-A customer's credit report in CRA:

EPAL Policy Description to obtain Credit Report

So far there is no problem. Now, a web service exposed by CRA to allow Bank-A to perform a Credit Rating check has no idea about the EPAL policy of Bank A. The data category is Credit Rating and the action is Credit Report. CRA wouldn't be able to issue a credit report without storing the information. Bank-A has no knowledge of the implementation of the web service, which is implemented to conform to CRA's privacy policy.

Thus, the Bank-A customer's information is thus stored is treated by at CRA applications as its own data conforming to the CRA'sits own privacy- policy discussed before. Thusis, enables the stored information to be shared with CRA's business partners leading to a conflict.

Obligations

In additionthe transaction discussed previously, the Bank-A privacyenterprise policyof "Bank-A" is not exchanged., eEven if the privacy policy is exchanged (by some means,) it does not state clearly how CRA could use the customer's data or information received, e.g.,(for example usage restrictions on Bank-A's data).

Here we propose Let us discuss some possible solutions that extend the EPAL language in the following paragraphs.

Solution 1:

One possible way is to handle conflicts is to define a new vocabulary called "Exclude Disclosure" for "Obligations" in the Bank-A's EPAL policyof "Bank-A". It means could state -- "Upon using the information to evaluate the credit of the customer, do not use the information for any Marketing purpose".Let us call the obligation as "Exclude Disclosure".

EPAL policy of Bank-A:

CRA has to conform to the obligations. The applications have to implement these obligations. This is basically going back to same application model where the privacy policies are under the control of applications and there is no strict enforcement enterprise wide.

A strict enforcement is the one in which it is enough for the applications to conform to the enterprise privacy policy with no tags attached. In the no tags-attached approach, the applications have to make sure that the privacy-policy allows the data user to retrieve the data. They don't have to check any thing else.

Importing Obligations as Conditions:

Another way to enforce the initiator's privacy policy with(usually restrictions) of data-owner is that the receiverrecipient enterprise should include theose (restrictions) as "C conditions" in its their EPAL enterprise policy.

Now the CRA's EPAL policy of CRA can be written aswith Conditions that says "Disclose data only when the customer belongs to CRA" in "Condition". This approach involves adding new conditions as and when new sets of actions and purposes are excluded from the business partners.

Unfortunately, nNot all obligations can become cConditions.:

Data-Owner (i.e., initiator) Oobligations can be converted to Data-Recipient (i.e., receiver) Cconditions as long as the action is repetitive as shown in theabove example. Not all obligations are restrictions that need to be implemented by the recipient repeatedly. Obligations by definition means, certain action need to be taken upon successful completion of the specified action for the specified purpose. These are usually repetitive actions that are executed every time upon successful completion of the specified action for the specified purpose. An example of a non-repetitive restriction is "Notifying the Owner of the receipt by an e-mail" or "Delete the record after 30 days"etc.

Solution 2:- Restriction List

AnotherSecond way to handle conflicts is to add a list of Rrestrictions to the a"Action"s and "pPurpose"s. For instance, when two enterprises, say Enterprise-A and Enterprise-B, indulge in a B2B handshake.: Enterprise-A is the sender (i.e., initiator) and Enterprise-B is the recipient (i.e., receiver), and the recipient should obey the restrictions that are imposed by Enterprise-A and vice versa.

Restrictions could be defined as "Restrict the information obtained from my enterprise (Enterprise-A or Enterprise-B) from being used for a specific sets of the following purposes and actions., Purpose1, purpose2, purpose3 and for the following actions, action1, action2, action3).

In this approach, the originator has the freedom to enforce the restrictions that the recipient should adhere to.

Note: Restrictions are different from conditions. Condition is something that should be met before performing the action. Restrictions are something that should be enforced which is applicable only in a B2B scenario where the enterprises exchange their privacy policies.

Here is the Bank-A's EPAL Ppolicy of Bank-A Wwith Rrestrictions:

When the CRA and Bank-A initiate the conversation, their EPALs' policies are exchanged and CRA imports all the "Restricted Action" and "Restricted Purpose" as "Conditions".

Now the EPAL policy of CRA becomes:

Once the new conditions are added, it is up to the applications to stick to the CRA's privacy policy of Credit Rating company and shouldwith the implementationthe policy.

This approach gives a flexibility to implement the following.

Policy Changes

The exchange of EPAL policies leads to a fewcouple of more topics for further discussion:.

[1] - Matthias Schunter, Paul Ashley, Satoshi Hada, Gunter Karjoth and Calvin Powers, "Enterprise Privacy Authorization Language (EPAL)," IBM Research Report, 2003/03/04. Online: http://www.zurich.ibm.com/security/enterprise-privacy/epal/Specification/index.html

[2] -- http://www.zurich.ibm.com/security/enterprise-privacy/epal/Specification/index.htmlsection 2.1

[3]- Rule excerpt from http://www.zurich.ibm.com/security/enterprise-privacy/epal/Specification/index.html