Summary: The Ponder Policy Specification Language

N. Damianou, N. Dulay, E. Lupu, and M. Sloman. The ponder specification language. In Workshop on Policies for Distributed Systems and Networks (Policy2001), pages 29–31, Bristol, UK, Jan 2001. HP Labs.

N. Damianou, N. Dulay, E. Lupu, M. Sloman, and N. D. N. Dulay. Ponder: An object-oriented language for specifying security and management policies, 2000.

N. Damianou, N. Dulay, E. Lupu, and M. Sloman. Ponder: A language for specifying security and management policies for distributed systems. Research Report. London, UK, Imperial College, Octuber 2000.

These papers introduced Ponder an object-orientate security policy language that has the ability to represent authorization, obligations, refrain, and delegation policies. It can also represent time and state constrains. Ponder is a flexible language that allows reuse of policy specifications, and it provides scalability by allowing composite policy types.

Ponder right rules in the form of: first stating the type of the policy (auth+, auth-, delg+, …) then stating the name of the policy (so it might be reused later). Then stating the subject (user), the target (object e.g. resource), and action, finally a when (for time constrains) is optional.  Ponder pre-defined type of policies; it has auth+ (for granting authority), auth- (for revoking authority), deleg+ (to grant delegation), deleg- (to revoke delegation), refrain (to apply prohibition), and oblig (to present obligations). Ponder also provides ‘filter’ to be able to apply specific constrain (e.g. location, time, specific target, etc.) on a policy. Ponder also make use of roles (group of people with the same role e.g. system administrator) and groups (group of people with anything in common e.g. same floor, same branch, etc.) to make it easier to manage large complex organizations. Finally, Ponder uses meta-policies, which are policies about policies, to avoid conflicts and to control the sequence of the policies.

Ponder has pre-defined the policy types, and each of these types has its own structure, for example if you are using delegation policy you need to add the ‘grantee’ filed, which specify the element receiving the delegation. For obligation policies you need to add ‘do’ filed.  

Damianou et al. in these papers introduced Ponder; a security policy language that has the ability to represent authorizations, obligations, delegations, and prohibitions. Ponder is different that it pre-defined the type of policies to be used, and provided a structure for each of these policies. Although Ponder covered a wide range of policies, but this pre-definition method made it hard to add to Ponder and to widen the language capabilities. Ponder provides conflict resolution using meta-policies, it also makes use of groups and roles to provide scalability to large organization. Ponder also provide flexibility by reusing the policies. Ponder focuses on access control and obligations. It also has the ability to represent time and state constrains. The use of filters in Ponder made it easy to apply any type of constrains such as sequence constrains. As a drawback, Ponder is not an easy language to understand or to map to runtime object-model. 

Summary: A POLICY DESCRIPTION LANGUAGE

J. Lobo, R. Bhatia, and S. A. Naqvi. A policy description language. In AAAI/IAAI, pages 291–298, 1999.

This paper introduced Policy Description Language (PDL), which is a real-time specialized production rule language to define policies. It is a declarative language. PDL has three categories: 1- set of events (e.g. router is down). 2- set of actions (send alert email). 3- set of functions to evaluate the environment (disk is 95% full). Each of these categories has its own class of symbols. PDL take in consideration sequence constrains.

In PDL policies are described by a collection of propositions of two types; policy rule propositions and policy defined event propositions. Policy rule propositions are expressions of the form:

event causes action if condition.

Which mean if the event occurs in a situation where the condition is true then the action will be executed.

A policy defined event proposition is an expression of the form:

event triggers pde(Ml = T1,...,Mk = Tk) if condition

Which mean if the event occurs in a situation where the condition is true, an instance of the primitive event pde will occur in the immediately following epoch with the valuation of each Ti as the value assigned to each attribute Mi of pde.

The language is a generic language that can be used to describe any type of policies and not only security policies. but as the authors claim it is a first proposal that is expected to grow. PDL do not have the ability to solve conflict or even detect them. The language can not distinguish between rights and obligations.

Lobo et al. in this paper introduce a new language: Policy Description Language (PDL). The authors admit it is a first proposal and that it is expected to grow. PDL is a language that can be used to describe any type of policies and not only security policies. it describes policy as an actions that take place at a specific event if the condition was true. This type of formalization will allow representing obligations, and prohibitions, but it do not have the ability to solve conflict or even detect them. The language cannot distinguish between rights and obligations. If delegation looked at as an action then it would be passable to represent delegations using PDL.

Summary: A Policy Language for a Pervasive Computing Environment

L. Kagal, T. W. Finin, and A. Joshi. A policy language for a pervasive computing environment. In POLICY, pages 63–. IEEE Computer Society, 2003.

This paper introduced a new language called Rei, which is based on deontic logic, and able to represent rights, prohibitions, obligations and dispensations. It is also able to solve conflicts, and represent delegations by using action operators. It is also able to reprsent sequance obligations. Rei express policies as what an entity (user, agent, service, etc.) ‘can’/‘can not’ and ‘should’/‘should not’ do in terms of actions, services, and conversations.

Rei includes three types of constructs: (i) policy objects, which represent rights, obligations, prohibitions and dispensations, (ii) meta policies, which is used for conflict resolution, and (iii)speech acts, which is used to dynamically modify the system; delegate, revoke, cancel and request. In Rei policies can be individual, role, or group – based policy. Also can be any combination of the three. This mechanism is different from other policy languages, which include special constructs for role/group based rights/obligations.

“Rights are permissions that an entity has. The possession of a right allows the entity to perform the associated action”. “Prohibitions are negative authorizations implying that an entity cannot perform the action”. “Obligations are actions that an entity must perform and are usually triggered when a certain set of conditions are true”. “Dispensations are actions that an entity is no longer required to perform. They act as waivers for existing obligations”.

Rei represent any rule as followe: PolicyObject(Action, Conditions), and to associate a policy object with an entity, the has construct is used: has(Subject, PolicyObject). Actions can be represented as a tuple with the following parameters: action(ActionName, TargetObjects, Pre-Conditions, Effects).

Rei includes four action operators that allow various kinds of complex actions to be specified; sequence: seq(A,B) denotes that action B must only be performed after action A. non-deterministic: nond(A,B) denotes either A or B can be performed, but not both. Once: once(A) denotes that A can only be performed once. Repetition: repetition(A) denotes that A can be executed several times.

Rei includes specifications for four speech acts that affect the policy objects of the communicating entities: (i) delegation, (ii) request, (iii) cancel, and (iv) revocation. Delegation allows an entity to give a right to another entity or group of entities, which can be represented as delegateSpeechAct(Sender, Receiver, right(Action, Condition)), where ‘Sender’ is the person delegating the right, ‘Reciver’ is the person receiving the delegated right, and ‘action’ represent the action that is delegated. Request: there are two kinds of requests; a request for an action and a request for a right. It is represented as requestSpeechAct(Sender,Receiver,Action) à disagree. Revocation is the removal of a right and acts as a prohibition, and it is represented as: revokeSpeechAct(Sender, Receiver, right(Action, Condition)).  Cancel: An entity can cancel any request it has sent. It can be represented as: cancelSpeechAct(Sender, Receiver, right(Action, X)).

Rei permits complex conditions, and supports the following operators: AND, OR, and NOT. A complex condition made of two conditions associated with an AND, will be true only when both conditions are true. A complex condition made of two conditions associated with an OR, will be true only when one of the conditions is true. A complex condition consisting of not(ComplexCondition) is true when Complex- Condition is cannot be proved.

In Rei if the conflict between ‘Right’ and ‘prohibition’ was solved, it will solve every other conflict. Rei uses Meta policies, which are “policies about how policies themselves are interpreted and how conflicts are resolved at run-time”. Meta policies regulate conflicting policies in two ways; (i) priorities (overrides(A1, B1) means A1 is given priority over B1), and (ii) precedence relations, which can be either positive or negative (negative means prohibitions hold over rights and dispensations are stronger than obligations). It can be general over the whole policy (metaRule(Policy, positive/negative)), over a set of actions (metaRuleAction(ActionConditions, positive/negative)), or over a set of entities (metaRuleAgent(ConditionOnAgent, positive/negative)).

Delegation is an important aspect in security policies. Rei identifies two types of delegation, while-delegations and when-delegations. “A while-delegation forces all following delegators to satisfy its conditions in order to be true. Whereas a when-delegation requires the immediate delegator to satisfy its conditions only at the time of the delegation and not after”. The default delegation type is the while delegation.

The paper then presented an application example showing the usefulness of using Rei. After that it compared Rei with other available languages such as Ponder, Woo and Lam work, and Jajodia et al.’s work. It also showed how Rei made use of the work by Sloman and the work by Lupu.

Kagal et al in this paper introduced Rei; as security policy language, that is based on deontic logic. It has the ability to represent obligations, rights, prohibitions and dispensations. It introduces two methods that can be used to solve conflicts, but both of these methods solve conflicts at run time when detected. Rei do not offer a design time conflict resolution method, which is more practical. Rei has the ability to represent sequence requirements, and if an action is required once or more. It is also able to represent complex rules using AND, OR, and NOT parameters. An important aspect of Rei that it has the ability to represent delegations, and distinguish between two types of delegation, also it distinguish between the right to execute and the right to delegate. Finally it has the ability to represent revocation, requests, and cancelation. Rei has strong representation capabilities; it is able to cover most of the security requirements, but it is a complex language. It is very strong on delegation, but might need some enhancement in conflict resolution.