A Policy Specification Language for Governing
Open, Dynamic Distributed Environments
Lalana Kagal, University of Maryland Baltimore County
Outline




Environments under consideration
Key Idea
Rei : a policy specification language
Examples




Collaborative MAS
Pervasive Computing
Internet Privacy
Semantic web services
 Related Work
 Contributions
 Summary
2 of 59
Characteristics of the Domain
Characteristics
1. Resources and clients are not
pre-determined
Restriction on mechanism
1. Mechanism cannot list access rights of
individuals
2. Constantly evolving
2. Run-time modification should be possible
3. Usually very large number of
resources, services and clients
3. It should be possible to control sets of
clients and services grouped by certain
common characteristics
4. Presence of semi-autonomous
entities
4. Mechanism should be automated
5. Span several domains
5. Mechanism should be easily extensible to
be usable for any domain-specific
information
6. Mechanism should include some way to
6. Entities belong to several domains handle conflicts in behavior specifications
3 of 59
Key Idea

Restriction on mechanism
Mechanism cannot list access rights of
individuals


Run-time modification should be possible


It should be possible to control sets of clients 
and services grouped by certain common
characteristics

Mechanism should be automated

Mechanism should be easily extensible to be 
usable for any domain-specific information

Mechanism should include some way to
handle conflicts in behavior specifications


Solution
Declarative policies that are described in
terms of attributes of entities
Speech act support for dynamic
modification
Policies can be described over sets of
entities
Policies represented in a machineunderstandable language
Policy specification language grounded in
an ontology language
Meta policies to handle conflicts in policies
4 of 59
What are Policies ?
 Policies are rules of behavior
 Describe optimal behavior (security, privacy, management, etc.)
 Positive and negative authorizations & obligations
 Policies are defined over ‘classes’ of entities and actions defined by
constraints on attributes of the action (and its actor and target) and the
general context – not just on their identity of the actor and action
 Management
 Can be enforced by the policy management system
 Can be reasoned over by entities to decide what to do next
 Policies allow the behavior of entities to be dynamically
modified
 Policies provide high-level control of entities in the
environment
5 of 59
An early policy for agents
1 A robot may not injure a human being, or,
through inaction, allow a human being to
come to harm.
2 A robot must obey the orders given it by
human beings except where such orders
would conflict with the First Law.
3 A robot must protect its own existence as long
as such protection does not conflict with the
First or Second Law.
-- Handbook of Robotics, 56th Edition, 2058 A.D.
6 of 59
On policies, rules and laws
 The interesting thing about Asimov’s laws were that robots
did not always strictly follow them
 This is a point of departure from more traditional “hard coded”
rules like DB access control, and OS file permissions
 Policies increase autonomy
 They describe “norms of behavior” that entities should follow to be
“good citizens”
 So, it’s natural to worry about issues like
 When an entity is governed by multiple policies, how does it resolve
conflicts among them?
 How can we define penalties when entities don’t fulfill their
obligations?
 How can we relate notions of trust and reputation to policies?
7 of 59
Rei Policy Spec Language
 Developed several versions of Rei, a policy specification
language, encoded in (1) Prolog, (2) OWL
 Models deontic concepts of permissions, prohibitions,
obligations and dispensations
 Uses meta policies for conflict resolution
 Uses speech acts for dynamic policy modification
 Used to model different kinds of policies
 Security
 Privacy
 Team formation, collaboration and
maintenance
 Conversation
8 of 59
Some Rei Examples
 Management policies
 You are permitted to send dispensations for obligations created by Y under
certain situations, as long as you are higher in the organizational hierarchy
than Y
 Security policies for pervasive computing environments
 You cannot use the camera functionality of your handheld device in this
domain
 You are permitted to access all services on resources located in any lab that
your advisor is affiliated to
 Privacy policies in the semantic web services framework
 I do not want to access any service that requires my SSN number in an
unencrypted format
 Conversation policies
 You are obliged to reply to all queries from anyone in your group
 Policies for information flow in multi-agent systems
 No members from CIA and FBI can exchange information about topic X
unless they are on a top priority team
9 of 59
Rei Policy Spec Language
 A declarative policy specification language
 Rules over permitted and obligated domain actions
 Currently represented in OWL-Lite + logical variables
 Increased expressivity as it can express relations like role-value maps
that are not currently possible in RDF or OWL
 OWL extension is subset of SWRL
 Reasons over domain dependent information in RDF and
OWL
 Can include any other ontology language as long as the appropriate
reasoner is hooked into the policy engine
 Policy tools
 Policy Engine
 Answers queries about policies and domain knowledge
 Example : Can X perform action Y on resource Z ? What are the current
obligations of X ? What actions can X perform on resource/service Z ? ….
10 of 59
Rei Policy Spec Language
 Policy Tools (cont.)
 Analysis tools
 Verifying whether the given set of test cases is satisfied
 Returning list of satisfied/unsatisfied test cases
 Performing what-if analysis for testing the impact of changes to
policies or domain knowledge
 Interface
 Java API
 Simple GUI in Protégé
 GUI in Eclipse (under construction)
11 of 59
Rei Specifications
 Rei Ontologies


Core specs
 Policy
 Granting
 Action
 Deontic Object
 Speech Act
 Meta Policy
 Constraint
Authoring aid specs
 Analysis
12 of 59
Constraint
 Simple Constraints
 Triple(Subject, Predicate, Object)
 Example : Group of entities that are affiliated to the LAIT
lab
<entity:Variable rdf:ID=”Var1”/>
<constraint:SimpleConstraint rdf:ID=”IsMemberOfLait">
<constraint:subject rdf:resource="#Var1"/>
<constraint:predicate rdf:resource="&univ;affiliation"/>
<constraint:object rdf:resource="&univ;LAITLab"/>
</constraint:SimpleConstraint>
 Boolean Constraints : And, Or, and Not
13 of 59
Policy
 Properties : Context, Grants, Default Policy,
Priorities
 A Policy is applicable if the Context is true
 Example
<policy:Policy rdf:ID=”CSDeptPolicy">
<policy:context rdf:resource="#IsMemberOfCS"/>
<policy:grants rdf:resource="#Perm_StudentPrinting"/>
<policy:defaultBehavior
rdf:resource="&metapolicy;ExplicitPermExplicitProh"/>
<policy:defaultModality
rdf:resource="&metapolicy;PositiveModalityPrecedence"/>
<policy:metaDefault
rdf:resource="&metapolicy;CheckModalityPrecFirst"/>
</policy:Policy>
14 of 59
Granting
 Links deontic rules to policies with additional
constraints
 Allows for reuse of deontic objects with different
constraints
 Encourages modularity
 Deontic objects and constraints can be defined by
technical staff
 Policy administrator can drag and drop appropriate
deontic objects and add constraints
15 of 59
Granting
 Example : Same permission used in Policy example
with extra constraints
<policy:Granting rdf:ID="Granting_PhStudentLaserPrinting">
<policy:to rdf:resource="#PersonVar"/>
<policy:deontic rdf:resource="#Perm_StudentPrinting"/>
<policy:requirement rdf:resource="#IsLaserPrinterAndPhStudent"/>
</policy:Granting>
<policy:Policy rdf:ID=”BioDeptPolicy">
<policy:grants rdf:resource="# Granting_PhStudentLaserPrinting"/>
</policy:Policy>
16 of 59
Deontic Object
 Deontic objects
 Permissions, Prohibitions, Obligations, Dispensations
(waiver for obligations)
 Common Properties : Actor, Action, Constraint
{StartingConstraint, EndingConstraint}
 StartingConstraint subproperty of Constraint
17 of 59
Permission
 ~O~ : Permission(X, Y, Constraint/
StartingConstraint, {EndingConst}, {Provision})
 X is said to have the permission to perform action Y
if the Constraint or StartingConstraint is true and
until EndingConstraint is true.
 Additional property : Provision
 These are obligations that are come into effect when the
permission is used
 After the permission is used, Provision comes into
effect
18 of 59
Example Permission
 Example : Students are permitted to print on certain
set of printers as long they replace the paper
<deontic:Permission rdf:ID="Perm_StudentPrinting">
<deontic:actor rdf:resource="#PersonVar"/>
<deontic:action rdf:resource="#ObjVar"/>
<deontic:constraint
rdf:resource="#IsStudentAndBWPrinter"/>
<deontic:provision
rdf:resource="#Obl_ReplacePaper"/>
</deontic:Permission>
19 of 59
Prohibition
 O~ : Prohibition(X, Y, Constraint/StartingConstraint,
{EndingConst}, {Sanction})
 X is said to be have a prohibition from performing action Y if
the Constraint (or StartingConstraint is true) and until
EndingConstraint is true.
 Additional property : Sanction
 In case prohibitions are violated, additional obligations or prohibitions
are usually applicable
 Or a certain action that is taken against the actor
 If the prohibition is violated, the Sanction comes into effect
 If the Sanction is an obligation or prohibition, it is imposed on X
20 of 59
Obligation
 O : Obligation(X, Y, Constraints/StartingConstraint,
{EndingConst}, {Sanction})
 X is said to be have a obligation to perform action Y if the
Constraint (or StartingConstraint is true) and until
EndingConstraint is true.
 If the obligation is not fulfilled before EndingConstraint is true,
it is said to have been violated.
 Additional property : Sanction
 In case obligations are violated, additional obligations or prohibitions
are usually applicable
 Or a certain action could be performed on the actor
 If the obligation is violated, the Sanction comes into effect
 If the Sanction is an obligation or prohibition, it is put into effect
21 of 59
Example Obligation
 If you borrow a book from the library, you’re obliged
to return it before the due date, otherwise you must
pay a fine
<deontic:Obligation rdf:ID=”Obl_ReturnBook">
<deontic:actor rdf:resource="#PersonVar"/>
<deontic:action rdf:resource=”&inst;ReturnBook"/>
<deontic:StartingConstraint
rdf:resource="#IsMemberAndBorrowedBook"/>
<deontic:EndingConstraint rdf:resource="#BeforeDueDate"/>
<deontic:sanction rdf:resource=”&inst;PayFine"/>
</deontic:Obligation>
22 of 59
Dispensation
 ~O : Dispensation(X, Y, Constraints/StartingConstraint,
{EndingConst})
 X is said to be have a dispensation from performing action Y
if the Constraint (or StartingConstraint is true) and until
EndingConstraint is true.
 After Constraint/StartingConstraint is true and until
EndingConstraint is true, X is no obliged to perform Y
23 of 59
Action
 Two kinds of actions : Domain Actions and Speech Acts
 Domain Actions
 Properties : Actor, Target, Effects, PreConditions
 Action(Actor, Target, PreConditions, Effects)
 Action can be performed on Target only when the PreConditions are
true and oncce performed the Effects are true.
 Example : Based on Rei
<action:Action rdf:ID=”EbiquityDeviceUsage">
<action:actor rdf:resource="#PersonVar"/>
<action:target rdf:resource="#ObjVar"/>
<action:location rdf:resource="&inst;EbiquityLab"/>
<action:precondition rdf:resource="#DeviceBelongsToEbiqLab"/>
<action:Action>
24 of 59
Action
 Example :
<owl:Class rdf:ID="CSPrinting">
<rdfs:subClassOf rdf:resource=”&univ;Printing"/>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="&action;location"/>
<owl:allValuesFrom rdf:resource=”&inst;CSDept" />
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>
25 of 59
Speech Acts
 Speech Acts
 Delegation, Revocation, Request, Cancel
 Properties : Sender, Receiver, Content (Deontic
object/Action), Conditions
 Used to dynamically modify existing policies
 Speech acts are valid only if the entities that make them
have the appropriate permissions
26 of 59
Delegation
 Delegation(Sender, Receiver, Permission(Receiver,
Action, Constraints, {EndingConst}, {Provision}),
Conditions)
 The Sender grants to the Receiver the Permission
as long the Conditions are true.
 If valid, leads to a permission.
27 of 59
Example Delegation
 Example : Delegation from ’Marty' to all students of the
'CSDept' giving them the permission to perform actions of
type ’LaserPrinting'
<action:Delegation rdf:ID=”MartyToCSStudents">
<action:sender rdf:resource="&inst;Marty"/>
<action:receiver rdf:resource="#PersonVar"/>
<action:content>
<deontic:Permission>
<deontic:actor rdf:resource="#PersonVar"/>
<deontic:action rdf:resource="#ObjectVar"/>
</deontic:Permission>
</action:content>
<action:condition>
<constraint:And>
<constraint:first rdf:resource="#IsStudentOfCS"/>
<constraint:second rdf:resource="#IsLaserPrinting"/>
</constraint:And>
</action:condition>
</action:Delegation>
28 of 59
Permission To Delegate
 Example : Marty has the permission to perform a delegation
speech act to graduate students wrt the LaserPrinting actions
<deontic:Permission rdf:ID="Perm_MartyDelegateFacultyCSPrinting">
<deontic:actor rdf:resource="&inst;Marty"/>
<deontic:action>
<action:Delegation rdf:ID="Perm_Del">
<action:sender rdf:resource="&inst;Marty"/>
<action:receiver rdf:resource="#var1"/>
<action:content>
<deontic:Permission>
<deontic:actor rdf:resource="#var1"/>
<deontic:action rdf:resource="#var2"/>
<deontic:constraint rdf:resource="#IsLaserPrinting"/>
</deontic:Permission>
</action:content>
</action:Delegation>
</deontic:action>
<deontic:constraint rdf:resource="#IsGraduateStudent"/>
</deontic:Permission>
29 of 59
Request
 Request(Sender, Receiver, Permission(Receiver,
Action), Constraints)
 The Sender asks the Receiver for the Permission
 If accepted, leads to a delegation
 Request(Sender, Receiver, Action, Constraints)
 The Sender asks the Receiver to perform the Action.
 If valid, leads to an obligation
30 of 59
Revocation
 Revocation(Sender, Receiver, Permission(Receiver, Action,
Constraints, {EndingConst}, {Provision}), Conditions)
 The Sender revokes from the Receiver the Permission as long the
Conditions are true.
 If valid, leads to a prohibition.
 Example : ’Marty' revokes the permission to use a specific
action ’HP123Printing from 'George'
<action:Revocation rdf:ID=”MartyFromGeorge">
<action:sender rdf:resource="&inst;Marty"/>
<action:receiver rdf:resource="&inst;George"/>
<action:content>
<deontic:Permission>
<deontic:action rdf:resource ="&inst;HP123Printing"/>
</deontic:Permission>
</action:content>
</action:Revocation>
31 of 59
Cancel
 Cancel(Sender, Receiver, Permission(Receiver,
Action), Constraints)
 The Sender does not need the earlier requested
Permission from the Receiver.
 Leads to a revocation.
 Cancel(Sender, Receiver, Action, Constraints)
 The Sender no longer wants the Receiver to perform the
Action.
 Leads to a dispensation
32 of 59
Meta Policy
 Meta policies
 Behavior
 ExplicitPermImplicitProh
 ImplicitPermExplicitProh
 ExplicitPermExplicitProh
 Priority
 Priority between rules in the same policy
 Priority between policies
 E.g. Federal policy overrides State policy
 Modality precedence
 E.g. Positive modality holds precedence over negative for CSDept policy
 Meta policy Default
 CheckModalityPrecFirst
 CheckPriorityFirst
33 of 59
Priority
 Example : To specify that the Federal policy has
higher priority that the State policy
<metapolicy:PolicyPriority rdf:ID="PriorityFederalState">
<metapolicy:policyOfGreaterPriority rdf:resource="&gov;Federal"/>
<metapolicy:policyOfLesserPriority rdf:resource="&gov;State"/>
<metapolicy:PolicyPriority>
 Priorities for policies and rules must be acyclic (it is
possible to check this but currently not implemented)
 Rei does not allow
 University policy overrides department policy
 Department policy overrides lab policy
 Lab policy overrides university policy
34 of 59
Modality Precedence
 Example : To state that negative modality holds for
the CSDept and in case of conflict modality
precedence should be checked before priorities
<policy:Policy rdf:ID=”CSDeptPolicy">
<policy:context rdf:resource="#IsMemberOfCS"/>
<policy:defaultModality
rdf:resource="&metapolicy;NegativeModalityPrecedence"/>
<policy:metaDefault
rdf:resource="&metapolicy;CheckModalityPrecFirst"/>
</policy:Policy>
35 of 59
Analysis
 Use Cases (known as test cases in Software
Engineering)
 Define a set of use cases that must always be satisfied in
order for the policies to be correct
 E.g. The dean of the school must always have access to
all the grad labs
 WhatIf
 To check the effects of changes to the policy or ontology
before actually committing them
 E.g If I remove Perm_StudentPrinting from the
GradStudentPolicy, will Bob still be able to print ?
36 of 59
UseCase Analysis
 Use cases : Statement and Deontic UseCases
 Statement UseCase checks the value of a property
 True or false statements can be checked
 Example : BobJones is affiliated with the CS department
<analysis:TrueStatementUseCase rdf:ID="BobJonesIsInCS">
<analysis:subject rdf:resource="&inst;BobJones"/>
<analysis:predicate rdf:resource="&univ;affiliation"/>
<analysis:object rdf:resource="&inst;CSDept"/>
</analysis:TrueStatementUseCase>
37 of 59
UseCase Analysis
 Deontic UseCase checks whether the specified actor has
the specified deontic on the target and the action
 Example : Marty should not be able to perform any action
on the HP-Printer
<analysis:ProhibitionUseCase rdf:ID="MartyCannotUseHP-Printer">
<analysis:actor rdf:resource="&inst;Marty"/>
<analysis:target rdf:resource="&inst;HP-Printer"/>
</analysis:ProhibitionUseCase>
38 of 59
What-If Analysis
 What-if analysis : Property and PolicyRule analysis
 Subclasses : WhatIfIAddProperty and WhatIfIRemoveProperty
 Allows the property value associated with an instance to be
temporarily added or removed
 Example : To test the effects of removing the 'CSDept' value of the
'affiliation' property from 'Marty'
<analysis:WhatIfIRemoveProperty rdf:ID=”RemoveMartyCS">
<analysis:instance rdf:resource="&inst;Marty"/>
<analysis:property rdf:resource="&univ;affiliation"/>
<analysis:value rdf:resource=”&univ;CSDept"/>
</analysis:WhatIfIRemoveProperty>
 To remove all values of a property, no value is specified
39 of 59
What-If Analysis
 Rule analysis
 Is used for checking the effect of changing a policy
 WhatIfIAddRule and WhatIfIRemoveRule
 Example : In order to test the effects of adding a policy rule,
'Perm_Joe', to a policy, 'CSPolicy'
<analysis:WhatIfIAddPolicyRule rdf:ID="AddPermToCSPolicy">
<analysis:policy rdf:resource="&inst;CSPolicy"/>
<analysis:granting rdf:resource="Perm_Joe"/>
</analysis:WhatIfIAddPolicyRule>
<deontic:Permission rdf:ID="Perm_Joe">
<deontic:actor rdf:resource="&inst;Joe"/>
<deontic:action rdf:resource="&inst; SomeAction"/>
</deontic:Permission>
40 of 59
Implementation Details
 XSB
USER
JAVA API
 Flora : F-logic over XSB
 F-OWL : is a reasoner for
RDF, OWL
 Java wrapper
REI INTERFACE
YAJXB
REI
FLORA
FOWL
XSB
Image adapted from Mohinder Chopra
41 of 59
Applications – past, present & future
 Coordinating access in supply chain management
system (EECOMS - IBM lead)
 Authorization policies in a pervasive computing
environment (UMBC)
 Policies for team formation, collaboration, information
flow in multi-agent systems (Genoa II (Topsail) - GITI lead)
 Security in semantic web services (UMBC, SRI, CMU)
 Privacy and trust on the Internet (UMBC)
 Enforcing domain policies on handhelds in pervasive
computing environments (UMBC, NIST)
 Privacy in a pervasive computing environment (UMBC)
 Task Computing (Fujitsu)
1999
2002
2003
2004
…
42 of 59
COLLABORATIVE MULTI-AGENT SYSTEMS
 Agents facilitate collaboration within inter-agency human
teams that are formed to handle a crisis
 Agencies and teams have policies that guide behavior of their
agents
 Policies are used for
 Team formation (selecting a leader, choosing team members)
 Collaboration
 Information flow
 Workflow component of an agent takes into
account relevant policies and its goals to
decide what to do next
 Lead: Global Infotek Inc. for DoD
43 of 59
PERVASIVE COMPUTING
Should I
allow
this
access ?
Should I
trust this
service ?
44 of 59
Applications
1.
Access control for Smart Spaces



2.
Physical world is divided into Smart
Spaces
Each smartspace has a controller that
enforces the access control policy of the
smartspace
SmartSpaces in an organization are
connected and it is possible to traverse
the hierarchy and access services in
another SmartSpace
Enforcement of domain policies

Domain policies are enforced on mobile
devices



Restricts functionality of mobile devices
within domains
E.g. You cannot use the IR or BT
functionality while you are in an untrusted
domain
Enforcement



Rei policies stored within policy servers
Rei policies instantiated to give ACL
ACL enforced on mobile device
45 of 59
SEMANTIC WEB SERVICES
 Is mainly at the specification level
 Extension of OWL-S profile with an attribute for
describing policies
 policyEnforced
 subPropertyOf securityRequirement which is a subproperty of
profile:parameter
 Range: Policy in Rei ontology
 Ontology for describing cryptographic characteristics
of service parameters
 Encrypted/Signed object
47 of 59
Our Approach
 Authorization, Privacy and Confidentiality Policy are
subclasses of Policy in Rei
 Authorization policies are usually associated with services
 Can be enforced during discovery
 Privacy policies are usually associated with clients
 Only matching done during discovery
 Algorithm for matching policies
 Integration of the algorithm into CMU’s Matchmaker and
OWL-S Virtual Machine (future work)
 Earlier version was integrated into the Matchmaker
48 of 59
Example policies
 Authorization
 Access control rules based on constraints over the requester, the
action, the target and the general context
 Example 1 : Stock service is not accessible after the market closes
 Example 2 : Only members of the LAIT lab who are Ph.D. students
can use the LAIT lab laser printer
 Privacy
 User restricts his access to services as constraints over input/output of
services
 Example 3 : Do not disclose my SSN
 Confidentiality
 User specifies the cryptographic protocols required for the input and
output of the service
 Policy 5 : Do not use a service that doesn’t encrypt all input/output
 Policy 6 : Use only those services that require my SSN if it is
encrypted
49 of 59
Example
 Mary is looking for a reservation service
 foaf description
 BravoAir is a reservation service
 OWL-S description
 Authorization policy
 Only users belonging to the same project as John can access the
service
50 of 59
Mary
<!-- Mary's FOAF description -->
<foaf:Person rdf:ID="mary">
<foaf:name>Mary Smith</foaf:name>
<foaf:title>Ms</foaf:title>
<foaf:firstName>Mary</foaf:firstName>
<foaf:surname>Smith</foaf:surname>
<foaf:homepage
rdf:resource="http://www.somewebsite.com/marysmith.html"/>
<foaf:currentProject rdf:resource=" &some;SWS-Project "/>
<sws:policyEnforced rdf:resource="&mary;ConfidentalityPolicy"/>
</foaf:Person>
</rdf:RDF>
51 of 59
BravoAir Policy
<entity:Variable rdf:ID="var1"/>
<entity:Variable rdf:ID="var2"/>
<constraint:SimpleConstraint rdf:ID="GetJohnProject"
constraint:subject="&john;John"
constraint:predicate="&foaf;currentProject"
constraint:object=”#var2"/>
<deontic:Permission rdf:ID=”AccessPermission">
<deontic:actor rdf:resource=”#var1"/>
<deontic:action rdf:resource="&bravoservice;BravoAir_ReservationAgent"/>
<deontic:constraint rdf:resource=”#AndCondition1"/>
</deontic:Permission>
………
<constraint:SimpleConstraint rdf:ID="SameProjectAsJohn"
constraint:subject=”#var1"
constraint:predicate="&foaf;currentProject"
constraint:object=”#var2"/>
<rdf:Description rdf:about="&bravoservice;BravoAir_ReservationAgent">
<sws:policyEnforced rdf:resource=”#AuthPolicy"/>
</rdf:Description>
<!-- constraints combined -->
<constraint:And rdf:ID="AndCondition1"
constraint:first=”#GetJohnProject"
constraint:second=”#SameProjectAsJohn"/>
52 of 59
How it works
BravoAir
Web service
Mary
URL to foaf desc
+ query request
<sws:policyEnforced rdf:resource =
Matchmaker
"&bravo-policy;AuthPolicy"/>
+
Bravo Service
OWL-S Desc
Reasoner
53 of 59
How it works
Mary’s query = BravoAir ? YES
Extract Bravo’s policy
Does Mary meets Bravo’s policy ?
<deontic:Permission rdf:about="&bravo-policy;AccessPermission">
<constraint:SimpleConstraint
<deontic:actor
rdf:resource="&bravo-policy;var1"/>
Authorization enforcement complete
rdf:about
= "&bravo-policy;GetJohnProject”
<deontic:action
rdf:resource="&bravo-service;BravoAir_ReservationAgent"/>
constraint:subject="&john;John"
<deontic:constraint
rdf:resource="&bravo-policy;AndCondition1"/>
constraint:predicate="&foaf;currentProject"
</deontic:Permission>
constraint:object="&bravo-policy;var2"/>
Mary
<policy:Granting rdf:about="&bravo-policy;AuthGranting">
var2 = &some;SWS-Project
<policy:to rdf:resource="&bravo-policy;var1"/>
<policy:deontic rdf:resource="&bravo-policy;AccessPermission"/>
<foaf:currentProject rdf:resource = ”&some;SWS-Project"/>
</policy:Granting>
BravoAir
Web service
<sws:AuthorizationPolicy rdf:about="&bravo-policy;AuthPolicy">
<constraint:SimpleConstraint
<policy:grants rdf:resource="&bravo-policy;AuthGranting"/>
rdf:about="&bravo-policy;SameProjectAsJohn"
</sws:AuthorizationPolicy>
constraint:subject="&bravo-policy;var1"
constraint:predicate="&foaf;currentProject"
<rdf:Description rdf:about="&bravo-service;BravoAir_ReservationAgent">
constraint:object="&bravo-policy;var2"/>
<sws:policyEnforced rdf:resource="&bravo-policy;AuthPolicy"/>
</rdf:Description>
Is the constraint true when
var2 = http://www.somewebsite.com/SWS-Project.rdf
var1 = http://www.cs.umbc.edu/~lkagal1/rei/examples/swssec/MaryProfile.rdf
54 of 59
Related Work
 WS-*
 SAML
 XACML : OASIS eXtensible Access Control Markup
Language
 EPAL : IBM Enterprise Privacy Authorization
Language
 Ponder
 KeyNote
 KAoS : Knowledgeable Agent-oriented System
55 of 59
Contributions of Rei
 Rei Methodology
 Domain knowledge represented in ontology languages
 Declarative policies
 Rei Policy Specification Language




Expressive and Extensible
Dynamic policy modification
Dynamic conflict resolution
Analysis specifications
 Rei Tools
 Used in a variety of applications within and outside
of UMBC
56 of 59
Future Work
 Enhancements




Formal semantics
Use of Courteous Logic
Static conflict detection
Provide explanation for failed decisions
 Example
 Policy : Only users who belong to the CS dept are permitted to use Y
 X is in the Bio dept
 Does X have the permission to perform Y ? Ans : No, Explanation :
Because X does not belong to the CS dept
 Applications
 Digital Rights Management
 HIPAA
 Content Filtering
57 of 59
Summary
 Declarative policies are useful for constraining
autonomous behavior in open, distributed systems
 The Rei policy language and associated tools have
provided a good base
 Semantic web languages (e.g., OWL) used,
grounding descriptions in sharable, semantically
rich, machine understandable ontologies
 We’re evaluating and exploring the utility of policies
through prototype applications
58 of 59
For more information
http://rei.umbc.edu/
59 of 59