C2RBAC: An Extended Capability-Role-Based Access Control with
Context Awareness for Dynamic Environments
Mitsuhiro Mabuchi1 and Koji Hasebe2
1 Toyota Motor Corporation, Japan
2 Department of Computer Science, University of Tsukuba, Japanmitsuhiro mabuchi@mail.toyota.co.jp, hasebe@cs.tsukuba.ac.jp

Keywords:

Access Control, Context-aware, Delegation, Capability, RBAC

Abstract:

Various working styles, such as remote work, have become more common instead of working in one office. Moreover, to accelerate the development of new technologies, collaborations among multiple companies
are increasing. Thus, most development projects are operating in dynamic environments, for example, dynamically changing teams, working from anywhere and at any time. To ensure security in such dynamic
environments while maintaining efficiency, flexible and scalable access control is necessary. We previously
proposed capability-role-based access control (CRBAC) that allows users to create capabilities for delegating
authority across various domains without an administrator’s operation. However, in dynamic environments,
a finer control is required based on where and when the authority is delegated or executed. In this paper,
we propose an access control model called context-aware CRBAC (C2RBAC). This model is an extension of
CRBAC obtained by introducing a mechanism of context-based restrictions on various operations regarding
the delegation of authority by capabilities, such as time, place, and device. In this paper, we present a formal
definition of C2RBAC and demonstrate its effectiveness using an example of collaborative development.

1 INTRODUCTION
Various working styles, such as remote work, havebecome more common instead of working in one office. In particular, because remote work is spreading rapidly due to the COVID-19 pandemic, the useof resources (servers and databases) from unexpected
places, such as public spaces, is increasing. Moreover, to accelerate the development of new technologies, collaborations among multiple companies are
increasing, for example, the collaboration of a company with data analysis skills and a company having
big data.
Thus, most development projects are operated indynamic environments because the team is assumed
to be dynamically organized across companies, andthe working style also changes dynamically, such asplaces, times, and devices depending on situations.
Flexible and scalable access control is paramount toensure security in such dynamic environments while
maintaining efficiency. However, configuring access
control by administrators may consume time and isinflexible if the team changes frequently. Manuallyassigning authority to users in other domains makes
managing the system even more challenging. Further-more, confidential data such as personal informationmust be protected from unexpected use by access control.
We previously proposed capability-role-based access control (CRBAC) (Hasebe et al., 2010) that is
an extension of role-based access control (RBAC)(Sandhu et al., 1996) with capability-based access
control (CBAC) (Snyder, 1981), (Levy, 1984). CRBAC allows users to create capabilities from theircapabilities for delegating authority across domains
without an administrator’s operation. However, afiner control is required in dynamic environments depending on where and when the authority is delegatedor executed. Because CRBAC cannot set any limitation by contexts associated with environments, users
having access to a customer information database canobtain sensitive information from that database.
To realize such capability management, we propose an access control model called context-aware
CRBAC (C2RBAC). This model is an extended CRBAC model with context-awareness. C2RBAC can
impose context-based restrictions on various operations related to the delegation of authority by capabilities, such as time, place, and device. The
context-based restrictions can prevent potential issues

in dynamic environments, for example, an unexpected
propagation of capability and the use of capability
from an unexpected place or time. The contexts comprise surrounding environment information of users,
such as place, time, and device, whereas the constraints are attributes of capabilities or roles, such as
the number of uses and expiration date. The contexts can be evaluated with rules attached to capabilities whenever users use a capability. In this paper, we formally define the C2RBAC model as thebasic C2RBAC0 model and describe model families
C2RBAC1, C2RBAC2, and C2RBAC3. Furthermore,
we demonstrate the effectiveness of C2RBAC using
an example of collaborative development.
The rest of this paper is organized as follows. Section 2 presents related work and comparison results.
Section 3 introduces the C2RBAC model. Section 4
demonstrates the application of C2RBAC considering
a plausible case of collaborative development as a dynamic environment. Finally, Section 5 concludes thisstudy and presents future work.

2 RELATED WORKRBAC (Sandhu et al., 1996) is widely used as a modelfor hierarchical and efficient access control in an organization or a system. It assigns a preset role that is aset of permissions to appropriate users by authenticating their identities. The permission-based delegation
model (Zhang et al., 2003) is an extension of RBAC
to realize role delegation among users in a single domain. These enable fine-grained access control for awell-organized company or system.
Numerous context-aware applications (Baldauf
et al., 2007) have been proposed for adapting dynamic
environments, such as the Internet of Things. In
particular, some applications extended RBAC to define new access control models to realize fine-grained
and well-organized access control in dynamic environments. Context-aware RBAC (Kulkarni and Tripathi, 2008) supports dynamic environments, such asplace and time, by personalizing user access privileges based on the context information collected by
the context management layer. Contex-role based
access control (Park et al., 2006) based on RBAC
was proposed by introducing context-role to adapt
to dynamic environments. Moreover, all environment roles were created and managed by administrators; therefore, this model could not yield flexible and scalable access control in expected dynamic
environments. Schefer-Wenzl et al. (Schefer-Wenzl
and Strembeck, 2013) proposed a model that supports
dynamic environments by extending process-related

RBAC (Strembeck and Mendling, 2011) with context
and setting restrictions by context when executing acertain task. Covington et al. (Covington et al., 2001)
proposed a model that combines newly defined environment roles assigned to users based on context information with existing subject roles assigned to users
based on user identity.
Another extension of RBAC, Rule-based RBAC
(RB-RBAC) (Al-Kahtani and Sandhu, 2002), wasproposed based on attribute information to address access control in dynamic environments. As a result ofcomparing a user s attribute with role allocation rules,
PB-RBAC assigns a specific role to that user. In addition, when the attribute changes because of environmental changes, RB-RBAC performs the comparisonof new attributes and rules to assign an appropriate
role. In attribute-based access control (ABAC) (Jinet al., 2012), the attribute is defined as a function thattakes an entity as input and outputs a value withina specific range. ABAC realizes fine-grained access
control by adding attributes to all users, subjects, andobjects. Our previous model, CRBAC (Hasebe et al.,2010), is an extension of RBAC with CBAC that enables flexible cross-domain access authority delegation. In CRBAC, users can create new capabilities
from capabilities or roles assigned to them for delegating authority without any operation by the administrator.
We also proposed workflow-aware CRBAC (WCRBAC) (Hasebe and Mabuchi, 2010) for applying
the workflow system to CRBAC. W-CRBAC supports
the workflow system to use a task transferable alongwith permissions by mapping a task to both a capability and a role.
We evaluate C2RBAC and other access control
models described above in terms of the following
eight items.
(1) Adding new members (or assigning authority toa user who has not been registered to a system)without an administrator’s operation(2) Delegating authority to users in the same domain
without an administrator’s operation(3) Revoking delegated authority from users in thesame domain without an administrator’s operation(4) Delegating authority to users in different domains
without an administrator’s operation(5) Revoking delegated authority from users in different domains without an administrator’s operation(6) Preventing unexpected authority propagation(7) Restricting authority management by a contextual
information(8) Traceability of authority propagation

(1)
(2)
(3)
(4)
(5)
(6)
(7)
(8)

RBAC
(Sandhu et al., 1996)
PBDM(Zhang et al., 2003)

Context-aware RBACs(Kulkarni and Tripathi, 2008),(Park et al., 2006),(Schefer-Wenzl and Strembeck, 2013),(Covington et al., 2001)

RB-RBAC(Al-Kahtani and Sandhu, 2002)
ABAC(Jin et al., 2012)

✓
✓

✓
✓

✓
✓

✓

✓
✓
✓

✓
✓
✓

✓

CRBAC
(Hasebe et al., 2010)
W-CRBAC(Hasebe and Mabuchi, 2010)
✓
✓
✓
✓
✓
partly✓C2RBAC
our new model
✓
✓
✓
✓
✓
✓
✓
✓

Table 1: A comparison table of access control models which adapted to dynamic environments.

CRBAC, W-CRBAC, and C2RBAC can realize(1), (4), and (5) by exploiting the characteristics of
CBAC. All models described above can realize (2),(3), and (8). However, CRBAC and W-CRBAC prevent capability propagation by constraints, such as thenumber of delegations and expiration date; they cannot perfectly realize (6) if there is a malicious user
because of capability flexibility. Therefore, C2RBAC
uses context restrictions to prevent them. Regarding (7), context-aware models, RB-RBAC, ABAC,
and C2RBAC, can support dynamic environments.
C2RBAC supports all items to achieve secure, flexible, and scalable access control for dynamic environments.

3.1

3 C2RBAC• Rolei , Peri , Sesi , Capi : the sets of roles, permissions, sessions, and capabilities in the i-th domain
for each i ∈ Dom, respectively. Here, Peri may
contain a special kind of permission, called creation of capabilities, denoted by create.

This section gives a formal definition of our proposed Context-Aware Capability Role Based AccessControl (C2RBAC). C2RBAC is a family consisting of four models named C2RBAC0 to C2RBAC3.
C2RBAC0 is a base model. C2RBAC1 and 2 are extensions of C2RBAC0 by introducing role hierarchy
and restrictions, respectively. Here, context is formally represented as a set of variables ranging overstates in the system, such as the current time, IP address of a user’s terminal. Context can restrict on each
operation of the delegation of authority, i.e. creation,transfer, execution of authority, and revocation of capablity.
Below, Section 3.1 defines the base model. Section 3.2 gives the definition of delegation of authority
with capability in this model as a state transition of
the system. Finally, Section 3.3 describes the extension of the base model. The application of the model
defined above to an example will be shown in the next
section.

C2RBAC0

The C2RBAC0 is the base model of the C2RBAC
family. The formal definition is the following. (Seealso Figure 1 for a graphical presentation of the family of C2RBAC models. In this figure, the definitionof the expression “rhi ”, which refers to the role hierarchy, is described in the definition of C2RBAC2 in
Section 3.3.)
Definition 1 (C2RBAC0). The C2RBAC0 model has
the following basic components. (Here, for a set X,
the notation P (X ) denotes the powerset of X.)• Sub, Dom: the sets of subjects and domains, respectively.

• S = S1 × · · · × Sk : the set of all possible states ofthe system. Here, a state is a snapshot of the system described by the values of the variables of thesystem at a given moment. In the following, astate of the entire system si called a global state,while a state of a part of the system (especially ina domain) is called a local state.
• Cxt = Cxt1 × · · · × Cxtn : the set of all possible
global states (or called contexts), where Cxti foreach i = 1, . . . , n is the set of all possible local
states in the i-th domain. That is, Cxti = Cxti1 ×
j· · · × Cxtih where Cxti = S′j for all j = 1, . . . , hwith j′ = 1, . . . , k. Here, various kinds of states
can be regarded as contexts. For example, thetime (from 0 to 23) and the user’s location (L1 ,
L2 , and L3 ) when a session is activated in Domain 1 are considered as contexts, the set Cxt1 is
Cxt11 ×Cxt12 with Cxt11 = {0, 1, . . . , 23} and Cxt12 =

Capi
Sub

CPAi

Model of the 1st domain
Usr1

URAi

CRAi

rhi

...
Usri

SCAi
UCAj, i
Rolei

RPAi

Peri

Usrj
...

ses_cises_rises_ui
Usrn
Model of the n-th domain

SRAi
ses_cxti

Sesi

Cxti

Figure 1: The family of C2RBAC models.

{L1 , L2 , L3 }. As a notational convention, to indicate a global or local state of the system (i.e., anelement of set Cxt or Cxti ), we often use σ or σi .
In addition to the above components, the following functions and relations are defined for each i ∈Dom:• usr : Dom → P (Sub), a function that determines
the set of users in the i-th domain for each i ∈Dom. We also use the notation Usri to denote usr(i). Hereafter, we assume that Sub =∪/ for any i ̸= j.
i∈Dom Usr i with Usr i ∩ Usr j = 0• ses ui : Sesi → Usri , a function mapping each session in the i-th domain to the user who establishes
it.
• ses ri : Sesi → P (Rolei ), a function mapping eachsession in the i-th domain to a set of roles that is
activated by this session.
• ses ci : Sesi → P (Capi ), a function mapping eachsession in the i-th domain to a set of capabilities.
• ses cxti : Sesi → Cxti , a function mapping eachsession in the i-th domain to the local state when
the session is established.
• URAi ⊆ Usri × Rolei , a many-to-many user-torole assignment relation.
• RPAi ⊆ Rolei × Peri , a many-to-many role-topermission assignment relation.
• UCA j,i : Usr j → P (Capi ), a function mapping
each user in the j-th domain to a set of capabilities.
• CRAi ⊆ Capi × Rolei , a many-to-many capabilityto-role assignment relation.
• CPAi ⊆ Capi × Peri , a many-to-many capabilityto-permission assignment relation.
• SRAi ⊆ Cxti × Rolei , a many-to-many context-torole assignment relation.

• SCAi ⊆ Cxti × Capi , a many-to-many context-tocapability assignment relation.
These components satisfy the following conditions:(C0-1) ses ri (s) ⊆ {r | ⟨ses ui (s), r⟩ ∈ URAi }, means
any role activated by a session is one that is assigned to the user who establishes the session.
(C0-2) ses ri (s) ⊆ {r | ⟨ses cxti (s), r⟩ ∈ SRAi }.
(C0-3)∪ Session s has the permissionsr∈ses ri (s) {p|⟨r, p⟩ ∈ RPAi }.
(C0-4) ses ci (s) ⊆ {c | ⟨ses ui (s), c⟩ ∈ UCAi }, means
any capability activated by a session is owned by
the user who establishes the session.
(C0-5) ses ci (s) ⊆ {c | ⟨ses cxti , c⟩ ∈ SCAi }.
(C0-6) For any r ∈ Rolei and c ∈ Capi , if ⟨c, r⟩ ∈CRAi then session s has the permissions thatare determined by (C0-2) above, otherwise(i.e.,⟨c, r⟩ ̸∈ CRAi ) then s has the permissions∪c∈ses ci (s) {p | ⟨c, p⟩ ∈ CPAi }.
The C2RBAC0 is a pure extension of the CRBAC
model, which was introduced by our previous work
based on the RBAC96 model. Here, the components
Contextsi , ses cxti , SRAi , and SCAi are the extended
parts from CRBAC, each of which plays the following roles: Contexti denotes the set of all possible local
states in the i-th domain; function ses cxti determines
the context when each session is established; relations
SRAi and SCAi determine the set of roles and capabilities that can be activated in each state, respectively.

3.2

Delegation of authority

Similar to the CRBAC proposed in our previous study,
various types of delegations are provided in C2RBAC.
As described in (Hasebe et al., 2010), the delegation

using capability transfer is modeled 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 the capability createdin the previous steps to another user.
For each of the first two steps, we can consider thefollowing two cases. For Step 1, there are two cases
in which the authority to create a new capability isbased on the (1) role or (2) capability of the user who
created the capability. For Step 2, there are two cases
in which the authority to be delegated assigned to thecreated capability is either (3) a role or (4) a capability. According these cases, we classify delegations
into four types D1–D4 as shown in Table 2.
Create from
Assign(3) Role(4) Capability

(1)
Role

(2)
Capability

D1
D2

D3
D4

Table 2: Types of Delegations.

We define the delegation of authority as the statetransitions in the model.
Definition 2 (Basic operations for delegation). The
basic operations for delegation (i.e., creation, assignment, and transfer) are defined by the following rulesof state transitions for a model. Here, CHi (called
creation history) is a set of quadruple of the form⟨u, σ, x, c⟩ with u ∈ Usri , σ ∈ S, x ∈ Rolei ∪Capi , andc ∈ Capi . Intuitively, an element ⟨u, σ, x, c⟩ in CHimeans that user u creates a capability c in state σ by
executing his/her authority assigned to the role or capability x. Thus, CHi indicates the history of creationsof capabilities in the i-th domain.
Creation rule: Let σ be a state such that ⟨u, σ, x, c⟩ ∈CHi .
(1) If r ∈ Rolei with ⟨u, r⟩ ∈ URAi , ⟨r, create⟩ ∈ RPAi ,and ⟨σ, r⟩ ∈ SRAi , then this rule can be applied toσ and defines new state σ′ by replacing Capi andCHi in σ with Cap′i and CHi′ , respectively, suchthat:
• Cap′i := Capi ∪ {c′ } where c′ ̸∈ Capi ;• CHi′ := CHi ∪ {⟨u, σ, r, c′ ⟩}.
(2) If ⟨u, c⟩ ∈ UCAi , ⟨c, create⟩ ∈ CPAi , and ⟨σ, c⟩ ∈SCAi , then this rule can be applied to σ and defines
new state σ′ by replacing Capi and CHi in σ with
Cap′i and CHi′ , respectively, such that:• Cap′i := Capi ∪ {c′ } where c′ ̸∈ Capi ;• CHi′ := CTi ∪ {⟨u, σ, c, c′ ⟩}.
The state transitions of these types are denoted bycre(u,r,c′ )cre(u,c,c′ )σ ⇝ σ′ (for Case (1)) and σ ⇝ σ′ (for Case(2)), respectively, and we can say “capability c′ is created by user u from his role r (from his capability c,
resp.)”
Assignment rule: Let σ be a state, u ∈ Usri , and c′(∈ Capi ) is created by u.
(3) If R′ ⊇ R ⊇ Rolei in σ such that ⟨u, r⟩ ∈ URAi
for any r ∈ R, then this rule can be applied to σ
and defines new state σ′ by replacing CRAi in σwith CRA′i := CRAi ∪ {⟨c′ , r⟩ | r ∈ R′ } and SRA′i :=SRAi ∪ {⟨σ, r⟩ | σ ∈ S, r ∈ R′ }.
(4) If P ⊇ Peri in S, then this rule can be applied toσ and defines new state σ′ by replacing CPAi in S
with CPA′i := CPAi ∪ {⟨c′ , p⟩ | p ∈ P} and SCA′i :=SCAi ∪ {⟨σ, c′ ⟩ | σ ∈ S}.
State transitions of these types are denoted byasg(R′ ,c′ )asg(P′ ,c′ )σ ⇝ σ′ (for Case (3)) and σ ⇝ σ′ (for Case(4)), respectively, and we can say “roles R′ (permissions P′ , resp.) is assigned to capability c”.
Transfer rule: Let σ be a state in which u ∈ Usri , u′ ∈Usr j , c′ ∈ Capi , and c′ is created by u (where i and j
may be the same domain number). Then this rule canbe applied to σ and defines new state σ′ by replacing
UCAi, j in σ with UCA′i, j := UCAi, j ∪ {⟨u′ , c′ ⟩} . Statetrans(u,u′ ,c′ )transitions of this type are denoted by σ⇝σ′
and we can say “capability c′ is transferred from user
u to the other user u′ ”. In particular, such transfer iscalled a cross-domain transfer if i ̸= j.
By combining these basic operations, we define
the delegations of types (D1) to (D4).
Definition 3 (Delegation). The delegations of types(D1) to (D4) are sequential compositions of basic operations Creation, Assignment, and Transfer as follows (where “;” is used to denote the sequentialcomposition operator):(D1) σ(D2) σ(D3) σ(D4) σcre(u,c′ ,r) asg(R′ ,c′ ) trans(u,u′ ,c′ )

⇝

;

⇝

;

⇝

;

⇝

;

⇝

;

⇝

;

⇝

;

⇝

;

⇝

σ′ .

⇝

σ′ .

⇝

σ′ .

⇝

σ′ .

cre(u,c′ ,r) asg(P′ ,c′ ) trans(u,u′ ,c′ )cre(u,c′ ,c)asg(R′ ,c′ )trans(u,u′ ,c′ )cre(u,c′ ,c)asg(P′ ,c′ )trans(u,u′ ,c′ )For readability, we also use the following notations todenote delegations of these types:(D1) σ(D2) σD1(u,u′ ,c′ ,r,R′ )

⇝

σ′ .

⇝

σ′ .

D2(u,u′ ,c′ ,r,P′ )(D3) σ(D4) σD3(u,u′ ,c′ ,c,R′ )⇝D4(u,u′ ,c′ ,c,P′ )

⇝

σ′ .
σ′ .

3.3 Extended models
Based on the C2RBAC0 model, we develop a
C2RBAC family similar to RBAC96 model (Sandhu
et al., 1996). C2RBAC1 and C2RBAC2 are extensions of C2RBAC0 by introducing role hierarchy andconstraints, respectively, that are essentially the same
as for RBAC1 and 2. Furthermore, similar to the
RBAC96 model, C2RBAC3 is obtained by the combination of C2RBAC1 and C2RBAC2.
Formally, C2RBAC1 is obtained from C2RBAC0
by adding the following component:• rhi , a partial order over Rolei , called role hierarchy. (The infix notation r′ ≥i r is also used to denote role hierarchy and we can say “r′ is seniorrole of r” or “r is junior role of r′ ” in the same
sense as in the RBAC96 model.)C2RBAC1 is as C2RBAC0 (Definition 1) whereconditions (C0-1), (C0-2), (C0-3), and (C0-6) arerespectively replaced with the following conditions:(C1-1), (C1-2), (C1-3), and (C1-6).
(C1-1) ses ri (s) ⊆ {r | ∃r′ ≥i r(⟨ses ui (s), r′ ⟩ ∈URAi )}, means any role activated by a session is
one that is assigned to the user who establishes thesession.
(C1-2) ses ri (s) ⊆ {r | r′ ≥i r(⟨ses cxti (s), r′ ⟩ ∈SRAi )}.
(C1-3)
Session s has the permissions∪′r′ ∈ses ri (s) {p | ∃r ≥i r (⟨r, p⟩ ∈ RPAi )}.
(C1-6) For any r, r′ ∈ Rolei and c ∈ Capi , if ⟨c, r⟩ ∈CRAi with r′ ≥i r, then session s has the permissions that are determined by (C0-2) above for r′ ,otherwise∪(i.e., ⟨c, r⟩ ̸∈ CRAi ) then s has the permissions c∈ses ci (s) {p | ⟨c, p⟩ ∈ CPAi }.
The former two are related to the role hierarchy,
that are the same as in the RBAC96, while the latter
two guarantee the inheritance of permissions with respect to the role hierarchy.
On the other hand, C2RBAC2 is obtained byadding various constraints. Typical examples are as
follows.
• Lifetime• The number of activations• The number of creations of new capabilities• The inheritance of permissions related to role hierarchy• The number of hops of capability transfer
Here we note that the difference between constraints and contexts: a state of the system is defined
as an element in Cxt, while the attributes of capabilities are supposed to be not involved in Cxt.

4CASE STUDY

We demonstrated the effectiveness of C2RBAC forthe eight items described in Section 2 using an example of collaborative development between four companies, Companies A, B, C, and D. The example scenario consists of the following five steps. The graphical presentation is shown in Figure 2, where the solidand dashed arrows represent the flows of the delegation of authority and access to resources, respectively.
Step 1. To start collaborative development with
Company B (Co.B), the administrator in Company A (Co.A) assigns the developer role to theManager and Alice in Co.A.
Step 2. Alice creates a capability (called c1 ) by executing the authority of the developer role and delegates it to Bob, a temporary member in Alice’s
team. This capability is limited in the executionof authority by the following constraints and contexts.
• Constraints: expiration date, and prohibition ofcapability creation and delegation.
• Contexts: Restriction of the available devices.
This delegation of authority allows Bob to accessthe resources required by him to work in terms ofthe devices authorized by this capability. Moreover, Bob cannot create new capabilities and delegate them to others. To realize the delegation of
authority in this step, the base model needs to provide items (1) and (2) presented in Table 1 in Section 2.
Step 3. Alice creates another capability (called c2 )from her developer role, and delegates it to Carolin Co.B. Here, there is no constraints on c2 fordelegation of authority, because Co.B is taking responsibility to develop and manage the web application and analyze data and outsources sometasks to Company C and D (Co.C and Co.D, respectively). On the other hand, c2 is assigned permissions to access the resources with the following constraints.
• Constraints: Expiration date.
To realize the delegation of authority in this step,
the base model needs to provide item (4) in Table
1.

Company A (Co. A)

Company B (Co. B)

devel
Administrator

Manager

devel

c2

c1
Alice

Carol

Bob

Customers’
Data

Data for
Analysis

Web LogCompany C (Co. C)c3c4
Company D (Co. D): delegation of authority: access

David

devel

: role “developer”

ci: i-th capability

Eve

Figure 2: A scenario of collaborative development with multiple companies in dynamic environments.

Step 4. Carol creates a capability (called c3 ) fromc2 , and delegates it to David, a data analyst in
Company C (Co.C). Access rights to the storage
are assigned to c3 for data analysis. Here, c3 inherits constraints of c2 , and additional constraints
are imposed, resulting in the following constraints
and contexts.
• Constraints: expiration date, and prohibition ofcapability creation and delegation.
• Contexts: limitation of a source IP address.
To realize the delegation of authority in this step,
the base model needs to support item (7) in Table
1.
Step 5. Carol creates another capability (called c4 )from c2 to access resources related to web application development and delegates it to Eve, an engineer in charge of the web application developmentin Company D (Co.D). The capability c4 also inherits the constraints of c2 . To continuously operate the web application, Carol allows Eve to create
new capabilities and delegate them for a limited
number of times as a constraint to only engineers
who belong in Co.D using contexts. As a result,c4 is assigned the following constraints and contexts.

delegate capabilities only to the members in thesame company, and they perform their operations
using only the permitted devices. Therefore, thebase model needs to realize items (2), (4), (6), and(7) in Table 1.
Capabilities can be revoked by anyone who has
an upper-level capability in a hierarchy of capability;
for example, Alice can revoke all capabilities such as
c1 , c2 , c3 , and c4 in this case study. If a capability is
revoked, all lower capabilities are also revoked simultaneously. For example, if Alice revokes c3 , c4 is also
revoked. Furthermore, anyone who has an upper-level
capability can confirm a history of creation and thedelegation of all lower-level ones. These features satisfy items (3), (5), and (8) in Table 1. Consequently,
we have shown that C2RBAC can support all items inTable 1.
The above scenario can be formally described by
the state transitions shown in Section 3.2 as follows.
Step 1. D1 (Admin, Manager, devel, admin, {devel})and D1 (Admin, Alice, devel, admin, {devel}).
Step 2. D2 (Alice, Bob, c1 , devel, {devel}).

• Constraints: expiration date, and limit on thenumber of creations and delegations.
• Contexts: restriction of available devices, andrestriction of delegation range.

Step 3. D2 (Alice,Carol, c2 , devel,{May(Data, access), May(Web, access)}).

Owing to the constraints and contexts, Eve can

Step 5. D4 (Carol, Eve, c4 , c2 , {May(Web, access)}).

Step 4. D4 (Carol, David, c3 , c2 , {May(Data, access)}).

5 CONCLUSIONS AND FUTURE
WORK
We proposed a new access control model, C2RBAC,
based on CRBAC with a mechanism of context-aware
control. To realize secure, flexible, and scalable
access control for dynamic environments, C2RBAC
provides context-aware capability management, suchas restricting delegation range, while maintaining
the flexibility and scalability of CRBAC. Similar to
CRBAC, we described model families C2RBAC1,C2RBAC2, and C2RBAC3. In addition, we demonstrated the effectiveness of C2RBAC by comparing itwith other models and using an example of collaborative development.
For future work, we will define protocols ofcontext-aware capability management to feasibly implement C2RBAC and develop a formal method for
security verification. In particular, we are interested
in a method for detecting unintended capability propagation by searching all possible delegation processes
using a model checking approach. We are also interested in implementing a prototype of C2RBAC.

ACKNOWLEDGMENT
We would like to thank the anonymous reviewers
whose comments/suggestions helped improve thismanuscript.

REFERENCES
Al-Kahtani, M. A. and Sandhu, R. (2002). A model for
attribute-based user-role assignment. In 18th Annual
Computer Security Applications Conference, 2002.
Proceedings., pages 353–362. IEEE.
Baldauf, M., Dustdar, S., and Rosenberg, F. (2007). A survey on context-aware systems. International Journalof Ad Hoc and Ubiquitous Computing, 2(4):263–277.
Covington, M. J., Long, W., Srinivasan, S., Dev, A. K.,
Ahamad, M., and Abowd, G. D. (2001). Securingcontext-aware applications using environment roles.
In Proceedings of the sixth ACM symposium on Access control models and technologies, pages 10–20.
Hasebe, K. and Mabuchi, M. (2010). Capability-role-based
delegation in workflow systems. In IEEE/IFIP 8th International Conference on Embedded and Ubiquitous
Computing, EUC 2010, Hong Kong, China, 11-13 December 2010, pages 711–717. IEEE Computer Society.
Hasebe, K., Mabuchi, M., and Matsushita, A. (2010).
Capability-based delegation model in rbac. In Proceedings of the 15th ACM symposium on Access control models and technologies, pages 109–118.

Jin, X., Krishnan, R., and Sandhu, R. (2012). A unified
attribute-based access control model covering dac,
mac and rbac. In IFIP Annual Conference on Data
and Applications Security and Privacy, pages 41–55.
Springer.
Kulkarni, D. and Tripathi, A. (2008). Context-aware rolebased access control in pervasive computing systems.
In Proceedings of the 13th ACM symposium on Access
control models and technologies, pages 113–122.
Levy, H. M. (1984). Capability-Based Computer Systems.
Butterworth-Heinemann, USA.
Park, S.-H., Han, Y.-J., and Chung, T.-M. (2006). Contextrole based access control for context-aware application. In International Conference on High Performance Computing and Communications, pages 572–
580. Springer.
Sandhu, R. S., Coyne, E. J., Feinstein, H. L., and Youman,
C. E. (1996). Role-based access control models. Computer, 29(2):38–47.
Schefer-Wenzl, S. and Strembeck, M. (2013). Modelling
context-aware rbac models for mobile business processes. International Journal of Wireless and Mobile
Computing 3, 6(5):448–462.
Snyder, L. (1981).
Formal models of capabilitybased protection systems. IEEE Trans. Comput.,
30(3):172–181.
Strembeck, M. and Mendling, J. (2011). Modeling Processrelated RBAC Models with Extended UML Activity Models. Information and Software Technology,
53(5):456–483.
Zhang, X., Oh, S., and Sandhu, R. S. (2003). PBDM: aflexible delegation model in RBAC. In Ferrari, E.
and Ferraiolo, D. F., editors, 8th ACM Symposium on
Access Control Models and Technologies, SACMAT
2003, Villa Gallia, Como, Italy, June 2-3, 2003, Proceedings, pages 149–157. ACM.