Obligations in PTaCL

Abstract

Obligations play an increasingly important role in authorization systems and are supported by languages such as XACML. However, our understanding of how to handle obligations in languages such as XACML, particularly in exceptional circumstances, is hampered by a lack of formality and rigor in the existing literature, including the XACML standard. PTaCL is an attribute-based policy language that makes use of tree-structured policies and targets, like XACML. However, PTaCL is more general than XACML and has rigorous operational semantics for request evaluation, from which a policy decision point can be implemented. In this paper, we enhance PTaCL by extending the policy syntax to include obligations and defining the obligations that should be associated with an authorization decision. Our final contribution is to extend our analysis to cases where policy evaluation may return an indeterminate value. We demonstrate that obligation semantics for PTaCL coincide with those of XACML when there is no indeterminacy. More importantly, we show that our obligation semantics provide a principled method for determining obligations for any policy-combining algorithm and the set of possible obligations in the presence of indeterminacy, thereby providing considerable advantages over existing approaches.

C. Williams—This research was supported by the EPSRC and the UK government as part of the Centre for Doctoral Training in Cyber Security at Royal Holloway, University of London (EP/K035584/1).

1 Introduction

There has been considerable work in recent years on defining authorization policies for “open” systems which need to make access control decisions based on user attributes, instead of identities. An authorization policy is typically defined by a target, a set of child policies and a decision-combining algorithm. The target, either implicitly or explicitly, identifies a set of requests. The policy is said to be “applicable” if the access request belongs to (or “matches”) the policy’s target. If a policy is applicable, then its child policies are evaluated and the results returned by those child policies are combined using the decision-combining algorithm. The most commonly used language of this type, particularly in real-world implementations, is XACML [16]. Despite its widespread use, the XACML standard is somewhat vague and inconsistent in its articulation of policy evaluation, making it unsuitable for formal analysis and leading to counterintuitive authorization decisions (notably when errors in policy evaluation occur) [13, 15].

An important aspect of authorization policies, and the focus of this paper, is obligations and the methods for returning them. An obligation is a mandate on what must be carried out before or after an access is approved or denied, and they are used to meet formal requirements of systems such as non-repudiation. One example of an obligation would be to log access to a resource when an access request is made. Usually, each access control policy will have associated obligations, rather than having obligations as separate functions, so obligations may be thought of as a function of the access request. The XACML 2.0 standard defines how to compute the set of obligations returned when policy evaluation occurs; however, like much of the standard, the definition lacks rigor.

There is some work that define methods for returning obligations in policy-combining languages [1, 13]. However, like XACML this work also lacks formal semantics and uses weak methods to return obligations in exceptional circumstances. The lack of a formal deterministic method for computing the appropriate obligation associated with an authorization decision motivates us to develop new methods that can provide this functionality and provide default ways of returning obligations.

To tackle some of the shortcomings of XACML, Crampton and Morisset defined the policy language PTaCL [6]. PTaCL defines three basic policy-combining operators, which can be used to represent all other policy-combining operators. PTaCL also provides a concise syntax for policy targets and precise semantics for policy evaluation. XACML policies (without obligations and conditions) can be encoded using PTaCL, which allows XACML to be analyzed within a more formal environment. In this paper, we extend the PTaCL syntax to incorporate obligations and define which obligations should be returned when evaluating an access request with respect to a PTaCL policy. We then show how to extend the PTaCL decision set so that we can handle errors in policy evaluation and demonstrate that our approach has advantages over existing approaches in the literature. The insights this provides suggests alternative ways of returning obligations in XACML. Thus the main contributions of this paper are:

• the specification of syntax extensions for PTaCL to incorporate obligations;

• the specification of “obligation semantics” for a PTaCL policy, defining precisely what obligations are returned for a given authorization request and PTaCL policy;

• a systematic extension of PTaCL to compute possible obligations in the presence of incomplete information; and

• a comparison of our approach with those in the literature and concrete proposals to improve how XACML handles obligations, particularly in the presence of indeterminate authorization decisions.

In the following section we provide an overview of PTaCL and introduce an example of a policy that we will use throughout the paper. In Sect. 3, we extend PTaCL policy syntax to include obligations and show how obligations can be evaluated in XACML by encoding policies in PTaCL. In Sect. 4, we explain how PTaCL semantics can be extended to account for indeterminacy in target and policy evaluation. We conclude the paper with a comparison and discussion of related work and ideas for future work.

2 PTaCL

PTaCL is intended to provide a generic framework for specifying target-based policy languages. In particular, it may be used to provide a more formal representation of XACML, thereby facilitating the analysis of XACML and identifying weaknesses in its specification.

PTaCL defines a policy target language (PTL), for specifying targets in terms of attributes (of users and resources), and a policy combining language (PCL), for combining (the decisions associated with the evaluation of) sub-policies [6]. For the purposes of this paper it is sufficient to understand that a policy target t is evaluated with respect to an access request q. This evaluation, which we denote by $[\!\![ t ]\!\!](q)$, may return true or false, which we denote by $1_\mathrm{T}$ and $0_\mathrm{T}$, respectively. If $[\!\![ t ]\!\!](q) = 1_\mathrm{T}$, we say the target is applicable to the request (and inapplicable if $[\!\![ t ]\!\!](q) = 0_\mathrm{T}$).

2.1 Syntax and Semantics

PTaCL policies are defined inductively with respect to a set of policy decisions D. We assume that D contains decisions 1 and 0, corresponding to “allow” and “deny”, respectively. For now, we assume $D = \{0,1,\bot \}$, where the decision $\bot$ denotes that a policy is not applicable to a request. (We consider more complex decision sets in Sect. 4.) Then 0 and 1 are (atomic) policies. Moreover, if p, $p_1$ and $p_2$ are policies and t is a target, then the following are policies:

$$ \begin{array}{rlrl} \mathop {\lnot }p &{} \text {(negation)} &{} \quad p_1 \mathbin {\wedge }p_2 &{} \text {(join)} \\ \mathop {\sim }p &{} \text {(deny-by-default)} &{} \quad (t,p) &{} \text {(selection)} \\ \end{array} $$

The semantics of a PTaCL policy are defined by applying the operators $\mathop {\lnot }$, $\mathop {\sim }$ and $\mathbin {\wedge }$ (defined on the set of decisions) to the decisions returned by the evaluation of sub-policies. The evaluation tables for $\mathop {\lnot }$, $\mathop {\sim }$ and $\mathbin {\wedge }$ are shown in Fig. 1a, b. The unary operators $\mathop {\lnot }$ and $\mathop {\sim }$ simply modify the decision: the former switches the values of 0 and 1, leaving $\bot$ unchanged; the latter transforms $\bot$ to 0, leaving 0 and 1 unchanged. These operators are used to implement policy negation and deny-by-default policies, respectively. The binary operator $\mathbin {\wedge }$ is strong conjunction in the Kleene three-valued logic [11]. It returns 0 if at least one of the operands is 0, 1 if both operands are 1, and $\bot$ otherwise. Given a request q, we write $\varDelta (p,q)$ to denote the decision returned by policy p for request q. The semantics of PTaCL policies are defined in Fig. 1c.

Fig. 1.

Decision operators and policy semantics in PTaCL

Policy Trees. Any PTaCL policy may be represented as a policy tree, in which leaf nodes are 0 or 1 decisions and internal nodes may be a target, one of the unary operators $\mathop {\lnot }$ or $\mathop {\sim }$, or the binary operator $\mathbin {\wedge }$. We introduce a special target all which is applicable to every request. Thus, we may assume that every policy has the form (t, p). Figure 2a shows the policy tree representing the policy

$$\begin{aligned} \mathop {\sim }\Big (t_5,\big (\mathop {\lnot }(t_3,(t_1,1) \mathbin {\wedge }(t_2,0)\big ) \mathbin {\wedge }(t_4,1)\big )\Big ). \end{aligned}$$

Fig. 2.

Evaluating a PTaCL policy

Request Evaluation. Request evaluation may be described in terms of policy trees and comprises two phases. The first phase evaluates the targets. The second phase propagates the decisions of sub-policies up to the root of the policy tree using the policy-combining operators at the internal nodes and the semantics defined in Fig. 1.

Consider the policy depicted in Fig. 2a and suppose that

$$\begin{aligned}{}[\!\![ t_1 ]\!\!](q) = [\!\![ t_4 ]\!\!](q) = [\!\![ t_5 ]\!\!](q) = 1_\mathrm{T}\ \text {and}\ [\!\![ t_2 ]\!\!](q) = [\!\![ t_3 ]\!\!](q) = 0_\mathrm{T}. \end{aligned}$$

The first phase of request evaluation results in the tree shown in Fig. 2b; recall that the targets for $\mathop {\sim }$ and $\mathop {\lnot }$ are all and thus necessarily evaluate to $1_\mathrm{T}$. The second phase of policy evaluation is shown in Fig. 2c. Note that the evaluation of the sub-trees with roots $t_3$ and $t_5$ consider the combination of a 1 and $\bot$ decision, and $\bot \wedge 1 = \bot$. At the root, the $\mathop {\sim }$ operator converts the $\bot$ decision into a 0 decision, which is the final decision returned for this policy.

2.2 Additional Operators

Crampton and Morisset showed that PTaCL is functionally complete [6]. In practical terms, this means we can introduce new binary operators to combine policies, which act as syntactic sugar, knowing that any such operator may be constructed using the PTaCL operators. In particular, we define three new operators: $\vee$, $\mathbin {\mathsf {aov}}$ and $\mathbin {\mathsf {dov}}$, where

$$\begin{aligned} d \vee d'&\mathop {=}\limits ^\mathrm{def} \lnot ((\lnot d) \wedge (\lnot d')) \\ d \mathbin {\mathsf {aov}}d'&\mathop {=}\limits ^\mathrm{def} (d \vee (\mathop {\sim }d')) \wedge ((\mathop {\sim }d) \vee d') \\ d \mathbin {\mathsf {dov}}d'&\mathop {=}\limits ^\mathrm{def} \lnot ((\lnot d) \mathbin {\mathsf {aov}}(\lnot d')) \end{aligned}$$

It is easy to show that these operators have the evaluation tables shown in Fig. 3. The operators $\mathbin {\mathsf {aov}}$ and $\mathbin {\mathsf {dov}}$ correspond to the XACML allow-overrides and deny-overrides combining algorithms, respectively. Thus, XACML (without obligations or conditions) may be encoded using PTaCL  [6].

Fig. 3.

Supplementary decision operators for PTaCL

To illustrate how the various techniques we develop may be applied in practice, and to demonstrate some shortcomings in XACML, we will use a running example due to Li et al. [13]. We cast their example in the syntax of PTaCL in the interests of brevity; the resulting policy and policy tree is shown in Fig. 4. The obligations (represented $o_1,o_2,o_5$) are not present in Li et al.’s original example; we include them to illustrate our methods for returning obligations alongside decisions.

Fig. 4.

Motivating example policy and policy tree

3 Obligations in PTaCL

In this section we define the method for incorporating obligations in PTaCL. In this paper, we are not concerned with the specific types of obligations, how they will be provided by the policy information point, or how they will be enforced by the policy enforcement point. Instead, we focus on how they will be combined by the policy decision point (following the approach taken by the XACML standard). Thus, we simply assume the existence of some “abstract” set of obligations O.

The method we define for computing obligations in PTaCL is inspired by the XACML standard, and one of our results shows that the obligations returned by a PTaCL policy will be the same as those returned by an equivalent XACML policy. While recognizing that there may be other ways of computing obligations, we make the assumption that the behavior specified by the XACML standard is that expected by the practitioners who designed it and is, therefore, a reasonable proxy for the required behavior of an obligations-combining strategy.

3.1 Defining Obligations in PTaCL

In XACML, each policy or policy set may be associated with one or more obligations. An obligation is associated with an effect (a decision in PTaCL), which may be Permit or Deny (denoted by 1 and 0, respectively, in PTaCL). Thus, the obligation associated with Permit is applied when the effect of a policy is Permit for a particular request. Informally, then, the result of evaluating a request in XACML is a pair comprising a decision and an obligation. Thus, we extend PTaCL syntax in the following ways.

• The PTaCL policy d, where $d \in \{0,1\}$, may only return d, so it suffices to extend the syntax for such policies to (d, o) (where $o \in O$).

• The unary policy operators $\mathop {\sim }$ and $\mathop {\lnot }$ are used only to eliminate or switch policy decisions, so we will assume that obligations are not associated with these operators. When evaluating policies with the operators $\mathop {\sim }$ and $\mathop {\lnot }$ the obligations from child nodes are passed up with no change.

• All other policies (generated using $\mathbin {\wedge }$ or targets) may return 0 or 1, so we extend the syntax for a policy p to $(p,o_0,o_1)$, where $o_i \in O$ is the obligation that should be returned if the evaluation of p returns decision $i \in \{0,1\}$.

Henceforth, we will write $\varOmega (p,q)$ to denote the obligations returned by the evaluation of policy p for request q. When depicting policy trees, we write $p_i$ to denote the policy with target $t_i$ and $o_{i,j}$ to represent the obligation associated with decision j for target $t_i$. We may not wish to specify obligations for every policy and every decision, so we assume the existence of a “null” obligation, denoted by $\epsilon$.

3.2 Computing Obligations in PTaCL

In general terms, when a policy language includes obligations, the policy decision point will return a decision and a set of obligations as a result of evaluating an access request. In terms of our notation, then, request evaluation will return the pair $(\varDelta (p,q),\varOmega (p,q))$: $\varDelta (p,q)$ is an element of D, as we have seen, and is determined by applying the relevant binary operator to the decisions returned by the child policies; $\varOmega (p,q)$ is a subset of O and, informally, is determined by taking the union of the sets of obligations associated with particular child policies (together with any relevant obligation for the parent policy). This method leverages the tree-structured, bottom-up evaluation strategy of PTaCL (and XACML) to return obligations from the nodes in the policy tree that influence the final decision returned by policy evaluation.

More formally, PTaCL obligation semantics are shown in Fig. 5a. The interesting case is policy conjunction, where we only take the obligations from child policies that return a decision equal to that of the parent policy. Thus we take obligations from both child policies if they return the same decision (as well as the relevant obligation from the parent policy), and if child policy $p_i$ returns 0 and the other does not then we return $\{o_0\} \cup \varOmega (p_i,q)$. (In all other cases, the decision returned is $\bot$ and the obligation set is empty.) We interpret $\{\epsilon \}$ as the empty set $\emptyset$.

Fig. 5.

Obligation semantics and look-up table

Fig. 6.

Decisions and obligations for the PTaCL $\vee$, $\mathbin {\mathsf {aov}}$ and $\mathbin {\mathsf {dov}}$ operators

By an abuse of notation, we can build an evaluation table for $\mathbin {\wedge }$, as shown in Fig. 5b (with the understanding that the relevant obligation needs to be included from the parent policy, the set of obligations associated with the decisions indexing the rows is $O_1$ and the set of obligations indexing the columns is $O_2$).

3.3 Computing Obligations for Derived Policy Operators

Given that (i) we can define arbitrary policy operators in terms of $\mathop {\sim }$, $\mathop {\lnot }$ and $\mathbin {\wedge }$ and (ii) we have defined how obligations are computed for these operators, we can extend our method of computing obligations to arbitrary policy operators. For example, we can define the obligations that should be returned by $\mathbin {\vee }$, $\mathbin {\mathsf {dov}}$ and $\mathbin {\mathsf {aov}}$, as shown in Fig. 6. (As in Fig. 5b for $\mathbin {\wedge }$, we assume that the relevant obligation from the parent policy will be included during policy evaluation; $O_1$ and $O_2$ are the obligations associated with the evaluation of $p_1$ and $p_2$, respectively.)

Consider the policy shown in Fig. 4b taken from our running example, and assume that all targets are applicable for a request q. (Where obligations are not shown, they are assumed to be $\epsilon$.) The result of evaluating the policy with respect to q is $(0,\{o_1,o_5\})$, as illustrated in Fig. 7b. In particular, $(0,\{o_1\}) \mathbin {\mathsf {dov}}(1,\{o_2\}) = (0,\{o_1\})$. The root policy has an obligation $o_5$, which is always returned (irrespective of the decision), so we return the set of obligations $\{o_1,o_5\}$ along with the 0 decision.

Fig. 7.

PTaCL policy evaluation with obligations

Our approach to obligations thus provides considerably greater flexibility than XACML, which only specifies how obligations should be computed for the pre-defined rule- and policy combining algorithms. Moreover, it is easy to show that the obligations computed by PTaCL for the $\mathbin {\mathsf {aov}}$ and $\mathbin {\mathsf {dov}}$ operators are identical to those computed by XACML. In other words, PTaCL is (i) consistent with XACML in terms of the obligations returned for standard operators, and (ii) provides an extensible mechanism for computing obligations for arbitrary policy operators.

4 Indeterminacy in PTaCL

Thus far, we have assumed that target evaluation will return either $1_\mathrm{T}$ or $0_\mathrm{T}$. In fact, PTaCL recognizes (like XACML) that target evaluation might fail and return $?_\mathrm{T}$. The full semantics for PTaCL are shown in Fig. 8.

Fig. 8.

PTaCL decisions in the presence of indeterminacy

The interesting case here is for policies of the form (t, p) when target evaluation returns $?_\mathrm{T}$. Informally, PTaCL assumes that either one of $1_\mathrm{T}$ and $0_\mathrm{T}$ could have been returned. Thus policy evaluation may return a set of decisions (reflecting the indeterminacy). The semantics for the other operators operate on sets, rather than single decisions, in the natural way. A simple inductive argument establishes that if we can guarantee that $[\!\![ t ]\!\!](q) \in \{1_\mathrm{T},0_\mathrm{T}\}$, then $\Delta (p,q) = \{d\}$ for some $d \in D$; moreover, d is the decision that would be returned by the original PTaCL semantics [6].

We now revisit the example in Fig. 4 and suppose that $[\!\![ t_1 ]\!\!](q) = 0_\mathrm{T}$ and $[\!\![ t_2 ]\!\!](q) = ?_\mathrm{T}$. Li et al. used this example to demonstrate flaws in the way in which XACML 2.0 computed decisions in the presence of indeterminacy [13]. Specifically, for this request, a deny decision would be returned, when one would expect an allow decision (since if $t_2$ had evaluated to either $0_\mathrm{T}$ or $1_\mathrm{T}$ the root policy would evaluate to 1). The evaluation of the same policy for the same request in PTaCL is shown in Fig. 9. The set-based semantics mean that additional information is based up the tree during evaluation, resulting in the expected decision.

Fig. 9.

PTaCL policy evaluation with indeterminacy

4.1 Failure of Target Evaluation

When target evaluation fails, PTaCL returns a decision set as opposed to a single decision. We can extend this method when obligations are included in PTaCL. Without indeterminacy, request evaluation returns a decision-obligation pair; with indeterminacy, therefore, it returns a set of decision-obligation pairs. If the evaluation of target t fails, for example, the leaf policy (t, (d, o)) evaluates to $\{(\bot ,\emptyset ),(d,\{o\})\}$.

We once again revisit our running example, again assuming that $[\!\![ t_1 ]\!\!](q) = ?_\mathrm{T}$ and $[\!\![ t_2 ]\!\!](q) = 1_\mathrm{T}$, as in Fig. 9. The resulting policy evaluation is shown in Fig. 10a and returns $\{(1,\{o_5\}),(1,\{o_2,o_5\})\}$. We see on this occasion that policy evaluation returns the same decision but different obligation sets.

Let us now consider request $q'$ such that $[\!\![ t_1 ]\!\!](q') = ?_\mathrm{T}$ and $[\!\![ t_i ]\!\!](q') = 1_\mathrm{T}$ for all other i. The resulting policy evaluation is shown in Fig. 10b. In this case, different decisions and different obligation sets are obtained.

Fig. 10.

PTaCL policy evaluation with indeterminacy and obligations

Thus, in many situations we will be faced with a set of decision-obligation pairs. The behavior of the policy enforcement point would need to be defined for such situations. One possibility is to adopt use the idea of a resolution function, as described by Crampton and Huth [5]. This is a topic for future research.

4.2 Failure of Policy Retrieval

In the previous section, we explored the scenarios that arise when target evaluation fails, in which case we considered the possibilities that the target evaluated to $1_\mathrm{T}$ and $0_\mathrm{T}$. In handling indeterminacy, the XACML standard makes the assumption that the contents or effect of a sub-policy or rule may be retrieved and inspected, and this influences the type of indeterminate decision returned (in XACML 3.0). However, it is not always possible to retrieve a sub-policy, or inspect a rule. This may occur if a policy is not self-contained: a policy may, for example, reference a sub-policy that is located on a remote server that has crashed. Even in these circumstances, we would still like to attempt to evaluate the root policy, despite lacking a complete policy tree. In the XACML standard, this scenario is not considered at all.

Under normal circumstances, the evaluation of policy with respect to a request q may return a 0, 1 or $\bot$ decision. However when a policy may not be retrieved, we only know that the policy could have evaluated to one of the three basic decisions 0, 1 or $\bot$. Hence, when we can not retrieve a policy, we return the set $\{0,1,\bot \}$ in place of the policy.

We now consider how we should handle obligations in this scenario. Given that obligations are part of the policy specification, we will have no information about the obligations that should be returned. To handle this lack of information, we consider two methods. Firstly, return the empty set of obligations with each of the three possible decisions. Thus the set of decision-obligations pairs for an irretrievable (sub)policy is then $\{(0,\emptyset ),(1,\emptyset ),(\bot ,\emptyset )\}$. Alternatively, return “error” obligation o! alongside each decision, rather than the empty set. In an implementation, the later option has merit as more information is provided and it highlights that an error occurred in policy evaluation, which can in turn be handled by the policy enforcement point.

Fig. 11.

Policy evaluation when $p_1$ is irretrievable

Returning to our running example, suppose policy $p_1$ is irretrievable and all the remaining targets are applicable for a request q. Policy evaluation under the first method is shown in Fig. 11 and results in the set $\{(0,\{o_5\}),(1,\{o_2,o_5\})\}$. Clearly, in this situation we are not able to return the correct set of obligations, even if policy evaluation returns a conclusive decision. Policy evaluation using the “error” obligation in the same example would return $\{(0,\{o!,o_5\}),(1,\{o!,o_2,o_5\})\}$.

5 XACML and Other Related Work

Informally, a policy written in XACML may be viewed as a tree in which the leaf nodes are XACML rules, nodes whose children are rules are XACML policies, and all other nodes are XACML policy sets. Each node has a target, defined in terms of user and resource attributes. A target determines whether a rule, policy or policy set is evaluated for a given access request. Each rule is associated with an effect (an authorization decision), which may be either “Permit” or “Deny”. Each policy node is associated with a rule-combining algorithm (RCA), which is used during request evaluation to combine the decisions of the policy’s rules that are applicable to the request. Each policy set node is associated with a policy-combining algorithm (PCA), which is used to combine the decisions of its applicable child policies. Thus, an XACML rule corresponds to leaf nodes (atomic policies) in a PTaCL policy tree; and XACML policies and policy sets are non-leaf nodes in a PTaCL policy tree.

In addition, each XACML policy and policy set (but not rules) may be associated with one or more obligations ¹. An obligation is defined by the FulfillOn attribute (whose value is either “Permit” or “Deny”) and an action (such as “create audit entry”). Policy evaluation returns a decision and a set of obligations to the policy enforcement point, which is required to enforce the decision and execute any obligations. The XACML 2.0 and 3.0 standards [14, 16] define how this set of obligations is computed:

“When such a policy or policy set is evaluated, an obligation SHALL be passed up to the next level of evaluation (the enclosing or referencing policy, policy set or authorization decision) only if the effect of the policy or policy set being evaluated matches the value of the FulfillOn attribute of the obligation...”

“...no obligations SHALL be returned to the PEP if...the decision resulting from evaluating the policy or policy set does not match the decision resulting from evaluating an enclosing policy set.”

“...If the [policy decision point] PDP’s evaluation is viewed as a tree of policy sets and policies, each of which returns “Permit” or “Deny”, then the set of obligations returned by the PDP to the [policy enforcement point] PEP will include only the obligations associated with those paths where the effect at each level of evaluation is the same as the effect being returned by the PDP.”

Like much of the XACML standard, this statement lacks formality and prior work has indicated that the way in which policy-combining algorithms and the way of computing obligations produces some counterintuitive results [13].

The XACML 2.0 standard [14] defines how obligations are returned when target evaluation fails:

“...no obligations SHALL be returned to the PEP if the policies or policy sets from which they are drawn are not evaluated, or if their evaluated result is “Indeterminate” or “NotApplicable”...”

Thus, obligations from any policy that evaluates to “Indeterminate” are lost in the evaluation process. The XACML 3.0 standard has improved the way in which decisions are computed in the presence of indeterminacy [16], but has not changed how obligations are computed.

The specification and computation of obligations in PTaCL has some similarities to, and some notable differences, from XACML, which we summarize in Table 1. We also include a comparison with the work on obligations by Li et al. [13], discussed below.

Table 1. Comparison of XACML and PTaCL

Arguably the two greatest improvements offered by the approach we propose are (i) the ability to return obligations when policy evaluation is indeterminate, and (ii) the ability to compute the set of obligations for any policy, irrespective of the operators used. In the first case, it seems natural to allow obligations to be returned even for indeterminate policies (and these could be considered as “default obligations”) and provides more fine-grained control over which requests are subject to indeterminacy. In the second case, we believe it is important to specify the computation of obligations as completely and unambiguously as possible, thus minimizing the likelihood that an implementation will be incorrect.

Other work exists that define methods for handling obligations in XACML. Alqatawna et al. [1] introduce a way of using obligations to implement a discretionary overriding mechanism in XACML. They do this by using two algorithms, an effects-combining algorithm which is similar to standard policy-combining algorithms and an obligations-combining algorithm, the implementation of the latter being left to the discretion of the policy author. We believe it will be more useful, in general, to provide, as we have done, standardized mechanisms for combining obligations that are natural extensions of the existing decision-combining algorithms.

Li et al. defined semantics for handling obligations in XACML, largely following the definition in the XACML standard where obligations are returned only from paths which “contribute” to the final decision returned by the PDP [13]. Li et al. do define an algorithm for computing the set of obligations for an arbitrary policy operator, although this algorithm requires the operator to have certain properties. In contrast, our approach to obligations is completely general: any policy operator can be defined using PTaCL and a decision and a set of obligations can be computed. Like our definition of obligations in PTaCL, if the outcome of policy evaluation is not-applicable then the set of obligations is defined to be empty. Like XACML, if the outcome of policy evaluation is indeterminate, then the set of obligations is defined to be indeterminate. We would argue that it is more useful to return as much information as possible to the PEP, which can then decide what obligations, if any, should be enforced. The work Li et al. differs when combining obligations from two sub-policies that return the same decision, by allowing for three different methods to be specified in the policy combining language: $\mathsf {both}$, $\mathsf {first}$ and $\mathsf {either}$, leaving the choice to the policy author.

Subsequently, Li et al. [12] developed an architecture extending the XACML architecture in order to handle access control policies with different types of obligations. The focus of their work is how to enforcing the obligations once they have been returned to the PEP, while we focus on which obligations should be returned in the first place. A combination of our Li et al.’s architecture and our method for returning obligations may be an interesting and beneficial solution to some of the issues in XACML. Finally, we note that there exists work on dependencies between obligations and the effect these might have on the ability to fulfil obligations [8, 9]. These considerations are outside the scope of this paper, but may prove fruitful areas for future research.

6 Conclusion

The need to support obligations in a policy language is important for many real-world situations. It is recognized, for example, that obligations will play an important part in systems that use context-sensitive policies, where controlled overrides of policy decisions are required [2, 3], and risk-aware policies [4, 7, 10].

We extend the PTaCL language to incorporate syntax for specifying obligations and semantics for computing obligations as part of policy evaluation. We compare our method for returning obligations with the way they are returned in the XACML 2.0 standard, as well as comparing them with other work in the field [1, 13]. In doing so, we highlight a number of shortcomings in the XACML specification and computation of obligations, and in subsequent attempts to “patch” XACML.

One deficiency in the XACML standard is the way in which XACML handles indeterminacy, not least because the rule- and policy-combining algorithms behave differently. We show how decision sets can be used in PTaCL to handle indeterminacy and illustrate its effectiveness using an example from the literature. We further extend PTaCL semantics to handle obligations when there is indeterminacy, which results in a set of decision-obligation pairs. This is more informative and expressive than previous attempts to handle obligations when indeterminacy arises [13].

In summary, we have provided a principled method for computing decisions and obligations in PTaCL. These methods provide a rigorous foundation for attribute-based access control languages, including XACML.

In this paper we were not concerned with the specific type or scope of obligations, nor how they are handled by the system after evaluation. This is however an important aspect of obligations within authorization systems, and there has been extensive research into this area [8, 9, 12]. Future work could extend PTaCL to handle different types of obligations and model the behaviour that occurs after a decision-obligation pair has been returned to the PEP. Another natural extension for future work would be to implement a custom XACML policy decision point that is capable of handling PTaCL policies, or implementing a compiler that can translate policies expressed in PTaCL into XACML.