Juri Luca De Coi and Daniel Olmedilla
L3S Research Center, University of Hannover, Appelstr. 9a, D-30167 Hannover, Germany
Policy languages, comparison, trust management, privacy, security, review.
Policies are a well-known approach to protecting security and privacy of users as well as for flexible 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 field. 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 first 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.
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 specific 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 field
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 fill 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 first 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.
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 field has
considerably changed and nowadays many aspects of
Luca De Coi J. and Olmedilla D. (2008).
In Proceedings of the International Conference on Security and Cryptography, pages 483-490
DOI: 10.5220/0001921004830490
(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-
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 field is not provided.
Finally (Duma et al., 2007) provides a comparison
specifically 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.
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 justified by the different requirements
they had to accomplish Ponder was meant to help lo-
cal security policy specification, therefore typical ad-
dressed application scenarios include registration of
users or logging and audit events. WSPLs 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-
Given the multiplicity of available languages and
the sometimes very specific contexts they fit 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 identified 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.
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
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-defined Semantics. According to (Seamons
et al., 2002) we consider a policy language’s seman-
tics to be well-defined 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 file. 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 file). 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 specific built-in construct, whereas
others (e.g., Cassandra and Protune) exploit more fine-
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 define a policy and (ii)
both policies are taken into account when processing
a request. In this paper we adopt a narrower defini-
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
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 notified 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-
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 flavor of the language (avail-
able RT flavors 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
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-defined Semantics. A policy language’s se-
mantics is well-defined 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-defined 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-defined 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 certificates,
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 definition
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 finally 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
fulfilled 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 fulfilled in or-
der for the request to be satisfied (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 definition of the semantics of such at-
tributes is outside WSPLs 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 satisfied
Underlying Formalism. The most part of lan-
guages provided with a well-defined 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 define 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-
tifiers. Finally, no formalisms underly Ponder (which
only bases on the Object-oriented paradigm), TPL,
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 specific
profile 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 defines a specific kind of poli-
cies in order to deal with delegation: the field
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
define 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 flexible 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 certificates signed
by trusted entities (certification 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
the activity of users who have already been success-
fully authenticated. The authors of PSPL were the
first 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-
Negotiation Support. As stated above, we use a
narrower definition of negotiation than the one pro-
vided in (Anderson, 2004), into which WSPL does not
fit, therefore only pretty few languages support nego-
tiation in the sense we specified 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-
WSPL and XACML provide
two other result values to cater for particular situa-
not applicable
is returned whenever no ap-
plicable policies or rules could be found, whereas
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)
fulfilled, 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
EPAL defines 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 fulfilling 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-
fies the policy; in case c
= c (resp. c
is the empty
) is returned. Protune allows
for more advanced explanation capabilities: not only
is it possible to ask why (part of) a request was (not)
fulfilled (
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 (
queries). A rudimentary form of
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 (
) and the effects of not meeting the
obligation (
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. XACMLs
support to extensibility is two-fold: (i) on the one
hand new datatypes, as well as functions for dealing
with them, may be defined 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 define how to take re-
sults from multiple policies and derive a single result,
nevertheless a standard extension mechanism is avail-
able to define new algorithms. Using non-standard
user-defined 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 satisfies the requirements of both (as-
suming that such a policy exists), since there can be
no standard algorithm for merging policies exploiting
user-defined attributes. Ontologies are the means to
cater for extensibility in KAoS and Rei: both KAoS
and Rei define 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 define 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
In this section we review the comparison performed in
section 5 and provide some general comments.
SECRYPT 2008 - International Conference on Security and Cryptography
Table 1: Policy language comparison (“–” = not applicable).
Cassandra EPAL KAoS PeerTrust Ponder Protune PSPL Rei RT TPL WSPL XACML
Yes Yes Yes Yes No Yes Yes Yes Yes No No No
Monotonicity Yes Yes Yes Yes Yes Yes Yes No
logic with-
out quanti-
Logic pro-
Logic pro-
logic, Logic
Action execu-
Yes (side-
effect free)
Yes No Yes (only
Yes (access
to system
Yes Yes (only
No No No Yes Yes
Delegation Yes No No Yes Yes Yes No Yes Yes (RT
) No No No
Type of evalua-
Local Local Distributed Local Distributed Distributed Distributed
Local Local Distributed
Evidences Credentials No No Credentials,
Credentials Credentials No No
Negotiation Yes No No Yes No Yes Yes No No Yes No (policy
Result format A/D and a
set of con-
A/D A/D A/D Explana-
A/D A/D A/D,
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.
By carrying out the task of comparing a consid-
erable amount of policy languages, we came to be-
lieve that they may be classified 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-defined 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 identified; 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., conflict 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.
Policies are a well-known approach to protecting se-
curity and privacy of users as well as for flexible 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 field.
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.
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
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 specification 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
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
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, deconfliction, and enforcement. In
POLICY 2003. IEEE Computer Society.
SECRYPT 2008 - International Conference on Security and Cryptography