Policy Management and PolicyGuided Interactions in Ubiquitous Computing Environments

1
Policy Management and Policy-Guided Interactions
in Ubiquitous Computing Environments

• V. Ramakrishna
• PhD Dissertation
• Computer Science Department, UCLA
• September 19th, 2008

2
Thesis Statement

• Automated negotiation for generation of service
  access agreements in ubiquitous computing
  environment can be achieved through a generic
  protocol guided by the participants policies.

3
Research Contributions

• General purpose negotiation protocol for exchange
  of information through speech acts
• Modeling negotiation as a distributed/decentralize
  d policy resolution procedure for agreement
  generation
• Implementation of negotiation within a policy
  management subsystem for ubiquitous devices and
  groups
• Dynamic context-sensitive access control through
  negotiation
• Building of a test case generator and large scale
  performance comparisons between centralized and
  decentralized policy resolutions

4
Outline

• Introduction and Motivation
• Solution Model and Procedures
• System Design and Implementation
• Analysis and Testing
• Related Work
• Future Work and Conclusion

5
The Ubiquitous Computing Scene

• Goal automated unobtrusive service access
  anywhere and at any time (Weiser 1991)
• Where are we?
• Standardized seamless networking technologies
• Mobile devices and agents
• Smart spaces aware of occupants identities and
  needs
• What is lacking?
• Automated configuration and facilitation of
  interactions between mutually unknown computers
  or agents
• Balancing automation with security and privacy
  concerns

Introduction Solution System Analysis
and Testing Related Work Conclusion
6
Ubiquitous Computing Characteristics
PHYSICAL INTEGRATION DEVICES, NETWORKS SERVICES
Coffee Shop
Personal Network

• Accessing Services
• Intertwined processes of
• discovery and access control
• Blurred distinction between producer and consumer
• No guarantee of prior trust relationships or
  shared protocols

Home Network
Internet

• Characteristics
• Decentralized control
• Heterogeneity
• Ad hoc interactions

News / Game / Streaming Video (WEB services)
SPONTANEOUS INTEROPERATION
Introduction Solution System Analysis
and Testing Related Work Conclusion
7
Our View of Interoperation

• A top-down approach abstract common features
  from different scenarios
• Incorporate safety and privacy bottom-up
• Achieve service access agreements across security
  and administrative domains while
• Preserving autonomy of intent and action
• Limiting or eliminating manual intervention

Introduction Solution System Analysis
and Testing Related Work Conclusion
8
A Smart Ubiquitous Conference Room

• Services Offered Internet, printer, display.
• Access Control Only conference officials may
  access the projector display.
• Policy No sound permitted during conference
  hours.
• Possession NSF credentials.

CONFERENCE ATTENDEE (an ACM member) (Already a
member of the network)
PDA CELL PHONE (Possessed by a conference
attendee)

• Requires Web access, Projector display, Printer.
• Possession UCLA credentials.
• Privacy Concern Release of credential

PRIVILEGED ACCESS
Introduction Solution System Analysis
and Testing Related Work Conclusion
9
Guarding Network Perimeters

• Requires Network Access, Run network apps.
• Privacy concern Releasing configuration info.
• Compromise Stop vulnerable services.
• Access Control Will run arbitrary code only from
  trusted source.

Firewalled Local Network

• Service Offered Network connectivity.
• Access Control Based on devices configuration.
• Security Constraint Members may run only safe
  networked applications.
• Policy Prospective client must reveal
  configuration information.

Introduction Solution System Analysis
and Testing Related Work Conclusion
10
Roadblocks and Challenges

• Cannot prepare for every interaction context
• Cannot identify, or have pre-arranged trust
  relationships with, everyone else
• Heterogeneity of device characteristics, service
  types and grades
• Difference in policies (goals and constraints)
• Interdependence of resources, entities, and
  constraints within a domain

Introduction Solution System Analysis
and Testing Related Work Conclusion
11
Solutions That Dont Work

• Existing interaction procedures
• Too open and lacking security, OR
• Secure but too inflexible
• Centralized or third party control
• Loss of privacy and autonomy
• Does not scale e.g., Smart Spaces
• Separate protocols for each scenario
• Contexts Service types and access modes
  Interacting entities ? Combinatorial explosion
• We should be able to control our domains through
  policies rather than inventing new mechanisms

Introduction Solution System Analysis
and Testing Related Work Conclusion
12

• Service or application layer agreements
• Based on policy
• Through a process of negotiation

Introduction Solution System Analysis
and Testing Related Work Conclusion
13
Platform and Assumptions
APPLICATION
APPLICATION
TRUST
NEGOTIATION FOR SERVICE ACCESS
NEGOTIATION FOR SERVICE ACCESS
PROOF / LOGIC / RULES
OUR PROTOCOL
Semantic Web
ONTOLOGY / RDF
NAMESPACES / XML
URI / HTTP
Internet / World Wide Web
TCP/IP
MAC LAYER
NETWORK
PHYSICAL LAYER
Introduction Solution System Analysis
and Testing Related Work Conclusion
14
All Interacting Devices Share

• Low level n/w mechanisms, like TCP/IP
• Secure communication protocols, like TLS
• Some common understanding of higher (application
  layer) objects
• Popularity of Semantic Web technologies (RDF/XML)
  validate this assumption

Introduction Solution System Analysis
and Testing Related Work Conclusion
15
Autonomous Domains

• Classes
• Single computing device
• Networked group of computing devices
• Devices affiliated to an organization
• Defined administrative boundary with independent
  policies
• Capable of autonomous computing and communication
• Offer services and run applications

Introduction Solution System Analysis
and Testing Related Work Conclusion
16
Domain Policies

• Represents desired system behavior, goals and
  choices
• Collection of facts, invariants and rules
• Specified by users
• Changes based on observations
• Knowledge of policies is private by default
• Minimum common abstraction necessary for
  interaction
• Policy is the only domain-dependent variable

Enables control over domain behavior of the scope
and flexibility required in ubiquitous computing
Introduction Solution System Analysis
and Testing Related Work Conclusion
17
Policy Classes and Ontology
Autonomous Entities (Including Agents)
Resources and Data
Relationships among Data and Resources
POLICY CLASSES
Constraints Deontic, Limits, Precedence

• Resource Usage
• Security and Access Control
• Context Awareness

Attributes Characteristics, Metadata
POLICY ONTOLOGY
Contextual Parameters Location, Time, etc.
Actions and Events
Mechanisms and Protocols Sensors, Networking,
Cryptography
Introduction Solution System Analysis
and Testing Related Work Conclusion
18
Negotiation Model
D1
D2
Decentralized policy resolution Bidirectional
protocol Multiple simultaneous objectives
G1
G2
P1
P2
Grant access to service set Q1
S1
S2
Grant access to service set Q2
Introduction Solution System Analysis
and Testing Related Work Conclusion
19
Scenario Conference Room
Membership Policy Membership will be granted if
you are certified by ACM or an ACM affiliated
organization AND if you are running a trusted OS
version AND if you are willing to shut off port
25 AND if you are willing to turn off sound.
OFFER (1) YES voucher, (2) YES, (3) NO OFFER
Journal membership for privileged access
OFFER (1) NO (2) NO (3) 2.6.17.1 (4) YES Port
25 closed (5) YES
OFFER (6) YES UCLA voucher object
CONFERENCE ATTENDEE C1 (an ACM member)
OFFER (4) YES NSF voucher object
REQUEST(Counter) (6) Valid accreditation
from ACM-affiliated school?
REQUEST(Counter) (4) Valid NSF accreditation?
PDA CELL PHONE
REQUEST(Counter) (1) Valid ACM voucher? (2)
Valid ACM Official voucher? (3) What OS do you
run? (4) Close port 25 (5) Turn off sound
Requires Membership for web access AND Projector
display access AND Printer access.
PRIVILEGED ACCESS
REQUEST (1) Membership (2) Printer access (3)
Projector display access
Introduction Solution System Analysis
and Testing Related Work Conclusion
20
Negotiation Who?

• Two-party negotiation
• A wants something from B and vice-versa, within
  As and Bs policy constraints
• Bilateral one-to-one (concurrent) negotiations
  supported
• Multi-party negotiation left for future work
• Much harder to analyze theoretical properties
  like completeness

Introduction Solution System Analysis
and Testing Related Work Conclusion
21
Negotiation What?

• What do they negotiate for?
• Resource access
• Information and data transfer
• Imposition of obligations
• Permissions to perform actions (typically,
  running operating system and network services)

Introduction Solution System Analysis
and Testing Related Work Conclusion
22
Domain Policy Model

• Individual policy statements specified in a
  declarative logical manner
• Policies collectively comprise a database
• Logically consistent statements
• Permits both examination and modification
  operations
• Policies can be related to each other
• Offer an interface to return answers to suitably
  framed logical queries
• Return unambiguous answer to a query
• Return satisfied and unsatisfied conditions

Introduction Solution System Analysis
and Testing Related Work Conclusion
23
Policy Language

• Prolog syntax and semantics
• Facts and rules
• Predicates and arguments
• Logical reasoning mechanisms for querying
  backward chaining, unification
• Negation-by-failure
• Sound, and efficient for our purposes

certificate(UCLA). certificate(NSF),possess(N
SF). file(song.mp3,audio), possess(song.mp3).
member(X) - candidate(X), possess(X,V),
validCredential(V). validCredential(V) -
certificate(V). validCredential(V) -
certifiedBy(V,ACM).
FACTS RULES
Introduction Solution System Analysis
and Testing Related Work Conclusion
24
Policy Language (Continued)

• Generality vs specificity

• access(E,R) - someConstraint(E,R).

• access(entity,resource).

• Local predicates vs global predicates

• door(X), partyMember(X).

• certificate(X), printer(X).

• System policies vs User policies

action(closePort,Po) - atom_concat(iptables A
INPUT j DROP p tcp dport,Po,C1),atom_concat(C1
,-i eth1,C),shell(C).

• access(S,V) - certificate(V), possess(S,NSF).

• Helper Functions

action(prohibit,sound) -shell('amixer set Master
mute',0).
Introduction Solution System Analysis
and Testing Related Work Conclusion
25
Basis of Negotiation

• Units messages representing speech acts
• Utterances that express intent to perform an
  action
• Categories
• A negotiation is a conversation
• Sequence of speech acts
• Illocutionary logic describes rules for
  appropriate responses
• Utility capture wide range of scenarios

Introduction Solution System Analysis
and Testing Related Work Conclusion
26
Message Types and Contents

• Requests
• Action ltDo Agt
• Action ltAllow me to do Agt
• Possession ltGive me Pgt
• State ltLet me change to state Sgt
• Question ltTell me gt
• Policies
• Obligation ltPromise to abide by Ogt
• Offers
• Agreement ltYes, I agree to do what you askgt
• Refusal ltNo, I will not do what you askgt
• Rejection ltI cannot accept your offergt
• Answer ltHere is what you asked/inquired aboutgt

Each message can contain multiple requests/offers
Introduction Solution System Analysis
and Testing Related Work Conclusion
27
Protocol State Machine
START
Receive REQUESTS / POLICIES
Trigger/Event to Start Negotiation
Receive OFFERS
INITIATE
PROCESS
SERVICE
Send REQUESTS / POLICIES / OFFERS
Send REQUESTS / OFFERS / POLICIES
Send REQUESTS / POLICIES / OFFERS
Send TERMINATE
Receive OFFERS
Receive REQUESTS / POLICIES
EXPECT
STOP
Receive TERMINATE / TIMEOUT
Send TERMINATE
Introduction Solution System Analysis
and Testing Related Work Conclusion
28
(No Transcript)
29
Negotiation Protocol
POSED D1?D2
RECEIVED D2?D1

• Series of REQUESTs and OFFERs
• Reply to a REQUEST could be
• An OFFER (positive/negative)
• A set of Counter-REQUESTS
• Each side maintains two REQUEST lists
• Requests received, and Requests posed
• Lists grow with additional counter-REQs
• Lists shrink with OFFERs (rollback)
• Termination both lists become empty
• ? An agreement has been achieved
• Typical requests tested credentials, attributes
  and state queries

OFFER R24
R24
D1
R23
R21
D2
R24
R23
R21
POSED D2?D1
RECEIVED D1?D2
Introduction Solution System Analysis
and Testing Related Work Conclusion
30
Generation of Counter-Requests

• A constraint-extraction algorithm
• Request member
• Formatted predicate
• member(S) ? INPUT
• Relevant facts
• possess(HP7200) printer(HP7200)
  groupSize(5) trustedDomain(ACM)
  trustedDomain(UCLA)
• Relevant policy
• member(S) - sound(S,prohibit,1000,1500),
  groupSize(G), Ggt4, closedPort(S,25),
  possess(S,V), voucher(V,M), trustedDomain(M).
• Extracted request set alternatives ? OUTPUT
• sound(prohibit,1000,1500) action(order,closePort
  ,25) possess(V), voucher(V,ACM)
• sound(prohibit,1000,1500) action(S,order,closePo
  rt,25) possess(S,V), voucher(V,UCLA)

Introduction Solution System Analysis
and Testing Related Work Conclusion
31
Negotiation Model Distributed Policy Resolution

• Goals Policies Logical Queries ? Agreement
• High-level goal policies must not be violated
• Agreement fits within the consistent parts of the
  negotiators policies (disregarding incompatible
  policies)
• Negotiation has the same effect as running a
  query through a union of the negotiators
  databases

Introduction Solution System Analysis
and Testing Related Work Conclusion
32
Protocol as a Distributed Derivation Tree

• Centralized resolution generates a tree
• Root represents goal
• Node ? children relation represents a rule
• Leaves represent facts
• Negotiation generates a similar tree
• Difference nodes distributed amongst negotiators
• Node ? children relation represents rules and
  requests
• Children ? parent relations represents offers

Introduction Solution System Analysis
and Testing Related Work Conclusion
33
Ubiquitous Policy Manager Design and
Implementation

• Prerequisite an environment/platform that
  supports collections of devices and offers
  services
• PANOPLY a middleware that manages devices
  clustered in spheres of influence
• Policies mediate interactions among devices and
  collections of devices

PANOPLY MIDDLEWARE
Introduction Solution System Analysis
and Testing Related Work Conclusion
34
Policy Management in Panoply

• Primary task negotiation between spheres for
  membership and service access
• Support for renegotiating agreements
• Arbitrate access to resources through negotiation
• Event-action triggers

Introduction Solution System Analysis
and Testing Related Work Conclusion
35
Concurrent Negotiations in Panoply
Introduction Solution System Analysis
and Testing Related Work Conclusion
36
Policy Manager - Functional View
Messaging Interface (To other system components,
remote computers)
FRONT END
Multi-Threading and Message Switching
Observer/Event Listener
Protocol State Machine
Fault Tolerance Handle node/network failure and
race conditions Use timeouts and unique
timestamps per thread
Fault Tolerance
CONTROLLER
Request Queue Management
Security/Trust Model
Formulation and Semantic Interpretation of
Messages

• Interfacing with Helper Functions
• Non-logical operations
• Processing of objects (say Java objects)
• Operating system operations
• Example sign and verify a voucher

Negotiation Heuristics
Interfacing with Helper Functions
POLICY ENGINE
Logical Knowledge Engineering Mechanisms
Policy Database
Introduction Solution System Analysis
and Testing Related Work Conclusion
37
Applications

• Group- and context-driven Panoply apps
• Interactive Narrative
• Smart Party
• Smart conference room
• Peer-to-peer file sharing
• Secure flexible perimeters
• Opportunistic configuration
• Credential/key
• Printer access/command

Introduction Solution System Analysis
and Testing Related Work Conclusion
38
Dynamic Access Control
APPLICATIONS
External Sphere
Events
Events
SPHERE
MANAGER
EVENT PROCESSOR
. . . . . . . . . . .
RUN QUERY
PASS
DROP
NEGOTIATE
POLICY MANAGER
External Sphere
OPERATING SYSTEM NETWORK
Introduction Solution System Analysis
and Testing Related Work Conclusion
39
Application The Smart Party
Cooperative music application deployed in a
multi-room environment

• Users bring mobile devices carrying music and
  musical preferences
• Each room builds custom play-list based on user
  presence and preferences
• Dynamically streams music from attendees

Smart Party
Living Room
Family Room
Dining Room
Folk
Rock
Jazz
RB
Rap
Eustice2008 PhD Thesis
Introduction Solution System Analysis
and Testing Related Work Conclusion
40
Access Control in a Smart Party

• Guest tries to force the room to play his
  favorite song
• Query made to Policy Engine
• Negotiation
• Do you have a valid host voucher?
• YES ? Update playlist
• NO ? Nothing changes

Introduction Solution System Analysis
and Testing Related Work Conclusion
41
Sample Performance Results
802.11b TLS
N1
N2
Case I R(N1) ? AO(N2) ? T(N1) Case II
R(N1) ? NO(N2) ? T(N1) Case III R(N1) ? 3
C-R(N2) ? 3 AO(N1) ? AO(N2) ? T(N1) Case IV
R(N1) ? C-R(N2) ? NO(N1) ? 3 C-R(N2)
(alternative) ? 3 AO(N1) ? 1 AO(N2) ? T(N1)
Initiator R(N1) Request for membership
Introduction Solution System Analysis
and Testing Related Work Conclusion
42
Analysis System Perspective

• Assumptions
• Finite policy database
• Finite length of each policy statement
• No cycles within a database
• Protocol termination
• Counter-Request generation procedure terminates
• Running time complexity O(R(RF)2FS2A)
• Deadlock-free
• Livelocks possible
• Cycles between negotiators result in duplicate
  requests
• Can be avoided with checks for duplicates (adds
  overhead)

Introduction Solution System Analysis
and Testing Related Work Conclusion
43
Success of Negotiation

• Primary negotiation aim given goals and
  policies, generate a result
• Set of results ranging from none to full
  satisfaction of goals
• Collection of such results are consistent with
  policies
• An oracle (centralized policy resolution) can
  generate an optimal solution
• Knows ltG1,P1,S1gt and ltG2,P2,S2gt, and uses a
  centralized resolution algorithm to determine the
  best result
• Complexity is still exponential
• Negotiation is a decentralized policy resolution
• Need to keep local policies private
• Must work with partial knowledge
• Ideal achieve the oracular result

Introduction Solution System Analysis
and Testing Related Work Conclusion
44
Grades of Success

• Correctness
• Result (set of goal satisfactions) is an improper
  subset of the oracular result
• Only criteria consistency with policy
• Completeness
• Negotiation protocol delivers oracular result
• Optimality
• Negotiation protocol delivers oracular result in
  fewest number of steps

Correctness lt Completeness lt Optimality
Introduction Solution System Analysis
and Testing Related Work Conclusion
45
Analysis Theoretical Perspective

• Correctness and Completeness? YES, with
  Exception
• Guaranteed to terminate in a finite number of
  steps
• Database has finite number of policies
• Each policy is of finite length
• Trivially correct in all cases
• End result of negotiation guaranteed to be
  consistent with policy, as Prolog query semantics
  are known to be correct
• Exhaustive search ensures that a solution will be
  found
• Exception
• Intermediate negotiation steps involve
  non-logical operations
• Database state modification may cause negotiation
  failure even when success is possible
• FIX keep track of modifications and undo them
• Optimality? NO GUARANTEE
• Negotiation time and steps depend on alternative
  selection ordering

Introduction Solution System Analysis
and Testing Related Work Conclusion
46
Optimality Testing

• Statistical comparison of actual and optimal
  negotiations
• Primary metric number of steps
• Oracle can estimate optimal (least) number of
  steps
• Negotiation is sub-optimal
• steps depends on alternative selection heuristic
• Other metrics (time, tree coverage) also measured
• Counter-Request selection heuristic used
• Size of request set

Introduction Solution System Analysis
and Testing Related Work Conclusion
47
Testing Tools

• Negotiation Protocol (decentralized PR)
• Centralized Policy Resolver Oracle
• Inputs
• Two policy databases and an initial goal
  (request)
• Process
• Combine two policy databases into a centralized
  one
• Outputs
• Full (centralized) derivation tree
• Total number of policies examined
• Number of steps taken by an optimal negotiation
• Test case generator

Introduction Solution System Analysis
and Testing Related Work Conclusion
48
Generation of Test Cases

• Pair of policy databases and goal sets
• One for each negotiator
• Variations based on size of tree
• Number of nodes in a tree O(bd)
• Control parameters
• bmax maximum branching factor
• Indicates length or complexity of policies
• dmax maximum depth
• Indicates interdependency of policies

Introduction Solution System Analysis
and Testing Related Work Conclusion
49
Negotiation Length Variation (Optimal Steps)
Introduction Solution System Analysis
and Testing Related Work Conclusion
50
Negotiation Length Variation (Branching Factor)
Introduction Solution System Analysis
and Testing Related Work Conclusion
51
Processing Time
Introduction Solution System Analysis
and Testing Related Work Conclusion
52
Processing Time Per Step
Introduction Solution System Analysis
and Testing Related Work Conclusion
53
Results Summary

• Actual negotiation increases linearly with the
  optimal negotiation length
• Average length of failed negotiations lt 4 steps
• Negotiation processing time dominates oracular
  processing time, but not the average time per
  step
• Increase in policy complexity results in
  significant increase in processing cost (but
  mainly for bmax gt 6)
• Fraction of intermediate requests granted and
  alternatives examined show small variations but
  are significantly lower than unity on average

Introduction Solution System Analysis
and Testing Related Work Conclusion
54
Related Work

• Negotiation Protocols
• Automated Trust Negotiation
• Protune, PeerTrust, TrustBuilder BYU,UIUC
• Goal client-server transactions on the Web
• Does not support alternatives or multiple goals
• No comparison with centralized model
• Web services negotiation (WS-Agreement)
• Policy Languages
• Rei pervasive computing language
• Cross-domain semantics
• Web services WS-Policy, XACML non-logical
• Ponder non-logical
• Ontology SOUPA, DAMLOIL, OWL

Introduction Solution System Analysis
and Testing Related Work Conclusion
55
Related Work (Continued)

• Middleware for open systems
• Ubicomp active space middleware Hyperglue
  MIT, Cerberus UIUC
• Service discovery JINI, UPnP
• Limited security features
• Access Control
• Generalized RBAC
• Dynamic RBAC
• Secure Context-sensitive Authorization Minami
  and Kotz
• Distributed Proof
• Test Case Generation
• Trust frameworks
• SECURE project
• Dynamic notion of trust
• Trust evolution based on interaction history
• Reputation frameworks

Introduction Solution System Analysis
and Testing Related Work Conclusion
56
Future Work

• Enhancements to the negotiation protocol
• Other heuristics expected time to finish,
  partial ordering based on privacy and trust
• Multi-party collective negotiation
• Avoiding DoS attacks
• Policy Manager
• Running on resource-constrained devices
• Porting to other middleware e.g., GAIA
• User Interaction
• More control and feedback
• Post-negotiation analysis
• User-friendly policies

Introduction Solution System Analysis
and Testing Related Work Conclusion
57
Conclusion

• Service-level interoperation in ubicomp requires
• Flexible solutions
• Minimal user intervention
• Generic policy-guided negotiation enables
  interoperation
• Negotiation is modeled as a distributed policy
  resolution procedure
• Proof-of-concept was demonstrated through a
  working implementation and practical applications
• Negotiation can be used as a tool for dynamic
  context-sensitive access control
• Large-scale optimality tests indicate feasibility
  of negotiation in practical situations

Introduction Solution System Analysis
and Testing Related Work Conclusion
58
Thank You

• V. Ramakrishna, Kevin Eustice, and Peter Reiher,
  Negotiating Agreements Using Policies in
  Ubiquitous Computing Scenarios, In the
  Proceedings of the IEEE International Conference
  on Service-Oriented Computing and Applications
  (SOCA'07), June 19-20, 2007, Newport Beach,
  California.
• Venkatraman Ramakrishna, Peter Reiher, and
  Leonard Kleinrock, Distributed Policy Resolution
  Through Negotiation in Ubiquitous Computing
  Environments, In submission to the 7th Annual
  IEEE International Conference on Pervasive
  Computing and Communications (PerCom 2009).
• Kevin Eustice, Leonard Kleinrock, Shane
  Markstrum, Gerald Popek, Venkatraman Ramakrishna,
  Peter Reiher, Enabling Secure Ubiquitous
  Interactions, In the Proceedings of the 1st
  International Workshop on Middleware for
  Pervasive and Ad-Hoc Computing (Co-located with
  Middleware 2003), 17 June 2003 in Rio de Janeiro,
  Brazil.
• Kevin Eustice, V. Ramakrishna, Alison Walker,
  Matthew Schnaider, Nam Nguyen and Peter Reiher,
  "nan0sphere Location-Driven Fiction for Groups
  of Users," In the Proceedings of the 12th
  International Conference on Human-Computer
  Interaction (HCII 2007), 22-27 July 2007,
  Beijing, P.R.China.
• Kevin Eustice, V. Ramakrishna, Nam Nguyen, and
  Peter Reiher, "The Smart Party A Personalized
  Location-aware Multimedia Experience," In the
  Proceedings of the Fifth IEEE Consumer
  Communications and Networking Conference (CCNC
  2008), Las Vegas, NV, January 10-12, 2008.

59
Case Study Secure Perimeters
OFFER (1) NO
OFFER (2) YES (3) NO
OFFER (2) YES UCLA Voucher (3) YES
OFFER (5) YES
OFFER (4) YES Result
OFFER (1) YES
Firewalled Local Network
REQUEST (Counter) (2) Credentialed by UCLA? (3)
Let me run networked applications
REQUEST (Counter) (5) Close port 25
REQUEST (1) Membership
REQUEST (Counter) (4) Upgrade Kernel
REQUEST (Counter) (1) Are you running Ubuntu?
REQUEST (Counter) (2) Are you running Redhat?
(3) v2.6.20 or higher?
Introduction Solution System Analysis
and Testing Related Work Conclusion
60
Case Study Interactive Narrative

• Team-, location- and action-driven fiction
  deployed in UCLA
• Purposes of negotiation
• Membership within location and team spheres
• Obtain location voucher
• Variations
• Dynamic role change
• Policy manager roles
• Hints based on context and location changes

61
Sample Test Case
Facts
Rules
storage(px6). voucher(ht). type(zp,bw). voucher(vk
). printerName(pjf). disp(l). group(py,acm). tim(g
h). brand(o,hp7100). parentName(htm). possess(disk
Space,0). displayName(ck). directory(ec,v). file(f
i1). type(xz1,color). voucher(c).
obey(X,open) - printer(VAR),displayName(X,
VAR001723). accessInfo(X,(tim(VAR01213))) -
possess(X, VAR0683),voucher(VAR0683),type(VAR0683,
VAR1684). access(X,diskSpace,VAR) -
childName(X, VAR023638). obey(X,run) -
voucher(VAR),type(VAR,VAR1),possess(X, diskSpace,
VAR1610). obey(X,open) - printer(VAR),memberIn(X)
. obey(X,open) - printer(VAR),childName(X,
VAR023592). accessInfo(X,(tim(VAR01213))) -
possess(X, diskSpace, VAR1573). accessInfo(X,(tim(
VAR01011))) - action(X, order, open,
VAR0554),printer(VAR0554). accessInfo(X,(childName
(VAR023))) - memberIn(X). obey(X,open) -
printer(VAR),possess(X, diskSpace,
VAR1481). accessInfo(X,(childName(VAR023))) -
displayName(X, VAR001382). access(X,VAR) -
voucher(VAR),type(VAR,VAR1),childName(X,
VAR023354). obey(X,run) - voucher(VAR),type(VAR,V
AR1),action(X, order, open, VAR0144),printer(VAR01
44).
Sample Goals
possess(VAR),door(VAR) action(order,play,VAR),door
(VAR),directory(VAR,VAR1) action(order,closePort,V
AR),door(VAR),type(VAR,VAR1) action(order,prohibit
,VAR),printer(VAR),brand(VAR,VAR1)