
 
or  dynamic (Lupu and Sloman 1999, Dunlop et al. 
2003); static conflicts can be detected in advance (at 
“compile time”), whereas dynamic conflicts are 
dependant on “run time” state and thus cannot be 
detected in advance. 
Conflict detection involves the identification of 
actual or potential policy conflicts. Methods for 
automatic conflict detection focus on analysing all 
policies relating to particular subject/action/target 
tuples and identifying whether the there is a conflict 
between the modality of these policies. Policies are 
generally constructed to reflect the obligation, 
permission and prohibition modal operators of 
deontic logic, thus modality conflicts are exhibited 
by policy pairs that, for a given subject/action/target, 
indicate behaviour that is prohibited vs. allowed, 
obliged vs. prohibited or obliged vs. not obliged. 
Other kinds of conflict detection, in particular those 
relating to the semantics of the policies, are 
significantly more difficult to detect automatically. 
Once potential policy conflicts have been 
detected, a decision must be made as to whether to 
seek to resolve the conflict, with this decision being 
application-specific, but typically related to the 
probability of occurrence of the identified conflict. 
Two approaches to conflict resolution are possible: 
revoke, re-specify and re-deploy offending policies, 
or let the system assign precedence levels that 
dictate which of the conflicting policies are actually 
invoked. The latter approach is more practical, and 
researchers have investigated/adopted numerous 
schemes for assigning policy preference, for 
example see (Lupu and Sloman 1999, Dunlop et al. 
2003). For example, precedence can be assigned 
based on: specific policies overriding general 
policies; newer policies override older policies; 
policies specified by a higher authority overriding 
those specified by lower authorities; negative 
policies overriding positive policies and vice versa; 
or explicit assignment of policy weights to govern 
precedence. These schemes all have strengths and 
weaknesses, but it is agreed that none is suited for 
use in all application scenarios. 
In our case, policies can be authored by 
individual users, as well as by administrators of 
systems. Sets of users in a physical space are likely 
to have policies with the potential to conflict with 
each other, and/or with system policies. We envisage 
policy conflict detection and resolution being 
performed every time the set of users in a space 
changes (as users enter/leave), or as the activities 
they are performing change (for example, a project 
meeting commences in a meeting room). We view 
the former as a form of static conflict detection and 
the latter more as dynamic conflict detection. We see 
conflict resolution based on higher authorities 
overriding lower authorities as the most appropriate 
scheme in our scenario: system policies are given 
precedence over user policies, and between users 
precedence is based on users’ profile, including their 
current roles within the space. User roles are 
assigned in accordance with system policies and 
may change over time. For example, in a meeting 
context, a user may be assigned a speaker role when 
he/she is detected as standing on a podium, and 
system policies will dictate that speakers have 
control over the projector, lights and other resources. 
In this case that user’s policies relating to, for 
example, lighting settings, will have precedence 
over those of other users. 
3  M-ZONES ACCESS CONTROL 
(MAC) PROCESS 
The M-Zones access control solution we propose has 
been realised in the context of a “Ubiquitous 
Management Architecture” (UMA) (Barrett et al. 
2004), developed as part of the M-Zones research 
programme (M-Zones 2005); which approaches 
management of ubiquitous computing environments, 
specifically smart spaces, by introducing the concept 
of “Managed Zones” (M-Zones) corresponding to 
administrative domains encompassing one or more 
distinct smart spaces. The UMA adopts a policy-
based management approach to facilitate intra- and 
inter- smart space management, with policy decision 
points (PDPs) organised in two levels, following the 
hierarchical approach described in (Ghamri-
Doudane et al. 2004). The PDP at the upper 
(M-Zone) level is responsible for all high level 
policies relating to the administration of the smart 
spaces. At the lower (smart space) level PDPs and 
PEPs control the discovery and execution of 
services. Ongoing decision making relating to access 
rights occurs at the M-Zone level, with access rights 
being communicated to individual smart spaces in 
the form of access control lists, which are enforced 
by the local PDP and PEPs. 
There are two other UMA components involved 
in access control: the Context Information Manager 
(CIM) and Personal Information Managers (PIMs). 
The CIM is responsible for gathering, aggregating 
and semantically enhancing context information 
subscribed to by the M-Zone PDP and notifying the 
M-Zone PDP when context changes occur. Each 
user has associated with him/her a PIM, which stores 
their user profiles, preferences and policies, and also 
acts as their interface to the system. Operation of the 
CIM and PIMs is described in (Barrett et al. 2004). 
USER-CENTRIC ADAPTIVE ACCESS CONTROL AND RESOURCE CONFIGURATION FOR UBIQUITOUS
COMPUTING ENVIRONMENTS
351