# Feasibility Assessment of a Fine-Grained Access Control Model on Resource Constrained Sensors
## 3 Access Control Model
### Authorization Policy Language and Codification
This makes a big difference with currently implemented and researched authorization policy expressiveness and therefore tightness in constrained devices, which convey conditions simply as value matching on a set of attributes. Moreover, there are no constrained-device-oriented approaches supporting obligations, which are enablers of advanced features such as precise and instant logging, active accounting, system and process context updating, system blocking, transaction level control, and usage-based control. In addition, any granting decision on an operational activity can be first triggered and then tracked through rule _id_, _effect_, _resource_ and _action_ constructs. Finally, optional _periodicity_ and _iteration_ constructs expand the potential of the obligations. Consequently, all these constructs nested in the main construct _policy_ enable the instantiation of an expressive policy, and it is the purpose of this paper to assess the feasibility according to its performance impact. Moreover, any policy instance is defined in the ACS, provisioned to the CDS when a security association establishment is requested, and enforced before the establishment and during its lifetime in the positive authoritative case. Likewise, this policy language can be used to define policy instances according to the most broadly implemented access control models (i.e., the RBAC and ABAC models). Any resulting policy instance \begin{table}
\begin{tabular}{l} \hline \hline _policy := ’t ’ ’id’ ’ ’:’ integer ’, ’‘effect’ ’:’ ( DENY | PERMIT ) ( ’,’’nleset’ ’: ’l’ rule+ ’)? ’l’_ \\ \hline \hline \end{tabular}
\end{table} 
Table 1: EBNF representation of a schematic policy. Figure 3: Policy language main constructs. is a text file that can be generated in several formats, edited by human administrators, and stored and processed by information systems. The length of any policy instance, in a human-readable format, grows proportionally with the desired tightness, and this would impact the performance negatively. Moreover, the policy expressiveness of the proposed policy language would become useless if the length of the resulting instances was excessive. Therefore, a specific policy instance codification is defined, therein achieving a notable reduction in the length of the policy instances. Considering a policy instance defined according to the proposed policy language, the goal is to generate the minimum possible bit stream. This compression limits the impact of the length of policy instances on both storage and energy consumptions. The proposed codification distinguishes from existing codifications that serialize policy instances through standardized generalist solutions such as CBOR. The proposed policy codification serializes each construct and concatenates them in a bit stream. The prior knowledge of the defined sequence of the constructs and their format is the cornerstone. An additional and crucial factor is the injection of some agreed-upon bit masks to specify both the existence or not of optional constructs and the number of elements in related arrays of nested constructs. This enables one to deal optimally with the elasticity defined in the policy language, therein avoiding unused but expected fields of expressive policies, which significantly shortens the length. Consequently, the compression ratios are higher than those resulting from currently available generalist approaches such as CBOR. With respect to covered policy formats, this policy codification can easily be applied to any original textual policy instance format (XACML, JSON, etc.). Moreover, the agreed-upon conventions can be parametrized for several application scenarios and domains, and the policy domain model (PDM) would be the set of adopted decisions, for example, on the length of the different arrays, the identifiers of functions, and labels. At implementation time, when the PDM is specified in a separate file, its patterning, versioning, modification, provisioning and activation are much more agile, thereby enabling an effective change management.