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

Enterprises today collect already large amounts
of personal data from their customers. In the
upcoming era of pervasive computing tracking the
flow and interchange of data most probably will get
out of individuals' control entirely, due to the huge
increase in scale, manner, and motivation of
collection, as well as the addition of new data types
such as context data. To ease privacy concerns,
enterprises more and more publish privacy
statements that outline the enterprise privacy criteria,
i.e. how data is being collected, used and shared.
These privacy statements can be found written in
natural language or described using P3P [1]. In
general, they merely constitute privacy promises and
need to be backed up by technological means. In the
work of Casassa et al. [2] the use of an Obligation
Management System (OMS), as a solution, is
proposed. There, Obligations are policies that dictate
expectations and duties for enterprises on how to
handle personal data and how to deal with its life-
cycle management. So far, most efforts related to
privacy protection are centered on developing
privacy control for enterprises, like OMS [2], E-P3P
[3], EPAL [4], XACML [5].
In our work, we address the idea of extending
privacy control in a substantial manner towards a
holistic privacy management, with the collaboration
enforcement systems. It is not sufficient to rely only
on enterprise's willingness to support individual's
privacy requirements, as it is typically deemed
sufficient today. Protecting individuals' privacy in
pervasive computing requires an additional level of
privacy protection. Together with the enforcement of
enterprise's privacy statements, government policies
and privacy laws, it is necessary to deploy
mechanisms specifically for defining,
communicating and enforcing people's privacy
preferences. Privacy is a very subjective concept,
what is acceptable to one person, may be
unacceptable to another. Thus, our approach is to
allow individuals, as users of pervasive services, and
enterprises to collaborate on the protection of
personal and sensitive data.
We particularly address in this paper how this
collaboration between personal privacy and
enterprise privacy solutions can be established. We
propose the use of agreements for creating automatic
bindings between parts and to ensure that data
protection requirements are adhered to. The main
problem, obviously, is that users still have to trust to
some degree in enterprises' “promises”. Thus, we
present the idea of employing observable bindings
between personal and enterprise frameworks. This is
realized by introducing an agreement negotiation
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
privacy enforcement model designed to allow the
integration of enterprise and personal privacy control
solutions. We detail an agreement negotiation
protocol, on a set of obligations, designed to reach
the right level of privacy and show how agreements
can be tracked by using notifications. Finally, we
present the first prototype of the “Obligations”
application, developed to allow non-expert users to
manage obligations by themselves.
2 PRIVACY PROTECTION IN PERVASIVE
COMPUTING
Laws and enterprise privacy alone are not
sufficient to prevent an unwanted intrusion into the
private sphere of an individual. Users of pervasive
computing systems need mechanisms to control and
manage their own privacy concerns. For instance, by
delimiting who has access to what data and under
which circumstances, which may be achieved by the
specification of privacy policies.
However, purely technological solutions, such as
policy systems for access control, by themselves, can
achieve privacy goals only in limited situations, i.e.,
they are necessary but not sufficient. Privacy control
in pervasive computing requires the integration of
several complementary mechanisms into a new
design space, to address privacy concerns raised by a
continuous collection and access to personal
contextual information.
The privacy design space defined by Jiang et al.
[6] and shown in Figure 1 is taken as the reference
design space within the context of our work. We
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,
to detect unwanted misuses of disclosed data and act
accordingly.
Protection during collection refers to the event at
which personal data is initially collected. Important
UbiCC Journal - Volume 5 www.ubicc.org
decisions should be made at this phase including
who can collect which data, under which
circumstances, what format, and how trusted is the
data collector. Access refers to the point at which
data is accessed, for a particular purpose, by the
ultimate recipient. Important decisions concerned
this phase are how accurate and how confidential the
data should be, who should be allowed to access it,
for what purpose, how accesses should be logged or
how data is suppose to be stored. Secondary use
refers to the use of data after initial access has been
made. Secondary use may also include passing data
from one party, who might have been authorized, to
another party, who might not. Important decisions
made at this phase should include who else should be
able to access the data, secondary use purposes, and
whether it is allowed to share the data even further
with others or how long the data can be stored.
The focus of this paper is on how to enable
mechanisms for secondary use and how those
measures can be integrated with mechanisms used
during collection and access. For secondary use, we
consider the specification and negotiation of
obligations as a preventative mechanism, and their
enforcement, by the enterprise recipient, an
avoidance measure. By ensuring that the service,
recipient of the data, is able to enforce a binding
agreement on a set of obligations, it can be avoided
that uncontrolled misuses of data after initial
collection takes place. With respect to detection
measures, common mechanisms are data logs and
legal audits. In our work we introduce additionally
the use of notifications to actively monitor the
ongoing use of disclosed data.
Figure 1: Privacy Design Space for Pervasive
Computing
Today, there are mechanisms that can be applied
independently for each of the areas covered by the
privacy design space, although measures for
1759
Special Issue of Ubiquitous Computing Security Systems
avoidance and detection need to be further developed,
and, even more important, an integration model
needs to be defined. Thus, we defined the privacy
enforcement model presented in Section 3.
2.1 Related Work
The use of obligations in computer systems by
itself is not a new topic. It has been largely used to
specify actions that must be performed by some
entity. In daily situations where people interact,
individuals are held responsible for their own actions,
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
policy management agent will notify all operators of
the error and log the event.
Obligations for secondary use control, also
called usage control, are requirements that must be
agreed on by obligation subjects, before authorizing
the access to the data. Obligations can be seen as a
binding statement to take some course of action in
the future by the obligation subject [9]. They are
crucial to restrict the flow and use of personal data in
the highly dynamic distributed environments
assumed in pervasive computing. Nevertheless, in
many policy systems, obligations have been defined
tightly coupled to the enforcement of access control
policies and in general they cannot be used for
secondary use control. This is the approach followed
by EPAL [4] and XACML [5]. Within these access-
control languages, obligations are a set of operations
associated with a policy that must be executed by the
Policy Enforcement Point (PEP) together with an
authorization decision before allowing the access to
the data. In the work of Park and Sandhu [10]
obligations are requirements that have to be fulfilled
by a subject at the time of the request for allowing
access to a resource. E.g., a user must give his name
and email address to download a company’s white
paper.
Therefore, the mentioned approaches do not
cover the role of obligations in the context of
secondary use control. In that context, obligations
should provide binding agreements between two
parts, the requesting third-party and the target (owner
of the data), regarding the use of data after its initial
collection. The work presented in [11] describes an
approach to archive digital signed commitments on
obligations between distributed parties. They
introduced the Obligation of Trust (OoT) protocol,
biCC Journal - Volume 5 www.ubicc.org
which executes two consecutive steps: Notification
of Obligation and Signed Acceptance of Obligation.
The OoT is built upon the XACML standard
following its Web Services Profile (WS-XACML).
The disadvantages of this approach are that it does
not cater for the enforcement and monitoring of such
obligations, on the one hand, and that it seems to be
rather complicated for a common user to manage
obligations following this protocol, on the other hand.
3 OUR PRIVACY ENFORCEMENT MODEL
Figure 2: Main characteristics of our Privacy
Enforcement Model
For addressing the integration of personal
privacy enforcement in pervasive computing, we
have developed a three-tier privacy enforcement
model, shown in Figure 2, which serves as the base
for the specification of the involved entities and for
the formalization of their collaboration. One of the
model’s main features is that it caters for the
integration of measures to address prevention,
avoidance and detection during the lifecycle of
personal data, i.e. collection, access and secondary
use. Thus, it covers the privacy design space
described in Section 2. The model we propose
consists of the following three pillars:
1. Data Collector: This pillar provides
abstractions for representing any data collector,
as typical source of context information found in
the environment. For dealing with them, we
classify them into two groups: i) The group of
data collectors under the direct control of a user,
such as, for example, a GPS tracking device. In
general, they are sources of personal context that
do not represent a privacy risk, per se. ii) Those
kind of data collectors that are run by enterprises,
e.g. mobile network operators. Langheinrich
addressed in his work the privacy implications of
those kind of data collectors and provided a
Privacy Awareness System (PawS) to help
individuals deal with them. In our model we
assume that a similar framework to PawS [12] is
in place for dealing with newly encountered data
collectors.
2. Trusted Privacy Manager: This central pillar
provides abstraction for a personal and trusted
privacy enforcement system. The role of the
1762
Special Issue of Ubiquitous Computing Security Systems
Trusted Privacy Manager is to orchestrate any
disclosure of personal data and to manage the
collaboration between entities with the goal to
protect an individual's privacy. Thus, it must
provide functionality for the evaluation of
service-side privacy policies (data collectors and
data consumers), the enforcement of its users'
privacy policies, for guiding the negotiation of
agreements on secondary use, and facilitating the
monitoring of disclosed data.
3. Data Consumer: This last pillar holds
abstractions for representing data consumers, in
particular consumers of context information that
depend on external data collectors to implement
their respective services, e.g a “Restaurant
Finder” or a “Buddy Finder” service. Obviously,
these are the main types of emerging services in
pervasive computing. However, context
providers and service providers are typically
decoupled and operate independently from each
other and, thus, must be orchestrated.
The privacy enforcement model we present here
is built around direct, one-to-one binding agreements
between the Trusted Privacy Manager and the other
two pillars, as shown in Figure 3. The Trusted
Privacy Manager acts as mediator between data
collectors and data consumers. It reduces and
simplifies potentially complex relationships between
them to contractual two-part agreements, on
previously negotiated obligations, avoiding direct
exchange of data between data collectors and data
consumers. The idea behind the use of agreements is
twofold: to specify actions allowed on disclosed data
and to avoid any uncontrolled disclosure that may
lead to unwanted exchanges of sensitive data.
The collaboration between pillars is built around
three functional blocks, Bilateral Privacy Access
Control, Obligations Negotiation and Management,
and Obligations Tracking as it is shown in Figure 2.
They are complementary and depend on each other
to guarantee a holistic privacy protection.
The first level of collaboration (Bilateral Privacy
Access Control) demands from each part to include
privacy-aware access control mechanisms. Note that
only in the case of the Trusted Privacy Manager
access control should be context-aware, since is the
only tier that should have access to any user context
data. Bilateral access control means that both the
service side privacy policy and a user's privacy
policy should be evaluated before revealing any data.
How this is achieved may differ in each case.
The second level, the Obligations Negotiation
and Management, requires from all three pillars to
adopt a common model for the specification of
obligations and trust that data collectors and data
consumers will handle personal data according to
such obligations. The third level Obligations
Tracking was introduced as an initial measure for
UbiCC Journal - Volume 5 1
www.ubicc.org
trust management and to allow lifecycle awareness
of the data. Our approach to establish a trusted
relationship between an enterprise service and the
Trusted Privacy Manager is based on the possibility
to subscribe to notifications about the use of
disclosed data.
In the collaboration of the Data Collector pillar
with other parts of the system, as it was mentioned
already, we rely on the idea elaborated by
Langheinrich. There, the privacy awareness system
for ubiquitous computing [12] allows data collectors
to describe their collection policies in a machine-
readable format and communicate these to their data
subjects. If the user agrees, the services can collect
information and users can utilize the services. Thus,
we can assume that a user is notified before a new
data collection is started, (e.g. video surveillance or
indoor security tracking), the user then can check the
service's privacy policy and either agrees to or denies
the collection. Due to the implicit nature of this type
of data collectors, a user in general can only accept
or reject the collection of the data in a “take or
(physically) leave“ fashion.
In such a situation, in our model, additionally,
we propose the negotiation of an agreement on a set
of obligations before any data collection is
commenced, to avoid unwanted misuses of the data
and furthermore, to control accesses to data being
collected. Thereby, a bilateral privacy access
contract is negotiated.
Symmetrically, for the Data Consumer we
assume that any consumer service first has to register
with an instance of the Trusted Privacy Manager and
upon registration discloses its privacy policy. The
service privacy policy (e.g. P3P) shall have at least
the following elements: data consumer description,
data elements the service requests, and purpose of
the request. If the registration is successful, the
Trusted Privacy Manager agrees on providing
context broker functionality for the subscribed
service according to the now established bilateral
privacy access contract. From this moment on and
for each service request, a Trusted Privacy Manager
entity evaluates its user’s privacy policies to decide
whether or not permission is granted. The data is
transmitted only when all the restrictions defined by
a user are fulfilled. This avoids unwanted “take or
leave situations“ with data consumers.
However, bilateral privacy access control only
addresses situations where information is disclosed
for the present use. This means that it only provides
preventative and avoidance measures during
collection and access. Thus, it does not cover cases
where information may be stored for future use or
even be sold in a potentially different situation. Here
is where the second and third functional blocks that
define the collaboration between the pillars come
into play, introducing more mechanisms for
detection and secondary use control. As a result, this
1761
Special Issue of Ubiquitous Computing Security Systems
avoidance and detection need to be further developed,
and, even more important, an integration model
needs to be defined. Thus, we defined the privacy
enforcement model presented in Section 3.
2.1 Related Work
The use of obligations in computer systems by
itself is not a new topic. It has been largely used to
specify actions that must be performed by some
entity. In daily situations where people interact,
individuals are held responsible for their own actions,
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
policy management agent will notify all operators of
the error and log the event.
Obligations for secondary use control, also
called usage control, are requirements that must be
agreed on by obligation subjects, before authorizing
the access to the data. Obligations can be seen as a
binding statement to take some course of action in
the future by the obligation subject [9]. They are
crucial to restrict the flow and use of personal data in
the highly dynamic distributed environments
assumed in pervasive computing. Nevertheless, in
many policy systems, obligations have been defined
tightly coupled to the enforcement of access control
policies and in general they cannot be used for
secondary use control. This is the approach followed
by EPAL [4] and XACML [5]. Within these access-
control languages, obligations are a set of operations
associated with a policy that must be executed by the
Policy Enforcement Point (PEP) together with an
authorization decision before allowing the access to
the data. In the work of Park and Sandhu [10]
obligations are requirements that have to be fulfilled
by a subject at the time of the request for allowing
access to a resource. E.g., a user must give his name
and email address to download a company’s white
paper.
Therefore, the mentioned approaches do not
cover the role of obligations in the context of
secondary use control. In that context, obligations
should provide binding agreements between two
parts, the requesting third-party and the target (owner
of the data), regarding the use of data after its initial
collection. The work presented in [11] describes an
approach to archive digital signed commitments on
obligations between distributed parties. They
introduced the Obligation of Trust (OoT) protocol,
biCC Journal - Volume 5 www.ubicc.org
which executes two consecutive steps: Notification
of Obligation and Signed Acceptance of Obligation.
The OoT is built upon the XACML standard
following its Web Services Profile (WS-XACML).
The disadvantages of this approach are that it does
not cater for the enforcement and monitoring of such
obligations, on the one hand, and that it seems to be
rather complicated for a common user to manage
obligations following this protocol, on the other hand.
3 OUR PRIVACY ENFORCEMENT MODEL
Figure 2: Main characteristics of our Privacy
Enforcement Model
For addressing the integration of personal
privacy enforcement in pervasive computing, we
have developed a three-tier privacy enforcement
model, shown in Figure 2, which serves as the base
for the specification of the involved entities and for
the formalization of their collaboration. One of the
model’s main features is that it caters for the
integration of measures to address prevention,
avoidance and detection during the lifecycle of
personal data, i.e. collection, access and secondary
use. Thus, it covers the privacy design space
described in Section 2. The model we propose
consists of the following three pillars:
1. Data Collector: This pillar provides
abstractions for representing any data collector,
as typical source of context information found in
the environment. For dealing with them, we
classify them into two groups: i) The group of
data collectors under the direct control of a user,
such as, for example, a GPS tracking device. In
general, they are sources of personal context that
do not represent a privacy risk, per se. ii) Those
kind of data collectors that are run by enterprises,
e.g. mobile network operators. Langheinrich
addressed in his work the privacy implications of
those kind of data collectors and provided a
Privacy Awareness System (PawS) to help
individuals deal with them. In our model we
assume that a similar framework to PawS [12] is
in place for dealing with newly encountered data
collectors.
2. Trusted Privacy Manager: This central pillar
provides abstraction for a personal and trusted
privacy enforcement system. The role of the
1762
Special Issue of Ubiquitous Computing Security Systems
users. The communication between a CAMS and the
UCPF services is realized by the Sentry’s PEP
component implementing an Interceptor pattern on
messages passing through the system. The Context
Handler provides access control to the system
repositories and acts as a mediator between the
Sentry and external context collectors. It also
manages the semantic models used to represent
policies and context data in the system.
The interaction of end-users with the UCPF is
made possible through the Sentry Manager Interface.
It is implemented as an API used to generate,
upgrade or delete privacy policies, receive
information about the current applicable policies, or
getting feedback on potential privacy risks and
obligations state.
The Noise Module is a modular functional
component that injects additional information into
the policy matching mechanism, typically for
altering the data disclosed. Currently implemented
are different levels of obfuscation, called
Transformations [16], within the Local
Transformation Point (LTP) and a disclosure
mechanism for a Virtual Context within the White
Lying Generator (WLG) [17].
The Sentry Registry is the only component that
is not co-located with the rest of the elements in the
gateway. This component is shared among Sentries
and thus must be hosted in the Internet. It tracks the
availability of people’s context and provides the
pointer to the appropriate Sentry service instance.
Services, organizations and Sentries need to be
registered with the UCPF before starting any context
request, which is done in the Sentry Registry. The
Sentry Registry has an important role in making
interactions possible between CAMS and Sentries,
and also between different Sentry instances,
providing Flexibility to deal with distributed and
changing entities. Finally, the Obligation Manager,
see next section, negotiates agreements and tracks
the obligations agreed on by third parties.
4 OBLIGATIONS IN THE UCPF
In the UCPF obligations are used to enable the
integration of measures for prevention, avoidance
and detection on secondary use of personal data. The
privacy enforcement model presented in Section 3,
distributes the enforcement of users' privacy
preferences between the UCPF and the enterprise
side. In Figure 3 we highlight those measures
enabled by the negotiation of agreements and their
posterior enforcement by the enterprise system.
Without the use of obligations, the UCPF could only
enforce preventative measures during access and
collection. Obligations are used to create automatic
bindings with CAMS and ensure that data protection
requirements are adhered to. Obligations in the
UCPF have the following purposes:
UbiCC Journal - Volume 5 www.ubicc.org
 They specify actions that should be performed
by a service, acting as the recipient of a user
data.
 Obligations are used to automatically exchange
user’s preferences on secondary use with
enterprises. For this reason, they are embedded
into agreements to be negotiated before the data
is given away.
 They enable the exchange of notifications
between the UCPF and third-party services and
with that post-disclosure life-cycle control.
The Obligation Manager (OM) is the UCPF's
component in charge of managing, negotiating and
tracking obligations. The OM consists of the
Obligation Handler and the Obligation Monitor
components as shown in Figure 4. The first is in
charge of creating agreements with the obligations
selected by a user and its negotiation. The Obligation
Monitor monitors the state of obligations based on
notifications and data logs. It also compiles
notifications to be sent by the Sentry to the service,
which can just confirm a received notification,
request a data log, or inform of an occurred violation
including sanctions to be carried out, e.g. unregister
the service.
The following two examples illustrate the type
of obligations handled by the OM in the UCPF.
Example 1: Bob will always allow to be tracked
by indoor security systems, if his data is never
disclosed, and he can access the data generated.
Example 2: Bob requires from all services using
his activity and location, that they do not store his
data or if yes to delete them within one week or a
maximum of one month. Moreover, Bob wants to get
a notification if a service discloses his location to the
same recipient more than 5 times a day.
4.1 Model of Privacy Obligations
We created a set of predefined obligations and
classified them into system obligations and
negotiable obligations. Obligations play a key role in
the establishment of the privacy enforcement model
presented in this paper, thus not all obligations are
negotiable. For instance, the obligation “Data MUST
NOT be disclosed to any third-party”, is a mandatory
obligation used to avoid uncontrolled retransmissions
of data. System obligations are designed to be agreed
on during the registration process of a new service
without negotiation. The goals of system obligations
are to control disclosures to third-parties, monitor
changes on a service privacy policy and enable the
access to collected data and data logs. They are
mandatory obligations which are by default
established independently of a user's preferences and
beforehand of any commercial transaction with a
service.
Negotiable obligations, on the other hand, are
1763
Special Issue of Ubiquitous Computing Security Systems
selected by a user and negotiated with the service,
which is the recipient of the data. Users can specify
obligations to be agreed on during the evaluation of a
service request, which will be subject of the
agreement negotiation protocol. They represent the
privacy constraints that a user may impose on an
enterprise service when data is disclosed. In our
definition, negotiable obligations have two aspects:
first, it is a second-class entity subject to the
enforcement of a policy in the UCPF and compiled
during the evaluation of a service request. And
second, when a policy evaluation contains
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
Casassa et al. [18] to facilitate collaboration with the
enterprise privacy enforcement system. Obligations
in the UCPF are XML documents with Event, Action,
Notification and Metadata elements. Figure 5 shows
the template used to create obligations in the UCPF,
together with a XML instance of the obligation “13”.
Some tags defined by HP’s OMS were left out in our
definition (e.g. Target), which only can be used
together with the OMS, and a new tag, the
Notification element, was added.
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 6 represent system obligations, they can be
used in the example 1, to control that unwanted
disclosures to third-parties do not occur. On the other
hand, the XML instances of Figure 7 belong to
negotiable obligations; they can be used in the
example 2 to limit the retention of the data and the
number of disclosures to a same subject.
An obligation is activated at the moment that its
Event occurs. We have considered in our
implementation eight different events, namely:
Disclosure request, Data leaking, Policy changed,
Data collection, Access request, Storage, Timeout,
UbiCC Journal - Volume 5 www.ubicc.org
and Datalog request. An Event is described with two
properties, the EventType that identifies the event
that will trigger the execution of the obligation, and
the property HasExtParameter, which ties its
applicability to a specific value. For instance, in
Figure 6 for the obligation number “11”, the event
Disclosure request is constrained by the identity of
the recipient (Recipient parameter) and the number
of disclosures allowed per day (Times parameter).
The values of these parameters are not included in
the definition of obligations, but in the agreement
document, as we will describe in the next section.
Figure 6: Example of System Obligations
Once an obligation is activated, and its event
parameters are true, its execution has two effects,
one is that an action must be performed, specified
with the property ActionType, and the second is that
a notification must be sent to a Sentry instance. The
type of notification that needs to be compiled is
identified by the NotificationType property. The
predefined obligations are distributed as an XML file.
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 7: Example of Negotiable Obligations
4.2 Agreement Negotiation Protocol
The schema adopted in the definition of
agreements is shown on the left hand side in Figure 8,
an agreement is an XML document with Agreement,
Resource, URLNotification, Timestamp, Negotiation,
ListObligations, and IfViolated elements.
Agreements are used to bind a list of obligations
between two parts, a UCPF and a third-party service,
and allow for their negotiation. The use of
agreements allows the personalization of general
obligations and with that, the use of a limited number
1764
Special Issue of Ubiquitous Computing Security Systems
of predefined obligations, which are “reused” in each
agreement, instead of creating new instances.
The Agreement tag identifies the involved parts
and the priority of such agreement. The priority
property can have one out of the following values:
Mandatory, Middle, Optional and Request. It applies
only if after finishing all the negotiation rounds the
agreement state is denied. The Resource element
identifies the data owner with the properties Owner
and Scope, the scope describe the type of resource
(e.g. location, activity, calendar). The Negotiation
tag specifies the state and the current round of a
negotiation, the OM always sets an agreement in
state “Negotiating” and controls the negotiation
round. A service can change the state property from
“Negotiating” to “Denied” or “Accepted”, but not
the negotiation round.
Figure 8: Agreement and Notification Template
In an agreement, obligations are associated with
the element ListObligations. This element does not
contain the specification of obligations but a
reference to one or more of the obligations included
in the list of common obligations. Each obligation is
represented with an ID and a state value. The State
property should be changed by the service from its
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
privacy policy of the requesting service changes an
agreement needs to be re-negotiated.
UbiCC Journal - Volume 5 www.ubicc.org
4.2.1 Negotiation Protocol.
The agreement negotiation protocol, cf. Figure 9
starts after the policy evaluation of a service request
within a Sentry instance concludes. If the policy
effect compiled contains obligations, the PEP queries
the OM for an agreement over the pending
obligations, step 1 in Figure 9. Then, if there is not a
previous agreement, the OM returns the agreement to
be negotiated, step 2. The Sentry launches the
negotiation, steps 3 to 14, which is repeated at most
for three rounds.
This protocol enables per-service and per-user
resource agreements negotiations that are guaranteed
to terminate after at most three negotiation rounds.
This is inspired by the work of Walker et al. [19] in
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
their acceptable equivalents. The enterprise service
may accept the second proposal, or start the third and
last round: Negotiating Minimum stage, in which a
new set of obligations classified as minimum replaces
those rejected. The goals of this negotiation strategy
are: i) to allow more than “take or leave” situations,
ii) to enable an automatic setup of user's privacy
preferences on secondary use, and iii) to execute the
obligation binding process transparent to the user.
Figure 9: Agreement Negotiation Protocol Sketch
In a situation where an enterprise does not accept
1765
Special Issue of Ubiquitous Computing Security Systems
the third and last proposal, no agreement is reached
and the priority of the rejected agreement is taken
into account by the OM. Each agreement is labeled
with a priority value. Priority Mandatory means that
the service (enterprise) MUST accept the agreement
otherwise permission will be denied (step 14).
Priority Middle means that the service SHOULD
accept the agreement otherwise data quality will
decrease in accuracy. A priority equals to Optional
means that the service MIGHT accept the agreement
and entails the disclosure of the requested data
anyway but the user will be notified that no
agreement was reached; a user may modify his
privacy settings based on the obligations rejected
then. If the priority is set to Request the user will be
asked whether or not he wants to disclose the data
anyway.
4.3 Notification Mechanism
Our approach to establish a trusted relationship
between an enterprise service and the UCPF also is
based on the possibility to subscribe to notifications
about the use of disclosed data. Obligations are used
to create automatic bindings between both parts, and
ensure that data protection requirements are adhered
to. However, in cases where such bindings cannot be
monitored, checking the compliance with the
obligation is almost impossible. The concept of Non-
observable Obligations is described in the work of
Hilty et al. [20] they suggest that a possible solution
is the use of nontechnical means, such as audits or
legal means. We propose, additionally, the idea of
employing observable bindings between our UCPF
and enterprise frameworks. This is realized by
introducing a notification exchange mechanism. This
mechanism is activated by the execution of an
obligation. Due to the fact that the enforcement of an
obligation in our model, follows the sequence Event-
Action-Notification, instead of a mere Event-Action
used by previous approaches.
Figure 10: Type of Notifications
We describe here two complementary
UbiCC Journal - Volume 5 www.ubicc.org
notification types, notifications used to notify a
UCPF and notifications developed to notify back a
service. Figure 10 describes and summarizes the
different notifications implemented. There are 13
notifications types, eight are used for notifying the
UCPF (as subscriber), namely: Leaking, Policy,
Repository, Datalog, Request, Granted Disclosure,
Access and Deletion, and five for notifying the
service in return: Reminder, Getdatalog,
Confirmation, Response and OnViolation.
Notifications as agreements are XML documents; the
schema used to create new instances of a notification
is shown on the right hand side in Figure 8. The main
element of a notification is the Notification tag; it
identifies the type of notification and holds relevant
information in the form of parameters. Depending on
the notification type used, different parameters need
to be provided. E.g. a Deletion notification should
include the time frame in which some data was
removed from the repository. On the other hand, a
Granted Disclosure notification should include also
the recipient of the data and the number of
disclosures that occurred in the period of time
considered. The parameters required by each
notification are shown in Figure 10. The use of
notifications allows for monitoring the status of the
active obligations and to communicate actions
(penalties) in case of a violation state. We introduced
the tag Violation for this case. It describes the
sanctions carried out once the OM observes such a
violation.
In summary, notifications are used for: i)
enabling monitoring of active obligations, ii)
auditing the enterprise service, iii) getting access to
personal data in the service's repository, iv) knowing
when the service's obligation policy changes in order
to re-negotiate agreements, and v) controlling when
an active obligation is violated.
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
overload for the process of adding new permissions
into the system and obligations, for us, are entities
independent from access control. We believe that the
1766
Special Issue of Ubiquitous Computing Security Systems
natural way of thinking about obligations, from the
perspective of users, is as a “set of privacy
preferences to be enforced by the service provider on
disclosed resources”. Thus, it follows that
obligations should be specified per service and
resource and not to depend on a rule specification.
Therefore, we implemented a separate application
where users can set up obligations per tuple (service,
resource).
For the development of the Obligation Manager
and its application we followed the rule of providing
some default setting, in a way that users do no need
to take care of critical situations by themselves.
Mandatory obligations, needed for keeping a proper
level of privacy, were labeled as System obligations
and excluded from the negotiation process. System
obligations should be agreed-on by service providers
during the registration process. The process is
transparent to the user and only services that fulfill
the registration requirements are available.
Negotiable obligations were added to offer users a
way to negotiate their privacy preference on
secondary use. Both obligation types should be
enforced by the enterprise privacy system. Hence,
obligations must be defined in advance and known
by both parties. A user then is limited to choose
among known obligations, what means that he
cannot specify new types of obligations. In our
implementation, due to the lack of a standard
definition of obligations, we developed our own set
of negotiable obligations, listed in Figure 11.
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)
“Limiting retention time”, 2) “Controlling data
disclosures”, 3) “Controlling data disclosures same
subject”, 4) “Controlling data accesses”, 5)
“Limiting number of disclosures per day to the same
subject”. If a user selects one or more of these sets,
for a registered service, they need to be negotiated
UbiCC Journal - Volume 5 www.ubicc.org
before disclosing any new data to that service.
4.5 Obligations Application
Figure 12 shows a screenshot of our application
prototype for managing sets of obligations. A user
can access this application directly from his “Privacy
Desktop” home window by clicking into the panel
“Obligations”. The access window that is opened
now, shown on the left hand side in Figure 12,
guides users in the selection of a service provider and
a resource among location, activity and calendar,
before allowing the access to the main screen of the
obligations application. In the main screen, shown on
the right hand side the predefined sets of obligations
are listed. If one or more obligations sets are selected
they will be included into an agreement that needs to
be negotiated before disclosing the resource to the
service.
With this application a user can change the
parameters of the obligations belonging to a set and
set the priority of each selected set. A set always
consists of the three mandatory obligations, labeled
as “Optimum”, “Acceptable”, and “Minimum”. They
can be predefined and be re-used, obviously, and do
not have to be defined separately each time. The
application offers also the possibility of checking
existing obligations and editing or canceling them.
The data displayed by this application is
gathered from a database instance, implemented
using MySQL, where predefined obligations,
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 12: UCPF GUI’s Obligation Application
5 CONCLUSIONS AND OUTLOOK
In this paper, we presented how privacy control
can be extended in a substantial manner toward
holistic privacy management, with the collaboration
1767
Special Issue of Ubiquitous Computing Security Systems
of personal privacy and enterprise privacy
enforcement. We introduced the notion of binding
agreements for each privacy-related resource. An
agreement is an XML document holding a set of
obligations selected by a user. Those selected
obligations need to be accepted by a third-party
service before a granted permission is given to
access the resource. Obligations describe the rights
and requirements for processing, storing or deleting
data that the recipient of a user's resource must
enforce. In order to avoid situations where
obligations may not be accepted by a service and
lead to simple denial of service, we developed a
well-defined negotiation protocol for trying to find
an agreement based on different classes of
obligations such as optimum, acceptable and
minimum type.
An obligation in the UCPF is defined as an
event-action-notification entity, instead of a mere
event-action. It follows that the enforcement of an
obligation by the enterprise privacy system, activates
the exchange of notifications. We concluded that just
using agreements on a set of obligations is not far-
reaching enough and introduced notifications to
enable obligation tracking and with that the
monitoring of the fulfillment of agreements and the
usage of disclosed data after releasing it. In this
paper, we showed that this is an easy but effective
way to enable trust between the client and the service.
We also presented the first prototype of the
“Obligation” application, a user interface created to
be managed by non-expert users, and used to add
new obligations sets to be negotiated with a
registered service.
Our future work includes applying our
framework to privacy-sensitive applications in the
context of patient-monitoring and -supervision, as
being found in integrated hospital IT landscapes.
There we are about to start work in the context of the
ITEA2 project AIMES[21].
6 REFERENCES
[1]. L. Cranor, M. Langheinrich, M. Marchiori, J.
Reagle. The platform for privacy preferences 1.0
(P3P 1.0) specification. W3C Recommendation,
Apr. 2002.
[2]. M. Casassa Mont and R. Thyne. A Systemic
Approach to Automate Privacy Policy
Enforcement in Enterprises. In Proceedings of
the PEP’ 06, LNCS 4258, pag. 118-134,
Springer Berlin, 2006.
[3]. G. Karjoth, M. Schunter and M. Waidner. The
platform for enterprise privacy practices- privacy
enabled management of customer data. In
Proceedings of PEP’02. LNCS, 2002.
[4]. P. Ashley, S. Hada, G. Karjoth, C. Powers and
M. Schunter. Enterprise Privacy Authorization
Language (EPAL 1.2). W3C Submission,
UbiCC Journal - Volume 5 www.ubicc.org
November 2003
[5]. Tim Moses. OASIS standard. eXtensible Access
Control Markup Language TC v2.0, February
2005.
[6]. Jiang, X., Hong, J. I., and Landay, J. A.
Approximate Information Flows: Socially-based
Modeling of Privacy in Ubiquitous Computing.
In proceedings of the 4th International
Conference on Ubiquitous Computing, 2002.
[7]. R. P. van de Riet and J. F. M. Burg. Linguistic
tools for modelling alter egos in cyberspace:
Who is responsible? Journal of Universal
Computer Science, 2(9):623–636, 1996.
[8]. Nicodemos Damianou, Naranker Dulay, Emil
Lupu, and Morris Sloman. Ponder: A language
for specifying security and management policies
for distributed systems, 2000.
[9]. Lalana Kagal. A Policy-Based Approach to
Governing Autonomous Behavior in Distributed
nvironments. Phd Thesis, University of
Maryland Baltimore County, September 2004.
[10]. Jaehong Park and Ravi Sandhu. The
uconabc usage control model. ACM Trans. Inf.
Syst.Secur., 7(1):128–174, 2004.
[11]. Uche M. Mbanaso, G. S. Cooper, David W.
Chadwick, and Anne Anderson. Obligations or
privacy and confidentiality in distributed
transactions. In EUC Workshops, 69–81, 2007.
[12]. M. Langheinrich. A privacy awareness
system for ubiquitous computing environments.
In Proceedings of the 4th International
Conference on Ubiquitous Computing. LNCS
No. 2498, Springer-Verlag, September 2002.
[13]. S. Alcalde Bagüés, A. Zeidler, C. Fernandez
Valdivielso, I. R. Matias. Sentry@Home -
Leveraging the Smart Home for Privacy in
Pervasive Computing. International Journal of
Smart Home Vol. 1 No. 2, 2007.
[14]. S. Alcalde Bagüés, J. Mitic, E. Emberger.
The CONNECT Platform: An Architecture for
Context-Aware Privacy in Pervasive
Environments. IEEE CS,Workshop on Secure
and Multimodal Pervasive Environments 2007.
[15]. Knopflerfish Open Source OSGi,
http://www.knopflerfish.org/
[16]. S. Alcalde Bagüés, A. Zeidler, C. Fdez-
Valdivielso, I. R.Matias. A User-Centric Privacy
Framework for Pervasive Environments. In
proceedings of the OTM Workshops (2) 2006:
1347-1356, LNCS.
[17]. S. Alcalde Bagüés, A. Zeidler, C. Fdez-
Valdivielso, I. R. Matias. Disappearing For A
While- Using White Lies in Pervasive
Computing. In Proceedings of the 2007 ACM
workshop on Privacy in Electronic Society 2007,
Alexandria, Virginia, USA.
[18]. M, Casassa Mont, Dealing with Privacy
Obligations: Important Aspects and Technical
Approaches, TrustBus 2004.
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