# Feasibility Assessment of a Fine-Grained Access Control Model on Resource Constrained Sensors
## 3 Access Control Model
### Authorization Policy Language and Codification  
In this section, a specific expressive policy language is briefly presented. The goal of this policy language is to overcome the resource constraints of the CDSs when enabling the definition of fine-grained policies to be provisioned and enforced in the CDS to comply with the least privilege principle. This policy language definition enables both the granting of decisions based on local context conditions and reacting accordingly to the requests by the execution of additional tasks defined as obligations. This policy language is declarative and adopts the deontic concepts of rights, prohibitions and obligations. It is inspired by non-constrained access control models, such as XACML, but it balances the expressiveness and feasibility in CDSs adopting and adapting just the core subset of definitions. A security policy defined with this policy language is an optional set of rules that conveys the conditions to be checked and the derived reactions such as in the broadly adopted event-condition-action approaches. Specifically, this policy language determines a sequence of constructs with particular significance in the decision making and enforcement time. The number and meaning of the constructs in this proposal result from the compromise between expressiveness and performance. The order of the sequence becomes essential to its proper interpretation. The elasticity of the policy is based on the definition of some constructs as mandatory but some others as optional. This design aspect enables the reduction of the length of the policy when a simple policy is sufficient. In addition, some constructs are extended through other nested constructs, where some of them can be instantiated many times within a container construct. Related to this elasticity feature, the more constructs instantiated, the higher the expressiveness of the policy, the more granular the policy is, and thus the tighter the enforcement is. Consequently, the challenge to overcome is to be feasible even in the most expressive use-case. Specifically, the proposed policy language enables a security policy instantiation through the _policy_ construct, with three nested constructs. First, a policy instance identification _id_ is specified for logging, tracking and auditing purposes. Then, a default policy granting _effect_ is specified. This effect will prevail in the case of an absence of rules or under any rule evaluation conflict. In the use cases where preliminary authorization enforced by the ACS and mutual authentication is sufficient, this _effect_ construct is highly useful, and the resulting policy instance is the simplest and shortest instance. It also becomes very functional for notifying revocation and related security association finalization. Finally, optionally, an array of rules may be instantiated as a _ruleset_ to define the conditions and related reactions. Each _rule_ in the array is an extensible construct. The representation of the policy construct in the Extended Backus-Naur Form (EBNF) notation is depicted in Table 1. This EBNF representation shows hierarchical constructs to be defined along with expandable, nestable and repetitive constructs as needed. Figure 2(a) also shows a graphical equivalent view, where optionality and contents are more clearly represented. The _rule_ construct depicted in Figure 2(b) is defined as a sequence of eight nested constructs, where the order is crucial. Some of them, such as _id_, _effect_, and _conditionset_, are mandatory, and the remainder, namely _periodicity_, _iteration_, _resource_, _action_ and _obligationset_, are optional. The _conditionset_ and _obligationset_ are arrays of expressions and obligations, respectively. These repeatable and extensible _expression_ and _obligation_ constructs are defined in a similar manner, and they enable the instantiation of rich expressions on attributes declared as inputs as well as reactive tasks declared as obligations.