# SOLIOT--Decentralized Data Control and Interactions for IoT
## 6 Mapping and Interaction Model
### Non-Functional Characteristics  
Many requirements from OT systems are not supported by SOLID as they are not relevant for its use cases (cf. Table 2). For instance, code integrity (N3) of the hosting platform, reliability (N5) or resilience (N6) are either as part of the implementation details. Furthermore, SOLID itself does not regard physical safety (N4) as no SOLID application is intended to physically interact with its users or any other real-world object. The SOLID use cases focus on decentralization of data storage and control, consequently privacy (N2) and scalability (N8) of SOLID networks are distinguishing features. The intended easy transmission of pods is currently without comparison. However, the current state of the specification [38] does not yet give sufficient guidelines how one hosting service can ship a Pod to another. Still, in a dynamic IoT network with potentially changing settings, the ability to adjust the location of resources and to ship all information seamlessly is an important feature. The merging of local, decoupled networks with the global Internet is one of the most impacting developments. While previously the security and integrity was ensured by restricting the access to sensitive parts of the shop floor, the rising need for interconnections undermines any firewall or otherwise intended separations. Consequently, each component needs to implement the complete security stack, as if it were placed in the open Internet. Such sometimes called 'Zero Trust' (N1) approaches demand the same proofs from any connecting party. Data or functionality must be prohibited without proper identity claims and whenever not backed up by the ACL rules. This transparent data protection (N2) approach enables the arriving user agents to understand potential obstacles and deficiencies. Measures to ensure a required Integrity (N3) and Resilience (N6) level are for instance proposed by the IDS [39]. Hardware-based trust anchors or virtual monitoring of a server's state, together with certified software modules, can increase the trust level both of the party operating a SOLIOT instance and the interacting user agent. These concepts however are still in their maturation process and only mentioned here. In general, a guaranteed resilience or integrity level cannot be accomplished without regarding the use case context. This is certainly also true for Safety (N4) considerations. Neither SOLID nor SOLIOT have out of the box understanding of the meaning--and potential risks--included in their data. Gradual approaches to this issue could be outlier detection or Complex Event Processing engines on top of the SOLIOT notifications. The self-descriptive nature of SOLIOT events, through their RDF-encoded content, certainly lowers the integration effort for third-party tools. As such concepts are however very use case specific they shall not be regarded further here. In contrast to that, Reliability (N5) can be supported by common methods like periodic backups and load balancing. Such measures can be applied to the SOLIOT hosting instance itself. One important consideration is the distinction between the offered state of a data resource and its internally managed history. A SOLIOT implementation should use transaction-driven data handling for each resource, allowing the seamless reverse of harmful interactions. As the network surrounding of a SOLIOT instance is not observed by the instance and maybe not observable at all, it must be assumed as compromised by malicious third parties. Therefore, a SLOIOT system must insist on the delivery of valid authentication and authorization proofs from anyone. The recommended pattern is Bearer Tokens from a local OAuth service (N7) with a duration of less than one hour. If the requesting of such dynamic tokens overstrains the abilities of a device, longer or even stable tokens may be accepted. Nevertheless, whenever unsafe interactions are requested, a TLS channel and an additional examination of the local ACL rules is required (N8).