1 of 30 Declarative Policies for Describing Web Service Capabilities and Constraints Lalana Kagal Tim Finin Anupam Joshi University of Maryland Baltimore County UMBC Position Paper

2 of 30 Overview Current Problem : Describing constraints and capabilities of web services Our Solution : Describing behavior specification of entities using declarative policies –These specifications include the description of constraints and capabilities of web services

3 of 30 Behavior Specifications We propose the use of declarative policies to describe behavior of entities including agents, web services, and users Based on deontic concepts –Permission, obligation, power, privilege, claim, etc. Example –‘You MUST use HTTP Authentication when accessing this service’ describes how an entity that wants to use the service should behave –Can be modeled as an security policy (or constraint) of a service –An entity is 'permitted' to access the service if it meets the policy i.e. uses HTTP authentication Example –You SHOULD not use my contact details for marketing of services or products –This is a privacy policy on the website being accessed

4 of 30 Behavior Specifications Constraint of a web service –Permissions, obligations, prohibitions on the accessing entity Capability of a web service –Claims, privileges, permissions, power of the web service

5 of 30 Possible Enforcement 1.Add enforcement mechanism to a broker or MatchMaker Centralized 2.Every entity (agent, user, and web service) is responsible for their own behavior Peer-to-peer approach Each entity is capable of reasoning over its own policies and goals, and the policies of the entities it needs to interact with, in order to infer how it should behave 3.Obligation management Policy framework by forcing the entity to behave a certain way Reputation servers, penalties etc.

6 of 30 What are Policies ? We define policies as norms of behavior –Describe ideal 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, actor, target, and the general context – not just on identities Policy 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

7 of 30 Our Current Work Rei : A policy specification language Declarative policy specification language that –Is defined in OWL that uses a rule-based approach –Includes provisional permissions and models consequences of deviating from a policy –Includes an implementation of a policy engine and analysis tools –Includes meta policy specifications for conflict resolution –Includes an integrated approach to using speech acts for dynamic policy modification –Has been used to model different kinds of policies Security Privacy Team formation, collaboration and maintenance Conversation

8 of 30 A declarative policy specification language –Rules over permitted and obligated domain actions Represented in OWL-Lite + logical variables –Rule-based approach –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 –F-OWL reasoner Rei Policy Spec Language

9 of 30 Rei Policy Spec Language 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 ? …. Analysis tools –Verifying whether the given set of test cases is satisfied –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)

10 of 30 Some Rei Examples Management policies –X is permitted to send dispensations for obligations created by Y under certain situations, as long as X is 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 –You are permitted to use the laser printer as long as you refill the paper tray 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

11 of 30 Some Rei Examples Conversation policies –You are obliged to reply to all queries from anyone in your group –Scully is obliged to refuse queries from congressional democrats regarding the estimated cost of the Medicare Bill otherwise he will lose his job Policies for information flow in multi-agent systems –Only CIA members of rank R or higher can be team leaders for crisis of type C –No members from CIA and FBI can exchange information about topic X unless they are on a top priority team

12 of 30 Univ:advisedBy Univ:affiliatedToUniv:locatedIn XY Z P IS PERMITTED TO PERFORM ANY ACTION WHOSE TARGET IS P IF X Building Rei Policies rdf:type

13 of 30 Rei Specifications –Core specs Policy Granting Action Deontic Object Speech Act Meta Policy Constraint –Authoring specs Analysis

14 of 30 Deontic Objects Permission : Not obliged not to (~O~ ) –provision property Prohibition : Obliged Not To (O~) –sanction propery Obligation : Obliged To (O) –sanction propery Dispensation : Not Obliged To (~O) Common Properties : Actor, Action, Constraint {StartingConstraint, EndingConstraint} StartingConstraint subproperty of Constraint

15 of 30 Example Permission Example : Students are permitted to print on certain set of printers as long they replace the paper

16 of 30 Speech Acts –Used to dynamically modify existing policies –Delegation, Revocation, Request, Cancel –Properties : Sender, Receiver, Content (Deontic object/Action), Conditions –Speech acts are valid only if the senders have the appropriate permissions For example, Marty has the permission to delegate the permission to enter the site of emergency supplies to all members of agency A –It is also possible to modify permissions to perform speech acts For example, John revokes Marty’s permission to delegate the permission to enter the site of emergency supplies to all members of agency A

17 of 30 Example Delegation Example : Delegation from ’Marty' to all students of the 'CSDept' giving them the permission to perform actions of type ’LaserPrinting’

18 of 30 Permission To Delegate Example : Marty has the permission to perform a delegation speech act to graduate students wrt the LaserPrinting actions

19 of 30 Analysis Analysis specifications to describe use-case and whatif analysis Analysis tools that can be run by policy engineers via the Java API 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 (known as regression testing in Software Engineering) –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 ?

20 of 30 Implementation Details XSB –Flora : F-logic over XSB F-OWL : is a reasoner for RDF, OWL Java wrapper Rei engine –Can be used by the policy enforcement component within a policy-based framework to decide permissions and obligations of entities –Can also be used for analysis by policy administrators XSB FLORA YAJXB JAVA API FOWL Image adapted from Mohinder Chopra REI REI INTERFACE POLICY ENGINEER/APPL

21 of … Applications – past, present & future 1.Coordinating access in supply chain management system (EECOMS - IBM lead) 2.Authorization policies in a pervasive computing environment (UMBC) 3.Policies for team formation, collaboration, information flow in multi-agent systems (Genoa II (Topsail) - Global Infotek, UMBC) 4.Policies for semantic web services (UMBC, SRI, CMU) 5.Privacy and trust on the Internet (UMBC) 6.Enforcing domain policies on handhelds in pervasive computing environments (UMBC, NIST) 7.Privacy in a pervasive computing environment (UMBC) 8.Task Computing (Fujitsu Labs, UMBC) 9.Dynamic Policy Management (Arizona State Univ)

22 of 30 Declarative Related Work Non SW Procedural KAoS Rei PDL ASL PolicyMaker KeyNote Delegation Logic Ponder SPKI RBAC XACML EPAL SAML WS* XML SW

23 of 30 Case Study A Web service, WS, wishes to stipulate that clients are required support a reliable messaging protocol and encrypt a specific header with WS-Security using a X.509 or user name security token in order to send an acceptable request message –WS defines this requirement as an Rei access control policy over a set of conditions. –Only when the conditions are satisfied, will the requesting client be 'permitted' to access the service. –Information about what it means to be a 'reliable messaging protocol' or 'encrypt specific header with WS-Security' will be expressed as domain ontologies described in RDF or OWL

24 of 30 Case Study The service has a P3P policy associated with its operations –This policy can either be expressed in P3P or can be described as a privacy policy using the P3P RDF ontology. Let us assume a client, C, has a policy as well, a Rei privacy policy specified over P3P RDF specifications and user context –E.g. You SHOULD not use my contact details for marketing of services or products

25 of 30 Case Study : How it Works Access request +privacy policy + privileges + permissions BravoAir Web service Client P3P policy + (access control policy) + privileges + permissions Broker + Rei engine

26 of 30 Case Study : How it Works Client, C, locates Web service, WS, and contacts it C sends WS its privacy policy and a description of its privileges and permissions WS verifies that the C has the permission or privilege to support a reliable messaging protocol and encrypt a specific header with WS-Security using a X.509 or user name security token by checking C's privileges and permissions WS sends C its access control policy and P3P policy C verifies that WS meets its privacy requirements by checking the P3P policy against its own privacy requirements The Rei policy engine currently supports most of the policy compliance testing used in this usecase A problem with this approach is that each party has to disclose its policy. Another approach is to use a trusted third part for checking policy compliance or use a negotiation protocol, where every entity reveals a little more during every message exchange

27 of 30 Open Issues Can we find the right balance between having a policy language or framework that is –powerful and expressive enough to handle a wide range of uses, (ii) efficient enough for real applications –reasonably easy for real developers to learn and use. Should the paradigm be dominated by –rule based approach (e.g., using RuleML or SWRL) –an ontology approach (e.g., using OWL) –a hybrid of the two –something else altogether. What are appropriate mechanisms for enforcement? How can we make them easy for developers to integrate into their systems?

28 of 30 Open Issues How do trust and reputation relate to policies ? Policy specification What methodologies, metrics and tools can be developed to support "policy engineering” Should justification be provided for policy decisions? If yes, how and in what format ? If the policies are private, what kind of justification is possible ?

29 of 30 Summary Declarative policies based on deontic concepts are useful for describing behavior Describing capabilities and constraints of web services is a subclass of describing behavior Semantic web languages used, grounding descriptions in sharable, semantically rich, machine understandable ontologies We have evaluated the utility of Rei policies through prototype applications within and outside UMBC –Semantic web services –Multi-agent systems –Pervasive Computing –Supply Chain Management Systems

30 of 30 For more information