Capability-Role-Based Delegation in Workflow Systems
Koji Hasebe and Mitsuhiro Mabuchi
Graduate School of Systems and Information Engineering
University of Tsukuba
1-1-1 Tennodai, Tsukuba 305-8573, Japan
hasebe@iit.tsukuba.ac.jp, mmabu@osss.cs.tsukuba.ac.jp

Abstract—Various security models for supporting delegation
in workflow systems have been proposed to achieve flexible
access control in collaborative business processes. Since workflow systems come into their own when controlling largescale business processes in a well-structured organization,these models are often based on role-based access control(RBAC). However, to realize a higher level of collaboration
enabling users in different organizations to complete a common
workflow, it is necessary to support cross-domain delegation oftasks. For this purpose, we propose a delegation model for
workflow systems that extends the capability-role-based access
control (CRBAC) model introduced in our previous work. The
central idea behind our proposed model is that authority toperform tasks, as well as roles, are mapped to capabilities,
thereby realizing delegation by capability transfer. By adopting
the approach of a capability-based access control mechanism,
our model provides both flexibility and reduced administration
costs, thus allowing it to cope with unexpected changes in task
assignments. We demonstrate these advantages by considering
an example.
Keywords-RBAC, capability-based access control, delegation,
workflow systems

I. I NTRODUCTION
Workflow systems are used to specify and control the
execution of business processes. A workflow system stores a
specification of workflow, which is defined as a collection oftasks with a specific execution order designed to achieve a
common business objective. In addition, a workflow systemstores information that identifies the owner of the execution
authority for each task. The authorization information is
specified in access control models. Since workflow systems
come into their own when controlling large-scale businessprocesses in a well-structured organization where users are
assigned roles, these models are often based on role-based
access control (RBAC) [10]. (An example of such a model
is given in [7].)To achieve flexible and dynamic access control in workflows, various attempts have been made at modeling thedelegation of authority for executing tasks [1], [13], [3], [4].
Although most studies in the literature restrict their scope
to delegation within a single domain, to achieve a higher
level of collaboration enabling users in different organizations to complete a common workflow, it is necessary torealize cross-domain delegation. For example, consideringa development process with collaboration between different

departments of a company, delegation of tasks is required
across multiple departments to cope with emergent calls forreinforcement or unexpected changes in team members.
To address the issue of cross-domain delegation in workflow systems, in this paper we propose a delegation modelthat extends the capability-role-based access control (CRBAC) model introduced in our previous work [6]. CRBAC
comprises a capability-based access control mechanism integrated with the RBAC96 model [10]. A capability-based
access control mechanism (cf. [8]) is considered a meansfor delegation of authority. In general, a capability, which isan unforgeable token, consists of an object identifier anda list of permitted operations for that object. Therefore,a capability represents a self-authenticating permission toaccess a specified object through a permitted operation,
thus allowing owners of the capability to access the object without any authentication. Moreover, it is used forcross-domain delegation by means of middleware such as
HomeViews [5] or CapaFS [9]. In terms of the capability,
the central idea of CRBAC is the mapping of permissions
as well as roles to capabilities in each domain, thereby
realizing the delegation of permissions and roles by capability transfer. Thus, in the CRBAC model, by considering
a set of permissions to perform tasks in a workflow, we
obtain the intended delegation model. More precisely, ourmodel, called W-CRBAC, is obtained by incorporating thefollowing extensions. First, we introduce the notion of tasks
to the CRBAC model, and then provide a definition of theworkflow specification and its instantiation (i.e., assignmentof a user to each task). Thus, as the models in [13], [3],we also consider two kinds of delegations, namely abstract
task delegation and concrete task delegation. The former
authorizes the delegatee to perform the delegated task in
any instance of the workflow, while the latter authorizes thedelegatee to perform only the delegated instance. Next, we
define the delegation of tasks and roles as state transitions
in a similar manner to the definition in CRBAC.
By adopting the approach of capability-based access control, the W-CRBAC provides delegation of tasks as well as
roles in workflow systems with the following advantages.
As in the CRBAC, cross-domain delegation can be achieved
without specific requests to administrators. This makes flexible and smooth user-to-user delegation possible even inemergent situations. Moreover, by avoiding authentication,
the administration cost is reduced especially in large-scale
workflow systems. On the other hand, as a trade-off for theseadvantages, capability based-access control has a potential
security issue, that is, unintended propagation of capabilities.
To avoid this issue, our model imposes certain restrictions oncapabilities, such as lifetime and the number of activation,
focusing on workflow management. Finally, in this paper,
we demonstrate the effectiveness of the W-CRBAC model
for workflow systems by considering an example situation.
This paper is organized as follows. Section II presents
related work. Section III introduces the W-CRBAC model,
while Section IV demonstrates the application of our model
to workflows using an example. Section V discusses how ourmodel can be implemented. Finally, Section VI concludes
the paper and presents future work.
II. R ELATED W ORK
There have been a number of studies on delegationin access control, with most of these classified into twoclasses according to the underlying model, either RBAC orworkflow. As an example of the first class, the RBDM0 [2]was the first attempt at modeling user-to-user delegation ofroles based on the RBAC96 model. RDM2000 [11] extended
the RBDM0 to support hierarchical roles and multi-stepdelegation, while PBDM [12] considered delegation basedon both roles and permissions. On the other hand, as an
example of the second class, Atluri and Warner [1] addressed
the issue of delegation in the context of workflow andpresented a conditional delegation model.
Compared with the number of studies in each class,studies focusing on both classes are far fewer. As an exampleof this approach, DW-RBAC [13] proposed a role-based
access control model supporting delegation and revocation
in workflow systems. This model provided a mechanism todelegate both abstract and concrete tasks, where the delegation request was accepted so long as certain authorization
conditions were satisfied. In [3], Crampton and Khambhammettu considered various kinds of delegation operations
based on the differences of task type (introduced in [13]),
workflow execution model, and delegation type. Moreover,in their subsequent work [4], satisfiability problem (i.e.,
problem of whether a set of authorized users can complete
a workflow) was investigated for each of these kinds ofdelegation operations. The main difference between thesethree papers and ours is that our motivation is to support
flexible delegation by adopting the approach of a capabilitybased access control mechanism, instead of supporting various kinds of delegations investigated in [3], [4].
III. D ELEGATION IN W ORKFLOW WITH CRBAC
In this section, we present formal definitions of our WCRBAC model and the delegation in workflow systems.

A. Overview
CRBAC [6] is an extension of the RBAC96 modelobtained by integrating a capability-based access control
mechanism into the RBAC96 model. Our proposed model,
called W-CRBAC, is an extension of CRBAC with the focus
on its application to workflow systems. In a similar mannerto the RBAC96 family, W-CRBAC (as well as CRBAC) has
been developed from the base model (called W-CRBAC0)
by adding either role hierarchy (W-CRBAC1) or various
constraints (W-CRBAC2). (Although we also considereda consolidated model, called W-CRBAC3, we omit thedefinition thereof in this paper.) Moreover, to model crossdomain delegation, we consider a collection of sub-models,each of which represents a single domain. More precisely,
our model has been developed according to the following
steps.
First, we introduce certain components to the original
RBAC0, namely, a set of capabilities, a set of tasks, amapping to determine the owner of the capabilities, andthe assignment, to the capabilities, of roles and permissions
to perform tasks. On the other hand, in terms of the setof tasks, we define a workflow specification as well as
its instantiations. Thus, as in [13], [3], in our model we
distinguish between abstract and concrete tasks and treat
roles and tasks of these kinds as delegation units. Next, we
define the delegation operations in terms of state transition.
In our model, new capabilities are created either from thedelegator’s role or from capabilities that were previously
obtained. Finally, we add the role hierarchy and constraints.
These extensions are essentially the same as in the RBAC96
model, but in this study we focus mainly on constraints oncapabilities that are useful for preventing unintended propagation of capabilities and maintaining workflow security.
In the rest of this section, we introduce our model in a
stepwise fashion: in Section III-B, we first present the definition of CRBAC0 then extend it to W-CRBAC0, including
a model of the workflow; in Section III-C, we define thedelegation; finally, in Sections III-D and III-E, we extend
the base model to W-CRBAC1 and 2, respectively.
B. W-CRBAC0 and Workflow Model
As a preliminary step, we first introduce CRBAC0 presented in [6] then define W-CRBAC0. (For a graphicalillustration of the family of W-CRBAC models, see Fig. 1,
where the components drawn with bold lines and underlines
are extended parts of the RBAC96 and CRBAC models,
respectively.)
Definition 1 (CRBAC0): The CRBAC0 model includes
the following basic components:• Sub, Dom (sets of subjects and domains, respectively).
• Rolei , P eri , Sesi , Capi (sets of roles, permissions,sessions, and capabilities, respectively, in the i-th domain for each i ∈ Dom).

;*23(

*+,(

!"#

1+%:(

*()%<+)<(+<(.)0;1+%:(*23(

1#.23!#+!&-2!4%&!.#/()$
$%&'

$-3(

*-3(

*8.&&0%,.)=()>6,0&?(%%(.)%0&9(!"!"!!
$%&(

20&($*3456(

-./0(

$%&4

120&(
-23(

!"!"!!

%0%78(%0%7"($%&)

Figure 1.

;20&(

58&0+<0%6%0%7&(!0%(

1#.23!#+!&-2!),&-!.#/()$*()%<+)<(+<(.)0"#$%&'()$&%*+#'!(,&-!.#/()$0!

The family of W-CRBAC models (for i-th domain)

In addition to the above components, the following functions and relations are defined for the i-th domain for eachi ∈ Dom:Sub• usr : Dom → 2, a function that determines the setof users in the i-th domain for each i ∈ Dom. We also
use the ∪notation U sri to denote usr(i) and assume that
Sub = i∈Dom U sri .
• ses ui : Sesi → U sri , a function mapping each session in the i-th domain to the user who has established
it.
Rolei
• ses ri : Sesi ×2, a function mapping each session
in the i-th domain to the set of roles that is activatedby this session.
• U RAi ⊆ U sri × Rolei , a many-to-many user-to-role
assignment relation.
• RP Ai ⊆ Rolei × P eri , a many-to-many role-topermission assignment relation.
Capi• ses ci : Sesi → 2, a function mapping eachsession in the i-th domain to a set of capabilities.
Capi• U CAj,i : U srj → 2, a function mapping each user
in the j-th domain to a set of capabilities.
• CRAi ⊆ Capi × Rolei , a many-to-many capability-torole assignment relation.
• CP Ai ⊆ Capi × P eri , a many-to-many capability-topermission assignment relation.
These components satisfy the following conditions:(C0-1) ses ri (s) ⊆ {r | hses ui (s), ri ∈ U RAi }, whichmeans that any role activated by a session is one
that is assigned to the user who establishes thesession.
(C0-2) Session
s has the permissions∪r∈ses ri (s) {p | hr, pi ∈ RP Ai }.
(C0-3) ses ci (s) ⊆ {c | hses ui (s), ci ∈ U CAi }, whichmeans that any capability activated by a session is
owned by the user who establishes the session.
(C0-4) For any r ∈ Rolei and c ∈ Capi , if hc, ri ∈ CRAi

session s has the permissions that are determinedby (C0-2) above, otherwise∪ (i.e., hc, ri 6∈ CRAi )s has the permissions c∈ses ci (s) {p | hc, pi ∈CP Ai }.
As explained before, CRBAC0 is a pure extension of theRBAC96 model, where the components of Capi , ses ci ,U CAj,i , CRAi , and CP Ai are the extended parts. The first
five components play the following roles: Capi denotes theset of capabilities issued in the i-th domain; function ses ci
determines the set of capabilities activated by each session;function U CAj,i represents the owner of the capabilities;
and relations CRAi and CP Ai determine, respectively,
which roles and permissions are assigned to each capability.
Before presenting the definition of W-CRBAC0, we here
introduce the definitions of workflow specification and its
instantiation as follows.
Definition 2 (Workflow specification): A workflow specification W is a partially ordered set of abstract tasks(T aski , ≤), where T aski = {t1 , . . . , tm } is a set of tasks
in domain i ∈ Dom.
Intuitively, the instantiation is an assignment of a subject
to each task in a workflow specification. The formal definition is as follows.
Definition 3 (Instance of workflow): An instance w of
workflow W = (T aski , ≤) is a sequence [(t1 , u1 ), . . . ,(tm , um )] of pairs of tasks and subjects, such that T aski ={t1 , . . . , tm }, {u1 , . . . , um } ⊆ Sub, and tj ≤ tk for any
j, k with j ≤ k. We also use IT ask w
i to denote the set{(t1 , u1 ), . . . , (tm , um )} of concrete (i.e., instantiated) tasks
in instance w.
In addition, for a given workflow and its instance, we
consider the corresponding permissions as follows.
Definition 4 (Permissions in workflow): For an abstract
task t in a workflow specification W = (T aski , ≤), thepermission to perform t in any instance of W is denoted byper(t). The set {per(t) | t ∈ T aski } is denoted by T P eri .

On the other hand, for a concrete task t in an instance w of
W = (T aski , ≤), the permission to perform t in instancew is defined as tuple hu, per(t)i.

In terms of these notions, W-CRBAC0 is defined asfollows.
Definition 5 (W-CRBAC0): The W-CRBAC0 model (fora workflow specification W = (T aski , ≤) and for a set of
instances {w1 , . . . , wk } of W ) is obtained from CRBAC0
by adding the following components:
T aski , the set of abstract tasks in W .
wk1
IT ask w
i , . . . , IT ask i , the sets of concrete tasks.
• T P eri , the set of corresponding permissions to theabstract tasks in T aski .
• IP er i , a set of permissions to perform concretetasks, initially defined as {hu, per(t)i | hu, ri ∈U RAi , hr, per(t)i ∈ RP Ai , t ∈ T aski } (which represents the set of all concrete permissions determinedby role assignments).
• ICP Ai ⊆ Capi × IP er i , a many-to-many assignment
relation between capabilities and permissions to perform concrete tasks.
••To make our discussion simpler, in the rest of this paper,
we consider only a fixed single workflow instance. We thus
omit the superscript w.
C. Delegation of Tasks
Based on W-CRBAC0 and the workflow model, we define
the delegation of authority of abstract tasks and concretetasks using capability transfer. (Although our model also
supports delegation of roles, due to space limitation, we
omit the delegation of this type. Cf. also [6].) As mentioned
in Section III-A, the delegation process can be regarded
as the sequential composition of the following three basic
operations:(Step 1) Creation: A user creates a new capability.
(Step 2) Assignment: A user assigns authority to thecapability.
(Step 3) Transfer: A user sends it to another user.
In each of the first two steps, we consider the following
cases. In Step 1, permission to create new capabilities is
assigned to either (1) a role, or (2) a capability ownedby the creator. In Step 2, the authority consists of either(3) a set of authorities of abstract tasks or (4) concretetasks. According to these cases, we classify delegations into
four types as shown in the following table. However, more
precisely, DC-I is further divided into the following twocases: the permission assigned to a capability owned by thecreater is to perform an abstract task or a concrete task. In
the table, these two cases are named “DC-AI” and “DC-II”,
respectively.

XXX
XXX Step 1(1) Role
XXX
Step 2
X(3) Abst. tasks
DR-A(4) Inst. tasks
DR-I(2) Capability
DC-A
DC-AI/-II

Furthermore, in Step 3, we classify each of these five
types into two categories depending on whether or not thedelegation is carried out across multiple domains.
To provide a formal definition of the delegation of authority in our model, we first represent Steps 1 to 3 asa set of rules for state transitions of the model. (In thedefinition, we use the symbols S, S 0 , . . . to denote states.)
Then, by considering all possible sequential compositions of
the transitions, we can obtain the delegation of these types.
Definition 6 (Basic operations for delegation): The basic operations for delegation (i.e., creation, assignment,
and transfer) are defined by the following rules for statetransitions of a model.
Creation rules: Let S be a state, in which u ∈ U sri , c ∈Capi . If user u has (1) role r or (2) capability c to which
permission “create” is assigned, then he can create a newcapability c0 .
Formally, these rules are defined as follows.
(1)
If r ∈ Rolei with hu, ri ∈ U RAi and hr, createi ∈RP Ai , then this rule can be applied to S and
defines new state S 0 by replacing Capi in S with
Cap0i , such that Cap0i := Capi ∪ {c0 } (wherec0 6∈ Capi ).
(2)
If hu, ci ∈ U CAi and hc, createi ∈ CP Ai , thenthis rule can be applied to S and defines new state
S 0 as (1).
Assignment rules: Let S be a state, in which p ∈ T P eri ,u ∈ U sri , t ∈ T aski , and c0 (∈ Capi ) is created by u fromhis role r or capability c. If (AA) permission p to perform
an abstract task is assigned to r or c, then (3) he can assign
p to new capability c0 . Also, if (AI) permission p to perform
an abstract task is assigned to r or c, or if (II) permission
hu, per(t)i to perform concrete task hu, ti is assigned to c,then (4) he can assign this permission to c0 .
Formally, these rules are defined as follows.
(3)
If hu, ri ∈ U RAi and hr, pi ∈ RP Ai , or if
hc, pi ∈ CRAi , then this rule can be applied to
S and defines new state S 0 by replacing CP Ai in
S with CP A0i := CP Ai ∪ {hc0 , pi}.
(4)
If one of the following conditions holds• (For AI) hu, ri ∈ U RAi and hr, pi ∈ RP Ai ,or if hc, pi ∈ CP Ai ,• (ForII) hu, per(t)i∈
ICAP i andhc, hu, per(t)ii ∈ ICP Ai ,then this rule can be applied to S and defines newstate S 0 by replacing ICP Ai in S with ICP A0i :=ICP Ai ∪ {hc0 , hu0 , per(t)ii} for any u0 ∈ Sub.

Transfer rule: Let S be a state, in which u ∈ U sri , u0 ∈U srj , c0 ∈ Capi , and c0 is created by u (where i and j may
be the same domain number). Then new capability c0 canbe transferred from user u to another user u0 . In particular,such a transfer is referred to as a cross-domain transfer if
i 6= j.
Formally, this rule can be applied to S and defines
new state S 0 by replacing U CAi,j in S with U CA0i,j :=U CAi,j ∪ {hu0 , c0 i} .

By considering all possible sequential compositions ofthese basic operations, we can define our aimed delegations
as shown in the table. (See also [6] for the detailed definition.)
Here, it should be noted that the delegation operations
defined in Definition 6 are known as “grant delegation”, i.e.
delegator has the delegated permissions after the delegation.
To define the other type of delegation operations, called“transfer delegation” can be also defined by modifying theassignment rules.
In closing of the definitions of our base model and workflow, to help the readers understand the formal definitions
we provide a simple example.
Example 1: Consider a development process of someelectronic device in Hardware R&D Division of a company.
One day, to support development of control software in
the device, Alice is invited from Information System R&D
Division and assigned to an abstract task, say t, in aworkflow. Since then, however, Alice should be absent fromthe office, thus she delegate another staff, say Bob, in thesame division.
To deal flexibly with such a situation, our model provides different types of delegations for different purposes.
For example, delegating task t to Alice can be realized
by the following procedure: the project leader creates a
new capability (say, c) by activating his role and assigns
permission to perform task t, and then sends it to Alice.
In our model, this delegation process can be describedby the following state transtions. First, by creation rulefor case (1), we obtain a new state by replacing CapH
with Cap0H := CapH ∪ {c}. Then by assignment rulefor case (3), we obtain a new state by replacing CP AH
with CP A0H := CP AH ∪ {hc, per(t)i}. Finally, by thetransfer rule, we obtain a new state by replacing U CAH
with U CA0H := U CAH ∪ {hAlice, {c}i}.
On the other hand, when Alice delegates her task, she
may choose a suitable type among DC-A and DC-AI inaccordance with the aim. For example, DC-A would be
used if she should leave the office for a long time due toan extended business trip or hospitalization, while DC-AI
would be used to delegate a concrete task. Furthermore,during the absence of Alice, if Bob needs to delegate the task
to another staff and if his delegated capability has the ability

to create a new capability, it can be realized by Bob without
asking the administrator in Hardware Division. However,such flexible delegation may cause a security issue, namely
unintended propagation of capabilities. To avoid this issue,
we also provide some kinds of constraints on capabilities,
which shall be presented in Section III-E.
D. W-CRBAC1
Based on the W-CRBAC0 model, we develop an extended
model, called W-CRBAC1, by introducing role hierarchy.
This extension is essentially the same as that in RBAC1.
W-CRBAC1 is defined as follows:
Definition 7 (W-CRBAC1): The W-CRBAC1 model isobtained by adding rhi , a partial order over Rolei , called arole hierarchy. (The infix notation r0 ≥rhi r is also used todenote the role hierarchy and we can say that “r0 is a seniorrole of r” or “r is a junior role of r0 ” in the same sense as
in the RBAC96 model.)In addition to the above, the following conditions are
satisfied for each i.
(C1-1) ses ri (s) ⊆ {r | ∃r0 ≥rhi r(hses ui (s), r0 i ∈U RAi )}.
(C1-2) Eachsession s ∈ Sesi has the set of permissions∪
00
00
r∈ses ri (s) {p | ∃r ≤rhi r(hr , pi ∈ RP Ai )}.
(C1-3) Eachsession s ∈ Sesi has the set of permissions
∪
00
≤ r0
0
r ∈{r | hci ,ri∈CRAi ∧ci ∈ses ci (s)} {p | ∃r00
(hr , pi ∈ RP Ai )}The former two conditions are related to role hierarchy,
and are the same as in the RBAC96. Intuitively, condition(C1-1) imposes the requirement that every role activatedby session s is equally or less powerful (junior) than anyrole of the user establishing session s. (C1-2) imposes therequirement that the permissions in session s are those
directly assigned to the session’s roles and all of their juniorroles. On the other hand, the third condition guarantees theinheritance of permissions in terms of the role hierarchy. In
other words, (C1-3) means that if a role is assigned to acapability and it is activated, then all the permissions are
assigned to this role and to all the junior ones.
E. W-CRBAC2
Similar to the development process of the RBAC96 family, here we develop another extension, called W-CRBAC2.
In this paper, we focus on the constraints on a capability,
and in the next section we explain how these constraints
are used to prevent unintended propagation of authority toperform tasks using an example workflow.
As examples, we introduce the following two constraints.
(R1) Lifetime(R2) Number of activations
There are also other constraints, such as the numberof creations of new capabilities, the number of hops in acapability transfer, or the depth of inheritance of permissions
to create new capabilities. (See also [6] for more constraints.)

!"#$%&'#()/-0#1&!''#!&#%)-+,.
$&%(%!3%.!''#$%/-0#1#!"#%)*+,$"(%3%.!''#*+,-.")/012#$#'#+"1$!"#$%&!'"#+,-."#%&!'"$%'&$%''#!'#%)*+.
$'(%!3%.!'&#$%+,-."#%#

20%&!''#

Figure 2.

We present the formal definitions of constraints R1 andR2 below.
R1 (Lifetime): To formalize the notion of lifetime, we first
introduce the following constant and function:+• time (∈ Z ), the current time of the global clock
represented by a non-negative integer;++• life i : Capi → Z × Z , a function mapping eachcapability in the i-th domain to the time after which it
can be activated and that after which it expires.
Using this constant and function, the lifetime of a capability can be represented by the following conditions for any
c ∈ Capi and i ∈ Dom:
• fst(life(c)) < time ⇒ ses ci (c) 6∈ Sesi ;• snd (life(c)) > time ⇒ ses ci (c) 6∈ Sesi .
Here fst and snd are the first and second projections of
the input.
R2 (Number of activations): To define this constraint wefirst introduce the following functions:• lim acti : Capi → N;
• cnt acti : Capi → N.
The former determines the possible number of activations,while the latter counts the number of activations thus far. By
using these functions, this constraint can be represented as
the following condition for any c ∈ Capi and i ∈ Dom:lim acti (c) ≥ cnt acti (c).
IV. E XAMPLE OF D ELEGATIONSIn this section, we demonstrate how to apply our model
to workflow systems by considering the following example
scenario, which is an extended version of Example 1. Herewe consider three tasks, t1 , t2 , and t3 . Initially, Charlie isassigned to these tasks, and then t1 and t3 are delegatedby capability transfers. (See also Fig 2 for the graphicalpresentation of this scenario. In this figure, assigned tasks aredenoted after the corresponding user name, while delegations
are depicted as arrows.)
Example 2: After Charlie, the project leader, delegated
the abstract task t1 to Alice via the capability c (described in

3012#$#'#+"()*&!'"#

Example 2

Example 1), he also invites David, a professor in a university,
to join the team for promoting the project by businessacademia collaboration. David accepts the invitation, soCharlie creates a new capability (called c1 ) by activating
his role and assigns the permission to perform abstract task
t3 , and then passes it to David. At this time, Charlie permits
David to delegate his task to Eve, one of his students,
if necessary. So, during his absence, David creates a newcapability (called c2 ) from this capability c1 then delegatesa concrete task hper(t3 ), Davidi for each time when Eve
works in his place. On the other hand, one day Alice isabsent without notice, so Charlie creates a new capability(called c3 ) and delegates a concrete task hper(t1 ), Charliei
to Bob via c3 .
The delegations appearing in this scenario (denoted by(1) to (3) in Figure 2) are respectively classified into
DR-A, DC-AI, and DR-I. In our model, these delegation
processes can be described as state transitions. For example, the second delegation (i.e., from David to Eve) is
described by the following state transitions (where CapH ,ICP AH , and U CAH,U niv are in the state before thisdelegation): Cap0H := CapH ∪{c2 }; ICP A0H := ICP AH ∪{hc2 , hDavid, per(t2 )ii}; U CA0H,U niv := U CAH,U niv ∪{hEve, c2 i}.
Finally, we would like to note that the following points.
First, as the scenario indicates, our model supports a flexible
user-to-user delegation of both abstract tasks and concretetasks without any authentication. This would be helpful
to cope flexibly with unexpected situation over different
domains. On the other hand, our model provides delegators
to set some constraints on the propagation of capability
by combining basic constraints. This would be useful tocompensate for the intrinsic weakness in the capabilitybased access control. For example, considering the scenario
in Example 2, it would be better to restrict the lifetime(R1) or the number of activations (R2) of capability c3 .
Also, it would be better to restrict the number of hops
capability transfer (cf. [6]) of capability c1 so that David
cannot propagate unnecessary permissions.

V. D ISCUSSIONR EFERENCES

In this section we briefly discuss how this model canbe implemented. A possible way is to implement RBAC
permissions using access control list (ACL) approach and thecapability-based permissions are implemented by extensionof the ACL approach. That is, the i-th domain (for eachi) has a reference monitor that manages RBAC permissions
by ACL-based access control mechanism with two matrices
specifying U RAi and RP Ai . Also, a reference monitor
stores workflow specifications and the execution schedules(which are not explicitly modeled in this paper). When a user
in the j-th domain tries to perform a concrete task in the ith domain by activating his capability (say, c), the referencemonitor checks the validity of this capability then dynamically adds a tentative user, whose name is just specified as“guest”, to the matrix of U RAi . If some permissions are
assigned to c, then the specific role, called r∗ , is assigned tothe tentative user in the matrix of U RAi , while a list which
specifies that all the permissions of c are assigned to r∗ isalso added to the matrix of RP Ai , thereby the guest user has
all the permissions. (Note that r∗ plays a role in associating
the guest user with the permissions.) When performing a
concrete task, a reference monitor checks the authority byreferring to the extended matrices. Then, after closing thesession, the server removes both the tentative user and thecorresponding permissions from the matrices.

[1] V. Atluri and J. Warner. Supporting conditional delegationin secure workflow management systems, Proceedings ofthe 10th ACM Symposium on Access Control Models andTechnologies (SACMAT’05), pp.49-58, 2005.

VI. C ONCLUSIONS AND F UTURE W ORK
We presented an access control model called W-CRBAC,
by extending the CRBAC model, which was introducedin our previous work [6]. To realize flexible cross-domaindelegation of tasks and roles, we introduced the notion of
authority to perform both abstract and concrete tasks, andmapped these to capabilities to be transferred. Owing to
the capability-based access control mechanism, our model
provides both flexibility and reduced administration costs,
thus making it possible to cope with emergent calls forreinforcement or unexpected changes in task assignments
in large-scale workflows. On the other hand, we proposed
various constraints on capabilities to prevent unintended
propagation of authority of tasks.
In future work, we intend developing formal methods
to check the satisfiability problem considered in [4] andto verify security in the W-CRBAC model. In particular,
we are interested in a method for checking satisfiability ofdelegation conditions, as well as unintended propagation ofcapabilities, by searching all possible traces of workflow
executions using a model-checking approach.
ACKNOWLEDGMENTS
This study was supported in part by the Grant-in-Aid for
the Global COE Program on “Cybernics: fusion of human,machine, and information systems” at the University ofTsukuba.

[2] E. Barka and R. Sandhu. A Role-based Delegation Modeland Some Extensions. Proceedings of the 23rd National
Information Systems Security Conference, pp.101-114, 2000.
[3] J. Crampton and H. Khambhammettu. On Delegation andWorkflow Execution Models, Proceedings of the 23rd ACM
Symposium on Applied Computing (SAC’08), pp.2337-2144,
2008.
[4] J. Crampton and H. Khambhammettu. Delegation and Satisfiability in Workflow Systems, Proceedings of the 13th
ACM Symposium on Access Control Models and Technologies(SACMAT’08), pp.31-40, 2008.
[5] R. Geambasu, M. Balazinska, S. D. Gribble, and M. Levy.
HomeViews: Peer-to-Peer Middleware for Personal Data
Sharing Applications, Proceedings of the ACM SIGMODInternational Conference on Management of Data, pp.235246, 2007.
[6] K. Hasebe, M. Mabuchi, and A. Matsushita. CapabilityBased Delegation Model in RBAC, Proceedings of the 15th
ACM Symposium on Access Control Models and Technologies(SACMAT’10), pp.109-118, 2010.
[7] S. Kandala and R. Sandhu. Secure Role-Based Workflow
Models, Database Security XV: Status and Prospects, pp.4558, 2002.
[8] H. M. Levy. Capability-Based Computer Systems, Digital
Equipment Corporation, 1984.
[9] J. T. Regan and C. D. Jensen. Capability File Names: Separating Authorization from User Management in an Internet
File System, Proceedings of the USENIX Security Symposium,
pp.211-233, 2001.
[10] R. Sandhu, E. Coyne, H. Feinstein, and C. Youman. RoleBased Access Control Models, IEEE Computer, vol.29, no.2,
pp.38-47, 1996.
[11] L. Zhang, G. Ahn, B. T. Chu. A rule-based framework for role
based delegation, Proceedings of the 6th ACM Symposiumon Access Control Models and Technologies (SACMAT’01),
pp.153-162, 2001.
[12] X. Zhang, S. Oh, and R. Sandhu. PBDM: A Flexible Delegation Model in RBAC, Proceedings of the 8th ACM Symposiumon Access Control Models and Technologies (SACMAT’03),
pp.149-157, 2003.
[13] J. Wainer, A. Kumar, and P. Barthelmess. DW-RBAC: A formal security model of delegation and revocation in workflow
systems, Information Systems, vol.32, pp.365-384, 2007.