IEEE Technology and Society Magazine - Winter 2014 - 78

and very trustworthy to provide
ambient temperature with a precision of ±1 degrees Celsius. The
weather station may be considered
untrustworthy for different users
with respect to different reasons, for
example, because it sends data to a
cloud storage service without allowing the user to choose which data can
be sent, or because data protection
violations have been reported for this
specific type of device. Using this
GUI the citizen can assess the trust
degrees of a particular entity represented by its identity using a trust
measurement mapped onto a Subjective Logic Opinion, which specifies
a value for Belief (b), Disbelief (d),
and Uncertainty (u) where b+d+u=1.
In our mapping, opinions with more
belief than disbelief are trustworthy, being untrustworthy otherwise.
When the uncertainty is lower than
the belief/disbelief this represents a
very trustworthy/untrustworthy opinion. Different mappings with more

Fig.2. SecKit known identities GUI.
78

levels of discrete values have been
proposed in the literature [18].
The specification of data protection and trust management policy
rules is done in SecKit using rule templates, which can be used to express
usage control policies consisting of
authorizations and obligations with
respect to the citizens' data. These
rules follow an Event-ConditionAction (ECA) structure: whenever
the event (E) is observed, and the
condition (C) evaluates to true, the
action (A) is performed. Events
represent a target activity pattern of
enforcement such as the access to the
citizens' data and conditions represent complex logic expressions. The
condition part of a rule template may
contain additional events, context
situation patterns, propositional, temporal, and cardinality operators.
The action part of a rule may
specify preventive or reactive behavior. The preventive part may allow,
deny, modify, or delay the execution

of an activity when the condition
is satisfied. The reactive part may
execute additional reactive activities,
for example, to request user consent,
to reset, increase, or decrease trust
measurements. Preventive and reactive enforcement behaviors allow the
modification of the system behavior
in order to comply with privacy and
trust requirements.
Fig. 3 shows two policy rule
template examples. The first policy
rule prevents access to the user data
when the entity trying to access the
data is considered untrustworthy
with respect to the enforcement of
privacy preferences. The second
policy rule will decrease the trust
belief on an entity when a data
protection violation is reported. In
order to be enforceable, these rule
templates should be parameterized with variables referencing the
citizen's identity and the entity that
tries to access the data or that is referenced in the violation report. The
rule templates can also be instantiated considering that a citizen/user
may hold more than one identity
that can be used in different contexts, for example, a work identity,
a bank identity, a social network
identity, or a possibly anonymous
identity. We omit here variables and
complex conditions to focus on the
general concept. Details of the policy language and runtime monitoring algorithm are already presented
in a previous publication [16].
In our approach, trust and data
protection policies are motivated by
a risk model that clarifies the concrete known harm to a citizen when
using IoT systems. The risk model
should be clear and well understood
by the users, and in practice can
guide from a human subject point
of view the selection of different
policy rule templates to be adopted.
The citizens' opinions with respect
to the acceptable level of risk they
are willing to take may change from
one context to another, from time
to time, from learning experiences,
from cultural perspectives, etc.
Our risk modelling approach is an

IEEE TECHNOLOGY AND SOCIETY MAGAZINE

WINTER 2014

Table of Contents for the Digital Edition of IEEE Technology and Society Magazine - Winter 2014