You are on page 1of 12

Special Issue of Ubiquitous Computing Security Systems

AGREEMENT NEGOTIATION FOR REACHING


THE RIGHT LEVEL OF PRIVACY

Susana Alcalde Bagüés1 2, Andreas Zeidler1


1
Siemens AG, Corporate Research and Technologies, Munich, Germany
salcalde@gmail.com, a.zeidler@siemens.com

Carlos Fernandez Valdivielso2, Ignacio R. Matias2


2
Public University of Navarra, Department of Electrical and Electronic Engineering,
Navarra, Spain
carlos.fernandez@unavarra.es, natxo@unavarra.es

ABSTRACT
In this article, we present new ways of establishing and enforcing binding
agreements with third-parties for personal privacy protection, regulating the way
the data is being used after initial collection. For that, we present a novel model of
privacy enforcement, complementing the notion of enterprise privacy with the
incorporation of an extra level of privacy enforcement, called personal privacy
enforcement. The core idea is twofold: First, to allow users of a pervasive service
to negotiate the desired level of privacy in a rather automated and simple way
before using the service and thereby granting access to personal data; and secondly,
to track and monitor the whole life-cycle of data after it was released. For this we
introduce the specification and use of an agreement negotiation protocol on a set of
obligations, which is described in this article.

Keywords: personal privacy, obligations, pervasive computing, privacy


architecture

1 INTRODUCTION of personal privacy and enterprise privacy


enforcement systems. It is not sufficient to rely only
Enterprises today collect already large amounts on enterprise's willingness to support individual's
of personal data from their customers. In the privacy requirements, as it is typically deemed
upcoming era of pervasive computing tracking the sufficient today. Protecting individuals' privacy in
flow and interchange of data most probably will get pervasive computing requires an additional level of
out of individuals' control entirely, due to the huge privacy protection. Together with the enforcement of
increase in scale, manner, and motivation of enterprise's privacy statements, government policies
collection, as well as the addition of new data types and privacy laws, it is necessary to deploy
such as context data. To ease privacy concerns, mechanisms specifically for defining,
enterprises more and more publish privacy communicating and enforcing people's privacy
statements that outline the enterprise privacy criteria, preferences. Privacy is a very subjective concept,
i.e. how data is being collected, used and shared. what is acceptable to one person, may be
These privacy statements can be found written in unacceptable to another. Thus, our approach is to
natural language or described using P3P [1]. In allow individuals, as users of pervasive services, and
general, they merely constitute privacy promises and enterprises to collaborate on the protection of
need to be backed up by technological means. In the personal and sensitive data.
work of Casassa et al. [2] the use of an Obligation We particularly address in this paper how this
Management System (OMS), as a solution, is collaboration between personal privacy and
proposed. There, Obligations are policies that dictate enterprise privacy solutions can be established. We
expectations and duties for enterprises on how to propose the use of agreements for creating automatic
handle personal data and how to deal with its life- bindings between parts and to ensure that data
cycle management. So far, most efforts related to protection requirements are adhered to. The main
privacy protection are centered on developing problem, obviously, is that users still have to trust to
privacy control for enterprises, like OMS [2], E-P3P some degree in enterprises' “promises”. Thus, we
[3], EPAL [4], XACML [5]. present the idea of employing observable bindings
In our work, we address the idea of extending between personal and enterprise frameworks. This is
privacy control in a substantial manner towards a realized by introducing an agreement negotiation
holistic privacy management, with the collaboration protocol together with a notification mechanism.

UbiCC Journal - Volume 5 www.ubicc.org 1758


Special Issue of Ubiquitous Computing Security Systems

Consequently, we present in this article our decisions should be made at this phase including
privacy enforcement model designed to allow the who can collect which data, under which
integration of enterprise and personal privacy control circumstances, what format, and how trusted is the
solutions. We detail an agreement negotiation data collector. Access refers to the point at which
protocol, on a set of obligations, designed to reach data is accessed, for a particular purpose, by the
the right level of privacy and show how agreements ultimate recipient. Important decisions concerned
can be tracked by using notifications. Finally, we this phase are how accurate and how confidential the
present the first prototype of the “Obligations” data should be, who should be allowed to access it,
application, developed to allow non-expert users to for what purpose, how accesses should be logged or
manage obligations by themselves. how data is suppose to be stored. Secondary use
refers to the use of data after initial access has been
2 PRIVACY PROTECTION IN PERVASIVE made. Secondary use may also include passing data
COMPUTING from one party, who might have been authorized, to
another party, who might not. Important decisions
Laws and enterprise privacy alone are not made at this phase should include who else should be
sufficient to prevent an unwanted intrusion into the able to access the data, secondary use purposes, and
private sphere of an individual. Users of pervasive whether it is allowed to share the data even further
computing systems need mechanisms to control and with others or how long the data can be stored.
manage their own privacy concerns. For instance, by The focus of this paper is on how to enable
delimiting who has access to what data and under mechanisms for secondary use and how those
which circumstances, which may be achieved by the measures can be integrated with mechanisms used
specification of privacy policies. during collection and access. For secondary use, we
However, purely technological solutions, such as consider the specification and negotiation of
policy systems for access control, by themselves, can obligations as a preventative mechanism, and their
achieve privacy goals only in limited situations, i.e., enforcement, by the enterprise recipient, an
they are necessary but not sufficient. Privacy control avoidance measure. By ensuring that the service,
in pervasive computing requires the integration of recipient of the data, is able to enforce a binding
several complementary mechanisms into a new agreement on a set of obligations, it can be avoided
design space, to address privacy concerns raised by a that uncontrolled misuses of data after initial
continuous collection and access to personal collection takes place. With respect to detection
contextual information. measures, common mechanisms are data logs and
The privacy design space defined by Jiang et al. legal audits. In our work we introduce additionally
[6] and shown in Figure 1 is taken as the reference the use of notifications to actively monitor the
design space within the context of our work. We ongoing use of disclosed data.
consider it to represent and cover quite accurately the
new privacy needs of users of pervasive computing
applications. It categorizes privacy protection
technologies into measures for prevention, avoidance,
and detection at the different stages of the data
lifecycle: collection, access, and secondary use.
Pervasive computing privacy requires then the
deployment of measures for: prevention, to ensure
that undesirable use of personal data will not occur.
Within the group of preventative measures we
include access control mechanisms, obfuscation and
anonymity. Privacy needs also measures for
avoidance, to minimize the risks and maximize the
benefits associated with data exchanges. By using
mechanisms for awareness, feedback and usage
control, the flow of information from data consumers
back to data owners can be increased. Users need to
be aware of personal privacy issues to properly
administrate privacy control and avoid risky
situations during the three phases of the data life
cycle. And finally, measures for detection are needed, Figure 1: Privacy Design Space for Pervasive
to detect unwanted misuses of disclosed data and act Computing
accordingly.
Protection during collection refers to the event at Today, there are mechanisms that can be applied
which personal data is initially collected. Important independently for each of the areas covered by the
privacy design space, although measures for

UbiCC Journal - Volume 5 www.ubicc.org 1759


Special Issue of Ubiquitous Computing Security Systems

avoidance and detection need to be further developed, which executes two consecutive steps: Notification
and, even more important, an integration model of Obligation and Signed Acceptance of Obligation.
needs to be defined. Thus, we defined the privacy The OoT is built upon the XACML standard
enforcement model presented in Section 3. following its Web Services Profile (WS-XACML).
The disadvantages of this approach are that it does
2.1 Related Work not cater for the enforcement and monitoring of such
The use of obligations in computer systems by obligations, on the one hand, and that it seems to be
itself is not a new topic. It has been largely used to rather complicated for a common user to manage
specify actions that must be performed by some obligations following this protocol, on the other hand.
entity. In daily situations where people interact,
individuals are held responsible for their own actions, 3 OUR PRIVACY ENFORCEMENT MODEL
for the obligations they assume, and they may be
punished if they fail to do what they have promised.
In 1996, Van the Riet et al. translated the
concept of obligations to the “cyberspace” In [7]
they conclude that although software entities cannot
take real responsibility, their specification still
should take into account what such entities must do
and what happens if they do not fulfill what has been
specified. For instance, within Ponder [8] obligations
are defined as event-triggered policies that carry-out
management tasks on a set of target objects or on the
subject itself, e.g. when a print error event occurs a Figure 2: Main characteristics of our Privacy
policy management agent will notify all operators of Enforcement Model
the error and log the event.
Obligations for secondary use control, also For addressing the integration of personal
called usage control, are requirements that must be privacy enforcement in pervasive computing, we
agreed on by obligation subjects, before authorizing have developed a three-tier privacy enforcement
the access to the data. Obligations can be seen as a model, shown in Figure 2, which serves as the base
binding statement to take some course of action in for the specification of the involved entities and for
the future by the obligation subject [9]. They are the formalization of their collaboration. One of the
crucial to restrict the flow and use of personal data in model’s main features is that it caters for the
the highly dynamic distributed environments integration of measures to address prevention,
assumed in pervasive computing. Nevertheless, in avoidance and detection during the lifecycle of
many policy systems, obligations have been defined personal data, i.e. collection, access and secondary
tightly coupled to the enforcement of access control use. Thus, it covers the privacy design space
policies and in general they cannot be used for described in Section 2. The model we propose
secondary use control. This is the approach followed consists of the following three pillars:
by EPAL [4] and XACML [5]. Within these access- 1. Data Collector: This pillar provides
control languages, obligations are a set of operations abstractions for representing any data collector,
associated with a policy that must be executed by the as typical source of context information found in
Policy Enforcement Point (PEP) together with an the environment. For dealing with them, we
authorization decision before allowing the access to classify them into two groups: i) The group of
the data. In the work of Park and Sandhu [10] data collectors under the direct control of a user,
obligations are requirements that have to be fulfilled such as, for example, a GPS tracking device. In
by a subject at the time of the request for allowing general, they are sources of personal context that
access to a resource. E.g., a user must give his name do not represent a privacy risk, per se. ii) Those
and email address to download a company’s white kind of data collectors that are run by enterprises,
paper. e.g. mobile network operators. Langheinrich
Therefore, the mentioned approaches do not addressed in his work the privacy implications of
cover the role of obligations in the context of those kind of data collectors and provided a
secondary use control. In that context, obligations Privacy Awareness System (PawS) to help
should provide binding agreements between two individuals deal with them. In our model we
parts, the requesting third-party and the target (owner assume that a similar framework to PawS [12] is
of the data), regarding the use of data after its initial in place for dealing with newly encountered data
collection. The work presented in [11] describes an collectors.
approach to archive digital signed commitments on 2. Trusted Privacy Manager: This central pillar
obligations between distributed parties. They provides abstraction for a personal and trusted
introduced the Obligation of Trust (OoT) protocol, privacy enforcement system. The role of the

biCC Journal - Volume 5 www.ubicc.org 1762


Special Issue of Ubiquitous Computing Security Systems

Trusted Privacy Manager is to orchestrate any trust management and to allow lifecycle awareness
disclosure of personal data and to manage the of the data. Our approach to establish a trusted
collaboration between entities with the goal to relationship between an enterprise service and the
protect an individual's privacy. Thus, it must Trusted Privacy Manager is based on the possibility
provide functionality for the evaluation of to subscribe to notifications about the use of
service-side privacy policies (data collectors and disclosed data.
data consumers), the enforcement of its users' In the collaboration of the Data Collector pillar
privacy policies, for guiding the negotiation of with other parts of the system, as it was mentioned
agreements on secondary use, and facilitating the already, we rely on the idea elaborated by
monitoring of disclosed data. Langheinrich. There, the privacy awareness system
3. Data Consumer: This last pillar holds for ubiquitous computing [12] allows data collectors
abstractions for representing data consumers, in to describe their collection policies in a machine-
particular consumers of context information that readable format and communicate these to their data
depend on external data collectors to implement subjects. If the user agrees, the services can collect
their respective services, e.g a “Restaurant information and users can utilize the services. Thus,
Finder” or a “Buddy Finder” service. Obviously, we can assume that a user is notified before a new
these are the main types of emerging services in data collection is started, (e.g. video surveillance or
pervasive computing. However, context indoor security tracking), the user then can check the
providers and service providers are typically service's privacy policy and either agrees to or denies
decoupled and operate independently from each the collection. Due to the implicit nature of this type
other and, thus, must be orchestrated. of data collectors, a user in general can only accept
or reject the collection of the data in a “take or
The privacy enforcement model we present here (physically) leave“ fashion.
is built around direct, one-to-one binding agreements In such a situation, in our model, additionally,
between the Trusted Privacy Manager and the other we propose the negotiation of an agreement on a set
two pillars, as shown in Figure 3. The Trusted of obligations before any data collection is
Privacy Manager acts as mediator between data commenced, to avoid unwanted misuses of the data
collectors and data consumers. It reduces and and furthermore, to control accesses to data being
simplifies potentially complex relationships between collected. Thereby, a bilateral privacy access
them to contractual two-part agreements, on contract is negotiated.
previously negotiated obligations, avoiding direct Symmetrically, for the Data Consumer we
exchange of data between data collectors and data assume that any consumer service first has to register
consumers. The idea behind the use of agreements is with an instance of the Trusted Privacy Manager and
twofold: to specify actions allowed on disclosed data upon registration discloses its privacy policy. The
and to avoid any uncontrolled disclosure that may service privacy policy (e.g. P3P) shall have at least
lead to unwanted exchanges of sensitive data. the following elements: data consumer description,
The collaboration between pillars is built around data elements the service requests, and purpose of
three functional blocks, Bilateral Privacy Access the request. If the registration is successful, the
Control, Obligations Negotiation and Management, Trusted Privacy Manager agrees on providing
and Obligations Tracking as it is shown in Figure 2. context broker functionality for the subscribed
They are complementary and depend on each other service according to the now established bilateral
to guarantee a holistic privacy protection. privacy access contract. From this moment on and
The first level of collaboration (Bilateral Privacy for each service request, a Trusted Privacy Manager
Access Control) demands from each part to include entity evaluates its user’s privacy policies to decide
privacy-aware access control mechanisms. Note that whether or not permission is granted. The data is
only in the case of the Trusted Privacy Manager transmitted only when all the restrictions defined by
access control should be context-aware, since is the a user are fulfilled. This avoids unwanted “take or
only tier that should have access to any user context leave situations“ with data consumers.
data. Bilateral access control means that both the However, bilateral privacy access control only
service side privacy policy and a user's privacy addresses situations where information is disclosed
policy should be evaluated before revealing any data. for the present use. This means that it only provides
How this is achieved may differ in each case. preventative and avoidance measures during
The second level, the Obligations Negotiation collection and access. Thus, it does not cover cases
and Management, requires from all three pillars to where information may be stored for future use or
adopt a common model for the specification of even be sold in a potentially different situation. Here
obligations and trust that data collectors and data is where the second and third functional blocks that
consumers will handle personal data according to define the collaboration between the pillars come
such obligations. The third level Obligations into play, introducing more mechanisms for
Tracking was introduced as an initial measure for detection and secondary use control. As a result, this

UbiCC Journal - Volume 5 1


www.ubicc.org 1761
Special Issue of Ubiquitous Computing Security Systems

avoidance and detection need to be further developed, which executes two consecutive steps: Notification
and, even more important, an integration model of Obligation and Signed Acceptance of Obligation.
needs to be defined. Thus, we defined the privacy The OoT is built upon the XACML standard
enforcement model presented in Section 3. following its Web Services Profile (WS-XACML).
The disadvantages of this approach are that it does
2.1 Related Work not cater for the enforcement and monitoring of such
The use of obligations in computer systems by obligations, on the one hand, and that it seems to be
itself is not a new topic. It has been largely used to rather complicated for a common user to manage
specify actions that must be performed by some obligations following this protocol, on the other hand.
entity. In daily situations where people interact,
individuals are held responsible for their own actions, 3 OUR PRIVACY ENFORCEMENT MODEL
for the obligations they assume, and they may be
punished if they fail to do what they have promised.
In 1996, Van the Riet et al. translated the
concept of obligations to the “cyberspace” In [7]
they conclude that although software entities cannot
take real responsibility, their specification still
should take into account what such entities must do
and what happens if they do not fulfill what has been
specified. For instance, within Ponder [8] obligations
are defined as event-triggered policies that carry-out
management tasks on a set of target objects or on the
subject itself, e.g. when a print error event occurs a Figure 2: Main characteristics of our Privacy
policy management agent will notify all operators of Enforcement Model
the error and log the event.
Obligations for secondary use control, also For addressing the integration of personal
called usage control, are requirements that must be privacy enforcement in pervasive computing, we
agreed on by obligation subjects, before authorizing have developed a three-tier privacy enforcement
the access to the data. Obligations can be seen as a model, shown in Figure 2, which serves as the base
binding statement to take some course of action in for the specification of the involved entities and for
the future by the obligation subject [9]. They are the formalization of their collaboration. One of the
crucial to restrict the flow and use of personal data in model’s main features is that it caters for the
the highly dynamic distributed environments integration of measures to address prevention,
assumed in pervasive computing. Nevertheless, in avoidance and detection during the lifecycle of
many policy systems, obligations have been defined personal data, i.e. collection, access and secondary
tightly coupled to the enforcement of access control use. Thus, it covers the privacy design space
policies and in general they cannot be used for described in Section 2. The model we propose
secondary use control. This is the approach followed consists of the following three pillars:
by EPAL [4] and XACML [5]. Within these access- 1. Data Collector: This pillar provides
control languages, obligations are a set of operations abstractions for representing any data collector,
associated with a policy that must be executed by the as typical source of context information found in
Policy Enforcement Point (PEP) together with an the environment. For dealing with them, we
authorization decision before allowing the access to classify them into two groups: i) The group of
the data. In the work of Park and Sandhu [10] data collectors under the direct control of a user,
obligations are requirements that have to be fulfilled such as, for example, a GPS tracking device. In
by a subject at the time of the request for allowing general, they are sources of personal context that
access to a resource. E.g., a user must give his name do not represent a privacy risk, per se. ii) Those
and email address to download a company’s white kind of data collectors that are run by enterprises,
paper. e.g. mobile network operators. Langheinrich
Therefore, the mentioned approaches do not addressed in his work the privacy implications of
cover the role of obligations in the context of those kind of data collectors and provided a
secondary use control. In that context, obligations Privacy Awareness System (PawS) to help
should provide binding agreements between two individuals deal with them. In our model we
parts, the requesting third-party and the target (owner assume that a similar framework to PawS [12] is
of the data), regarding the use of data after its initial in place for dealing with newly encountered data
collection. The work presented in [11] describes an collectors.
approach to archive digital signed commitments on 2. Trusted Privacy Manager: This central pillar
obligations between distributed parties. They provides abstraction for a personal and trusted
introduced the Obligation of Trust (OoT) protocol, privacy enforcement system. The role of the

biCC Journal - Volume 5 www.ubicc.org 1762


Special Issue of Ubiquitous Computing Security Systems

users. The communication between a CAMS and the  They specify actions that should be performed
UCPF services is realized by the Sentry’s PEP by a service, acting as the recipient of a user
component implementing an Interceptor pattern on data.
messages passing through the system. The Context  Obligations are used to automatically exchange
Handler provides access control to the system user’s preferences on secondary use with
repositories and acts as a mediator between the enterprises. For this reason, they are embedded
Sentry and external context collectors. It also into agreements to be negotiated before the data
manages the semantic models used to represent is given away.
policies and context data in the system.  They enable the exchange of notifications
The interaction of end-users with the UCPF is between the UCPF and third-party services and
made possible through the Sentry Manager Interface. with that post-disclosure life-cycle control.
It is implemented as an API used to generate,
upgrade or delete privacy policies, receive The Obligation Manager (OM) is the UCPF's
information about the current applicable policies, or component in charge of managing, negotiating and
getting feedback on potential privacy risks and tracking obligations. The OM consists of the
obligations state. Obligation Handler and the Obligation Monitor
The Noise Module is a modular functional components as shown in Figure 4. The first is in
component that injects additional information into charge of creating agreements with the obligations
the policy matching mechanism, typically for selected by a user and its negotiation. The Obligation
altering the data disclosed. Currently implemented Monitor monitors the state of obligations based on
are different levels of obfuscation, called notifications and data logs. It also compiles
Transformations [16], within the Local notifications to be sent by the Sentry to the service,
Transformation Point (LTP) and a disclosure which can just confirm a received notification,
mechanism for a Virtual Context within the White request a data log, or inform of an occurred violation
Lying Generator (WLG) [17]. including sanctions to be carried out, e.g. unregister
The Sentry Registry is the only component that the service.
is not co-located with the rest of the elements in the The following two examples illustrate the type
gateway. This component is shared among Sentries of obligations handled by the OM in the UCPF.
and thus must be hosted in the Internet. It tracks the
availability of people’s context and provides the Example 1: Bob will always allow to be tracked
pointer to the appropriate Sentry service instance. by indoor security systems, if his data is never
Services, organizations and Sentries need to be disclosed, and he can access the data generated.
registered with the UCPF before starting any context Example 2: Bob requires from all services using
request, which is done in the Sentry Registry. The his activity and location, that they do not store his
Sentry Registry has an important role in making data or if yes to delete them within one week or a
interactions possible between CAMS and Sentries, maximum of one month. Moreover, Bob wants to get
and also between different Sentry instances, a notification if a service discloses his location to the
providing Flexibility to deal with distributed and same recipient more than 5 times a day.
changing entities. Finally, the Obligation Manager,
see next section, negotiates agreements and tracks 4.1 Model of Privacy Obligations
the obligations agreed on by third parties. We created a set of predefined obligations and
classified them into system obligations and
4 OBLIGATIONS IN THE UCPF negotiable obligations. Obligations play a key role in
the establishment of the privacy enforcement model
In the UCPF obligations are used to enable the presented in this paper, thus not all obligations are
integration of measures for prevention, avoidance negotiable. For instance, the obligation “Data MUST
and detection on secondary use of personal data. The NOT be disclosed to any third-party”, is a mandatory
privacy enforcement model presented in Section 3, obligation used to avoid uncontrolled retransmissions
distributes the enforcement of users' privacy of data. System obligations are designed to be agreed
preferences between the UCPF and the enterprise on during the registration process of a new service
side. In Figure 3 we highlight those measures without negotiation. The goals of system obligations
enabled by the negotiation of agreements and their are to control disclosures to third-parties, monitor
posterior enforcement by the enterprise system. changes on a service privacy policy and enable the
Without the use of obligations, the UCPF could only access to collected data and data logs. They are
enforce preventative measures during access and mandatory obligations which are by default
collection. Obligations are used to create automatic established independently of a user's preferences and
bindings with CAMS and ensure that data protection beforehand of any commercial transaction with a
requirements are adhered to. Obligations in the service.
UCPF have the following purposes: Negotiable obligations, on the other hand, are

UbiCC Journal - Volume 5 www.ubicc.org 1763


Special Issue of Ubiquitous Computing Security Systems

selected by a user and negotiated with the service, and Datalog request. An Event is described with two
which is the recipient of the data. Users can specify properties, the EventType that identifies the event
obligations to be agreed on during the evaluation of a that will trigger the execution of the obligation, and
service request, which will be subject of the the property HasExtParameter, which ties its
agreement negotiation protocol. They represent the applicability to a specific value. For instance, in
privacy constraints that a user may impose on an Figure 6 for the obligation number “11”, the event
enterprise service when data is disclosed. In our Disclosure request is constrained by the identity of
definition, negotiable obligations have two aspects: the recipient (Recipient parameter) and the number
first, it is a second-class entity subject to the of disclosures allowed per day (Times parameter).
enforcement of a policy in the UCPF and compiled The values of these parameters are not included in
during the evaluation of a service request. And the definition of obligations, but in the agreement
second, when a policy evaluation contains document, as we will describe in the next section.
obligations, these obligations are not enforced by the
Sentry’s PEP but activate a negotiation protocol.
Then, obligations are first-class entities used to
exchange personal privacy preferences with an
enterprise service. Negotiable obligations are used to
control the information disclosed among individuals
(users of a particular service), authorized purposes,
number of accesses and retention time of user
resources.
In the representation of obligations basically we
follow the schema adopted by the OMS designed by Figure 6: Example of System Obligations
Casassa et al. [18] to facilitate collaboration with the
enterprise privacy enforcement system. Obligations Once an obligation is activated, and its event
in the UCPF are XML documents with Event, Action, parameters are true, its execution has two effects,
Notification and Metadata elements. Figure 5 shows one is that an action must be performed, specified
the template used to create obligations in the UCPF, with the property ActionType, and the second is that
together with a XML instance of the obligation “13”. a notification must be sent to a Sentry instance. The
Some tags defined by HP’s OMS were left out in our type of notification that needs to be compiled is
definition (e.g. Target), which only can be used identified by the NotificationType property. The
together with the OMS, and a new tag, the predefined obligations are distributed as an XML file.
Notification element, was added. These obligations are common to all data collectors
and data consumers. Therefore, we need agreement
documents to personalize and bind obligations with
third-parties.

Figure 5: Obligation Template and XML Example

Examples of both types of obligations are shown


in Figure 6 and Figure 7. The XML instances of Figure 7: Example of Negotiable Obligations
Figure 6 represent system obligations, they can be
used in the example 1, to control that unwanted 4.2 Agreement Negotiation Protocol
disclosures to third-parties do not occur. On the other The schema adopted in the definition of
hand, the XML instances of Figure 7 belong to agreements is shown on the left hand side in Figure 8,
negotiable obligations; they can be used in the an agreement is an XML document with Agreement,
example 2 to limit the retention of the data and the Resource, URLNotification, Timestamp, Negotiation,
number of disclosures to a same subject. ListObligations, and IfViolated elements.
An obligation is activated at the moment that its Agreements are used to bind a list of obligations
Event occurs. We have considered in our between two parts, a UCPF and a third-party service,
implementation eight different events, namely: and allow for their negotiation. The use of
Disclosure request, Data leaking, Policy changed, agreements allows the personalization of general
Data collection, Access request, Storage, Timeout, obligations and with that, the use of a limited number

UbiCC Journal - Volume 5 www.ubicc.org 1764


Special Issue of Ubiquitous Computing Security Systems

of predefined obligations, which are “reused” in each


agreement, instead of creating new instances. 4.2.1 Negotiation Protocol.
The Agreement tag identifies the involved parts The agreement negotiation protocol, cf. Figure 9
and the priority of such agreement. The priority starts after the policy evaluation of a service request
property can have one out of the following values: within a Sentry instance concludes. If the policy
Mandatory, Middle, Optional and Request. It applies effect compiled contains obligations, the PEP queries
only if after finishing all the negotiation rounds the the OM for an agreement over the pending
agreement state is denied. The Resource element obligations, step 1 in Figure 9. Then, if there is not a
identifies the data owner with the properties Owner previous agreement, the OM returns the agreement to
and Scope, the scope describe the type of resource be negotiated, step 2. The Sentry launches the
(e.g. location, activity, calendar). The Negotiation negotiation, steps 3 to 14, which is repeated at most
tag specifies the state and the current round of a for three rounds.
negotiation, the OM always sets an agreement in This protocol enables per-service and per-user
state “Negotiating” and controls the negotiation resource agreements negotiations that are guaranteed
round. A service can change the state property from to terminate after at most three negotiation rounds.
“Negotiating” to “Denied” or “Accepted”, but not This is inspired by the work of Walker et al. [19] in
the negotiation round. the “Or Best Offer” protocol. The Obligation
Manager makes a first proposal in the Negotiating
Optimum stage. The enterprise side cannot make any
counter-proposal at this stage, since the user should
not be involved during the negotiation, for the sake
of simplicity and user friendliness. Therefore, the
service provider is limited to check the list of
obligations attached and to reject or bind them. If the
agreement is denied by the enterprise, which means
that one or more obligations are rejected, the OM
issues the second proposal: Negotiating Acceptable
stage. It includes a new set of obligations where the
rejected obligations of the first set are replaced by
Figure 8: Agreement and Notification Template their acceptable equivalents. The enterprise service
may accept the second proposal, or start the third and
In an agreement, obligations are associated with last round: Negotiating Minimum stage, in which a
the element ListObligations. This element does not new set of obligations classified as minimum replaces
contain the specification of obligations but a those rejected. The goals of this negotiation strategy
reference to one or more of the obligations included are: i) to allow more than “take or leave” situations,
in the list of common obligations. Each obligation is ii) to enable an automatic setup of user's privacy
represented with an ID and a state value. The State preferences on secondary use, and iii) to execute the
property should be changed by the service from its obligation binding process transparent to the user.
value “Pending” to “Rejected” or “Accepted”.
Moreover, an obligation, in an agreement, has the
property EventParameter to personalize the event
that should trigger the execution of the obligation.
The parameter included depends on the type of
obligation, some obligations may add the parameter
“Recipient” (without parameter it is considered as
any recipient), other obligations require the
parameter “Times”, to identify the number of times
that the data can be accessed, the parameter “Date” is
used to specify when the data should be removed and
the parameter “Purpose” identifies allowed
secondary uses of the data. Finally, agreements
include the tag IfViolated to inform about the
consequences of violating any of the obligations
agreed on during the negotiation.
Agreements are negotiated per service and
resource if an agreement exists; there is no need to
re-negotiate it in following requests. Only if the Figure 9: Agreement Negotiation Protocol Sketch
privacy policy of the requesting service changes an
agreement needs to be re-negotiated. In a situation where an enterprise does not accept

UbiCC Journal - Volume 5 www.ubicc.org 1765


Special Issue of Ubiquitous Computing Security Systems

the third and last proposal, no agreement is reached notification types, notifications used to notify a
and the priority of the rejected agreement is taken UCPF and notifications developed to notify back a
into account by the OM. Each agreement is labeled service. Figure 10 describes and summarizes the
with a priority value. Priority Mandatory means that different notifications implemented. There are 13
the service (enterprise) MUST accept the agreement notifications types, eight are used for notifying the
otherwise permission will be denied (step 14). UCPF (as subscriber), namely: Leaking, Policy,
Priority Middle means that the service SHOULD Repository, Datalog, Request, Granted Disclosure,
accept the agreement otherwise data quality will Access and Deletion, and five for notifying the
decrease in accuracy. A priority equals to Optional service in return: Reminder, Getdatalog,
means that the service MIGHT accept the agreement Confirmation, Response and OnViolation.
and entails the disclosure of the requested data Notifications as agreements are XML documents; the
anyway but the user will be notified that no schema used to create new instances of a notification
agreement was reached; a user may modify his is shown on the right hand side in Figure 8. The main
privacy settings based on the obligations rejected element of a notification is the Notification tag; it
then. If the priority is set to Request the user will be identifies the type of notification and holds relevant
asked whether or not he wants to disclose the data information in the form of parameters. Depending on
anyway. the notification type used, different parameters need
to be provided. E.g. a Deletion notification should
4.3 Notification Mechanism include the time frame in which some data was
Our approach to establish a trusted relationship removed from the repository. On the other hand, a
between an enterprise service and the UCPF also is Granted Disclosure notification should include also
based on the possibility to subscribe to notifications the recipient of the data and the number of
about the use of disclosed data. Obligations are used disclosures that occurred in the period of time
to create automatic bindings between both parts, and considered. The parameters required by each
ensure that data protection requirements are adhered notification are shown in Figure 10. The use of
to. However, in cases where such bindings cannot be notifications allows for monitoring the status of the
monitored, checking the compliance with the active obligations and to communicate actions
obligation is almost impossible. The concept of Non- (penalties) in case of a violation state. We introduced
observable Obligations is described in the work of the tag Violation for this case. It describes the
Hilty et al. [20] they suggest that a possible solution sanctions carried out once the OM observes such a
is the use of nontechnical means, such as audits or violation.
legal means. We propose, additionally, the idea of In summary, notifications are used for: i)
employing observable bindings between our UCPF enabling monitoring of active obligations, ii)
and enterprise frameworks. This is realized by auditing the enterprise service, iii) getting access to
introducing a notification exchange mechanism. This personal data in the service's repository, iv) knowing
mechanism is activated by the execution of an when the service's obligation policy changes in order
obligation. Due to the fact that the enforcement of an to re-negotiate agreements, and v) controlling when
obligation in our model, follows the sequence Event- an active obligation is violated.
Action-Notification, instead of a mere Event-Action
used by previous approaches. 4.4 Obligations Management from the User
Perspective
Our work is driven by the vision that (non-
expert) users of the UCPF shall be empowered to
control their own personal privacy. Especially for the
area of obligation management, we addressed its
implementation from the perspective of normal users.
The main questions were How can a non-technically-
savvy user understand and manage obligations? and
How can we assist such users in negotiating
obligations with the providers of services used?'
Our solution to the above questions was to
implement an application, as part as the UCPF GUI,
called “Obligations”, in which a user can specify his
obligations easily. In the design stage we discarded
the idea of defining new obligations at the time of
adding a new rule. Mainly because it means an
Figure 10: Type of Notifications overload for the process of adding new permissions
into the system and obligations, for us, are entities
We describe here two complementary independent from access control. We believe that the

UbiCC Journal - Volume 5 www.ubicc.org 1766


Special Issue of Ubiquitous Computing Security Systems

natural way of thinking about obligations, from the before disclosing any new data to that service.
perspective of users, is as a “set of privacy
preferences to be enforced by the service provider on 4.5 Obligations Application
disclosed resources”. Thus, it follows that Figure 12 shows a screenshot of our application
obligations should be specified per service and prototype for managing sets of obligations. A user
resource and not to depend on a rule specification. can access this application directly from his “Privacy
Therefore, we implemented a separate application Desktop” home window by clicking into the panel
where users can set up obligations per tuple (service, “Obligations”. The access window that is opened
resource). now, shown on the left hand side in Figure 12,
For the development of the Obligation Manager guides users in the selection of a service provider and
and its application we followed the rule of providing a resource among location, activity and calendar,
some default setting, in a way that users do no need before allowing the access to the main screen of the
to take care of critical situations by themselves. obligations application. In the main screen, shown on
Mandatory obligations, needed for keeping a proper the right hand side the predefined sets of obligations
level of privacy, were labeled as System obligations are listed. If one or more obligations sets are selected
and excluded from the negotiation process. System they will be included into an agreement that needs to
obligations should be agreed-on by service providers be negotiated before disclosing the resource to the
during the registration process. The process is service.
transparent to the user and only services that fulfill With this application a user can change the
the registration requirements are available. parameters of the obligations belonging to a set and
Negotiable obligations were added to offer users a set the priority of each selected set. A set always
way to negotiate their privacy preference on consists of the three mandatory obligations, labeled
secondary use. Both obligation types should be as “Optimum”, “Acceptable”, and “Minimum”. They
enforced by the enterprise privacy system. Hence, can be predefined and be re-used, obviously, and do
obligations must be defined in advance and known not have to be defined separately each time. The
by both parties. A user then is limited to choose application offers also the possibility of checking
among known obligations, what means that he existing obligations and editing or canceling them.
cannot specify new types of obligations. In our The data displayed by this application is
implementation, due to the lack of a standard gathered from a database instance, implemented
definition of obligations, we developed our own set using MySQL, where predefined obligations,
of negotiable obligations, listed in Figure 11. obligations sets and user selected obligation sets are
saved. Each obligation set, associated with a tuple
(service, resource, and user), receives an identifier
number, which will be referenced by the rule effect
send to the Sentry's PEP for that selected service and
user's resource.

Figure 11: Predefined Obligations sets

The question remaining at this point obviously


is: How can a user setup his obligation policies with
respect to the optima-l, acceptable-, and minimum
agreement round? For this we grouped negotiable
obligations in sets of three obligations, optimal,
acceptable and minimum, one for each of the three
negotiation rounds allowed. These three obligations
of a set do not need to be different; they may differ
only on the event parameter e.g., the timeout to
delete data from a repository: 5 days, 1 month or 1
year. The application offers a selection of five
predefined sets, shown in Figure 11 namely: 1) Figure 12: UCPF GUI’s Obligation Application
“Limiting retention time”, 2) “Controlling data
disclosures”, 3) “Controlling data disclosures same 5 CONCLUSIONS AND OUTLOOK
subject”, 4) “Controlling data accesses”, 5)
“Limiting number of disclosures per day to the same In this paper, we presented how privacy control
subject”. If a user selects one or more of these sets, can be extended in a substantial manner toward
for a registered service, they need to be negotiated holistic privacy management, with the collaboration

UbiCC Journal - Volume 5 www.ubicc.org 1767


Special Issue of Ubiquitous Computing Security Systems

of personal privacy and enterprise privacy November 2003


enforcement. We introduced the notion of binding [5]. Tim Moses. OASIS standard. eXtensible Access
agreements for each privacy-related resource. An Control Markup Language TC v2.0, February
agreement is an XML document holding a set of 2005.
obligations selected by a user. Those selected [6]. Jiang, X., Hong, J. I., and Landay, J. A.
obligations need to be accepted by a third-party Approximate Information Flows: Socially-based
service before a granted permission is given to Modeling of Privacy in Ubiquitous Computing.
access the resource. Obligations describe the rights In proceedings of the 4th International
and requirements for processing, storing or deleting Conference on Ubiquitous Computing, 2002.
data that the recipient of a user's resource must [7]. R. P. van de Riet and J. F. M. Burg. Linguistic
enforce. In order to avoid situations where tools for modelling alter egos in cyberspace:
obligations may not be accepted by a service and Who is responsible? Journal of Universal
lead to simple denial of service, we developed a Computer Science, 2(9):623–636, 1996.
well-defined negotiation protocol for trying to find [8]. Nicodemos Damianou, Naranker Dulay, Emil
an agreement based on different classes of Lupu, and Morris Sloman. Ponder: A language
obligations such as optimum, acceptable and for specifying security and management policies
minimum type. for distributed systems, 2000.
An obligation in the UCPF is defined as an [9]. Lalana Kagal. A Policy-Based Approach to
event-action-notification entity, instead of a mere Governing Autonomous Behavior in Distributed
event-action. It follows that the enforcement of an nvironments. Phd Thesis, University of
obligation by the enterprise privacy system, activates Maryland Baltimore County, September 2004.
the exchange of notifications. We concluded that just [10]. Jaehong Park and Ravi Sandhu. The
using agreements on a set of obligations is not far- uconabc usage control model. ACM Trans. Inf.
reaching enough and introduced notifications to Syst.Secur., 7(1):128–174, 2004.
enable obligation tracking and with that the [11]. Uche M. Mbanaso, G. S. Cooper, David W.
monitoring of the fulfillment of agreements and the Chadwick, and Anne Anderson. Obligations or
usage of disclosed data after releasing it. In this privacy and confidentiality in distributed
paper, we showed that this is an easy but effective transactions. In EUC Workshops, 69–81, 2007.
way to enable trust between the client and the service. [12]. M. Langheinrich. A privacy awareness
We also presented the first prototype of the system for ubiquitous computing environments.
“Obligation” application, a user interface created to In Proceedings of the 4th International
be managed by non-expert users, and used to add Conference on Ubiquitous Computing. LNCS
new obligations sets to be negotiated with a No. 2498, Springer-Verlag, September 2002.
registered service. [13]. S. Alcalde Bagüés, A. Zeidler, C. Fernandez
Our future work includes applying our Valdivielso, I. R. Matias. Sentry@Home -
framework to privacy-sensitive applications in the Leveraging the Smart Home for Privacy in
context of patient-monitoring and -supervision, as Pervasive Computing. International Journal of
being found in integrated hospital IT landscapes. Smart Home Vol. 1 No. 2, 2007.
There we are about to start work in the context of the [14]. S. Alcalde Bagüés, J. Mitic, E. Emberger.
ITEA2 project AIMES[21]. The CONNECT Platform: An Architecture for
Context-Aware Privacy in Pervasive
6 REFERENCES Environments. IEEE CS,Workshop on Secure
and Multimodal Pervasive Environments 2007.
[1]. L. Cranor, M. Langheinrich, M. Marchiori, J. [15]. Knopflerfish Open Source OSGi,
Reagle. The platform for privacy preferences 1.0 http://www.knopflerfish.org/
(P3P 1.0) specification. W3C Recommendation, [16]. S. Alcalde Bagüés, A. Zeidler, C. Fdez-
Apr. 2002. Valdivielso, I. R.Matias. A User-Centric Privacy
[2]. M. Casassa Mont and R. Thyne. A Systemic Framework for Pervasive Environments. In
Approach to Automate Privacy Policy proceedings of the OTM Workshops (2) 2006:
Enforcement in Enterprises. In Proceedings of 1347-1356, LNCS.
the PEP’ 06, LNCS 4258, pag. 118-134, [17]. S. Alcalde Bagüés, A. Zeidler, C. Fdez-
Springer Berlin, 2006. Valdivielso, I. R. Matias. Disappearing For A
[3]. G. Karjoth, M. Schunter and M. Waidner. The While- Using White Lies in Pervasive
platform for enterprise privacy practices- privacy Computing. In Proceedings of the 2007 ACM
enabled management of customer data. In workshop on Privacy in Electronic Society 2007,
Proceedings of PEP’02. LNCS, 2002. Alexandria, Virginia, USA.
[4]. P. Ashley, S. Hada, G. Karjoth, C. Powers and [18]. M, Casassa Mont, Dealing with Privacy
M. Schunter. Enterprise Privacy Authorization Obligations: Important Aspects and Technical
Language (EPAL 1.2). W3C Submission, Approaches, TrustBus 2004.

UbiCC Journal - Volume 5 www.ubicc.org 1768


Special Issue of Ubiquitous Computing Security Systems

[19]. Daniel D. Walker, Eric G. Mercer, and Kent


E. Seamons. Or Best Offer: A Privacy Policy
Negotiation Protocol. In Proceedings of the
IEEE Workshop on Policies for Distributed
Systems and Networks, p. 173 – 180, 2008.
[20]. M. Hiltya, D. A. Basin, and A. Pretschner.
On Obligations. In Proceedings of the 10th
European Symposium on Research in Computer
Security (ESORICS 2005), 2005.
[21]. ITEA2 Project AIMES: Project Homepage,
http://www.aimes-project.eu/

UbiCC Journal - Volume 5 www.ubicc.org 1769