# CBDAC: Context-Based Dynamic Access Control Model Using Intuitive 5W1H for Ubiquitous Sensor Network

Authors: Jiseong Son; Jeong-Dong Kim; Hong-Seok Na; Doo-Kwon Baik
Journal: International Journal of Distributed Sensor Networks
 (2015)

---

## Abstract

Currently, access control is facing many issues for information protection in the ubiquitous sensor network (USN) environment. In particular, dynamic access control is a central problem where context always changes because of volatile ubiquitous sensors. The use of context is important in USN. In this paper, we focus on the context-driven privacy protection model. In context-based access control research, the access permission technique that uses context is being intensely investigated because of the ease with which various dynamic access permissions can be assigned in accordance with the various changes in context. A key feature of this approach is dynamic access control. Therefore, we propose a model for privacy preservation that is context-based dynamic access control that uses intuitive 5W1H for USN. According to this model, the access control strategy can be determined dynamically based on context elements and subject attributes, in addition to objects and operations, using access control entities; therefore, it is relatively easy to infer the dynamic access control of context expressivity both accurately and efficiently.


---

## Body

## 1. Introduction

Ubiquitous computing is an environment unrestricted by spatiotemporal conditions [1]. It allows computing among humans, objects, and information through the interaction of diverse sensors immersed in the ubiquitous sensor network (USN) environment [2]. The context is information produced in the diverse ubiquitous sensors, and such information provides various services through an intersystem information exchange in various domains and interaction. Such context is volatile information strongly influenced by environmental elements, such as time and space. Therefore, in order to process such information, a dynamic processing technology is required in USN. Furthermore, because the access permission to entities that will perform the service according to the changing context is also volatile, an approach control model to accommodate the dynamic change is required. In other words, despite the fact that the same user gains access to a certain system, depending on the surrounding context (e.g., time, space, and user), the user access authorization can change dynamically.There are already preexisting studies on various technologies and techniques to process context [3–10]. Many of the studies offered ontological-modeling-based techniques for the processing of semantic context [7–10]. The main issue of the ontology-based context-aware model is the maintenance of interoperability between the modeling level and context information. The modeling level for context recognition is divided into tightly and loosely coupled pervasive system modeling. Tightly coupled pervasive system modeling can provide high-performance services that can be specialized in certain domains, but additional time and cost are incurred for the additional processes necessary for analyzing the context information of different domains. Loosely coupled pervasive system modeling is advantageous in that it is independent of the domain and utilizes a variety of context information. However, it is less appealing because it is not adequate for processing inferences or providing the high-performance service required for processing context application (generating context B through context A) and context combination (context B + context C = context D in context A) processing.In order to remedy such problems, in a previous research [11] that we conducted, we proposed an intuitive ontology-based CA5W1HOnto model that supports semantic context through the use of 5W1H. In [11], in order to express context information, ontological concepts and properties were utilized for defining the semantic context and a wide range of standardized relationships. Such applications are very advantageous in terms of adaptability and interoperability with the ontologies already developed in diverse domains. Because of these features, the CA5W1HOnto model exhibits high levels of expandability and recyclability.Role-based access control (RBAC) [12–14] is the most representative access control model. Recent studies proposed various extended RBAC (such as relationship-based, purposed-based, and context-based). The basic RBAC concept is as follows: permissions are assigned to functional roles within an enterprise or individual user, and then the necessary permissions are authorized by assigning them to a role or a set of roles [15]. The role-based model grants (or denies) a subject access to data regardless of the request context. In addition, a privacy policy is mainly concerned with which data object is used for which purposes. Thus, purpose is a central concept in many privacy-protecting access control models [16–19].Unfortunately, privacy protection cannot be readily conducted by traditional RBAC models. The first reason is that whereas traditional RBAC models focus on which user is performing which action on which data object, privacy policies are concerned with which data object is used [20]. Another reason for the difficulty of privacy protection is that the comport level of data usage varies from individual to individual [15]. In addition, in order to process the dynamic context change in role- and purpose-based research, conditions or constraints were defined to support the changing access control. Nevertheless, conditions or constraints are defined only in part by the developer; hence, they have limitations in covering/supporting the various context changes required in a ubiquitous computing environment. In this paper, we focus on the context-driven privacy protection model. In fact, context and access control are essentially interdependent. In context-based access control research, an access permission technique that uses context is being intensely investigated because of the ease with which various dynamic access permissions can be assigned in accordance with the various changes in context [21–29].In this paper, we propose aCA5W1HOnto-based dynamic access control (CBDAC) model for the USN environment. The proposed model makes use of the ontological concept using 5W1H to process the context information. Furthermore, the proposed model guarantees privacy protection when processing the context information in various domains and assigns access permission without any limitation to certain domains. In other words, access permission is assigned dynamically according to the change in context information such that, even for a subject with the same role, access permission is defined differently depending on the context information and access condition. Not only does the proposed model authorize access based on roles, which is the key concept of RBAC, but also dynamic access control is also possible because access permission is assigned based on context information, access condition, and intended goal.Consequently, we address this goal by presenting a comprehensive approach to dynamic access control management, which is the fundamental problem on which context-aware access control can be developed. In our paper, the purpose term has been superseded by goal. Furthermore, our notion of role attributes is closely related to the notions presented in [30, 31] in that it allows the specification and enforcement of context-based policies in RBAC. However, we build upon and further elaborate the existing notions with the presence of conditional roles with context-aware entities in order to achieve fine-grained administrative access control.The remainder of this paper is organized as follows. Section2 describes the background and related work; the model of the CBDAC that formally defines the notation of access permission is illustrated in Section 3; Section 4 describes its use case scenario and implementation. Finally, in Section 5, we suggest the conclusion and future work.


## 2. Background and Related Work

### 2.1. CA5W1HOnto

Context refers to a special form of knowledge and, for this reason, it constitutes an important modeling requirement that is the tradeoff between expressiveness and complexity. To resolve the tradeoff issue that concerns context-aware modeling, ontology (i.e., OWL-DL) may be utilized. The ontological concept is an important component in determining the expressiveness of knowledge and reasoning capability for context awareness. Ontology amply expresses concepts and their relationships and automatic reasoning in processing context based on the expressive capacity. The modelCA5W1HOnto is a context-aware ontological model based on the five Ws and one H (5W1H) [11]. Furthermore, CA5W1HOnto is a method for interpreting and abstracting semantic context designed to support the intuitive integration of different context-aware schemas, to which the maxim (such as why, who, what, where, when, and how) is applied [11].Figure1 shows the key elements that constitute the CA5W1HOnto model that consists of <Concept, Instance, Context> triples, where the first two elements of the triple set utilize the properties defined through the existing ontology. The Context element carries all six attributes of the maxim. The element of Context contains various contextual activities. In turn, the Context component helps define the basic characteristics of the maxim and the schemas utilized among ontological concepts. The CA5W1HOnto model proffers services tailored for a specific time, space, and set of user preferences across different domains. The model performs modeling of the essential elements by defining, in accordance with the maxim, the context required for the integration and interoperability of the defined contextual information.Figure 1
Conceptual model ofCA5W1HOnto.TheCA5W1HOnto model defines, in the unit of<Concept, Instance, Context>, the ontological elements (e.g.,concept,instance,datatype,data property, andobject property) for context-aware definition. By defining each in an independent component module, adaptability and independence are guaranteed when developing a context-aware model applicable to diverse domains. In other words, the maxim-applied context-aware modeling technique is an intuitive model in nature and thereby allows interoperability between systems or models throughout integration and sharing of schemas that belong to diverse domains. Detailed explanation ensues hereunder as to how to map between the properties of the maxim and the context-aware elements defined by the CA5W1HOnto model.One of the merits of ontologically modeling contextual information lies in its ability to automatically extract new knowledge on current context, in addition to providing ample formalism with streamlined expressiveness about the knowledge.


### 2.2. RBAC

RBAC was proposed by Sandhu et al. in 1996 [32]. The fundamental idea of RBAC is to authorize data access based on user role. Role means the function of the user or the organization, and such role and user have anN:N relationship. In other words, the user can have various different roles, and one role can be assigned to several users. The relationships among roles are defined through the role hierarchy. RBAC can be applied to various environments or applications through simple role-based access control, where the role attributes are associated with the roles in order to enforce global constraints such as the principle of the separation of duty [33]. That is, there is a limitation to providing privacy protections by defining conditions flexibly based on the attributes of the role (e.g., conditional activation, role deactivation, and role membership qualification). RBAC can be divided into the more detailed attributes of roles, permissions, users, and sessions, and a more diverse definition of constraints is necessary [8, 9]. In addition, because the role hierarchy is a predefined static role, in dynamic environments such as context-aware, wireless computing, and ubiquitous computing environments, where a volatile context is produced, instead of determining the access control permission based on simply on role, dynamic access control is required for the process of such a volatile context.Purpose-based Access Control (PBAC) [34] defines the access control model using not only an RBAC-based role, but also purpose as a key concept. Purpose describes the reasons for data collection and data access. PBAC defines the relationships among purposes with the purpose hierarchy (purpose tree) and, based on this, the intended and access purposes are specified. Access purpose specifies the purpose for the access when a request for data access is made. When the user makes a request for data access, the access control engine compares the access and intended purposes of the data requested by the user and then verifies whether the user has access authorization. However, the access purpose of the PBAC is declared by the users, which implies low flexibility, and the storage of privacy metadata is based on labeling schemes, which is triggered overhead.Dynamic Purpose-based Access Control (DPBAC) [35] includes a dynamic concept in the PBAC model. In order to implement strengthened privacy preservation, DPBAC separates the access purpose authorization from the access decision. For the protection of privacy data, the data provider predefines the intended purpose (AIP or PIP). In contrast, the data owner holds the responsibility for the policy that manages the authorization of the access purpose. DPBAC defines the conditional role and supports the preexisting RBAC and other dynamic access controls. Because the conditional role compares the predefined static role based on subject attributes and context attributes of the system, it dynamically determines the access purpose and purpose compliance.Conditional Purpose-based Access Control Model with Dynamic Role (CPBAC) [20] makes use of the preexisting PBAC and DPBAC to support the conditional role. In CPBAC, the conditional intended purpose is proposed so that data access is permitted only when a certain purpose satisfies some conditions. In order to fulfill such a requirement, the data provider should predefine the intended purpose for the protection of the privacy data and set the scope of the data to be made publicly.


### 2.3. Context-Based Access Control Models

The concept of the basic RBAC model grants or denies role access to data regardless of the requested context. However, the requested context affects the decision to access objects or systems. In other words, context information provides significant access control parameters. For example, in mobile banking systems, environmental context such as location, time, and others could affect the access decision to grant or deny data access to the account or operating function of the banking system. For this reason, extended access control models based on RBAC were proposed to support context information [21–29].CRBAC [21] is a contextual role-based access control authorization model for electronic patient records (EPRs). Contextual authorizations use the environmental information available at access time, such as user/patient relationship, in order to determine whether a user is allowed to access an EPR resource. This model extends RBAC by data-access rules for processing the context of large-scale healthcare. The data-access rules are defined by a five-tuple <Role, Privilege-Type, Operation, Object, Authorization-Type>. The five-tuple represents more expressions than the basic RBAC. However, a logical expression of CRBAC is difficult for the modeling that uses data-access rules. Another proposed contextual extension of RBAC is the Attribute-Based Access Control (ABAC) model [22]. The ABAC model authorizes or denies service access based on the attributes communicated by the subject. In order to specify the attribute-based policies, a data structure that uses algebraic operations was proposed. Geo-RBAC is an access control model for processing spatial and location-based information by expanding RBAC [23]. In Geo-RBAC, spatial entities are used for modeling objects, user positions, and geographically bounded roles. A physical position includes the information provided from mobile devices or smartphones and logical, device-independent position information such as roads, villages, buildings, or locations. Geo-RBAC is a flexible model for spatial information processing with high reusability. Generalized Temporal Role-Based Access Control (GTRBAC) [24] proposed the access control model to consider the time context and offered an extended RBAC model capable of expressing a wider range of temporal constraints. In particular, this model is designed possibly not only for period constraints, but also for the regular expressions of roles, user-role assignments, and role-permission assignments. The CAP model [25] is the access control model for resources in pervasive computing environments. This model consists of a two-step access control with the user session registering to the domain authority and the session agent self-governing access through the session permission assignment database. Dynamic Role-Based Access Control model (DRBAC) [26] extends the basic RBAC model to support the dynamic context information. This model dynamically adjusts the static role and permission assignments based on context information but depends on a central authorizer to change the active role of the user’s agent according to context change. Carminati et al. [27] proposed an access control model for the purpose of controlling information sharing in a web-based social network. This model uses the rule-based approach to specify access policies. The context of the certified users is defined by the type, depth, and trust level of the relationship among the nodes in the network. The difference between such a model and the conventional access control system is that access control enforcement is conducted on the client side through semidecentralized architecture. RelBac [28] proposed permissions as being relationships between subjects and objects, where subjects and objects are entity sets, and permissions are a relationship set. The novel idea that this model presents is that, for the process of dynamic contexts, it formalizes the binary relationship between subjects and objects as permissions. SitBAC [29] is a model that utilizes those situations that define context elements and attributes for applying context to the access control. Furthermore, in this research, an inference is supported with OWL-DL and SWRL. However, SitBAC is specialized to a domain called healthcare; hence, it has limitations with respect to the processing context of other domains.


## 2.1. CA5W1HOnto

Context refers to a special form of knowledge and, for this reason, it constitutes an important modeling requirement that is the tradeoff between expressiveness and complexity. To resolve the tradeoff issue that concerns context-aware modeling, ontology (i.e., OWL-DL) may be utilized. The ontological concept is an important component in determining the expressiveness of knowledge and reasoning capability for context awareness. Ontology amply expresses concepts and their relationships and automatic reasoning in processing context based on the expressive capacity. The modelCA5W1HOnto is a context-aware ontological model based on the five Ws and one H (5W1H) [11]. Furthermore, CA5W1HOnto is a method for interpreting and abstracting semantic context designed to support the intuitive integration of different context-aware schemas, to which the maxim (such as why, who, what, where, when, and how) is applied [11].Figure1 shows the key elements that constitute the CA5W1HOnto model that consists of <Concept, Instance, Context> triples, where the first two elements of the triple set utilize the properties defined through the existing ontology. The Context element carries all six attributes of the maxim. The element of Context contains various contextual activities. In turn, the Context component helps define the basic characteristics of the maxim and the schemas utilized among ontological concepts. The CA5W1HOnto model proffers services tailored for a specific time, space, and set of user preferences across different domains. The model performs modeling of the essential elements by defining, in accordance with the maxim, the context required for the integration and interoperability of the defined contextual information.Figure 1
Conceptual model ofCA5W1HOnto.TheCA5W1HOnto model defines, in the unit of<Concept, Instance, Context>, the ontological elements (e.g.,concept,instance,datatype,data property, andobject property) for context-aware definition. By defining each in an independent component module, adaptability and independence are guaranteed when developing a context-aware model applicable to diverse domains. In other words, the maxim-applied context-aware modeling technique is an intuitive model in nature and thereby allows interoperability between systems or models throughout integration and sharing of schemas that belong to diverse domains. Detailed explanation ensues hereunder as to how to map between the properties of the maxim and the context-aware elements defined by the CA5W1HOnto model.One of the merits of ontologically modeling contextual information lies in its ability to automatically extract new knowledge on current context, in addition to providing ample formalism with streamlined expressiveness about the knowledge.


## 2.2. RBAC

RBAC was proposed by Sandhu et al. in 1996 [32]. The fundamental idea of RBAC is to authorize data access based on user role. Role means the function of the user or the organization, and such role and user have anN:N relationship. In other words, the user can have various different roles, and one role can be assigned to several users. The relationships among roles are defined through the role hierarchy. RBAC can be applied to various environments or applications through simple role-based access control, where the role attributes are associated with the roles in order to enforce global constraints such as the principle of the separation of duty [33]. That is, there is a limitation to providing privacy protections by defining conditions flexibly based on the attributes of the role (e.g., conditional activation, role deactivation, and role membership qualification). RBAC can be divided into the more detailed attributes of roles, permissions, users, and sessions, and a more diverse definition of constraints is necessary [8, 9]. In addition, because the role hierarchy is a predefined static role, in dynamic environments such as context-aware, wireless computing, and ubiquitous computing environments, where a volatile context is produced, instead of determining the access control permission based on simply on role, dynamic access control is required for the process of such a volatile context.Purpose-based Access Control (PBAC) [34] defines the access control model using not only an RBAC-based role, but also purpose as a key concept. Purpose describes the reasons for data collection and data access. PBAC defines the relationships among purposes with the purpose hierarchy (purpose tree) and, based on this, the intended and access purposes are specified. Access purpose specifies the purpose for the access when a request for data access is made. When the user makes a request for data access, the access control engine compares the access and intended purposes of the data requested by the user and then verifies whether the user has access authorization. However, the access purpose of the PBAC is declared by the users, which implies low flexibility, and the storage of privacy metadata is based on labeling schemes, which is triggered overhead.Dynamic Purpose-based Access Control (DPBAC) [35] includes a dynamic concept in the PBAC model. In order to implement strengthened privacy preservation, DPBAC separates the access purpose authorization from the access decision. For the protection of privacy data, the data provider predefines the intended purpose (AIP or PIP). In contrast, the data owner holds the responsibility for the policy that manages the authorization of the access purpose. DPBAC defines the conditional role and supports the preexisting RBAC and other dynamic access controls. Because the conditional role compares the predefined static role based on subject attributes and context attributes of the system, it dynamically determines the access purpose and purpose compliance.Conditional Purpose-based Access Control Model with Dynamic Role (CPBAC) [20] makes use of the preexisting PBAC and DPBAC to support the conditional role. In CPBAC, the conditional intended purpose is proposed so that data access is permitted only when a certain purpose satisfies some conditions. In order to fulfill such a requirement, the data provider should predefine the intended purpose for the protection of the privacy data and set the scope of the data to be made publicly.


## 2.3. Context-Based Access Control Models

The concept of the basic RBAC model grants or denies role access to data regardless of the requested context. However, the requested context affects the decision to access objects or systems. In other words, context information provides significant access control parameters. For example, in mobile banking systems, environmental context such as location, time, and others could affect the access decision to grant or deny data access to the account or operating function of the banking system. For this reason, extended access control models based on RBAC were proposed to support context information [21–29].CRBAC [21] is a contextual role-based access control authorization model for electronic patient records (EPRs). Contextual authorizations use the environmental information available at access time, such as user/patient relationship, in order to determine whether a user is allowed to access an EPR resource. This model extends RBAC by data-access rules for processing the context of large-scale healthcare. The data-access rules are defined by a five-tuple <Role, Privilege-Type, Operation, Object, Authorization-Type>. The five-tuple represents more expressions than the basic RBAC. However, a logical expression of CRBAC is difficult for the modeling that uses data-access rules. Another proposed contextual extension of RBAC is the Attribute-Based Access Control (ABAC) model [22]. The ABAC model authorizes or denies service access based on the attributes communicated by the subject. In order to specify the attribute-based policies, a data structure that uses algebraic operations was proposed. Geo-RBAC is an access control model for processing spatial and location-based information by expanding RBAC [23]. In Geo-RBAC, spatial entities are used for modeling objects, user positions, and geographically bounded roles. A physical position includes the information provided from mobile devices or smartphones and logical, device-independent position information such as roads, villages, buildings, or locations. Geo-RBAC is a flexible model for spatial information processing with high reusability. Generalized Temporal Role-Based Access Control (GTRBAC) [24] proposed the access control model to consider the time context and offered an extended RBAC model capable of expressing a wider range of temporal constraints. In particular, this model is designed possibly not only for period constraints, but also for the regular expressions of roles, user-role assignments, and role-permission assignments. The CAP model [25] is the access control model for resources in pervasive computing environments. This model consists of a two-step access control with the user session registering to the domain authority and the session agent self-governing access through the session permission assignment database. Dynamic Role-Based Access Control model (DRBAC) [26] extends the basic RBAC model to support the dynamic context information. This model dynamically adjusts the static role and permission assignments based on context information but depends on a central authorizer to change the active role of the user’s agent according to context change. Carminati et al. [27] proposed an access control model for the purpose of controlling information sharing in a web-based social network. This model uses the rule-based approach to specify access policies. The context of the certified users is defined by the type, depth, and trust level of the relationship among the nodes in the network. The difference between such a model and the conventional access control system is that access control enforcement is conducted on the client side through semidecentralized architecture. RelBac [28] proposed permissions as being relationships between subjects and objects, where subjects and objects are entity sets, and permissions are a relationship set. The novel idea that this model presents is that, for the process of dynamic contexts, it formalizes the binary relationship between subjects and objects as permissions. SitBAC [29] is a model that utilizes those situations that define context elements and attributes for applying context to the access control. Furthermore, in this research, an inference is supported with OWL-DL and SWRL. However, SitBAC is specialized to a domain called healthcare; hence, it has limitations with respect to the processing context of other domains.


## 3. CBDAC Model

In this section, we propose an overall structure and formalized definition for the CBDAC model, which is the extended form of RBAC, during the application of ontology technologies. It is ultimately aimed at guaranteeing the dynamic access condition of the data access control.Based on the RBAC model, the CBDAC model extends mainly in the aspects described following Figure2. Figure 2 shows the proposed CBDAC model that consists of theProfile Manager, Ontological Concepts, Context Manager, Concepts, andAccess Permission. In particular, at the research stage of privacy protection in the CBDAC model, theAccess Conditions andIntended Goal (that consists ofAllowable Intended Goal,Conditional Intended Goal, andProhibited Intended Goal) intoAccess Permission are significant.(i)
Profile Manager defines and manages the information onProfile andRoles with regard toSubject in order to generate context. The key concept of the RBAC model isRole, which represents a certain specific job function in an organization. ARole is assigned to theSubject, such as RBAC, by theProfile Manager. In other words, theRole of theSubject represents a working position or working function of the user/system assigned within theProfile Manager.(ii)
Ontological Conceptis defined by the ontological elements (e.g.,concept,instance,datatype,data property, andobject property). It is utilized for managing context in theContext Manager.(iii)
Context Managerconsiders the context of a subject based on CA5W1HOnto by applying 5W1H (Why, Who, What, Where, When, and How). The CA5W1HOnto model is designed to support intuitive integration of different context-aware schemas, to which the 5W1H is applied. The CA5W1HOnto model consists of <Concept, Instance, Context> triples.Concept and Instance are defined by ontological concepts described through the existing ontology.Context is the entities of concept and instance (such as time, location, user profile, and access goal) defined by 5W1H.(iv)
Concepts consist ofSubject andObject by ontological concepts. TheSubject can be a user, application, or agent; that is, theSubject is various context elements generated by ubiquitous sensors.Object is the target data, system, or services that theSubject requests.(v)
Access Permission signifies the operation of a certainrole of theSubject, whether access to a certainObject under certainAccess ConditionandIntended Goal is granted or denied. TheAccess ConditionandIntended Goal are the constituent of theAccess Permission.(vi)
Access Conditionconsists of the six elements <Goal,Role,Action,Status,Location,Time>. TheAccess Condition is used to check whether theContext (5W1H) concepts of the CA5W1HOnto are in accordance with the constituent of theAccess Condition.Figure 2
Overview of the CBDAC model.The formalized definition of Role Assignment is as follows.Definition 1 (role assignment).
(i)Subject Assignment SA⊆ Subject × Role is a many-to-many mapping relationship betweensubjects and their assignedroles.
(ii)Role Assignment RA⊆ Role×CA5W1HOnto.
(iii)Roles⊆ Role×Role are set of roles that define the function and relationship between roles.The formalized definition and simple scenario ofCA5W1HOnto is as follows.Definition 2 (CA5W1HOnto).
CA
5W1H
Onto ={<Concept, Instance, Context>∣Concept∈ Ontological Concepts, Instance ∈ Ontological Instances, Context}is context-aware modeling that processes context in Context Manager.(i)
Concept ={<sub, obj>∣sub ∈ Subject, obj∈ Object} consists of subject and object. The concept is defined by ontological concepts.(ii)
Instance ={<sub_element, obj_element>∣sub_element∈ Subject Elements, obj_element ∈ Object Elements} consists of sets of subject and object elements.(iii)
Context ={5W1H <Why, Who, What, Where, When, How>∣why∈ Why, who ∈ Who, what ∈ What, where ∈ Where, when ∈ When, how ∈ How} is a set of context-aware elements:
(a)
Who: the subject assigned role, namely, an agent that may be a person, organization, or system involved in a context;(b)
Why: the reason the context occurred;(c)
How: the action leading to the context, namely, a context that may occur when it is acted upon by another entity that is often a human or software agent;(d)
What: the access target (Object);(e)
Where: the location of the subject (including spatial information);(f)
When: the time when the context occurred.Simple Scenario. User A wants to transfer 100 dollars to friend B’s account through the mobile banking system of bank C using a SmartPhone at 00:00 AM. The available time for credit transfer on the mobile banking system is from 00:10 AM to 11:50 PM.By examining the above scenario, we can find that there are several contexts: (1) Concepts, such asUser andMobile_Banking_System; (2) Instances, such asUser_A, Transfer_Process, Mobile_Banking_System_of_Bank_C, SmartPhone, and00:00 AM; (3) Context between concepts, such asCredit_Transfer; (4) Condition, such asfrom 00:10 AM to 11:50 PM. The following represents the CA5W1HOnto model defined based on the previous scenario:CA5W1HOnto={Concept →User, Mobile_Banking_System; Instance → User_A, Transfer_Process, Mobile_Banking_System_of_Bank_C, SmartPhone, 00:00 AM Context → Credit_Transfer};Context ={5W1H(Who, Why, How, What, Where, When)}:
Why = Credit_Transfer,Who = User_A,How = Transfer_Process,What = Mobile_Banking_System_of_Bank_C,Where = GPS & SmartPhone,When = Start_Time(00:00 AM).The formalized definition of Dynamic Access Control model for dynamic access permission is as follows.Definition 3 (dynamic access control).
Dynamic Access Control DyAC ={Subject, Object, Access Permission} means that when the contexts are changed dynamically, theSubject is granted (or is denied) access to theObject by theAccess Permission. In other words, theAccess Permission is applied dynamically depending on the volatile context.The formalized definition of Access Permission is as follows.Definition 4 (access permission).
(i)Access Permission AP = {Context, Access Condition, Intended Goal} means an allowable condition whetherSubject can accessObject based onContext. This is not assigned to static roles but to conditional roles (such asAccess Conditions). Subjects of context entities dynamically activate access conditions according to their context element (such as 5W1H) during the access process.
(ii)Access Permission Assignment APA⊆ Context Manager×Access Permission determines access privileges by mapping the elements ofContext Managerto the elements ofAccess Permission. TheSubject is allowed to access theObject only if the context elements (5W1H) in CA5W1HOnto are in accordance with the condition of theAccess Permission.
(iii)Access Conditions AC ={<goal, role, action, status, location, time>∣goal∈ Goal, role ∈ Role, action ∈ Action, status ∈ Status, location ∈ Location, time ∈ Time} are the set of conditions expressed for object access:(a)
Goal: the purpose of Object access and of performing context-based system;(b)
Role: the acceptable Role set of Subject;(c)
Action: the acting range performed by Context;(d)
Status: the state of accessible Object;(e)
Location: the range of accessible location and spatial information;(f)
Time: the range of accessible time.
(iv)Intended Goal IG= {<aig, cig, pig>∣aig⊆ Goal, cig ⊆ Goal, pig ⊆ Goal} is the set of intended goals.IG is the use specified for the determination of the dynamic access permission by the subject role and goal. Consider the following:(a)
AIG: the Allowable Intended Goal (AIG) is a goal always accessible through determination of who and why inCA5W1HOnto, regardless of AC;(b)
CIG: the Conditional Intended Goal (CIG) is a conditionally accessible goal only if Context ofCA5W1HOntocorresponds with AC;(c)
PIG: the Prohibited Intended Goal (PIG) is a goal always prohibitive through determination of who and why inCA5W1HOnto, regardless of AC.
(v)Context Access CA⊆ Context×Objectis a many-to-many mapping relationship betweenCA5W1HOnto andObject.
(vi)Intended Goal Compliance IGC⊆ APA⋈IGis a one-to-one relationship between eachAP andObject, as well as boundIG.A key feature of our proposed model is that it supports not only semantic context, but also dynamic access control. Thus, in this paragraph, we described the stage to provide function definitions to facilitate the discussion of CBDAC model using the context elements and its attributes.Definition 5 (CBDAC model function).
(i)assigned_role:Subject →Role, the mapping of subjects onto a set of roles. Formally,assigned_role(s) = {r∈ Role∣<s, r>∈SA}.
(ii)access_goal_authorization:C →AP, the mapping of contextc in CA5W1HOnto ontoAP. Formally,access_goal_authorization(c)={ap∈ AP∣<c,ap>∈APA}.
(iii)intended_goal_binding:Object →IG, the mapping of objecto ontoig, which means finding the boundig of theObject.
(iv)intended_goal_compliance:C×AC×IG→{Grant_Access, Conditionally_Grant_Access, Deny_Access} is used to determine compliance among thecontexts, access condition,and theobject’s intended goal.Formally,(a)
intended_goal_compliance(c, ac, ig) =Grant_Accessiffc×ac∈ AIG;(b)
intended_goal_compliance(c, ac, ig) =Conditionally_Grant_Accessiffc×ac∈ CIG;(c)
intended_goal_compliance(c, ac, ig) =Deny_Accessiffc×ac∈ PIG.


### 3.1. Mapping CA5W1HOnto and Access Condition

In order to supportCA5W1HOnto-based dynamic access control, we herein define the mapping relationship between CA5W1HOnto construct types andAC description types. Figure 3 shows this mapping relationship.Figure 3
Mapping relationship betweenCA5W1HOnto andAC.TheWhyelement from CA5W1HOnto compares the purpose that the context is attempting to accomplish by mapping it to theGoalofAC (such asWhy∷Goal).Whocompares theSubject that produced the context with the role authorized to access the context by mapping it to theRole (such asWho∷Role).How is the process performed by the access objective to process the context, and it compares each process required for the context processing by mapping it to theAction of theAC (such asHow∷Action).What becomes theObject, that is, access objective, and theStatusbeing mapped indicates the state ofObject(such asWhat∷Status).Where indicates the location or spatial information of the context, whereasLocation compares to determine whether access permission is within the permissible location (such asWhere∷Location).When implies the time when the context was produced, andTime compares to determine whether they are within the allowed time range (such asWhen∷Time).Location,Status, andTimeclasses are subclasses ofAction. For theSubject accesses theObject,Location,Status, andTime of access condition depend on acting range because the acting range is performed by context information. Table 1 defines and explains the mapping relationship between CA5W1HOnto andAC in detail.Table 1
Mapping definition.
Mapping betweenCA5W1HOnto and AC
Definition
Why∷Goal
Compares the reason the context occurred (Why) with the purpose for Object access, and for performing context-based system (Goal). Its ingredients are Functional_Goal,and NonFunctional_Goal.
Who∷Role
Compares theSubject that produced the context (Who) with the acceptable role set of Subject (Role). Its ingredients are Actor(User and System), and Profile.
How∷Action
Compares the action leading to the contexts (How) with the acting range that is performed by context (Action). Its ingredients are Atomic_Action, Composite_Action, Expectation, Precondition, Effect, Input, Output, and the like.
What∷Status
Compares the access target context (What) with the State of accessible Object(Status). Its ingredients are Atomic_Status and Composite_Status.
Where∷Location
Compares the location of Subject (Where) with the range of accessible location (Location). Its ingredients are GPS, Atomic_Location,andComposite_Location.
When∷Time
Compares the time the occurred (When) with the range of accessible time (Time). Its ingredients are Start_Time, End_Time, and Repetition_Time.


### 3.2. Dynamic Access Decision

The important challenge for implementing role-based and PBAC models (not context-based access control model) is that it may be difficult to infer the access purpose both accurately and efficiently. With our proposed CBDAC model, the access control strategy can be determined dynamically based on the context elements (such as 5W1H) and subject attributes, in addition to the objects and operations, using access control entities (such as goal, role, action, status, location, and time), and thus it is relatively easy to infer the dynamic access control of context expressivity both accurately and efficiently. Accordingly, we determine dynamic access control by means of Definitions6, 7, and 8.Definition 6 (context attribute).
Context Attributes are defined as the set of 5W1H properties linked to the granting (or denial) ofAC. LetContextAttribute denote the set of context attributes that consist of the values {5W1H (Why,Who,What,How,Where,When)}. EveryContext c∈Context is associated with a set of context attributes denoted bycn = {{why1, who1, what1, how1, where1, when1},{why2,…,whenn}}. LetContextAttribute denote the set of all possible values of context information.Definition 7 (access condition attribute).
Access Condition Attributes are defined as the set of properties linked to granting in the context of the access control system. LetAccessConditionAttributes denote the set ofAC attributes that consist of the values {goal, role, status, action, location, time}. Everyac∈AC is associated with a set of access condition attributes denoted byacn = {{goal1, role1, status1, action1, location1, time1},  {goal2,…,timen}}. Each attributeacn is associated with a finite domain of possible values, denoted asDn.Definition 8 (access condition operation).
As previously mentioned, the sets ofContext andAC represent the set of defined context elements (5W1H) andAC elements (Goal, Role, Action, Status, Location, Time). Let the setsgoal,role,action,status,location, andtime represent the sets of predefinedGoalAttribute,RoleAttribute,ActionAttribute,StatusAttribute,LocationAttribute, andTimeAttribute. In addition,X =GoalAttribute∪RoleAttribute∪ActionAttribute∪StatusAttribute∪LocationAttribute∪TimeAttribute. Each variablex∈X has a finite domain of possible values, denoted asDomain(X). Each Access Condition inac is of the form <x,op,value>, wherex∈X,value∈Domain(X), andop∈{=,≠,<,>,≤,≥}.We propose Algorithm1 for dynamic access decision of the CBDAC model. The algorithm processes mapping between CA5W1HOnto andAC. The input comprisesContext c,Access Condition ac, andIntended Goal ig. The output comprises an access decision such asgrant_access ordeny_access. During the mapping betweenContext attributes andAC attributes, as described in Definitions 6 and 7, we perform theCHECK_INTENDED_GOAL_COMPLIANCE function that checks the intended goal compliance betweenContext attributes andAC attributes, as described in Definition 5. TheCHECK_CONDITION is a function to check whether theContext attribute corresponds to theAC attribute. The respective attributes ofContext andAC are as follows:CHECK_CONDITION(ci, acj)= <whyi∷goalj, whoi∷rolej, howi∷actionj, whati∷statusj, wherei∷locationj, wheni∷timej>.Algorithm 1:Dynamic access decision by mapping between CA5W1HOnto and AC.
INPUT:
(i) Access Requirement
(ii) c, a set of context attribute
(iii) ac, a set of access condition attribute
(iv) ig, intended goal
OUTPUT: Access Decision (Grant_Access or Deny_Access)
METHOD:
(1)ci←the attribute of contexts inCA5W1HOnto
(2)acj ←the attribute of  predefined Access Condition
(3)i, j is the identification number of attributes
(4)while  MAPPING(ci, acj)  do
(5)CHECK_INTENDED_GOAL_COMPLIANCE(ci, acj, ig)
(6)if  (ci×acj ∈ AIG)  then
(7)   return  Grant_Access
(8)else if  (ci×acj ∈ CIG)  then
(9)   CHECK_CONDITION(ci, acj)
(10)   if  ∀ci⊆acj  then
(11)        return  Grant_Access
(12)   else
(13)       return  Deny_Access
(14)else  if  (ci×acj ∈ PIG)  then
(15)   return  Deny_Access


## 3.1. Mapping CA5W1HOnto and Access Condition

In order to supportCA5W1HOnto-based dynamic access control, we herein define the mapping relationship between CA5W1HOnto construct types andAC description types. Figure 3 shows this mapping relationship.Figure 3
Mapping relationship betweenCA5W1HOnto andAC.TheWhyelement from CA5W1HOnto compares the purpose that the context is attempting to accomplish by mapping it to theGoalofAC (such asWhy∷Goal).Whocompares theSubject that produced the context with the role authorized to access the context by mapping it to theRole (such asWho∷Role).How is the process performed by the access objective to process the context, and it compares each process required for the context processing by mapping it to theAction of theAC (such asHow∷Action).What becomes theObject, that is, access objective, and theStatusbeing mapped indicates the state ofObject(such asWhat∷Status).Where indicates the location or spatial information of the context, whereasLocation compares to determine whether access permission is within the permissible location (such asWhere∷Location).When implies the time when the context was produced, andTime compares to determine whether they are within the allowed time range (such asWhen∷Time).Location,Status, andTimeclasses are subclasses ofAction. For theSubject accesses theObject,Location,Status, andTime of access condition depend on acting range because the acting range is performed by context information. Table 1 defines and explains the mapping relationship between CA5W1HOnto andAC in detail.Table 1
Mapping definition.
Mapping betweenCA5W1HOnto and AC
Definition
Why∷Goal
Compares the reason the context occurred (Why) with the purpose for Object access, and for performing context-based system (Goal). Its ingredients are Functional_Goal,and NonFunctional_Goal.
Who∷Role
Compares theSubject that produced the context (Who) with the acceptable role set of Subject (Role). Its ingredients are Actor(User and System), and Profile.
How∷Action
Compares the action leading to the contexts (How) with the acting range that is performed by context (Action). Its ingredients are Atomic_Action, Composite_Action, Expectation, Precondition, Effect, Input, Output, and the like.
What∷Status
Compares the access target context (What) with the State of accessible Object(Status). Its ingredients are Atomic_Status and Composite_Status.
Where∷Location
Compares the location of Subject (Where) with the range of accessible location (Location). Its ingredients are GPS, Atomic_Location,andComposite_Location.
When∷Time
Compares the time the occurred (When) with the range of accessible time (Time). Its ingredients are Start_Time, End_Time, and Repetition_Time.


## 3.2. Dynamic Access Decision

The important challenge for implementing role-based and PBAC models (not context-based access control model) is that it may be difficult to infer the access purpose both accurately and efficiently. With our proposed CBDAC model, the access control strategy can be determined dynamically based on the context elements (such as 5W1H) and subject attributes, in addition to the objects and operations, using access control entities (such as goal, role, action, status, location, and time), and thus it is relatively easy to infer the dynamic access control of context expressivity both accurately and efficiently. Accordingly, we determine dynamic access control by means of Definitions6, 7, and 8.Definition 6 (context attribute).
Context Attributes are defined as the set of 5W1H properties linked to the granting (or denial) ofAC. LetContextAttribute denote the set of context attributes that consist of the values {5W1H (Why,Who,What,How,Where,When)}. EveryContext c∈Context is associated with a set of context attributes denoted bycn = {{why1, who1, what1, how1, where1, when1},{why2,…,whenn}}. LetContextAttribute denote the set of all possible values of context information.Definition 7 (access condition attribute).
Access Condition Attributes are defined as the set of properties linked to granting in the context of the access control system. LetAccessConditionAttributes denote the set ofAC attributes that consist of the values {goal, role, status, action, location, time}. Everyac∈AC is associated with a set of access condition attributes denoted byacn = {{goal1, role1, status1, action1, location1, time1},  {goal2,…,timen}}. Each attributeacn is associated with a finite domain of possible values, denoted asDn.Definition 8 (access condition operation).
As previously mentioned, the sets ofContext andAC represent the set of defined context elements (5W1H) andAC elements (Goal, Role, Action, Status, Location, Time). Let the setsgoal,role,action,status,location, andtime represent the sets of predefinedGoalAttribute,RoleAttribute,ActionAttribute,StatusAttribute,LocationAttribute, andTimeAttribute. In addition,X =GoalAttribute∪RoleAttribute∪ActionAttribute∪StatusAttribute∪LocationAttribute∪TimeAttribute. Each variablex∈X has a finite domain of possible values, denoted asDomain(X). Each Access Condition inac is of the form <x,op,value>, wherex∈X,value∈Domain(X), andop∈{=,≠,<,>,≤,≥}.We propose Algorithm1 for dynamic access decision of the CBDAC model. The algorithm processes mapping between CA5W1HOnto andAC. The input comprisesContext c,Access Condition ac, andIntended Goal ig. The output comprises an access decision such asgrant_access ordeny_access. During the mapping betweenContext attributes andAC attributes, as described in Definitions 6 and 7, we perform theCHECK_INTENDED_GOAL_COMPLIANCE function that checks the intended goal compliance betweenContext attributes andAC attributes, as described in Definition 5. TheCHECK_CONDITION is a function to check whether theContext attribute corresponds to theAC attribute. The respective attributes ofContext andAC are as follows:CHECK_CONDITION(ci, acj)= <whyi∷goalj, whoi∷rolej, howi∷actionj, whati∷statusj, wherei∷locationj, wheni∷timej>.Algorithm 1:Dynamic access decision by mapping between CA5W1HOnto and AC.
INPUT:
(i) Access Requirement
(ii) c, a set of context attribute
(iii) ac, a set of access condition attribute
(iv) ig, intended goal
OUTPUT: Access Decision (Grant_Access or Deny_Access)
METHOD:
(1)ci←the attribute of contexts inCA5W1HOnto
(2)acj ←the attribute of  predefined Access Condition
(3)i, j is the identification number of attributes
(4)while  MAPPING(ci, acj)  do
(5)CHECK_INTENDED_GOAL_COMPLIANCE(ci, acj, ig)
(6)if  (ci×acj ∈ AIG)  then
(7)   return  Grant_Access
(8)else if  (ci×acj ∈ CIG)  then
(9)   CHECK_CONDITION(ci, acj)
(10)   if  ∀ci⊆acj  then
(11)        return  Grant_Access
(12)   else
(13)       return  Deny_Access
(14)else  if  (ci×acj ∈ PIG)  then
(15)   return  Deny_Access


## 4. Use Case Scenario and Implementation

In this section, we describe a use case scenario of the CBDAC model to ensure the ability to provide responses for dynamic access control applying the mobile banking system. In addition, we describe an implementation that the CBDAC model is defined using ontology.TheDyAC is the triple set <Subject,Object,AP>. Using a use case scenario, we find thatSubject becomesUser, which generatesContext inmobile_Banking_System, whereasObject is assigned to theMobile_Banking_Systemas an access objective for theContext. The access permission ofAPis determined by theContext element of the CA5W1HOnto, as well asAC andIG.AP is an important entity that allows dynamic access control and notices the change in the context (AC).TheGoal ofAC is the goal that the context is attempting to perform, which isCredit_Transfer, and the accessibleRoleis allocated only touser andSystem_Admin.Action is theTransfer_Process in Mobile_Banking_System_of_Bank_C, andStatusis only accessible when the system is in theActivationstate.Locationindicates the scope of the accessible spatial information, which is defined byGPS,SmartPhone, orIP_Address.Timeindicates the system-accessible time slot from00:10 AM to11:50 PM. The access to an object is only permitted if six elements of the contexts defined byAC have been satisfied.IG signifies the predetermined intended goal. It determines an access privilege based on theSubjectandContext.The following shows an example ofDyAC based on scenario described above:DyAC ={Subject → User; Object → Mobile_Banking_System; AP};AP ={Context → Credit_Transfer; AC; IG → cig};Context ={5W1H(Why, Who, How, What, Where, When)};AC ={Goal, Role, Action, Status, Location, Time}:
Goal → Functional_Goal(Credit_Transfer),Role → Actor(User/System_Admin),Action → Atomic_Action (Transfer_Process),Status → Atomic_Status (Activation),Location → Atomic_Location (GPS/SmartPhone/IP_Address),Time → Start_Time (00:10 AM), End_Time (11:50 PM).Table2 describes the example ofIG byDyAC. In the mobile banking system,Subject consists of departments (such asUser,m-Banking_Department,Sales_Department,System_Admin, etc.);Context consists of Deposit, Credit_transfer, Open_account, Close_account, Account_Balance_Inquiry, and so forth. When theSubject is User, the User has access to Deposit, Credit_Transfer, Context, and Open_Account only if the context of user corresponds with a particular condition (i.e.,AC is goal, role, action, status, location, and time). The access ofUser to Close_Account is denied because ofpig, which is theintended goal of the user. On the other hand, the access ofUser to Account_Balance_Inquiry is always granted because ofaig, which is theintended goal of the user. When theSubject ism-Banking_Dept., the access ofm-Banking_Dept. to Deposit and Credit_Transfer is denied despite the correspondence withAC because ofpig, which is intended goal ofm-Banking_Dept. However, the access ofm-Banking_Dept. to Open_Account, Close_Account, and Account_Balance_Inquiry is granted bycig only if theContext ofe-Banking_Dept. corresponds withAC. When theSubject isSales_Dept., theSales_Dept. is allowed access to Open_Account only if theContext ofSales_Dept. corresponds withAC, but theSales_Dept.is denied access to the otherContext. When theSubject isSystem_Admin, theSystem_Admin is denied access to Account_Balance_Inquiry, but the access ofSystem_Admin to the otherContextis allowed only if theContext ofSales_Dept. corresponds withAC. Therefore, theSubject isUser inDyAC, and the access ofUser for Credit_Transfer is allowed only if theContext ofUser corresponds with allAC.Table 2
Predetermined intended goal.
Context
Subject
User
m-Banking_Dept.
Sales_Dept.
⋯
System_Admin
Deposit
cig
pig
pig
⋯
cig
Credit_Transfer
cig
pig
pig
⋯
cig
Open_Account
cig
cig
cig
⋯
cig
Close_Account
pig
cig
pig
⋯
cig
Account_Balance_Inquiry
aig
cig
pig
⋯
pig
⋯
⋯
⋯
⋯
⋯
⋯We implement the CBDAC model using Protégé [36, 37]. Figure 4 illustrates the hierarchical classes and instances in the CBDAC model. The class hierarchy shows overall classes and equivalent relation between the CA5W1HOnto class and theDyAC class. The instances of classes are assigned by contexts in scenario. The ontology of the CBDAC model divides the classes into three groups: CA5W1HOnto,DyAC, andConcept. The CA5W1HOnto class includes subclasses to represent the context elements that are theContext class. TheDyAC class includes subclasses to represent the dynamic access control elements. The subclasses of theDyAC classes areIntended Goal class andAccess Condition class. TheIntended Goal class represents the access privileges assigned to subject and context. The subclasses of theIntended Goal class consist of theaig,cig, andpig classes, such as those indicated in Table 2. TheAccess Condition class represents the conditions for the object access. TheAccess Condition class consists of six subclasses, as described in Definition 4. TheContext class that represents the context elements consists of six subclasses, as described in Definition 3. The subclasses of theAccess Condition andContext classes have an equivalent relationship to each other. TheConcept class includes the subclassesSubject andObject. TheConcept class is subclass of the CA5W1HOnto and theDyAC classes for dynamic access decision.Figure 4
A screenshot of the hierarchical structure and instances in the CBDAC model.Based on the scenario presented above, a comparison is made to determine whether theSubject satisfies the access condition of theObject through the mapping of CA5W1HOnto of the CBDAC model and the AC elements (CA5W1HOnto↔Access Condition).Why∷Goal makes the comparison by mapping the Credit_Transfer ofWhy and Credit_Transfer of theGoal. Because Credit_Transfer of theMobile Banking System is a functionalGoal, a comparison is made to determine whether the purpose of the process is the same by a mapping such asWhy∷Goal →Credit_ Transfer∷Functional_Goal (Credit_Transfer).Who
∷
Role compares to determine whether the value ofWho is within the scope allowed to access by mappingUser A ofWho and theUser/System_Admin of theRole asWho∷Role →User_A∷Actor(User/System_Admin).How∷Actionconducts the comparison by mapping the Transfer_Process in theMobile Banking System ofHow and the Transfer_Process in theMobile Banking System of theAction. Because Credit_Transfer of theMobile Banking System is a single process, mapping is performed asHow∷Action →Transfer_Process∷Atomic_Action(Transfer_Process); it compares to determine whetherContext is an executable process.What∷Status compares to determine at which status of theWhat value a permission for access is granted by mapping theMobile_Banking_System_of_Bank_C ofWhat andActivation ofStatus asWhat∷Status →Mobile_Banking_System_of_Bank_C∷Atomic_Status(Activation). That is, access is permitted only when theMobile_Banking_System_of_Bank_C is in the state ofActivation.Where∷Location compares to determine whether the value ofWhere is within the accessibleLocation range by mapping theGPS andSmartPhone values ofWhere and theGPS,SmartPhone, andIP_Address values ofLocation. Because Credit_Transfer makes access at a specific location or through a specific device, the access permission scope is Atomic_Location and it is expressed asWhere∷Location →GPS and SmartPhone∷GPS and Atomic_Location(SmartPhone/IP_Address). Finally,When∷Time compares to determine whether the value ofWhen is within the allowed time slot by mapping theStart_Time(00:00 AM) ofWhen andEnd_Time (11:50 PM). It is expressed asWhen∷Time →Start_Time (00:00 AM)∷Start_Time (00:10 AM), End_Time (11:50 PM):CA5W1HOnto↔Access Condition:
Why∷Goal → Credit_Transfer∷Functional_Goal (Credit_Transfer),Who∷Role → User_A∷Actor (User/System_Admin),How∷Action → Transfer_Process∷Atomic_Action (Transfer_Process),What∷Status→Mobile_Banking_System_of_Bank_C∷Atomic_Status (Activation),Where∷Location → GPS & SmartPhone∷GPS & Atomic_Location (SmartPhone/IP_Address),When∷Time → Start_Time (00:00 AM) ∷Start_Time (00:10 AM),End_Time (11:50 PM).As shown in the comparison,Start_Time (00:00 AM) of When does not correspond with the range of accessible time fromStart_Time (00:10 AM) toEnd_Time (11:50 PM) onWhen∷Time. Consequently,User_A is denied access to the functionCredit_Transfer inMobile_Banking_System_of_Bank_C because theUser_A does not have permissible authority for the functionCredit_Transfer inMobile_Banking_System_of_Bank_C usingSmartPhoneat00:00 AM.Figure5 shows the CBDAC model by ontological concepts including classes, instances, and their relationship. Yellow circle represents each class, and the purple circle indicates each instance using the NavigOwl that is a visualization tool Ontology [37]. Further, an arrow indicates each relationship. Our model can be applied and depicted in a real-life scenario using ontological concept. Therefore, we ensure the ability of the CBDAC model to provide correct responses by representing dynamic access decision with a real-life banking system scenario.Figure 5
A screenshot of the overall CBDAC model.


## 5. Conclusion

In this paper, we proposed an access control model for privacy protection based on context in USN named theCA5W1HOnto-based dynamic access control (CBDAC) model. The CBDAC model makes use of the ontological concept using 5W1H to process context information; it guarantees privacy protection when processing context information in various domains and assigns access permission without any limitation to certain domains in USN. It is possible to process dynamic access control usingDyAC. In other words, access permission is dynamically assigned according to the change in context information such that, even for a subject with the same role, access permission is defined differently depending on the context information and access condition. Consequently, not only does the CBDAC model authorize access based on roles, which is the key concept of role-based access control, but dynamic access control is also possible because access permission is assigned based on context information, access condition, and intended goal. We also described the algorithm that achieves compliance computation between the access condition and the intended goal. In addition, we showed an applicable use case scenario. To improve our current research, we plan to advance the dynamic access control through the definition of the context-access rule and reasoning method for supporting context inferences, and also a more adequate scenario for experiment and evaluation will be applied.



---

*Source: 836546-2015-09-27.xml*