# Feasibility Assessment of a Fine-Grained Access Control Model on Resource Constrained Sensors
## 3 Access Control Model
### Authorization Policy Language and Codification
#### 3.2.1 Resulting Policy Instance Review  
When instantiating security policies ranging from simple use cases to highly critical cases, the lengths of the instance files increase progressively due to the elasticity enabled by the policy language. To illustrate such effects, four representative sample groups are conveyed hereinafter.  
* Sample 1 (S1): A policy with no rules comparable in expressiveness to traditional approaches broadly implemented and validated in C0 CDSs. This example might be the access granted to a subject initially authenticated and authorized in the ACS and then authenticated in the CDS.
* Sample 2 (S2): A policy containing one rule with conditions, somewhat comparable in expressiveness to the recently researched DcapBAC approaches based on PKC and CBOR policy codifications, which have been validated in less-constrained devices (C2 CDSs). Certainly, the proposed approach under analysis enables rich expressions on attributes such as arithmetic, logical, textual, relational, and comparative, depending on the application domain, rather than only the simple matching of DcapBAC. For example, beyond initial authorization in the ACS and local authentication in the CDS, access for any maintenance action can be granted only after ensuring that the battery level exceeds a given threshold and not matches it.
* Sample 3 (S3): A policy with one rule containing both conditions and obligations. This level of expressiveness is beyond any existing feasible solutions for constrained devices. For example, after checking a local condition, such as the battery status, any maintenance action shall be granted, and, additionally, the system status flag or semaphore is updated as a reaction enabled by obligations.
* Sample 4 (S4): A policy with several rules containing conditions, obligations and periodic re-evaluation. This level of expressiveness is far beyond the capabilities of existing solutions. This example incrementally covers checking different conditions related to different actions on different resources. For example, it can enforce the checking of the system status attribute correlation before maintenance actions can occur and/or the checking of the attempts to perform any operation on the system before granting administration rights. Both conditions highlight its finer granularity. Additionally, each access may produce specific reactions through obligations such as updating system flags to enable transactional controls, updating counters to enable usage controls, or performing concrete remote notifications that enable instant awareness.  
To summarize, these four sample groups (S1-S4), defined with a clarifying purpose, convey incremental expressiveness of the policy and therefore granularity and tightness at enforcement time. The four samples range from no rules to several rules to be enforced locally in the CDS, as summarized in Table 2. It is also noted in which constrained platforms each sample range can be used based on currently feasible access control models. The proposed access control model is excluded, and once its feasibility is demonstrated, it would enable all samples in all C0-C2 platforms.