Capability-Based Delegation Model in RBAC
Koji Hasebe

Mitsuhiro Mabuchi

Akira Matsushita

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,
akira@cybernics.tsukuba.ac.jp
ABSTRACTFor ﬂexible and dynamic resource management in environments where users collaborate to fulﬁll their common tasks,
various attempts at modeling delegation of authority havebeen proposed using the role-based access control (RBAC)
model. However, to achieve a higher level of collaborationin large-scale networked systems, it is worthwhile supporting cross-domain delegation with low administration cost.
For that purpose, we propose a capability-role-based access
control (CRBAC) model, by integrating a capability-based
access control mechanism into the RBAC96 model. Central
to this scheme is the mapping of capabilities to permissions
as well as to roles in each domain, thereby realizing the delegation of permissions and roles by capability transfer. Bytaking this approach of capability-based access control, ourmodel has the advantages of ﬂexibility and reduced administration costs. We also demonstrate the eﬀectiveness of ourmodel by using examples of various types of delegation inclinical information systems.

Categories and Subject Descriptors
D.4.6 [Security and Protection]: Access Control

General Terms
Security, Theory

Keywords
RBAC, capability-based access control, delegation

1. INTRODUCTION
Role-based access control (RBAC) is a prominent model
for protection of resources in well-structured organizations
such as hospitals, universities, and companies. The central
idea behind this model is that users in an organization are
naturally mapped to roles in the organization, and accessrights are associated with the roles, thereby assigning appropriate permissions to the users belonging to these roles.

.

For ﬂexible and dynamic resource management in environments where users collaborate to fulﬁll their common
tasks, various attempts at modeling delegation of authority
based on the RBAC96 model [14] have been proposed, suchas RBDM [2, 3], RDM2000 [19], PBDM [21], and AtluriWarner’s model [1]. Although most studies in the literature restrict their scope to delegation in a single domain, toachieve a higher level of collaboration in distributed environments, it is worthwhile delegating across multiple domains.
For example, considering the infrastructure for large-scaleclinical information systems where medical doctors in diﬀerent hospitals collaborate to treat their patients, delegation ofaccess rights to electronic medical records is required acrossmultiple hospitals.
To realize cross-domain delegation, one of the easiest ways
is to prepare in advance tentative accounts for guest users
in each domain. Then, by assigning suitable permissions to
the guest accounts, users in diﬀerent domains may access resources via these accounts. Another possible way is to register users in diﬀerent domains or to use some mechanism supporting cross-domain authentication such as Kerberos [17].
However, these solutions remain unsatisfactory on the following counts. For the former solution, adequate ﬂexibility
for coping with unusual scenarios is lacking. For example, inthe case of emergency in the networked clinical information
system, it is useful for doctors to be able to immediately
refer to a patient’s medical records stored in diﬀerent hospitals. However, the solution of using guest accounts would
be cumbersome to deal with in such an emergency due tothe need for administrator operations in assigning suitable
access rights for each case. On the other hand, for the latter
solution, it requires the consolidation of all the users participating in the whole network system. This may cause
problems in administration costs if the network includes alarge number of diﬀerent domains. Moreover, to provide
a high level of collaboration across diﬀerent domains, especially when they independently have a hierarchy of roles
based on RBAC, it is worthwhile providing a mechanism
which assigns both permissions and roles of a host domain
to the guest users. However, this would also be diﬃcult
in the case of networked systems that include a number ofdomains due to the administration costs.
To address the issue of ﬂexible delegation based on RBAC,
we propose a capability-role-based access control (CRBAC)
model, by integrating a capability-based access control mechanism into the RBAC96 model. Capability-based access
control mechanism (cf. [15, 10]) is considered a means fordelegation of authority. In general, a capability, which isan unforgeable token consisting of an object identiﬁer anda list of permitted operations for that object. A capability
represents a self-authenticating permission to access a speciﬁed object in permitted operations, whereby owners of thecapability can access the object without any authentication.
Moreover, it is used for cross-domain delegation by meansof middleware such as HomeViews [7] or CapaFS [13].
To integrate a capability-based access control mechanism
into RBAC, our central idea is to extend the RBAC96 modelby introducing a set of capabilities as well as the mappingsfrom these capabilities to permissions and roles. Thus, in ourmodel, a user can delegate both permissions and roles by acapability transfer. By basing the approach on capabilitybased access control, our model has the following advantages. First, cross-domain delegation can be achieved without any authentication or speciﬁc request to the administrators. This makes ﬂexible and smooth user-to-user delegation
possible even in unusual situations such as an emergency inclinical systems. Second, by avoiding authentication, theadministration cost is reduced especially in large-scale network systems. Finally, our model supports delegation ofroles across diﬀerent domains, which also makes it possible
to assign roles in the host domain to invited users from outside. In addition, due to the mapping of capabilities to roles,
appropriate permissions are automatically assigned to guest
users even if the structure of roles varies.
On the other hand, since any owner of a capability has
the access right speciﬁed in the capability, systems withcapability-based access control has a potential security issue,
namely unintended propagation of capabilities. A simple example is that a malicious participant may steal transferredcapability, thus our model requires suitable authenticationfor each capability transfer. Moreover, it is possible that adelegatee transfers a capability to another user while a delegator does not intend to delegate authority to the user. In
order to avoid such unintended propagation, in our model
we provide various kinds of constraints on capabilities, suchas lifetime, limitation of creation, and possible number ofdelegation steps. In this paper, we demonstrate the eﬀectiveness of our model by using examples of various types ofdelegation in clinical information systems.
There have been a number of attempts at integration ofcapability-based access control mechanism with other access control models, such as Gong’s identity-based capability protection system called ICAP [9], or Neuman’s work
[11] where Kerberos credentials were extended so that they
could be used as capabilities. These studies introduced capability to realize ﬂexible delegation and reduced administration cost. Our work has similar motivation, but we apply
this approach within RBAC, which is not yet thoroughly
investigated. That is the main contribution of this paper.
The rest of this paper is organized as follows. Section
2 presents related work. Section 3 introduces the CRBAC
model. As with RBAC96, we ﬁrst present the base model,
CRBAC0, then gradually extend it by adding role hierarchy
and/or constraints. We also introduce the formal deﬁnition of delegation of authority, which is represented by statetransitions (i.e., rewriting instances of a model). Section 4
demonstrates how to apply our model by considering someplausible cases of clinical information systems. Finally, Section 5 concludes this paper and presents future work.

2.

RELATED WORK

There have been a number of attempts at modeling delegation of authority based on the RBAC96 model. (cf. also[12] for a comprehensive guide on delegation). The RBDM0[2] was the ﬁrst attempt at modeling user-to-user delegationof roles in the RBAC model. In particular, it considered
the ability of a user in a role to delegate his role membership to another user in some other role. This paper and its
successor (called RBDM1) [3] also considered some extensions such as revocation, partial delegation, multi-step delegation, and delegation with role hierarchy. RDM2000 [19]was an extension of RBDM0 in supporting hierarchical roles
and multi-step delegation but taking a diﬀerent approachfrom RBDM0. This paper also introduced a rule-based language for specifying and enforcing delegation. While RBDM
as well as RDM2000 considered only delegation of roles,
PBDM [21] considered delegation based on both roles andpermissions. PBDM also supported various types of delegation, such as user-to-user, temporal, partial, and multistep delegation. Crampton and Khambhammettu [6] studied transfer-delegation for the RBAC model. Although themodels described so far restricted their scope to delegation
in a single domain, recently some models supporting crossdomain delegation have been proposed. Among these models, Atluri and Warner [1] addressed the issue of delegation in the context of workﬂow and presented a conditionaldelegation model. In addition, Gomi et al., [8] and Chadwick and Otenko [4] considered cross-domain delegation (although these works are not based on the RBAC model).
The main diﬀerence between these three papers and ours isthat our motivation is to support ﬂexible delegation without any authentication mechanism. It should be noted thatfrom a practical viewpoint, there have been many papers
motivated to apply RBAC to various speciﬁc information
systems. Among them, [20] as well as [16] considered clinical information systems, which were similar to those used
for our example systems.

3.

CRBAC

In this section, we introduce our CRBAC model. In Section 3.1, we present a brief overview of our model. In Sections 3.2 and 3.3, we deﬁne the base model, called CRBAC0,
and the delegation of authority in our model. In Sections
3.4 and 3.5, we extend the basic model to CRBAC1 and 2
by introducing role hierarchy and some constraints on capabilities in a similar way to the construction of the family of
RBAC96 models.

3.1

Overview

CRBAC is an extension of the RBAC96 model obtainedby integrating a capability-based access control mechanism
into a RBAC96 model. In a similar manner to the RBAC96
family, the CRBAC is developed from the base model (called
CRBAC0) by adding the role hierarchy (CRBAC1) or various constraints (CRBAC2). (Although we also considered
the consolidated model, called CRBAC3, in this paper weomit the deﬁnition because it can be obtained directly from
CRBAC1 and 2).
Usually, the delegation based on the capability-based access control mechanism is achieved using the following threesteps: (1) delegator (i.e., a user who wishes to delegate authority to another user) creates a capability then (2) assigns
some access rights to the capability, and (3) transfer it to

*+,(

*12(

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

$-2(

*-2(

&8(

!"!"!!
$%&($*2345(

-./0(

-12(

10&(

$%&3

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

!0%(

Figure 1: The family of CRBAC models
the intended delegatee (i.e., receiver of the capability).1 To
model this delegation process in the RBAC to make it possible to delegate both roles and permissions across multiple
domains, we extend the RBAC96 by the following process.
First, to construct the CRBAC0 from the original RBAC0
model, we introduce some components to the RBAC0, namely,a set of capabilities, a mapping to determine the owners of
the capabilities, and the assignment of roles and permissions
to the capabilities. Note that in terms of these assignments
we treat both roles and permissions as delegation units. Additionally, we assume that new capabilities are created either
from the delegator’s role or capabilities that were previously
obtained. In our model, the inheritance relation with respect to the creation of capabilities is represented as a tree
structure, which is grown according to the propagation ofcapabilities. Moreover, to model cross-domain delegation,
we consider a collection of sub-models, each of which represents a single domain. On the other hand, in our model, thedelegation process itself is represented as state transitions,which will be deﬁned after introducing the CRBAC0.
Next, we extend CRBAC0 by introducing role hierarchy ina manner analogous to the RBAC96 model. We note that,in the CRBAC1, by means of the assignment of roles tocapabilities, suitable permissions are automatically assigned
to guest users in an environment where the host domain’s
role hierarchy may vary. For example, let us consider thesituation where a user has a capability (say, c) to which arole (say, r) is assigned. In the RBAC96 model, the user has
all the permissions assigned to r and its junior roles. Then,
if the junior roles change, the permissions assigned to r alsochange. In our model, the permissions assigned to c are also
directly reﬂected via the assignment of r to c.
Similar to the RBAC96 model, we also consider some constraints in the CRBAC0. Although we could consider various constraints related to users, sessions, and roles investigated in [14], we focus attention on the constraints on ca1
When implementing these steps, steps (1) and (2) are usually regarded as a single step, because in general the capability consists of an object identiﬁer and permissions forthis object. However, in our model, to categorize the typesof delegation we divide this creation of capability into these
two steps.

pability. In this paper, some constraints that would be useful to protect unintended propagation of capabilities include
lifetime, creation of a new capability, and/or the number ofhops of capability transfer.

3.2

CRBAC0

The CRBAC0 is the base model of the CRBAC family.
The formal deﬁnition is as follows. (See Fig 1 for a graphicalpresentation of the family of CRBAC models. Here, as weshall see later, the components with heavy lines are extended
parts of the RBAC96 model.)Definition 1 (CRBAC0). The CRBAC0 model has thefollowing basic components:• Sub, Dom (sets of subjects and domains).
• Rolei , P eri , Sesi , Capi (sets of roles, permissions,sessions, and capabilities in the i-th domain for eachi ∈ Dom). Here, P eri may contain a special kind of
permission, called creation of capabilities, denoted bycreate.
In addition to the above components, the following functions and relations are deﬁned for i-th domain for each i ∈Dom:• usr : Dom → 2Sub , a function that determines theset of users in the i-th domain for each i ∈ Dom. We
also use the S
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 establishes it.
• ses ri : Sesi × 2Rolei , 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-to-permission
assignment relation.

• ses ci : Sesi → 2Capi , a function mapping each session
in the i-th domain to a set of capabilities.
• U CAj,i : U srj → 2Capi , 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 }, means anyrole activated by a session is one that is assigned tothe user who establishes the session.
S(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 }, means 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 ∈ CRAithen session s has the permissions that are determinedby (C0-2) above, otherwise(i.e., hc, ri 6∈ CRAi ) thenSs has the permissions c∈ses ci (s) {p|hc, pi ∈ CP Ai }.
As explained in the previous subsection, the CRBAC0 is
a pure extension of the RBAC96 model where the components of Capi , ses ci , U CAj,i , CRAi , and CP Ai are theextended parts. These components play the following roles:
Capi denotes the set of capabilities issued in the i-th domain;function ses ci determines the set of capabilities activatedby each session; function U CAj,i represents the owner of capabilities; relations CRAi and CP Ai determine which roles
and permissions are assigned to each capability, respectively.

3.3 Delegation of authority
Owing to our uniﬁed treatment of roles and capabilities,
the CRBAC can support various types of delegations. As
mentioned in Section 3.1, the process of delegation using
capability transfer 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 the capability.
(Step 3) Transfer. A user sends it to another user.
For each of the ﬁrst two steps, we can consider the following
two cases. For Step 1, the permission to create new capabilities is assigned to (1) a role or (2) a capability owned by
the creator. For Step 2, the authority consists of (3) a set ofroles or (4) a set of permissions. According these cases, weclassify delegations into four types D1–D4 as shown in thefollowing table.

```
Create from``````
Assign``(3) Role(4) Capability(1) Role(2) Capability

D1
D2

D3
D4

Furthermore, for Step 3, we classify each of D1–D4 into
two categories depending on whether the delegation is madeacross multiple domains or not.
To provide the formal deﬁnition of the delegation of authority in our model, we ﬁrst represent Steps 1 to 3 as a setof rules for the state transitions of model. (In the deﬁnition,
we use the symbols S, S 0 , . . . to denote states.) Then, byconsidering some sequential compositions of the transitions,
we deﬁne the delegation of types D1–D4.
Before presenting the deﬁnition of delegation, to represent
the relation of the capabilities with respect to the creation,
we here introduce the creation tree as follows.
Definition 2 (Creation tree). A creation tree is atree structure consisting of the following components:• For each tree, the root node is a role in Rolei ,• rci ⊇ Rolei × 2Capi ,• cci ⊇ Capi × 2Capi .
For readability, throughout we use the inﬁx notations →rci
and →cci to denote rci and cci , respectively. Intuitively,hr, ci ∈ rci and hc1 , c2 i ∈ cci represent that capability c andc2 are created from role r and capability c1 , respectively. Insuch a case, we often say “r (c1 , resp.) is the parent of c (c2 ,resp.)”. The reﬂexive asymmetric transitive closure of cci isdenoted by cc∗i . Additionally, we use the notation CTi todenote rci ∪ cc∗i , thus it determines the creation relation of
the capabilities in i-th domain.
The relations rci and cci satisfy the following conditions
for each i ∈ Dom.
(C0-5) If r →rci c then hr, createi ∈ RP Ai .
(C0-6) If c →∗cci c0 then hc, createi ∈ CP Ai .
(C0-7) If r →rci c then{p|hr, pi ∈ RP Ai } ⊇ {p|hc, pi ∈ CP Ai }.
(C0-8) If c →∗cci c0 then{p|hc, pi ∈ CP Ai } ⊇ {p|hc0 , pi ∈ CP Ai }.
Intuitively, the former two represent the requirement thata new capability can be created whenever the right of creation is assigned to the parent. On the other hand, the lattertwo represent the requirement that the permissions assigned
to a created capability are weaker than the those assigned
to the parent.
Definition 3 (Basic operations for delegation).
The basic operations for delegation (i.e., creation, assignment, and transfer) are deﬁned by the following rules ofstate transitions for a model.
Creation rule: Let S be a state in which u ∈ U sri , c ∈Capi .
(1) If r ∈ Rolei with hu, ri ∈ U RAi and hr, createi ∈ RP Ai
in S, then this rule can be applied to S and deﬁnes newstate S 0 by replacing Capi and CTi in S with Cap0i and
CTi0 , respectively, such that:• Cap0i := Capi ∪ {c0 } where c0 6∈ Capi ;• CTi0 := CTi ∪ hr, ci.

/"3Transfer 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 this rule can be applied
to S and deﬁnes new state S 0 by replacing U CAi,j in S
with U CA0i,j := U CAi,j ∪ {hu0 , c0 i} . State transitions of

6175#-"$&-

8$#,#'&!
+2!"#$%&'/01'-1(23()*/01'-1(43()"0trans(u,u0 ,c0 )this type are denoted by S;
S 0 and we can say“capability c0 is transferred from user u to the other user u0 ”.
In particular, such transfer is called a cross-domain transfer
if i 6= j.

DB!"#$%&'"()*(+),-&-()"-.),-

By combining these basic operations, we deﬁne the delegations of types (D1) to (D4).

,%&+'/5"-#),-3(b) State S 0 (after the delegation)
Clinic C
U srCharlie
Role
doctor1
P ercreate, may(DB, read),may(DB, write)
Cap
[c1 ]
U RA hCharlie, doctor1 i
RP A hdoctor1 , createi,
hdoctor1 , may(DB, read)i,
hdoctor1 , may(DB, write)i
U CA
CP A [hc1 , may(DB, read)i]CT[doctor1 → c1 ]Definition 4 (Delegation). The delegations of types(D1) to (D4) are sequential compositions of basic operations
Creation, Assignment, and Transfer as follows (where “;” isused to denote the sequential-composition operator):
Hospital H
Bob
doctor2• (D1): S• (D2): S• (D3): S

hBob, doctor2 i• (D4): S• (D1): S

Figure 2: Example 1• (D2): S(2) If p ∈ P eri with hu, ci ∈ U CAi and hc, createi ∈ CP Ai ,then this rule can be applied to S and deﬁnes new state
S 0 by replacing Capi and CTi in S with Cap0i and CTi0 ,respectively, such that:• (D3): S• Cap0i := Capi ∪ {c0 } where c0 6∈ Capi ;• CTi0 := CTi ∪ hc, c0 i.
cre(u,r,c0 )

;

0

;

;

;

;

;

cre(u,c0 ,r) asg(P 0 ,c0 ) trans(u,u0 ,c0 )

;

;

;

;

;

cre(u,c0 ,c) asg(R0 ,c0 ) trans(u,u0 ,c0 )

;

;

;

;

;

cre(u,c0 ,c) asg(P 0 ,c0 ) trans(u,u0 ,c0 )

;

;

;

;

;

S0.
S0.
S0.
S0.

For readability, we also use the following notations to denotedelegations of these types:[hBob, {c1 }i]

The state transitions of these types are denoted by Scre(u,c0 ,r) asg(R0 ,c0 ) trans(u,u0 ,c0 )• (D4): S

D1(u,u0 ,c0 ,r,R0 );D2(u,u0 ,c0 ,r,P 0 );D3(u,u0 ,c0 ,c,R0 );D4(u,u0 ,c0 ,c,P 0 )

;

S0.
S0.
S0.
S0.

Finally, to help the readers understand the formal deﬁnitions we provide a simple example of a scenario in a clinicalinformation system. (See Fig 2 (a) for the graphical presentation). Larger and more realistic examples are presented in
Section 5.

cre(u,c,c )S 0 (for Case (1)) and S;
S 0 (for Case (2)), respec0
tively, and we can say“capability c is created by user u fromhis role r (from his capability c, resp.)”
Assignment rule: Let S be a state in which u ∈ U sri andc0 (∈ Capi ) is created by u.
(3) If R0 ⊇ R ⊇ Rolei in S such that hu, ri ∈ U RAi for any
r ∈ R, then this rule can be applied to S and deﬁnes
new state S 0 by replacing CRAi in S with CRA0i :=CRAi ∪ {hc0 , ri|r ∈ R0 }.
(4) If P ⊇ P eri in S, then this rule can be applied to S
and deﬁnes new state S 0 by replacing CP Ai in S with
CP A0i := CP Ai ∪ {hc0 , pi|p ∈ P }.
State transitions of these types are denoted by Sasg(P 0 ,c0 )asg(R0 ,c0 );S0(for Case (3)) and S;
S 0 (for Case (4)), respectively,
and we can say “roles R0 (permissions P 0 , resp.) is assigned
to capability c”.

Example 1. One day, Alice suddenly loses consciousness
and is transferred to emergency hospital H. The result of
the urgent examination indicates that she is in hypoglycemic
shock. Bob, a doctor in the hospital, immediately starts totreat Alice and looks for her primary care doctor to refer toher medical record, because he suspects she has severe diabetes mellitus on the basis of her symptoms. Subsequently,
from her ID card, Bob identiﬁes her primary care doctor as
Charlie in local clinic C. Charlie then allows Bob to refer tothe medical record stored in a database of the clinic by creating new capability c1 and assigning permission may(DB, r)(i.e., permission to read the contents of the database) andpasses it on to Bob.
Let us consider that the delegation is done by D2, that is,Charlie creates the new capability c1 by activating his role
doctor1 and assigns only the permission to read the contents of a database. In this case, the basic components are
as shown in the table of Fig 2 (b), where the columns list thecomponents of clinic C or hospital H. (We omit some components if they do not explicitly appear in this instance.)
In this table, the items surrounded by square brackets indicate the new ones which are added by the delegation ofc1 . The expression “may(o, r)” represents the permission toaccess the object o with a certain right r (e.g. read, write,
or execution).
More precisely, the delegation process can be described by
the following state transitions. First, by the creation of rulecre(Charlie, c1 , doctor1 ), we obtain a new state by respectively replacing CapC and CTC (components of the initialstate) with:•

Cap0C := CapC ∪ {c1 },• CTC0 := CTC ∪ hdoctor1 , c1 i.
Then by the assignment rule asg(may(DB, read), c1 ), we
obtain a new state by replacing CP AC with:• CP A0C := hc1 , may(DB, read)i.
Finally, by the transfer rule trans(Charlie, Bob, c1 ), we obtain a new state by replacing U CAC with:• U CA0C := U CAC ∪ hBob, {c1 }i.
Moreover, the activation of capability c1 by Bob to read theclinical record can be represented by the state transition:• Ses0C := SesC ∪ {s}(where SesC is the set of sessions in the adjacent state) with• ses u0C (s) = Bob,
• ses c0C (s) = {c1 }.
Remark 1. So far we explained the base model and thedelegation in CRBAC. We discuss here 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 server that manages RBAC permissions by ACLbased access control mechanism with two matrices specifying U RAi and RP Ai . When a user in the j-th domain
accesses an object in the i-th domain by activating his capability (say, c), the server checks the validity of this capability
then dynamically adds a tentative user, whose name is justspeciﬁed as “guest”, to the matrix of U RAi . If some roles
are assigned to c, then these roles are assigned to this tentative user in the matrix of U RAi , thereby the guest user
may activate these roles. On the other hand, if some permissions are assigned to c, then the speciﬁc role, called r∗ , isassigned to the tentative user in the matrix of U RAi , while
a list which speciﬁes that all the permissions of c are assigned to r∗ is also 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.)
Then, after closing the session, the server removes both thetentative user and the corresponding permissions from thematrices. In other words, in our model, capability plays arole of token that invokes such an automatic revision of ACL
instead of asking the administrator of such a revision.
Actually, this dynamic revision of ACLs would burden
the server, especially when the number of objects speciﬁed

in a capability is large. However, this mechanism makes it
possible to avoid the administrator operations and authentication, thus in the case of emergency, users may delegate authority without sending the password of the prepared guest
user account and without any request to the administrator.

3.4

CRBAC1

Based on the CRBAC0 model, we develop an extended
model named CRBAC1 by introducing role hierarchy. Thisextension is essentially the same as for RBAC1. That is,
CRBAC1 is deﬁned as follows:
Definition 5 (CRBAC1). The CRBAC1 model consists of the following components:• Sub, Rig, Dom, and usr are unchanged from CRBAC0.
• The sets Rolei , Capi , Obji , Sesi , P eri , ses ui , ses ri ,U RAi , U CAi,j , RP Ai , CP Ai , and CRAi are also deﬁned as in the CRBAC0 for each domain i.
• rhi , a partial order over Rolei , called role hierarchy.
(The inﬁx notation r0 ≥rhi r is also used to denote role
hierarchy and we can say “r0 is senior role of r” or “r isjunior role of r0 ” in the same sense as in the RBAC96
model.)In addition to the above setting, the following conditions are
satisﬁed for each i.
(C1-1) ses ri (s) ⊆ {r | ∃r0 ≥rhi r(hses ui (s), r0 i ∈ U RAi )}.
(C1-2) ForSeach session s ∈ Sesi , it has the set of permissions r∈ses ri (s) {p | ∃r00 ≤rhi r(hr00 , pi ∈ RP Ai )}.
(C1-3) For each
S session s ∈ Sesi , it has the set of permissions r0 ∈{r | hci ,ri∈CRAi ∧ci ∈ses ci (s)} {p | ∃r00 ≤ r0
(hr00 , pi ∈ RP Ai )}The former two are related to the role hierarchy, that are thesame as in the RBAC96. Intuitively, the condition (C1-1)
means the requirement that every role activated by session
s is less or equally powerful (junior) to any role of a user
who establishes the session s. (C1-2) means the requirementthat the permissions in session s are those directly assigned
to the session’s roles and all of their junior roles. On theother hand, the third condition guarantees the inheritanceof permissions with respect to the role hierarchy. In otherwords, (C1-3) means that if a role is assigned to a capability
and it is activated, then all the permissions are assigned tothis role and to all the junior ones. More speciﬁcally, we
explain this by using a slightly extended version of Example
1 as follows:
Example 2. After urgent treatment for Alice (describedin Example 1), Bob is invited to clinic C to treat Alice incollaboration with Charlie. For that purpose, Charlie delegates to doctor1 via the capability c2 . In clinic C, the role
doctor1 has a nurse as a junior role, so Bob may have all
the permissions assigned to the nurse by activating c2 . One
day, the role structure in clinic C changes, so doctor1 also
has a technician as a junior role.
The state (say, S 00 ) after the delegation of c2 can be speciﬁedby taking RP A00C and CRA00C as follows and all the othercomponents as the table in Fig 2. (Here p1 and p2 are certain
permissions.)• RP A00C := {hdoctor1 , p1 i, hnurse, p2 i}.
• CRA00C := {hc2 , doctor1 i}.
For this state, when Bob activates c2 by session s2 (i.e.,ses ci (s2 ) = {c2 } and ses ui (s2 ) = Bob), by condition (C13) he has the permissions p1 and p2 . (Note that, in thiscase, the variable r0 in (C1-3) ranges over the singleton{doctor1 }.) Again, after adding the new role technician(with htechnician, p3 i ∈ RP A00C ), when Bob activates c2 , bycondition (C1-3) he also has permission p3 in addition to p1
and p2 .
As this example indicates, this inheritance is useful forenvironments where users in diﬀerent domains collaborate
on a speciﬁc domain performing as roles in this domain andthe role hierarchy may vary.

3.5 CRBAC2
Similar to the development process of the RBAC96 family, we here develop another extension named CRBAC2. In
this paper, we focus attention on the constraints related tothe capability. In particular, we consider the following ﬁve
constraints, that would be useful for prohibiting unintended
propagation of capabilities.
(R1) Lifetime(R2) The number of activations(R3) The number of creations of new capabilities(R4) The inheritance of permissions related to role hierarchy(R5) The number of hops of capability transfer
There are also other constraints such as the depth of inheritance of permission to create new capabilities. On the other
hand, here we do not consider the constraints on the destination of capability transfer, because it is not plausible fromthe viewpoint of the implementation.
From now on, we present the formal deﬁnitions of constraints R1–R5 below:
R1 (Lifetime): To make the discussion simpler, we assume
that all the users as well as all the system components (e.g.,terminal computers) refer the unique global clock. To formalize the notion of lifetime, we ﬁrst introduce the following
constant and function:• time (∈ Z+ ), the current time of the global clock represented by non-negative integer;• life i : Capi → Z+ × Z+ , a function mapping eachcapability in the i-th domain to the time from which
it can be activated and the time from which it expires.
Note that we may omit the onset and expiry time by setting
them as 0 and +∞, respectively.
By means of these constants and functions, the lifetime ofa capability can be represented by the following conditions
for any c ∈ Capi and for any 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 ﬁrst and second projection of the
input.
R2 (The number of activation): To deﬁne this constraint
we ﬁrst 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 so far.
Thus, by using these functions, this constraint can be represented as the following condition for any c ∈ Capi and forany i ∈ Dom.
lim acti (c) ≥ cnt acti (c).
R3 (The number of creations): For a constraint of thiskind, there are two options: the number of creations andthe depth of descending from a single capability. In either
case, we can represent these constraints as the restrictions
on the width and depth of the creation tree, respectively.
That is, we ﬁrst introduce the following functions:• lim cre wi : Capi → N;
• lim cre di : Capi → N.
Then the constraints are represented by the following conditions for any c ∈ Capi and for any i ∈ Dom:
• lim cre wi (c) ≥ |{c0 |c →cci c0 ∧ c ∈ Capi }| ;• There is no sequence of capabilities c1 , c2 , . . . ck withk = lim cre di (c) such that c →cci c1 →cci · · · ck−1 →cci
c0 .
R4 (The inheritance of permissions): Although there arevarious constraints of this kind, they can be deﬁned in common by some modiﬁcation of condition (C1-3) introducedin the previous subsection. One of the simplest examples isthe constraint prohibiting any inheritance of permissions ofjunior roles that can be deﬁned by replacing (C1-3) with thefollowing condition:(C1-30 ) For each
S session s ∈ Sesi , it has the set of permissions r0 ∈{r | hci ,ri∈CRAi ∧ci ∈ses ci (s)} {p | (hr0 , pi ∈RP Ai )}.
R5 (The number of hops of capability transfer): To deﬁne
this, we ﬁrst introduce the following functions:• lim hopi : Capi → N, a mapping of each capability to
the limited number of times of capability transfer;• cnt hopi : Capi → N, a mapping of each capability to
the number of the capability transfers that have been
executed so far.
As a formalization of R2, the former determines the possible number of hops of capability transfer, while the lattercounts the number of hops so far. Thus, the constraint isrepresented as the following condition for any c ∈ Capi andfor any i ∈ Dom:lim hopi (c) ≥ cnt hopi (c).

%!,

0#'123+43$'#"*!93*.)#$1*5!1*+.3%&7,

0#'123+43$&(5#(/3%&6,)6)63!")7!"#$%%$&'#()*$+(,!""#$$)7%-+"1+(,&*)+*,,-&. /0)-1#)#%1!""#$$
Device%1#"8.*"*!.,&%'#(%(#$*-#."/,(b) State S 00 (after the delegation)
U sr
Role
P er
Cap
U RA
RP A
U CA
CP A
CRA
CT

Dept. of Surgery (D1 )David, Eliza
supervisor, residency[c2 ]hDavid, residencyi, hEliza, supervisori[hEliza, {c1 }i, hDavid, {c2 }i][hc2 , may(Dev, operate)i][hc1 , doctori][c1 → c2 ]Dept. of SI (D2 )Doctor, T echnician
doctor, technician
create, may(Dev, operate), may(Dev, setup)[c1 ]hDoctor, doctori, hT echnician, techniciani
hdoctor, createi, hdoctor, may(Dev, operate)i,
htechnician, may(Dev, setup)i[doctor → c1 ]Figure 3: Case 1

The constraints presented above are indeed useful to avoid
security issues with respect to delegation based on the capability transfer. For example, considering the scenario of
Example 1, it would be better to restrict the lifetime (i.e.
R1) and/or the number of activations (i.e. R2) of capability c1 , and it is also the case for constraints R3 and R5 in
prohibiting unwanted propagation of the permission in hospital H. Additionally, for the case of Example 2, if Bob does
not need to activate roles other than doctor1 for collaboration purposes, it would be better to cut oﬀ the inheritance
relationship of doctor1 by the constraint R4.

4. CASE STUDY
In this section we demonstrate how to apply our model
to some speciﬁc environments. For this purpose we consider
two cases of clinical information systems.

4.1 Case 1
The ﬁrst case is a scenario where delegations are done bothin a single domain and across multiple domains. (See also
Fig 3 (a) for the graphical presentation of this case.) Thiscase also includes the creation of capabilities both from a role
and another capability. We also consider some constraints
on the capabilities.
Case 1. David starts his new post of residency in thedepartment of surgery in hospital H, where Eliza is his supervisory doctor. In this hospital, Eliza has charge of a
special investigation, so she has the capability (called c1 ),which is created from role doctor by a doctor in the department of special investigation, to operate the computer device

for the investigation. In the department of special investigation, other than doctors, there are some technicians who
engage in the setup of this device. So, they are assigned therole technician to permit only the setup of the device. Twomonths later, David has gained suﬃcient training to handle this special device, thus Eliza creates a new capability(called c2 ) from c1 to operate the device and passes it tohim. Here, the lifetime of c2 is set as his residency period.
The basic components of the state after the delegations of
c1 and c2 are presented in the table of Fig 3 (b), where thecomponents surrounded by square brackets are newly addedby the delegation process.
The delegation process can be speciﬁed by the following
state transitions:• S ; S 0 by
D1(Doctor, Eliza, c1 , doctor, {doctor});• S 0 ; S 00 by
D4(Eliza, David, c2 , c1 , {may(Dev, operate)}).
Here, S, S 0 , and S 00 are initial state, the state after the ﬁrst
delegation, and the state after the second delegation. Moreprecisely, according to the D1 rule, the intermediate state
S 0 can be obtained by the following replacement:• Cap0D2 := CapD2 ∪ {c1 };0• CTD:= CTD2 ∪ {hdoctor, c1 i};
2• U CA0D2 := U CAD2 ∪ {hEliza, {c1 }i};!*(

20/3/$1-*'-#,./%*01+*4,(*$("'!*'

*'!*)

!"#$%
!"#$%#&'(&'(")'!"#$%#&)(*),(*$(")!*4+#../"0!"#$%#&)(*$$+,,
DB1*$$+,,*$$+,,DB2(b) State S 000 (after the delegation)
U sr
Role
P er
Cap
U RA
RP A
U CA
CP A
CT

Clinic C
F ritzdoctor1
create, may(DB1 , access)[c1 , c3 ]hF ritz, doctor1 i
hdoctor1 , createi, hdoctor1 , may(DB1 , access)i[hF ritz, {c3 }i][hc1 , createi, hc1 , may(DB, access)i][doctor1 → c1 ]Hospital H
George, Hillary
doctor2
create, may(DB2 , access)[c2 ]hGeorge, doctor2 i, hHillary, doctor2 i
hdoctor2 , createi, hdoctor2 , may(DB2 , access)i[hGeorge, {c1 }i, hHillary, {c2 }i][hc2 , may(DB, access)i][c1 → c2 , doctor2 → c3 ]Figure 4: Case 2• CRA0D2 := CRAD2 ∪ {hc1 , doctori}.
Again, according to the D4 rule, the ﬁnal state S 0 can beobtained from S1 by the following replacement:• Cap00D1 := Cap0D1 ∪ {c2 };
00
0
• CTD
:= CTD∪ {hc1 , c2 i};
1
1• U CA00D1 := U CA0D1 ∪ {hDavid, {c2 }i};
• CP A00D1 := CP A0D1 ∪ {hc2 , {may(DB, operate)i}.
In this case we may consider the following constraints.
First, with the delegation of c1 , Eliza may operate the computer device by activating the role doctor. Moreover, indomain D2 , if doctor is in a senior role to the technician
then she is also allowed to set up the device by the condition (C1-3) in either CRBAC1 or CRBAC3. Otherwise, if
Eliza does not need to set up the device, it is possible tointroduce constraint R4 to forbid her to do so. In addition
to the above constraint, Eliza can weaken the authority of
c2 by adding lifetime or by disabling any new creation ortransfer using R1, R3, R5, respectively. We note that such
constraints can be naturally represented in our model byusing some special functions introduced in Section 3.5.

Case 2. Alice regularly sees Fritz, her primary care doctor at a clinic C. One day, Alice’s medical condition takes
a turn for the worse, so he puts Alice in touch with George,a doctor for cardiovascular internal medicine in the general
hospital H, to provide an examination by a specialist. At
this time, to allow George to read Alice’s medical record in
the clinic, Fritz creates a new capability (called c1 ) from hisrole doctor1 and passes it to him. Then he performs physicalexaminations referring to Alice’s past medical record. As aresult, George considers that she requires hospitalization toundergo cardiac surgery. He consults Hillary, a doctor in
the department of cardiac surgery and allows her to read
Alice’s medical record by making another capability (calledc2 ) from this capability c1 . Hillary agrees with George’s
assessment and admits Alice to hospital H. Then Hillary
makes a plan for diagnoses and treatments based on the examinations and the past medical record. In addition, Fritz is
accepted as a care member for Alice by the regional referral
system, so Hillary makes a capability (called c3 ) to access
Alice’s medical chart in Hospital H, and passes it to him.
The basic components of the ﬁnal state are presented in
the table of Fig 4 (b). The delegation process can be speciﬁed by the following state transitions:

4.2 Case 2• S ; S 0 by
D2(F ritz, George, c1 , doctor1 ,{create, may(DB1 , access)})

The second case is a more complex scenario. (See also Fig
4 (a) for the graphical presentation of this case.)• S 0 ; S 00 by
D4(George, Hillary, c2 , c1 , {may(DB1 , access)})• S 00 ; S 000 by
D2(Hillary, F ritz, c3 , c2 , {may(DB2 , access)})
Similar to the previous case, here we may consider someconstraints on the delegation. First, when Fritz creates c1 ,he can set the limit number of creations (i.e., R3) as well as
the number of hops of capability transfer (i.e., R5). So, if hewants to forbid any propagation of the permission assigned
to c1 , he can set the numbers of both lim hopC (c1 ) andlim cre wC (c1 ) as 0. In this case, George cannot propagate
it because it would violate the conditions of R3 and R5.
In closing the case study, we would like to stress the following points. First, as these scenarios indicate, our model supports a ﬂexible user-to-user delegation of both roles and permissions without any authentication. This would be helpful
for collaboration between diﬀerent domains. Next, as presented in the explanations, our model provides delegators
to set various constraints on the propagation of capability
by combining basic constraint rules R1–R5. This would
be useful to compensate for the intrinsic weakness in thecapability-based access control.

5. CONCLUSIONS AND FUTURE WORK
We proposed an access control model named CRBAC integrating a capability-based access control mechanism into
the RBAC96 model. Owing to the ﬂexibility of capabilitybased access control, our model supported both delegationof roles and permissions in terms of capability transfer. Additionally, CRBAC made possible cross-domain delegation
without any authentication, which should reduce the administration costs. Similar to the RBAC96 model, we also
addressed some extensions by introducing role hierarchy aswell as various types of constraints on the capability-based
delegation, thereby providing a high level of collaboration
between diﬀerent organizations while preventing unintended
propagation of the capabilities.
For future work, one of the most interesting and worthwhile directions is to develop a formal method for security
veriﬁcation of the CRBAC. In particular, we are interested
in a method for detecting unintended propagation of capability by searching all possible delegation processes using amodel-checking technique [5]. We are also interested in thefeasibility of the proposed model, which could be investigated through a prototype implementation.

6. ACKNOWLEDGMENTS
The authors would like to thank the anonymous reviewers
for useful suggestions and comments which help us improve
this paper. This study was supported in part by the Grantin-Aid for the Global COE Program on “Cybernics: fusion ofhuman, machine, and information systems” at the Universityof Tsukuba.

7. REFERENCES[1] V. Atluri and J. Warner. Supporting conditional delegationin secure workflow management systems, Proceedings of the10th ACM Symposium on Access Control Models andTechnologies (SACMAT’05), pp.49-58, 2005.
[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] E. Barka and R. Sandhu. Role-Based Delegation
Model/Hierarchical Roles, Proceedings of the 20th Annual
Computer Security Applications Conference (ACSAC 04),
pp.396-404, 2004.
[4] D. W. Chadwick and A. Otenko. The PERMIS X.509 Role
Based Privilege Management Infrastructure, Proceedings ofthe 10th IFIP Open Conference on Communications andMultimedia Security (CMS’06), pp.67-86, 2006.
[5] E. M. Clarke, O Grumberg, and D. A. Peled. Model
Checking, MIT Press, 2000.
[6] J. Crampton and H. Khambhammettu. Delegation in
Role-Based Access Control, Proceedings of the 11th
European Symposium on Research in Computer Security(ESORICS’06), LNCS vol.4189, pp.174-191, 2006.
[7] 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.235-246, 2007.
[8] H. Gomi, M. Hatakeyama, S. Hosono, and S. Fujita. A
Delegation Framework for Federated Identity Management,
Proceedings of the ACM Workshop on Digital Identity
Management (DIM’05), pp.94-103, 2005.
[9] L. Gong. A Secure Identity-Based Capability System,
IEEE Symposium on Security and Privacy, pp.56-63, 1989.
[10] H. M. Levy. Capability-Based Computer Systems, Digital
Equipment Corporation, 1984.
[11] B. C. Neuman. Proxy-Based Authorization and Accounting
for Distributed Systems, Proceedings of the 13th
International Conference on Distributed Computing
Systems, pp.283-291, 1993.
[12] Q. Pham, J. Reid, A. McCullagh, and E. Dawson. On a
Taxonomy of Delegation, the FIFP International
Information Security Conference (IFIP/SEC-2009),
pp.353-363, 2009.
[13] 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.
[14] R. Sandhu, E. Coyne, H. Feinstein, and C. Youman.
Role-Based Access Control Models, IEEE Computer,vol.29, no.2, pp.38-47, 1996.
[15] L. Snyder. Formal Models of Capability-Based Protection
Systems, IEEE Trans. on Computers, vol.c-30, no.3,
pp.172-181, 1981.
[16] K. Sohr, M. Drouineaud, and G-J. Ahn. Formal
Specification of Role-based Security Policies for Clinical
Information Systems, Proceedings of the 20th Annual ACM
Symposium on Applied Computing (SAC’05), pp.332-339,
2005.
[17] J. G. Steiner, B. C. Neuman, and J. I. Schiller. Kerberos:
An Authentication Service for Open Network Systems,
Proceedings of the Winter 1988 USENIX Conference,
pp.191-201, 1988.
[18] J. Wainer and A Kumar. A Fine-grained, Controllable,
User to User Delegation Method in RBAC, Proceedings ofthe 10th ACM Symposium on Access Control Models andTechnologies (SACMAT’05), pp.59-66, 2005.
[19] L. Zhang, G. Ahn, B. T. Chu. A rule-based framework forrole based delegation, Proceedings of the 6th ACM
Symposium on Access Control Models and Technologies(SACMAT’01), pp.153-162, 2001.
[20] L. Zhang, G. Ahn, and B. T. Chu. A Role-Based
Delegation Framework for Healthcare Information Systems,
Proceedings of the 7th ACM Symposium on Access Control
Models and Technologies (SACMAT’02), pp.125-134, 2001.
[21] X. Zhang, S. Oh, and R. Sandhu. PBDM: A Flexible
Delegation Model in RBAC, Proceedings of the 8th ACM
Symposium on Access Control Models and Technologies(SACMAT’03), pp.149-157, 2003.