A REVIEW OF TRUST MANAGEMENT,

SECURITY AND PRIVACY POLICY LANGUAGES

Juri Luca De Coi and Daniel Olmedilla

L3S Research Center, University of Hannover, Appelstr. 9a, D-30167 Hannover, Germany

Keywords:

Policy languages, comparison, trust management, privacy, security, review.

Abstract:

Policies are a well-known approach to protecting security and privacy of users as well as for ﬂexible trust

management in distributed environments. In the last years a number of policy languages were proposed to

address different application scenarios. In order to help both developers and users in choosing the language

best suiting her needs, policy language comparisons were proposed in the literature. Nevertheless available

comparisons address only a small number of languages, are either out-of-date or too narrow in order to provide

a broader picture of the research ﬁeld. In this paper we consider twelve relevant policy languages and compare

them on the strength of ten criteria which should be taken into account in designing every policy language.

Some criteria are already known in the literature, others are introduced in our work for the ﬁrst time.

By comparing the choices designers made in addressing such criteria, useful conclusions can be drawn about

strong points and weaknesses of each policy language.

1 INTRODUCTION

Security management is a foremost issue in large scale

networks like the World Wide Web. In such a sce-

nario, traditional assumptions for enforcing access

control regulations do not hold anymore. In partic-

ular identity-based access control mechanisms have

proved to be ineffective, since in decentralized and

multicentric environments, the requester and the ser-

vice provider are often unknown to each other.

Policies are a well-known approach to protecting

security and privacy of users in the context of the

Semantic Web: policies specify who is allowed to

perform which action on which object depending on

properties of the requester and of the object as well

as parameters of the action and environmental factors

(e.g., time).

The potential policies have proved to own is not

fully exploited yet, since nowadays their usage is

mainly restricted to speciﬁc application areas. In the

last years many policy languages were proposed, tar-

geting different application scenarios and provided

with different features and expressiveness: scope and

properties of available languages have to be known to

the user in order to help her in choosing the one most

suitable to her needs.

In an attempt to help with these and other prob-

lems, comparisons among policy languages have been

provided in the literature, anyway existing compar-

isons either do not consider a relevant number of avail-

able solutions or are mainly focused on the application

scenarios the authors worked with, moreover policy-

based security management is a rapidly evolving ﬁeld

and most of this comparison work is now out-of-date.

Currently a broad and up-to-date overview cover-

ing most of the relevant available policy languages is

lacking; in this paper we intend to ﬁll this gap by pro-

viding an extensive comparison covering twelve pol-

icy languages. Such a comparison will be carried out

on the strength of eleven criteria, partly already known

in the literature and partly introduced in our work for

the ﬁrst time.

This paper is organized as follows: in section 2 re-

lated work is accounted for. Sections 3 and 4 respec-

tively introduce the languages which will be compared

in the rest of the paper and the criteria according to

which the comparison will be carried out. The actual

comparison takes place in section 5, whereas sections

6 and 7 respectively present overall results and con-

cludes the paper.

2 RELATED WORK

The paper of Seamons et al. (Seamons et al., 2002)

is the basis of our work: some of the insights they

suggested have proved to be still valuable right now

and as such they are addressed in our work as well.

Nevertheless in over three years the research ﬁeld has

considerably changed and nowadays many aspects of

483

Luca De Coi J. and Olmedilla D. (2008).

A REVIEW OF TRUST MANAGEMENT, SECURITY AND PRIVACY POLICY LANGUAGES.

In Proceedings of the International Conference on Security and Cryptography, pages 483-490

DOI: 10.5220/0001921004830490

 SciTePress

(Seamons et al., 2002) are out of date.

The pioneer paper of Seamons et al. paved the way

to future research on policy language comparisonslike

Tonti et al. (Tonti et al., 2003), Anderson (Ander-

son, 2006) and Duma et al. (Duma et al., 2007): al-

though (Tonti et al., 2003) actually presents a compar-

ison of two ontology-based languages (namely KAoS

and Rei) with the object-orientedlanguage Ponder, the

work is rather an argument for ontology-based sys-

tems, since it clearly shows the advantages of ontolo-

gies.

Because of the impressive amount of details it pro-

vides, (Anderson, 2006) restricts the comparison to

only two (privacy) policy languages, namely EPAL

and XACML, therefore a comprehensive overview of

the research ﬁeld is not provided.

Finally (Duma et al., 2007) provides a comparison

speciﬁcally targeted to givinginsights and suggestions

to policy writers (designers): therefore the criteria, ac-

cording to which the comparison is carried out, are

mainly practical ones and scenario-oriented, whereas

more abstract issues are considered out of scope and

hence not addressed.

3 PRESENTATION OF THE

CONSIDERED POLICY

LANGUAGES

To date a bunch of policy languages have been de-

veloped and are currently available: we have cho-

sen those which at present seem to be the most pop-

ular ones, namely Cassandra (Becker and Sewell,

2004), EPAL (Ashley et al., 2003), KAoS (Uszok

et al., 2003), PeerTrust (Gavriloaie et al., 2004), Pon-

der (Damianou et al., 2001), Protune (Bonatti et al.,

2006), PSPL (Bonatti and Samarati, 2000), Rei (Ka-

gal et al., 2003), RT (Li and Mitchell, 2003), TPL

(Herzberg et al., 2000), WSPL (Anderson, 2004) and

XACML (Lorch et al., 2003).

The number and variety of policy languages pro-

posed so far is justiﬁed by the different requirements

they had to accomplish Ponder was meant to help lo-

cal security policy speciﬁcation, therefore typical ad-

dressed application scenarios include registration of

users or logging and audit events. WSPL’s name it-

self (namely Web Services Policy Language) suggests

its goal: supporting description and control of vari-

ous aspects and features of a web service. Web ser-

vices are addressed by KAoS too, as well as general-

purpose grid computing, although it was originally

oriented to software agent applications. Rei’s design

was primarily concerned with support to pervasive

computing applications (i.e. those in which people

and devices are mobile and use wireless networking

technologies to discover and access services and de-

vices). EPAL (Enterprise Privacy Authorization Lan-

guage) was proposed by IBM in order to support en-

terprise privacy policies. Some years before IBM had

already introduced the pioneer role-based policy lan-

guage TPL (Trust Policy Language), which paved the

way to other role-based policy languages like Cas-

sandra and RT (Role-based Trust-management frame-

work), both of which aimed to address access control

and authorization problems which arise in large-scale

decentralized systems The main goal of PSPL (Port-

folio and Service Protection Language) was providing

a uniform formal framework for regulating service ac-

cess and information disclosure in an open, distributed

network system like the web. PeerTrust is a simple

yet powerful language for trust negotiation on the Se-

mantic Web based on a distributed query evaluation.

Trust negotiation is addressed by Protune too, which

supports a broad notion of “policy” and does not re-

quire shared knowledge besides evidences and a com-

mon vocabulary. Finally XACML (eXtensible Access

Control Markup Language) was meant to be a stan-

dard general purpose access control policy language,

ideally suitable to the needs of most authorization sys-

tems.

Given the multiplicity of available languages and

the sometimes very speciﬁc contexts they ﬁt into, one

may argue that a meaningful comparison among them

is impossible or, at least, meaningless. We claim

that such a comparison is not only possible but even

worth: to this aim we identiﬁed eleven criteria which

should be taken into account in designing every pol-

icy language. By comparing the choices designers

made in addressing such criteria, useful conclusions

can be drawn about strong points and weaknesses of

each policy language. More important yet, by outlin-

ing advantages and drawbacks of each language, our

analysis will hopefully help a user in choosing the one

which mostly suits her needs.

4 PRESENTATION OF THE

CONSIDERED CRITERIA

We acknowledge the remark made by (Duma et al.,

2007), according to which a comparison among pol-

icy languages on the basis of the criteria presented

in (Seamons et al., 2002) is only partially satisfac-

tory for a designer, since general features do not help

in understanding which kind of policies can be prac-

tically expressed with the constructs available in a

language. Therefore in our comparison we selected

a good deal of criteria having a concrete relevance:

on the other hand, since we did not want to come

SECRYPT 2008 - International Conference on Security and Cryptography

484

short on theoretical issues, we selected four additional

criteria, basically taken from (Seamons et al., 2002)

and somehow reworked and updated them. We called

these more theoretical criteria core policy properties

whereas more practical issues have been grouped un-

der the common label contextual properties.

4.1 Core Policy Properties

Well-deﬁned Semantics. According to (Seamons

et al., 2002) we consider a policy language’s seman-

tics to be well-deﬁned if the meaning of a policy writ-

ten in that language is independent of the particular

implementation of the language.

Monotonicity. In the sense of logic a system is

monotonic if the set of conclusions which can be

drawn from the current knowledge base does not de-

crease by adding new information to the knowledge

base. In the sense of (Seamons et al., 2002) a pol-

icy language is considered to be monotonic if an ac-

complished request would also be accomplished if ac-

companied by additional disclosure of information by

the peers: in other words, disclosure of additional ev-

idences and policies should only result in the granting

of additional privileges. Policy languages may be not

monotonic in the sense of logic but still be monotonic

in the sense of (Seamons et al., 2002), like Protune.

Condition Expressiveness. A policy language must

allow to specify under which conditions the request of

the user should be accomplished. Policy languages

differ in the expressiveness of such conditions: some

languages allow to set constraints on properties of the

requester, but not on parameters of the requested ac-

tion, moreover constraints on environmental factors

(e.g., time) are not always supported.

Underlying Formalism. A good deal of policy lan-

guages base on some well-known formalism: Protune

and PSPL base on Logic programming, whereas Cas-

sandra, Peer-Trust and RT on a subset of it (namely

Constrained DATALOG) and KAoS on Description

logics. Knowledge about the formalism a language

bases upon can be useful in order to understand some

basic features of the language itself.

4.2 Contextual Properties

Action Execution. During the evaluation of a pol-

icy some actions may have to be performed: one may

want to retrieve the current system time, to send a

query to a database or to record some information in

a log ﬁle. It is worth noticing that this criterion eval-

uates whether a language allows the policy writer to

specify actions within a policy: during the evaluation

of a policythe engine may carry out non-trivialactions

on its own (e.g., both RT and TPL engines provide

automatic resolution of credential chains) but such ac-

tions are not considered in our investigation

Delegation. Delegation is often used in access con-

trol systems to cater for temporary transfer of access

rights to agents acting on behalf of other ones (e.g.,

passing write rights to a printer spooler in order to

print a ﬁle). The right of delegating is a right as well

and as such can be delegated, too. Some languages

provide a means for cascaded delegations up to a cer-

tain length, whereas others allow unbounded delega-

tion chains. In order to support delegation many lan-

guages provide a speciﬁc built-in construct, whereas

others (e.g., Cassandra and Protune) exploit more ﬁne-

grained features of the language in order to simulate

high-level constructs.

Type of Evaluation. In languages supporting nego-

tiations, policy evaluation is distributed: at each step

of the negotiation a peer sends the other one infor-

mation which (possibly) lets the negotiation advance.

Each peer can (unsuccessfully) terminate the negotia-

tion, moreover the peer who received the original re-

quest may decide to accomplish it, thereby success-

fully terminating the negotiation. Evaluation is sup-

posed to be performed locally by languages which do

not support negotiations, although some of them may

allow to split a policy on several nodes and provide

some means for collecting all fragments before (or

during) the evaluation. Finally some languages like

Ponder neither support distributed evaluation nor dis-

tributed policies

Evidences. During the evaluation of authentication

policies, it may be needed for the requester to pro-

vide some signed statements (credentials) issued by

a trusted entity and asserting some properties about

the requester itself. PeerTrust, Protune and PSPL pro-

vide another kind of evidence, namely declarations

which are non-signed statements about properties of

the holder (e.g., credit-card numbers)

Negotiation Support. (Anderson, 2004) adopts a

broad notion of “negotiation”, namely a negotiation

is supposed to happen between two peers whenever

(i) both peers are allowed to deﬁne a policy and (ii)

both policies are taken into account when processing

a request. In this paper we adopt a narrower deﬁni-

tion of negotiation by adding a third prerequisite stat-

ing that (iii) the evaluation of the request must be dis-

tributed, i.e., both peers must locally evaluate the re-

quest and either decide to terminate the negotiation

or send a partial result to the other peer who will go

on with the evaluation. Whether the evaluation is lo-

cal or distributed may be considered an implementa-

tion issue, as long as policies are freely disclosable.

Distributed evaluation is required under a conceptual

point of view as soon as the need for keeping policies

A REVIEW OF TRUST MANAGEMENT, SECURITY AND PRIVACY POLICY LANGUAGES

485

private arises: indeed if policies were not private, sim-

ply merging the peers’ policies would reveal possible

compatibilities between them

Policy Engine Decision. The result of the evalua-

tion of a policy must be notiﬁed to the requester. The

result sent back by the policy engine may carry in-

formation to different extents: in the easiest case a

boolean answer may be sent (allowed vs. denied).

Some languages support error messages, whereas Pro-

tune is the only language providing enough informa-

tive content to let the user understand how the re-

sult was computed (and thereby why the query suc-

ceeded/failed)

Extensibility. Since experience showsthat each sys-

tem needs to be updated and extended with new fea-

tures, a good programming practice requires to keep

things as general as possible in order to support future

extensions. Almost every language provides some

support to extensibility. RT may be regarded as an ex-

ception since, as pointed out by (Becker and Sewell,

2004), the need for more advanced features was han-

dled by releasing a new ﬂavor of the language (avail-

able RT ﬂavors can be obtained by combining RT

and RT

on the one hand with RT

and/or RT

the other one). In the following we will provide a de-

scription of the mechanisms languages adopt in order

to support extensibility

5 COMPARISON

In this section the considered policy languages will be

compared according to the criteria outlined in section

4. The overall results of the comparison are summa-

rized in Table 5

Well-deﬁned Semantics. A policy language’s se-

mantics is well-deﬁned if the meaning of a policy writ-

ten in that language is independent of the particular

implementation of the language. We assume policy

languages based on Logic programming or Descrip-

tion logics to have well-deﬁned semantics: the for-

malisms underlying the considered policy languages

will be accounted for in the following. So far we

restrict ourselves to list the languages provided with

a well-deﬁned semantics, namely, Cassandra, EPAL,

KAoS, PeerTrust, Protune, PSPL, Rei and RT

Monotonicity. In the sense of (Seamons et al.,

2002) a policy language is considered to be mono-

tonic if disclosure of additional evidences and policies

only results in granting additional privileges, therefore

the concept of “monotonicity” does not apply to lan-

guages which do not provide support for credentials,

Table 5 does not contain criterion “condition expres-

siveness” since such criterion is not well-suited to be repre-

sented in a table.

namely EPAL, Ponder, WSPL and XACML. All other

languages are monotonic, with the exception of TPL,

which explicitly chose to support negative certiﬁcates,

stating that a user can be assigned a role R if there

exists no credential of some type claiming something

about it. The authors of TPL acknowledge that it is al-

most impossible proving that there does not exist such

a credential somewhere, therefore they interpret their

statement in a restrictive way, i.e., they assume that

such a credential does not exist if it is not present in

the local repository. Despite this restrictive deﬁnition

the language is not monotonic since, as soon as such a

credential is released and stored in the repository, con-

sequences which could be previously drawn cannot be

drawn anymore

Condition Expressiveness. A role-based policy

language maps requesters to roles, the assigned role

is afterwards exploited in order (not) to authorize the

requester to execute some actions. The mapping to

a role may in principle be performed according to

the identity or other properties of the requester (to be

stated by some evidence) and eventually environmen-

tal factors (e.g., current time). Cassandra (equipped

with a suitable constraint domain) supports both sce-

narios. Environmental factors are not taken into ac-

count by TPL, where the mapping to a role is just per-

formed according to the properties of the requester;

such properties can be combined by using boolean

operators, moreover a set of built-in operators (e.g.,

greater than, equal to) is provided in order to set con-

straints on their values. Environmental factors are not

taken into account by RT

either, where role member-

ship is identity-based, meaning that a role must ex-

plicitly list its members; nevertheless since (i) roles

are allowed to express set of entities having a cer-

tain property and (ii) conjunctions and disjunctions

can be applied to existing roles in order to create new

ones, then role membership is ﬁnally based on prop-

erties of the requester. RT

goes a step beyond and, by

adding the notion of parametrized role, allows to set

constraints not only on properties of the requester but

even on the ones of the object, the requested action

should be performed upon. A non role-based policy

language does not split the authentication process in

two different steps but directly provides an answer to

the problem whether the requester should be allowed

to execute some action. In this case the authorization

decision can be made in principle not only depend-

ing on properties of the requester or the environment,

but also according to the ones of the object the action

would be performed upon as well as parameters of the

action itself. EPAL introduces the further notion of

“purpose” for which a request was sent and allows to

set conditions on it. Some non role-based languages

make a distinction between conditions which must be

SECRYPT 2008 - International Conference on Security and Cryptography

486

fulﬁlled in order for the request to be taken into con-

sideration (which we call prerequisites, according to

the terminology introduced by (Bonatti and Samarati,

2000)) and conditions which must be fulﬁlled in or-

der for the request to be satisﬁed (requisites); not al-

ways both kinds of conditions have the same expres-

siveness. Let start checking whether and to which ex-

tent the non role-based policy languages we consider

support prerequisites: WSPL and XACML allow only

to use a simple set of criteria to determine a policy’s

applicability to a request, whereas Ponder provides a

complete solution which allows to set prerequisites in-

volving properties of requester, object, environment

and parameters of the action. Prerequisites can be set

in EPAL and PSPL as well. With the exception of

Ponder, which allows restrictions on the environment

just for delegation policies, each other language sup-

ports requisites (Rei is even redundant in this respect):

KAoS allows to set constraints on properties of the

requester and the environment, Rei also on action pa-

rameters and Protune, PSPL, WSPL and XACML also

on properties of the object. EPAL supports conditions

on the purpose for which a request was sent but not

on environmental factors. Attributes must be typed in

EPAL, WSPL, XACML and typing can be considered

a constraint on the values the attribute can assume,

anyway the deﬁnition of the semantics of such at-

tributes is outside WSPL’s scope. Finally, in PeerTrust

conditions can be expressed by setting guards on poli-

cies: each policy consists of a guard and a body, the

body is not evaluated until the guard is satisﬁed

Underlying Formalism. The most part of lan-

guages provided with a well-deﬁned semantics rely on

some kind of Logic programming or Description log-

ics. Logic programming is the semantic foundation

of Protune and PSPL, whereas a subset of it, namely

Constraint DATALOG, is the basis for Cassandra,

PeerTrust and RT. KAoS relies on Description logics,

whereas Rei combines features of Description logics

(ontologies are used in order to deﬁne domain classes

and properties associated with the classes), Logic pro-

gramming (Rei policies are actually particular Logic

programs) and Deontic logic (in order to express con-

cepts like rights, prohibitions, obligations and dispen-

sations). EPAL exploits Predicate logic without quan-

tiﬁers. Finally, no formalisms underly Ponder (which

only bases on the Object-oriented paradigm), TPL,

WSPL and XACML

Action Execution. Ponder allows to access system

properties (e.g., time) from within a policy, moreover

it supports obligation policies, asserting which actions

should be executed if some event happens. XACML

allows to specify actions within a policy; these ac-

tions are collected during the policy evaluation and

executed before sending a response back to the re-

quester. A similar mechanism is provided by EPAL

and of course by WSPL, which is indeed a speciﬁc

proﬁle of XACML. The only actions which the policy

writer may specify in PeerTrust and PSPL are related

to the sending of evidences, whereas Protune supports

whatever kind of actions, not necessarily side-effect

free, as long as a basic assumption holds, namely that

action results do not interfere with each other. Cas-

sandra (equipped with a suitable constraint domain)

allows to call side-effect free functions (e.g., to access

the current time). Finally, KAoS, Rei, RT and TPL do

not support execution of actions

Delegation. Ponder deﬁnes a speciﬁc kind of poli-

cies in order to deal with delegation: the ﬁeld

valid

allows positive delegation policies to specify con-

straints (e.g., time restrictions) to limit the validity of

the delegated access rights. Rei allows not only to

deﬁne policy delegating rights but even policy dele-

gating the right to delegate (some other right). Del-

egation is supported by RT

(“D” stands indeed for

“delegation”). Ponder delegation chains have length

1, whereas in RT delegation chains always have un-

bounded length. Cassandra and Protune provide a

more ﬂexible mechanism which allows to explicitly

set the desired length of a delegation chain (as well

as other properties of the delegation). Delegation (of

authority) can be expressed in PeerTrust by exploit-

ing operator “@”. Finally, EPAL, KAoS, PSPL, TPL,

WSPL and XACML do not support delegation

Type of Evaluation. The most part of the consid-

ered languages require that all policies to be evaluated

are collected in some place before starting the evalua-

tion, which is hence performed locally: this is the way

EPAL, KAoS, Ponder, RT and TPL work. Other lan-

guages, namely Cassandra, Rei, WSPL and XACML,

perform policy evaluation locally, nevertheless they

provide some facility in order to collect policies (or

policy fragments) which are spread over the net. Poli-

cies can be collected into a single place if they are

freely disclosable, therefore the languages mentioned

so far do not address the possibility that policies them-

selves may have to be kept private. Protection of sen-

sitive policies can be obtained only by providing sup-

port to distributed policy evaluation, like the one car-

ried out by PeerTrust, Protune or PSPL

Evidences. The result of a policy’s evaluation may

depend on the identities or other properties of the peer

who requested for its evaluation: a means needs hence

to be provided in order for the peers to communicate

such properties to each other. Such information is

usually sent in the form of digital certiﬁcates signed

by trusted entities (certiﬁcation authorities) and called

credentials. Credentials are a key element in Cassan-

dra, RT and TPL, whereas they are unnecessary in

Ponder, whose policies are concerned with limiting

A REVIEW OF TRUST MANAGEMENT, SECURITY AND PRIVACY POLICY LANGUAGES

487

the activity of users who have already been success-

fully authenticated. The authors of PSPL were the

ﬁrst ones advocating for the need of exchanging non-

signed statements (e.g., credit card numbers), which

they called declarations; declarations are supported

by PeerTrust and Protune as well. Finally, EPAL,

KAoS, Rei, WSPL and XACML do not support ev-

idences

Negotiation Support. As stated above, we use a

narrower deﬁnition of negotiation than the one pro-

vided in (Anderson, 2004), into which WSPL does not

ﬁt, therefore only pretty few languages support nego-

tiation in the sense we speciﬁed above, namely Cas-

sandra, PeerTrust, Protune and PSPL

Policy Engine Decision. The evaluation of a pol-

icy should end up with a result to be sent back to

the requester. In the easiest case such result is a

boolean stating whether the request was (not) accepted

(and thereby accomplished): KAoS, PeerTrust, Pon-

der, PSPL, RT and TPL conform to this pattern. Be-

sides

permit

and

deny

WSPL and XACML provide

two other result values to cater for particular situa-

tions:

not applicable

is returned whenever no ap-

plicable policies or rules could be found, whereas

indeterminate

accounts for some error which oc-

curred during the processing; in the latter case op-

tional information is available to explain the error. A

boolean value, stating whether the request was (not)

fulﬁlled, does not make sense in the case of an obliga-

tion policy, which simply describes the actions which

must be executed as soon as an event happens, there-

fore besides the so-called rulings

allow

and

deny

EPAL deﬁnes a third value (

don’t care

) to be re-

turned by obligation policies; one of the elements an

EPAL policy consists of is a global condition which is

checked at the very beginning of the policy evaluation:

not fulﬁlling such a condition is considered an error

and a corresponding error message (

policy error

)

is returned; a further message (

scope error

) is re-

turned in case no applicable policies were found. Cas-

sandra’s request format contains (among others) a set

of constraints c belonging to some constraint domain;

the response consists of a subset c

′

of c which satis-

ﬁes the policy; in case c

′

= c (resp. c

′

is the empty

set)

true

(resp.

false

) is returned. Protune allows

for more advanced explanation capabilities: not only

is it possible to ask why (part of) a request was (not)

fulﬁlled (

Why

and

Why-not

queries respectively), but

the requester is even allowed to ask since the be-

ginning which steps she has to perform in order for

her request to be accomplished (

How-to

and

What-if

queries). A rudimentary form of

What-if

queries

is supported also by Rei obligation policies: the re-

quester can decide whether to complete the obliga-

tion by comparing the effects of meeting the obliga-

tion (

MetEffects

) and the effects of not meeting the

obligation (

NotMetEffects

)

Extensibility. Extensibility is a fuzzy concept: al-

most all languages provide some extension points to

let the user adapt the language to her current needs.

Extensibility is described as one of the criteria taken

into account in designing Ponder: in order to pro-

vide smoothly support to new types of policies that

may arise in the future, inheritance was considered a

suitable solution and Ponder itself was therefore im-

plemented as an object-oriented language. XACML’s

support to extensibility is two-fold: (i) on the one

hand new datatypes, as well as functions for dealing

with them, may be deﬁned in addition to the ones

already provided by XACML (ii) as we mentioned

above, XACML policies can consist of any number of

distributed rules; XACML already provides a number

of combining algorithms which deﬁne how to take re-

sults from multiple policies and derive a single result,

nevertheless a standard extension mechanism is avail-

able to deﬁne new algorithms. Using non-standard

user-deﬁned datatypes would lead to wasting one of

the strong points of WSPL, namely the standard al-

gorithm for merging two policies, resulting in a sin-

gle policy that satisﬁes the requirements of both (as-

suming that such a policy exists), since there can be

no standard algorithm for merging policies exploiting

user-deﬁned attributes. Ontologies are the means to

cater for extensibility in KAoS and Rei: both KAoS

and Rei deﬁne basic built-in ontologies, which are

supposed to be further extended for a given applica-

tion. Extensibility was the main issue taken into ac-

count in the design of Cassandra: its authors realized

that standard policy idioms (e.g., role hierarchy or role

delegation) occur in real-world policies in many sub-

tle variants: instead of embedding such variants in an

ad hoc way, they decided to deﬁne a policy language

able to express this variety of features smoothly; in or-

der to achieve this goal, the key element is the notion

of constraint domain, an independent module which is

plugged into the policy evaluation engine in order to

adjust the expressiveness of the language. A standard

interface to external packages is the means provided

by Protune in order to support extensibility: function-

alities of a component implementing such interface

can be called from within a Protune policy. Finally,

PeerTrust, PSPL, RT and TPL do not provide exten-

sion mechanisms

6 DISCUSSION

In this section we review the comparison performed in

section 5 and provide some general comments.

SECRYPT 2008 - International Conference on Security and Cryptography

488

Table 1: Policy language comparison (“–” = not applicable).

Cassandra EPAL KAoS PeerTrust Ponder Protune PSPL Rei RT TPL WSPL XACML

Well-deﬁned

semantics

Yes Yes Yes Yes No Yes Yes Yes Yes No No No

Monotonicity Yes – Yes Yes – Yes Yes Yes Yes No – –

Underlying

formalism

Constraint

DATALOG

Predicate

logic with-

out quanti-

ﬁers

Description

logics

Constraint

DATALOG

Object-

oriented

paradigm

Logic pro-

gramming

Logic pro-

gramming

Deontic

logic, Logic

program-

ming,

Description

logics

Constraint

DATALOG

– – –

Action execu-

tion

Yes (side-

effect free)

Yes No Yes (only

sending

evidences)

Yes (access

to system

properties)

Yes Yes (only

sending

evidences)

No No No Yes Yes

Delegation Yes No No Yes Yes Yes No Yes Yes (RT

) No No No

Type of evalua-

tion

Distributed

policies,

Local

evaluation

Local Local Distributed Local Distributed Distributed Distributed

policies,

Local

evaluation

Local Local Distributed

policies,

Local

evaluation

Distributed

policies,

Local

evaluation

Evidences Credentials No No Credentials,

Declara-

tions

– Credentials,

Declara-

tions

Credentials,

Declara-

tions

– Credentials Credentials No No

Negotiation Yes No No Yes No Yes Yes No No Yes No (policy

matching

supported)

Result format A/D and a

set of con-

straints

A/D,

scope

error

policy

error

A/D A/D A/D Explana-

tions

A/D A/D

A/D A/D A/D,

not

applicable

indetermi-

nate

A/D,

not

applicable

indetermi-

nate

Extensibility Yes Yes Yes Yes Yes Yes No Yes No No No Yes

For obligation policies a rough version of “What-if” query is available.

A REVIEW OF TRUST MANAGEMENT, SECURITY AND PRIVACY POLICY LANGUAGES

489

By carrying out the task of comparing a consid-

erable amount of policy languages, we came to be-

lieve that they may be classiﬁed in two big groups

collecting, so to say, standard-oriented and research-

oriented languages respectively. EPAL, WSPL and

XACML can be considered standard-oriented lan-

guages since they provide a well-deﬁned but restricted

set of features: standard-oriented languages are hence

a good choice for users who do not need advanced

features but for whom compatibility with standards is

a foremost issue. Ponder, RT and TPL are somehow

placed in between: on the one hand Ponder provides a

complete authorization solution, which however takes

place after a previously overcome authentication step,

therefore Ponder cannot be applied to contexts (like

pervasive environments) were users cannot be accu-

rately identiﬁed; on the other hand RT and TPL do

not provide a complete authorization solution, since

they can only map requesters to roles and need to rely

on some external component to perform the actual

authentication. Finally research-oriented languages

strive toward generality and extensibility and provide

a number of more advanced features in comparison

with standard-oriented languages (e.g., conﬂict har-

monization in KAoS and Rei, negotiations in Cas-

sandra, PeerTrust and PSPL or explanations in Pro-

tune); they should be hence the preferred choice for

users who do not mind about standardization issues

but require the advanced functionalities that research-

oriented languages provide.

7 CONCLUSIONS

Policies are a well-known approach to protecting se-

curity and privacy of users as well as for ﬂexible trust

management in distributed environments. In the last

years a number of policy languages were proposed to

address different application scenarios. In order to

help both developers and users in choosing the lan-

guage best suiting her needs, policy language com-

parisons were proposed in the literature. Nevertheless

available comparisons address only a small number of

languages, are either out-of-date or too narrow in or-

der to provide a broader picture of the research ﬁeld.

In this paper we considered twelve relevantpolicy lan-

guages and compared them on the strength of eleven

criteria which should be taken into account in design-

ing every policy language.

By comparing the choices designers made in ad-

dressing such criteria, useful conclusions can be

drawn about strong points and weaknesses of each

policy language.

REFERENCES

Anderson, A. H. (2004). An introduction to the web ser-

vices policy language (wspl). In POLICY 2004. IEEE

Computer Society.

Anderson, A. H. (2006). A comparison of two privacy pol-

icy languages: Epal and xacml. In SWS 2004. ACM

Press.

Ashley, P., Hada, S., Karjoth, G., Powers, C., and Schunter,

M. (2003). Enterprise privacy authorization language

(epal 1.2). Technical report.

Becker, M. Y. and Sewell, P. (2004). Cassandra: Distributed

access control policies with tunable expressiveness. In

POLICY 2004. IEEE Computer Society.

Bonatti, P., Olmedilla, D., and Peer, J. (2006). Advanced

policy explanations. In ECAI 2006. IOS Press.

Bonatti, P. and Samarati, P. (2000). Regulating service ac-

cess and information release on the web. In CCS 2000.

ACM Press.

Damianou, N., Dulay, N., Lupu, E., and Sloman, M. (2001).

The ponder policy speciﬁcation language. In POLICY

2001. Springer.

Duma, C., Herzog, A., and Shahmehri, N. (2007). Privacy

in the semantic web: What policy languages have to

offer. In POLICY 2007. IEEE Computer Society.

Gavriloaie, R., Nejdl, W., Olmedilla, D., Seamons, K. E.,

and Winslett, M. (2004). No registration needed: How

to use declarative policies and negotiation to access

sensitive resources on the semantic web. In ESWS

2004. Springer.

Herzberg, A., Mass, Y., Michaeli, J., Ravid, Y., and Naor,

D. (2000). Access control meets public key infrastruc-

ture, or: Assigning roles to strangers. In 2000 IEEE

Symposium on Security and Privacy. IEEE Computer

Society.

Kagal, L., Finin, T. W., and Joshi, A. (2003). A policy

language for a pervasive computing environment. In

POLICY 2003. IEEE Computer Society.

Li, N. and Mitchell, J. C. (2003). Rt: A role-based trust-

management framework. In DISCEX III. IEEE Com-

puter Society.

Lorch, M., Proctor, S., Lepro, R., Kafura, D., and Shah, S.

(2003). First experiences using xacml for access con-

trol in distributed systems. In XMLSEC 2003. ACM

Press.

Seamons, K. E., Winslett, M., Yu, T., Smith, B., Child, E.,

Jacobson, J., Mills, H., and Yu, L. (2002). Require-

ments for policy languages for trust negotiation. In

POLICY 2002. IEEE Computer Society.

Tonti, G., Bradshaw, J. M., Jeffers, R., Montanari, R., Suri,

N., and Uszok, A. (2003). Semantic web languages for

policy representation and reasoning: A comparison of

kaos, rei, and ponder. In ISWC 2003. Springer.

Uszok, A., Bradshaw, J. M., Jeffers, R., Suri, N., Hayes,

P. J., Breedy, M. R., Bunch, L., Johnson, M., Kulka-

rni, S., and Lott, J. (2003). Kaos policy and domain

services: Toward a description-logic approach to pol-

icy representation, deconﬂiction, and enforcement. In

POLICY 2003. IEEE Computer Society.

SECRYPT 2008 - International Conference on Security and Cryptography

490