SOCIOTAL D1.2.1 FINALsociotal.eu/sites/default/files/docs/deliverables/SOCIOTAL_D1.2.1... · Section 1 - Introduction to IoT-A methodology ... review, FI-WARE was considered as the

PROPRIETARY RIGHTS STATEMENT This document contains information, which is proprietary to the SOCIOTAL Consortium. Neither this document nor the information contained herein shall be used, duplicated or

communicated by any means to any third party, in whole or in parts, except with prior written consent of the SOCIOTAL consortium.

Specific Targeted Research Projects (STReP)

SocIoTal

Creating a socially aware citizen-centric Internet of Things

FP7 Contract Number: 609112

WP1 – Socially-aware citizen centric architecture and community APIs

Deliverable report

Contractual date of delivery:31/08/2014 Actual submission date: /08/2014

Deliverable ID: D1.2.1

Deliverable Title: First version of SocIoTal Architecture

Responsible beneficiary: UNIS

Contributing beneficiaries: UNIS, CEA, UC, CRS4, DNET, UMU

Start Date of the Project: 1 September 2013 Duration: 36 Months Revision: 1 Dissemination Level: Public

FP7 Contract Number: 609112 Deliverable report – WP1 / T1.2/D1.2.1 Document ID: D1.2.1

Version Date: 29 August 2014 Security: Confidential

Page II

Document Information

Document ID: D1.2.1 Version: Final 1.0 Version Date: 12 August 2014 Authors: Dionysia Triantafyllopoulou, Michele Nati (UNIS), Ignacio Elicegui,

Carmen Lopez, Luis Muñoz, Luis Sanchez (UC), Jose Luis Hernández, Jorge Bernabé, Victoria Moreno (UMU), Davide Carboni, Alberto Serra (CRS4), Nenad Gligoric, Srdjan Krco (DNET), Olivier Savry (CEA).

Security: Public

Approvals

Name Organization Date Visa

Project Management

Team K. MOESSNER UNIS

Document history

Revision Date Modification Authors Draft 26/5/2014 First Draft ToC CEA Draft 03/06/2014 First version of Data Model UC Draft 04/06/2014 First version of section 2 UNIS

Draft 17/06/2014 Updated section 2 UNIS, CEA, UMU, UC, CRS4, DNET

Draft 17/06/2014 Provided criteria for platform selection UNIS Draft 20/6/2014 Provided information views CEA Draft 02/07/2014 First version of section 5 (Deployment constraints) UNIS

Draft 04/07/2014 Updated section 5, consolidated section 6.2 UNIS, CEA, UMU, UC, CRS4, DNET

Draft 16/07/2014 Provided section 8 (success indicators) CEA Draft 16/07/2014 Provided section 4.4.3 (context model) UNIS Draft 17/0/72014 Updated contributions UC Draft 18/07/2014 Updated contributions CRS4 Draft 21/0/72014 Updated contributions UC

Review Release

23/07/2014 First release to be reviewed UNIS

Final Release

04/08/2014 Final release including all reviews UNIS

Final Version 12/08/2014 Final version ready for submission UNIS



Page III

Content

Description of the deliverable content and purpose ....................................................... 4

Section 1 - Introduction to IoT-A methodology ............................................................... 5

1.1 IoT-A presentation .................................................................................................. 5

1.2 IoT-A methodology ................................................................................................. 5

Section 2 - Requirements towards functional components ........................................ 10

Section 3 - Information views ......................................................................................... 19

Section 4 - Data Models ................................................................................................... 21

4.1 Resource Model .................................................................................................... 21

4.2 Service Model ....................................................................................................... 22

4.3 Virtual Entity Model .............................................................................................. 22

4.4 Other models ........................................................................................................ 26

Section 5 - Deployment Constraints .............................................................................. 31

Section 6 - Selection of existing platform ..................................................................... 35

6.1 Criteria for selection ............................................................................................. 35

6.2 Review of existing platforms ............................................................................... 35

Section 7 - Selected Platform Description ..................................................................... 39

7.1 FI-WARE introduction .......................................................................................... 39

7.2 Open Source ......................................................................................................... 39

7.3 Space for SocIoTal innovation ............................................................................ 40

7.4 Collaboration and Support with platform owner ............................................... 41

7.5 Closeness to IoT-A ............................................................................................... 41

7.6 Reuse of most components and functionalities ................................................ 43

Section 8 - Success indicators ....................................................................................... 45

Section 9 - Conclusion .................................................................................................... 47

References ............................................................................................................................ 48

Abbreviations and Acronyms ............................................................................................. 51

Annex I .................................................................................................................................. 52

Security Information Views ............................................................................................. 52

Use case Information views ............................................................................................ 57



Page 4/70

Executive summary Description of the deliverable content and purpose Following the definition of the SocIoTal requirements, scenarios and use cases performed in Task 1.1, the aim of this deliverable is to provide the initial version of the SocIoTal architecture. The designed architecture uses the principles and the framework defined in the Internet of Things – Architecture (IoT-A) EU research project as a reference, taking advantage of its inherent interoperability and capability features, and valuable functional views. This approach allowed the focus of the proposed architecture design on the novel context- and privacy-aware features of SocIoTal, without reinventing the wheel when it comes to the implementation of already existing and well-performing modules. Firstly, a careful review of the identified requirements of Task 1.1 was performed in order to derive the various components that the SocIoTal architecture comprises atop the IoT-A Architecture Reference Model (ARM). Moreover, the interactions between the different SocIoTal functional blocks in all identified use cases were formally described, using the well-defined IoT-A information views. Particular emphasis was given on the interactions between the various modules and the components that comprise the Security functional group, in order to highlight the increased context-security and privacy-awareness of the proposed architecture. In order to have a complete initial version of the SocIoTal architecture, following the principles of IoT-A, the Data, Community, User and Context Models were also provided, although it has to be noted that, since they are based on work ongoing in Work Packages 2-4, their detailed final versions will be provided with the final version of the architecture. As a next step, the process followed in order to select an existing architecture to be used as the base for the development of the envisioned SocIoTal innovations was described. Six different platforms were evaluated in terms of i) development model, ii) space for SocIoTal innovation, iii) collaboration and support with platform owner, iv) closeness to the IoT-A architecture and v) reuse of most components and functionalities. Following this careful review, FI-WARE was considered as the core platform that will be used as the foundation for the development of the SocIoTal tools. Finally, a number of success indicators that allow the evaluation of the introduced architecture in terms of its main goal, i.e., “An architecture for a citizen-centric IoT deeply embedding privacy and security by design which is aligned with emerging IoT reference architecture”, are described.



Page 5/70

Section 1 - Introduction to IoT-A methodology 1.1 IoT-A presentation Today, a large number of different means are used to enable communications between heterogeneous devices. Unfortunately, the “Internet of Things” (IoT) is often seen as vertical silos that do not support interoperability and with inappropriate models of governance. IoT-A, the Internet of Things Architecture (IP EU project from 2009 to 2012) [1], proposed a viable global solution to lower those barriers and which ensures not only the interoperability but also the scalability requirements and the security and privacy in its design, which are so often neglected. This solution rests upon the creation of an architecture reference model together with an initial set of key building blocks, principles and guidelines for the technical design of the protocols, interfaces and algorithms suitable for any IoT system. SocIoTal has chosen to follow the framework deployed by IoT-A to create its architecture because it enables to focus our development on the main aspects of the project without being forced to reinvent the wheel on the classic functionalities of an IoT system. This methodology ensures us to have an interoperable and scalable system and provides us a richness of functional views (decomposition diagrams, technical use cases, interaction example, interfaces, sequence charts), which can be reused easily. IoT-A is also able to supply common language and common concepts to improve the communication between partners and to compare quickly different architectural proposals. 1.2 IoT-A methodology IoT-A provides a methodology to design an architecture for an IoT system. The final result of this approach is the generation a set of views, which completely defines the targeted architecture. Those views are the physical view, the context view, the functional view, the information view, and the operational and deployment view. Figure 1 highlights the way to generate them.

Figure 1. IoT‐A methodology diagram

This method is now summarized step by step. A more complete review can be found in deliverable D1.5, provided by the IoT-A project [2].



Page 6/70

1.2.1 Business goals A specification of the purpose of the IoT system is the basis of its building. It requires the definition of a business model, of the things involved and of a short list of actors. For SocIoTal, the Description of Work is the main document which addresses this need. 1.2.2 Physical Entity View The Physical Entity View describes the scenario in the physical world with physical users, physical entities without any consideration of virtual or digital objects. It describes what are the relevant measures to process in order to make the story reaches its end. 1.2.3 Context View As indicated in the Figure 1, the IoT context view consists of two parts: the context view and the IoT Domain model. The context view is an architecture that is generated at the very beginning of the architecture process and those views were already drawn for each use case in SocIoTal D1.1 [3]. It describes “the relationships, dependencies, and interactions between the system and its environment (the people, systems, and external entities with which it interacts)”. The IoT Domain Model, on the other hand, provides a semantic and ontological overlay for the context view, in which it provides guidance on the core entities of an IoT system and how the entities relate to each other. It enables partners of the project to discuss with a common language.

Figure 2. The IoT Domain Model

The IoT Domain Model introduces an important concept, the Virtual Entity (VE), Figure 2, which is a model of the physical entity with different attributes (e.g., a shirt can be modelled by its size, color, collar, etc.). A device (sensor, tag) will be attached to this physical entity to try to catch the value of those attributes. They will be hosted by resources (memory of the sensor for example) and they can be retrieved thanks to a specific IoT service. IoT service provides a low level description of the physical world (e.g., the value of sensor 456) but a user may require a high level information about an entity. For example, if the user wants to know the temperature of room 350, an association between the room 350 and the sensor providing its temperature is mandatory. This association is ensured by a VE service, which makes the link between the VE (room 350) and the IoT service (Value of sensor providing the temperature of the room). 1.2.4 Requirement process IoT-A proposes a full process to derive the requirements of the IoT system. First of all, a threat analysis will impose design choices. IoT-A also provides an exhaustive list of functional and non-functional requirements, referred to as UNI, which can address any kind



Page 7/70

of IoT system. Then designers have to choose tactics by mapping the requirements onto qualities or perspectives like interoperability, scalability, availability, performance, security and privacy. Finally, those changes of point of view enable to identify design choices for addressing the underlying qualitative requirements. During this stage, the need of specific components in the architecture becomes clearer and clearer. 1.2.5 Functional view The Architecture Reference Model (ARM) of IoT-A defines a set of functional groups and functional components derived from the requirements process and which can be found in various IoT systems, see Figure 3.

Figure 3. The IoT‐A Architecture Reference Model

The ARM exposes 9 different Functional Groups (FGs) (which are more detailed in D1.5 (P108) of IoT-A):

The Application: represents the user or the application interacting with the IoT system.

The Device: sensor, actuator or tag, which will provide information to the system or which modify the system.

The IoT Process Management FG: provides the functional concepts and interfaces necessary to augment traditional processes with the idiosyncrasies of the IoT world.

The Service Organisation FG: is used for composing and orchestrating Services at different levels of abstraction.

The Management FG: enables the management of the IoT: configuration of devices, tracking of faults, monitoring, reporting, and administration of the whole IoT system.

Virtual Entity FG: contains functions for interacting with the IoT system on the basis of VEs as well as functionalities for discovering and looking up services that can provide information about VEs, or which allow the interaction with VEs (but also for managing associations and finding new associations).

IoT Service FG: contains IoT services as well as functionalities for discovery, look-up, and name resolution of IoT services.



Page 8/70

Communication FG: is an abstraction, modelling the variety of interaction schemes derived from the many technologies belonging to IoT systems and providing a common interface to the IoT service FG.

The Security FG: ensures the security and privacy in the IoT system. Those functional groups are composed of many components that IoT-A describes with their interfaces and their default functions set, which open the road to the design of the interactions between them: the information view. 1.2.6 Information view The information view defines the flow of data between the different functional components addressed previously. IoT-A describes a restraint set of possible interactions between a server and a client to simplify the view:

“push(data)”: a simple on-way communication from a server to a client “request/response” is a synchronous way of communication between two parties. “subscribe/notify” is an asynchronous way of communication between two parties:

The client just indicates its interest in a service and this service sends notifications when new data are available.

“publish/subscribe” allow a loose coupling between communication partners. There are services offering information and advertise those offers on a broker component. When clients declare their interest in certain information on the broker, the component will make sure the information flow between service and client will be established.

An exemplary information view describing how data is pushed towards IoT and VE services is shown in Figure 4.

Figure 4. Information view describing how data is pushed towards IoT and VE services

1.2.7 The Operational and Deployment view This view will discuss how to move from the service description and the identification of the different functional elements to the selection among the many available technologies in the IoT to build up the overall networking behavior for the deployment. It identifies technologies for the three main element groups of the IoT Domain Model: devices, resources and services. Each of them poses a different deployment problem, which, in turn, reflects on the operational capabilities of the system. For example, devices can be funded on many different technologies:

Sensor and actuators networks Radio Frequency IDentification (RFIDs) and smart cards WiFi or other unconstrained technologies Cellular networks

Their communication protocols can be then chosen. IoT-A strongly suggests the Internet Protocol (IP) and proposes a specific IoT protocol suite.



Page 9/70

After having selected the devices and their communication methods, the system designer has to account for services and resources. They consist of a piece of software, which can be deployed according to the following options: on smart objects, on gateways, in the cloud. On the same line, it is important to select where to store the information collected by the system. The storage can be local, or in the web or locally with a web cache. Finally, one of the core features of IoT systems is the resolution of services and virtual entities which can be deployed on specific servers of the system or which can be provided by a third party through an Application Programming Interface (API). The operational and deployment view gives the final picture of the architecture but it will not encompass all its aspects. All the other views remain essential for its understanding.



Page 10/70

Section 2 - Requirements towards functional components The first step towards the introduction of the SocIoTal functional components was the detailed evaluation of the functional and non-functional requirements, as defined in Task 1.1. This section provides a high-level description of the functional components introduced by SocIoTal. The definition of each functional component is followed by a reference to the specific requirements from which the component is derived. Process Modelling: Composition (Trigger/Action) Description: This component provides a mechanism to combine two services in a business logic composition to generate alarms or events in the Personal Dashboard. REQ100 SocIoTal shall provide a dashboard to the user REQ102 The user shall be able to associate data of different sensors to generate an

alarm on his dashboard Process Execution: Scheduler Description: The scheduler component executes the business logic composition generating a new event sending triggered data to the selected actuator. REQ100 SocIoTal shall provide a dashboard to the user REQ141 The scheduler checks new data for compositions and triggers events pushing

data to the related actuator IoT Service: Subscription Request Description: This component provides a connection between the user environment application (or another functional component) and the IoT Broker for the subscribe/notify pattern mechanism. The IoT Service: Subscription Request Component is able to forward notifications from the broker when new events are generated. REQ104 Notifications shall be confidential REQ105 The user shall be notified of an event Happiness Index Computation Tool Description: This component provides computation of the happiness index in the city based on different predefined sets of inputs. The final value of the happiness index is visualized using Visualization module. REQ140 SocIoTal shall provide a method for computation of the city’s happiness index Visualisation module Description: This component provides visualization of the different Virtual Entities by using the Smart City Dashboard as an enabler. Visualization can be initiated by using the Scheduler to model a set of process to be executed and displayed; or manually, by using the API to set an entity type and value. The main functionality of this component is modelling of the specific information that is going to be displayed using dashboards in the city. REQ142 SocIoTal shall provide a city dashboard to the user



Page 11/70

Metadata Processor Description: Focused on observations and events provided by the devices registered in the SocIoTal platform, it conforms the raw data gathered, according to the data model defined within SocIoTal platform and pushes the so constructed information device gateway. REQ65 SocIoTal shall provide a resource with the functionality of modelling all

information coming from sensors REQ97 Modelling of data shall be common IoT Service: Post Request Description: This service enables client to post various types of virtual entities to the SocIoTal platform storage. Various entities can be posted including reports about physical entities such as different events in the user vicinity (text, image as a virtual entity representation of this event). REQ139 User shall be able to POST data to the platform VE Service: Communities Description: A VE Service [4] handles an entity services which represent an overall access point to a particular entity, offering means to learn and manipulate the status of the entity. Specifically, this component is in charge of the communities’ management. This VE Service allows the creation, update or removal of a community as well as the management of users, VE and resources which shape the community. This component should work jointly with security components in order to lookup the security level (authorisation, trust & reputation, etc.) of the different communities and also the access to the component per se. REQ73 The user shall to be able to filter people who are not in his bubble of trust and

who try to get location data or other private information REQ74 The composition of the bubble of trust shall be confidential and only accessible

by members of the bubble of trust REQ86 Devices shall provide the means to be discovered REQ87 The user shall not be able to discover a bubble of which he is not a member REQ88 The member shall be able to enter a new bubble of trust REQ93 The user shall be able to avoid that personal data leave his bubble of trust VE Service: VE History Storage Description: Although the two main functions defined for the VE Service functional component are to read and set an attribute value for an entity, this component can also provide VE history storage functionality [4]. This block will be able to publish integrated context information (VE context information –dynamic or static), VE state information and VE capabilities. REQ119 A Virtual Entities’ directory shall be provided



Page 12/70

IoT Broker Description: This component allows a client (through the IoT Service Subscription Request) to subscribe to a service and receive notifications from it whenever a change occurs in the entity administrated by the service, following a subscribe/notify pattern. In contrast to the request/response pattern, the client will not have to be await to the answer after a petition, thus being able to continue its tasks and receiving the information when a change occurs. In the case of the service, it will send the notifications to the IoT Broker and the latter will be in charge of sending the notifications to all clients subscribed. The information flow involving the IoT Broker is as follows: when the IoT Broker receives a Subscription Request(), it keeps the record of the operation (client and subscription information) and requests the subscription to the correspondent service. The latter registers the subscription and sends the notifications to the IoT Broker whenever a change occurs in the entity managed by the service. When the IoT Broker receives the notification, it will multicast the information to the subscribed clients. REQ105 The user shall be notified of an event VE Service: F2F Interaction Detection Description: This VE Service considers information on nearby users’ presence and facing direction. Each device estimates the interpersonal distance with its nearby devices, through a novel machine-learning based technique to classify if a user is in proximity to perform face-to-face interaction. Further, the relative orientation of the users is computed through a threshold-based approach. The knowledge of the users’ interpersonal distance estimation and relative orientation computation is combined to infer if the users are performing a face-to-face interaction, allowing the assessment of the users’ trust and reputation as well as the estimation of the social relations among devices. REQ114 SocIoTal shall provide a mechanism to assess trust and reputation of users and

devices REQ132 The SocIoTal system shall provide the capability to measure social relations

among devices REQ136 The SocIoTal system shall provide the capability to automatically create/extend

a bubble based on devices’ social interaction IoT Service: Discover Request Description: An IoT Service has three main functions [4]: (1) return information provided by a resource in a synchronous way, (2) accept information sent to a resource in order to store the information or to configure the resource or to control an actuator device and (3) subscribe to information. More specifically, this component is in charge of processing user’s discovery requests of devices, users, VE, services or communities. These petitions should embrace all parameters needed to a successful discovery such as IDs, attributes or descriptions as applicable. When a user/application requests a discovery, this block sends a request to the VE Service: Communities to check the communities to which the user/app has access, after this process the request is forwarded to the VE Resolution where the discovery information is retrieved to the IoT Service: Discover Request which will forward the information to the correspondent client/app. REQ86 Devices shall provide the means to be discovered



Page 13/70

IoT Service: Registering Device Request Description: This component provides the facilities to register (or update information about) devices or resources in order to be integrated within the system. Once the devices/resources are registered, they can be accessed by appropriate services following the corresponding security rules established by the security functional group. This block will receive the registration requests and it will launch the process to register the device/resource into the Resource Directory and to inform other blocks such as the VE & IoT Service Monitoring or the VE Service: VE History Storage. Moreover, when a change in the description of the device/resource occurs, this component will update the registration and inform all involved functional components. REQ59 A User or a device shall be registered before using the service REQ99 Owners shall register the virtual entities of the objects they want to share IoT Service: Resource History Storage Description: This component allows the access to the Resource Storage, which is in charge of storing all resource information. This storage supports different file formats such as text, audio, video or images. REQ67 SocIoTal shall provide a storage resource REQ84 Secure storage of data shall be ensured REQ94 The storage server shall support multimedia file formats (audio, video, images) IoT Service: DirectionData Description: This IoT Service is used in order to store information regarding the users’ facing direction. This will then be used by the face-to-face enabler in order to infer face-to-face interactions among users and assess the respective levels of trust and reputation between the users who are in close distance to each other. The front direction of participants’ torsos is considered as user direction. REQ114 SocIoTal shall provide a mechanism to assess trust and reputation of users and


among devices IoT Service: NearbyDevicesData Description: This IoT Service is used in order to store information regarding presence of nearby users. This will then be used by the face-to-face enabler in order to infer face-to-face interactions among users and assess the respective levels of trust and reputation. To detect nearby devices there is a need of obtaining either the absolute or the relative position of the devices in vicinity. Absolute position requires continuous monitoring of the user with positioning sensors such as GPS but are very energy consuming and do not operate indoors. Other absolute position systems exist but require additional hardware. REQ114 SocIoTal shall provide a mechanism to assess trust and reputation of users and


among devices



Page 14/70

Group Manager Description: The Group Manager module enables sharing information in a secure and private way, with those groups of entities (communities or bubbles) that satisfy certain particular sets of identity attributes values. These particular sets of attributes are represented by attribute sharing policies, which are influenced by context information where the data sharing is being performed. This module is envisioned to manage opportunistic bubbles, that is, dynamic sharing groups, which are not previously registered as community anywhere. To this aim, the group manager makes use of attribute based encryption mechanism, namely the Ciphertext-Policy Attribute-Base Encryption (CP-ABE) scheme [5]. With this scheme, data to be shared within a group is encrypted under a policy of attributes, while keys of participants are associated with sets of attributes. Only those target users that satisfy particular identity attributes (those given in the policy) possess the cipher keys to decrypt the data. In this way, a data producer can exert full control over how the information is disseminated to other entities, while a consumer’s identity can be intuitively reflected by a certain private key. REQ73 The user shall to be able to filter people who are not in his bubble of trust and

who try to get location data or other private information REQ74 The composition of the bubble of trust shall be confidential and only accessible

by members of the bubble of trust REQ93 The user shall be able to avoid that personal data leave his bubble of trust Authorization Description: The Access Control module is responsible for making authorization decisions based on access control policies. These polices define the permissions that a subject (smart object or user) has over certain target resources (e.g., IoT service). Thus, the policies specify which particular actions that subjects or groups (communities of bubbles) are allowed to perform over a target resource under certain conditions. These conditions usually refer to the context information provided by the context manager module. In this regard, the eXtensible Access Control Markup Language (XACML) [6] policy language is adopted in SocIoTal to deal with authorization policies. Additionally, it is desirable to employ access control solutions specially meant to IoT scenarios. In this sense, the authorization component is able to perform capability-based access control based on the mechanism presented in [63]. It describes authorization tokens specified in JavaScript Object Notation (JSON) and Elliptic Curve Cryptography (ECC) optimizations to manage access control on constrained devices. REQ83 A user shall be authorized to access a service REQ115 Users shall be able to specify their access control preferences REQ116 SocIoTal shall be able to evaluate an access request depending on access

control policies REQ123 A user’s data shall be processed only with the user's consent REQ138 The SocIoTal system shall provide the capability to enforce a data access policy

based on the data consumer context Authentication Description: Authentication ensures that an identity of a subject (user or smart object) is valid, i.e., that the subject is indeed who it or what it claims to be. The authentication module enables authenticating users and smart objects based on the provided credentials. The credential can be in form of login/password, shared key, digital certificate. Traditional authentication mechanisms based on for instance login-password or electronic IDs have been already solved in by other projects and solutions. SocIoTal focuses on



Page 15/70

alternative and more sophisticated ways of performing authentication ensuring, at the same time, privacy and minimal disclosure of attributes. Thus, this kind of alternative privacy-preserving way of authentication using anonymous credential system is handled in SocIoTal framework by the Identity Management Component. The IdM is able to verify anonymous credential and then, in case the identity is proved, the IdM interacts with the authentication module which is the one that actually delivers authentication assertion to be used during a transaction. SOC-F01 The platform should provide authentication protocols/mechanisms to access

services/resources Identity Management Description: The Identity Management module is responsible for managing the identities of the smart objects and users. The module is able to take into account privacy concerns to manage subjects’ credentials (from users or smart objects), in a privacy-preserving way relying on anonymous credential systems. It is able to endow subjects with mechanisms to ensure anonymity, which is done mainly issuing pseudonyms and proof of credentials to minimal personal data disclosure. The Identity Management system is responsible for managing and storing the credentials, which are used by subjects to request information from an IoT services. The IdM allows users to obtain the proper credentials that can be use afterwards to derive proofs of identity to be presented to a Verifier (e.g., IoT Service provider) in order to prove the identity condition while disclosing the minimum amount of private information. The component is endowed with a cryptographic engine like Idemix [64] or U-Prove [65] responsible for low level cryptographic operations required by the anonymous credential system. The information provided by the Context Manager module is used by the IdM to handle the usage of partial identities under a specific context. REQ61 A User or a device shall be anonymised (or identified by a pseudonym) REQ76 Pseudonyms shall be refreshed frequently REQ85 The user shall have the possibility to change his pseudonym when he wants Key Exchange and Management (KEM) Description: The Key Exchange and Management (KEM) component assists peers involved in a communication in the process of establish a security context, like for instance, setting up tunnels for a security communication. It involves cryptographic key exchange and provides interoperability between the peers in order to reach an agreement regarding the security functions to use for the communication. This component is also in charge of storing and generating the cryptographic keys. This traditional end-to-end encryption mechanism as well as key exchange is not a main target goal of the SocIoTal project since these issues are already addressed by different IoT platforms. SOC-F02 The platform should provide key exchange and management Context Manager Description: The Context Manager is the module in charge to infer the context where the device is operating by relaying on input received from the environment. Context should be computed locally to the device or follow defined device and user settings for the data that can be used for context inference. Applying privacy preserving data mining techniques to the shared data could protect device and user privacy in case of context computed externally to the device. Mechanisms to communicate context should be also envisioned. Moreover, as



Page 16/70

part of the SocIoTal framework, context is also one of the inputs for the assessment of the level of trust and reputation among users and devices. REQ107 The context shall be able to change the privacy policies REQ109 SocIoTal shall be able to capture the context of the user REQ110 The context of the user shall be private information REQ111 Context of the user shall not be used without the consent of the user REQ112 The user shall be informed in real-time if a service or other people use his

context REQ114 The SocIoTal shall provide a mechanism to assess trust and reputation of users

and devices REQ131 The SocIoTal system shall provide the capability to enable data collection based

on context REQ132 The SocIoTal system shall provide the capability to measure social relations

among devices REQ134 The SocIoTal system shall provide the capability to recognise user context and

to match it to predefined policies REQ135 The SocIoTal system shall provide the capability to adapt communication to

context REQ136 The SocIoTal system shall provide the capability to automatically create/extend

a bubble based on devices’ social interaction REQ137 The SocIoTal system shall provide the capability to adapt discovery to context REQ138 The SocIoTal system shall provide the capability to enforce a data access policy

based on the data consumer context Context Manager: Mobility Learning & Reliability Description: This component is a computation engine fed by time-stamped absolute location information inputs regarding mobile devices/users, which can be acquired by any continuous, e.g., Global Positioning System (GPS) / Global Navigation Satellite System (GNSS), Real Time Location Systems, location-enabled Wireless Sensor Networks, WiFi fingerprinting, etc.) or even discontinuous, e.g., detected sporadic connectivity with respect to Bluetooth-Low Energy (BT-LE) beacons, Femto-BS, etc.) localization means. As a first outcome, the function can issue mobility habits (i.e., integrated over time, out of past and current estimated trajectories) in the form of the most probable paths/directions/next-step hop followed by the devices/users (e.g., along with their probability weights, which can be also time-dependent) conditioned on their current spatial occupancy. It can also produce additional quality indicators reflecting the reliability of the mobility learning process it-self, that is to say, the mobility predictability (i.e., how much the past estimated trajectories have been spatially dispersed so far, and thus, reflecting if the inferred average mobility behavior is sufficiently representative or not). Finally, one more output regards the deviation of the currently acquired location information/trajectory with respect to the learnt expected behavior, reflecting somehow the mobility compliance with expectations (which can be integrated further as a trust component if the reliability of the learning process was assumed to be high). REQ68 SocIoTal shall be able to discover devices or people close to a location



Page 17/70

Context Manager: Location based T&R Rating Description: Based on location data and assisted by any kind of sensor data, this component will compute a rating of trust and reputation. The use of this component can be static or dynamic and based not only on location of the user but also on location of surrounding sensors, gateways and other people. REQ68 SocIoTal shall be able to discover devices or people close to a location REQ114 SocIoTal shall provide a mechanism to assess trust and reputation of users and


among devices Identity Management: Location based Pseudonym generation Description: Based on location of the user but also on location of the surrounding objects and people, this component is able to generate a pseudonym that can be used by the Identity Management component to preserve privacy. REQ61 A User or a device shall be anonymised (or identified by a pseudonym) REQ76 Pseudonyms shall be refreshed frequently REQ85 The user shall have the possibility to change his pseudonym when he wants Policy Manager Description: The Policy Manager is the decision taking engine that receives the adequate context classification from the Context-Manager and uses it to decide which policy to apply in order to control the behaviour of all the policy-aware components. The Policy-Manager can be configured with a set of default system defined policies that apply for each context defined and implemented by the Context-Manager and it can also be provided with an intelligence (e.g., reinforcement learning) that can include feedback from the user in terms of the policy rating and application in order to adapt its behaviour. REQ107 The context shall be able to change the privacy policies REQ108 Privacy policies shall be properly formalized and checked REQ115 Users shall be able to specify their access control preferences REQ116 SocIoTal shall be able to evaluate an access request depending on access

control policies REQ123 A user’s data shall be processed only with the user's consent REQ134 The SocIoTal system shall provide the capability to recognise the user

context and to match it to predefined policies REQ135 The SocIoTal system shall provide the capability to adapt communication to

context REQ138 The SocIoTal system shall provide the capability to enforce data access

policy based on data consumer context REQ89 Users shall be able to choose if they want to be discovered (thanks to their

devices) A holistic view of the SocIoTal Functional Components is provided in Figure 5.



Page 18/70

Figure 5. The SocIoTal functional components



Page 19/70

Section 3 - Information views Information views, as described in IoT-A, define how the different functional components interact. The flows of data are obviously dependent on the modelled use case and can be split into multiple stages. For example, those steps could be the discovery of an IoT service, the subscription to the service, the pushing of data to the service, etc. The type of interaction was also mentioned: push of data, subscribe/notify, request/response, publish/subscribe. Figure 6 shows the information view of the Weather Forecast (Sharing Info/Entities) use case.

Figure 6. Weather forecast use case information view

In order not to overload the deliverable, the information views (almost twenty views) were moved in the document’s Annex I. To ease the understanding of the diagrams, the requests of security components were not included in the flow as arrows but they were added in the comments with references to generic security flows. There are 5 security information views:

IoT service request: shows the interactions between security components when any kind of IoT service is requested by a user or application. This case is often used in the different scenarios.

VE service request: same as previous case but for a VE service. IoT Service Push Data: shows the interactions between security components when a

device pushes data in an IoT service. Secure Group Sharing: shows the security flow when a user or application wants to

share data in a group of users or things. Context Manager access to a VE service: shows the security flow when the Context

Manager requests a VE service, a case often use with the enablers developed in SocIoTal.

Figure 7 presents the security information view for the request of an IoT service as an example. All the other flows can be seen in Annex I.



Page 20/70

Figure 7. Security information view for the request of an IoT service



Page 21/70

Section 4 - Data Models IoT based systems need data to process instructions, trigger events and generate outcomes; and these data sets are totally dynamic. Changes here must be detected in a real time, and applications must quickly adapt to such changes [7]. As for the IoT, current deployments are, and future networks will continue to be, heterogeneous, multi-vendors, multi-services and largely distributed. Consequently, the risk of non-interoperability will increase. Having this in mind, the nature of the information is the most important feature to consider when data is being handled, including also:

Trust and validation of the data gathered. Representation and standardization (through data and information models) of the

collected data sets. Share these information models among the IoT services and applications.

The model in the IoT for exchanging data is based on simple concepts and its relationships, as syntactical descriptions between those concepts. For example an object or entity is composed of a set of intrinsic characteristics or attributes that define the entity itself, plus a set of relationships with other entities that partially describe how it interacts with those entities. The objects/entities can represent anything that is relevant to the management domain (in this case IoT). Moreover, the relations that can exist between the different model entities can represent many different types of influence, dependence, links and so on, depending mainly on the type of entities that these relationships connect. The model’s objective is to describe the entity and its interaction with other entities by describing the data and relationships that are used in as much detail as is required. This abstraction enables the model to be made more comprehensible by different applications. Since this format is machine-readable, the information can be processed by applications much easier than an equivalent, free-form textual description. So, the different data and information models introduced in this section will be used to describe, store and manage the entities involved in SocIoTal, from raw data produced on sensor devices to users and communities sharing processed information sets in a standardised way within SocIoTal tools/platform. The here envisioned standardised models aim to properly communicate all the involved SocIoTal modules, allowing the data access and sharing within them. Choose or manage the proper description models also enables the interaction with modules and/or information systems outside SocIoTal. 4.1 Resource Model A resource in IoT is the software core component related to a device or entity that can provide information or enable controlling of it (e.g., a sensor or an actuator) [8]. The W3C Semantic Sensor Networks Incubator Group has developed the Semantic Sensor Network (SSN) ontology [9] that provides a high-level schema to describe sensor devices, their operation and management, observation and measurement data, and process related attributes of sensors. It is used to create the IoT-A resource description model, which in turn will sustain the SocIoTal platform resources. This model describes different attributes of the IoT resources, including functional, thematic and spatial features, providing also links to other resources, entities and services same system. The resource basic concept has datatype properties that specify its name (hasName), an ID (hasResourceID) and time zone Uniform Resource Identifier (URI) (hasTimeZone). The resource provider can specify certain keywords describing the resource through the hasTag property. A resource also has a location property (hasResourceLocation) that can represent the location of the device the resource runs on. The resource type is denoted in terms of the type property (hasType) to the ResourceType concept. Resources can be instances of either of the following types: sensor, actuator, RFID tag, storage or processing resource. The



Page 22/70

different resource types are not disjoint. When the type is a sensor, the hasType property serves as a link to an instance of a sensor that conforms to an available sensor model (e.g., SSN sensor ontology). This allows linking the resource concept to external models which already define in detail related concepts, without the need of repeating them in the Resource Model. As the access to a resource is provided by an IoT Service, this link to the service is denoted by the ‘isExposedThroughService’ object property that links the resource model to an IoT Service instance of the IoT-A service model. The resource model also captures the link to the hardware ‘device’ on which the resource is hosted by defining a property isHostedOn, binding the Resource Model to a Device Model. 4.2 Service Model A generic service model describes common interfaces and exposes the functionality of a device by accessing its hosted resources [8]. The resource/service modelling can be also extended to business processes. An approach for modelling of business processes by using semantically annotated resources that take dynamicity of the IoT environments into account is described in [10]. The service model will also contain information needed for discovering and looking up the service as well as information on how to invoke it. These information will be essential when developing, implementing and running SocIoTal enablers involving discovering features. The service model to be used within SocIoTal tools will be based on the IoT-A specifications shown in Figure 8.

Figure 8. IoT‐A Service Model (D4.3)

4.3 Virtual Entity Model An entity is a virtualisation of “things” in IoT and could be a person, animal, car, a physical location or any other object in the physical world. The “entity” is the main focus of interactions by user and software agents in the IoT world. In addition to the profile properties such as name and identifier, the virtual entity model defined in IoT-A [8], followed by SocIoTal, includes properties to describe location of an entity, and description elements for features of interest for an entity (features that can be observed by a sensing mechanism or can be changed/controlled by an actuation process). The IoT-A Domain Model [11] presents a Unified Modelling Language (UML) diagram where the virtual entity forms the main focus of interactions by humans and/or software agents. The purpose of these models is to present a structure for the respective information and



Page 23/70

relationships. The service aspects are captured by the service model, which exposes resource functionalities and provides a standardised access mechanism to the resource capabilities. These IoT Services are associated to Virtual Entities through what is called “associations”. Figure 9 and Figure 10 present the domain models seeds of the Santander and Novi-Sad use cases within SocIoTal.



Page 24/70

attributeName: string = event01attributeType: string = event

Event: attribute

Use Case Virtual Entity Data Model

Identifier: string = WSep1entityType: string = REST_SERVICEURL: stringparameters

IoT Service: Webservice endpoint

userId: int = 34EntityType : String = ReportEntity

User: VE

Use Case Virtual Entity API [IoT Services]

Identifier: string = HICentityType : string = scheduled_serviceURL: stringparameters

IoT Service: Happiness Index Computation

Identifier: string = IB01entityType: string = REST_SERVICEURL: stringparameters

IoT Broker: Service

Descriptin: string = VE descriptionuserId: int = unique IDuserCredentials: credentials

User Metadata: MetaData VE

Data = problem description

EventValue: Value

Info: ValueContainer

Description: string = evententityCategory: string = BuildingProblementityTopic: string = Elevator MalfanctionentityImage: BLOBuserId : int = 34

EventMetaData: MetaData_Ev

EventAssociation

attributeName: string = moodattributeType: string = mood

Mood: Attribute

Data: Happy

MoodValue: Value


Mood: string = mood_typeuser_id :int = 34

MoodMetaData: MetaData_Mood

attributeName: string = happiness indexattributeType: string = happiness measure

HappinessIndex: Attribute

Data: 60

HapinessIndexValue: Value


Index: int = happiness index valuecityId: int = city identifier

HappinessIndexMetaData: MetaData_HI

MoodAssociation

HappinessIndexAssociation

Figure 9. Novi‐Sad use case VE model



Page 25/70

Use Case Virtual Entity API [IoT Services]

identifier : string = VirtualWS01entityType : string = Sensing Entity

Weather Station : Virtual Entity : Virtual Entity

attributeName : string = Temperature01attributeType : string = Observation

Temperature : Attribute

Info : ValueContainer

Data = 23

TempValue : Value

phenomenom = Temperatureuom = ºCtimestamp = Obs_Time_Datelocation = Obs_GPSurl = /local/WS_VE_01/Temp

TempMetadata : MetaData_Obs

attributeName : string = Pressure01attributeType : string = Observation

Pressure : Attribute

Info : ValueContainer Data = 100

PressValue : Value

phenomenom = Atm. Pressuom = kPatimestamp = Obs_time_datelocation = Obs_GPSurl = /local/WS_VE_01/Press

PressMetadata : MetaData_Obs

attributeName : string = Humidity01attributeType : string = Observation

Humidity : Attribute

Info : ValueContainer

Data = 65

HumidityValue : Value

phenomenom = Air Humidityuom = %timestamp = Obs_time_datelocation = Obs_GPSurl = /local/WS_VE_01/Hum

HumidityMetadata : MetaData_Obs

description : string = VE descriptionowner : string = MyVEcreationTimestamp : uint = timestampgenericHub : string = BelongtoWSNuri = /local/WS_VE_01

WS_Metadata : MetaData_VE

identifier : string = WS01_HumServ01entityType : string = REST_ServiceURL : stringParameters

Humidity : Service

identifier : string = WS01_ResentityType : string = Weather Station

WS01_Resource : Resource

identifier : string = WS01entityType : string = Weather Station Devdescription : string

WS01 : Device

0..*

description : string = Res. descriptionuri : string = /local/Resowner : string = MyVE

creationTimestamp : uint = timestampgenericHub : string = BelongtoWSN

location : string = GPS

Res01_Metadata : MetaData_Res

identifier : string = WS01_TempServ01entityType : string = REST_Service URL : stringParameters

Temperature : Service

identifier : string = WS01_PressServ01entityType : string = REST_ServURL : stringParameters

Pressure : Service

TempAssociation

PressureAssociation

HumidityAssociation

Use CaseVirtual EntityData Model

Figure 10. Santander use case VE model

4.3.1 Associations The relations between Resources and Virtual Entities are modelled as associations between Virtual Entities and Services: an aspect of the Physical Entity is modelled as a Domain Attribute of the Virtual Entity, following the Virtual Entity Model presented in IoT-A [4]. The IoT Service may provide information about the Physical Entity, which corresponds to reading the Domain Attribute of the Virtual Entity, or the IoT Service may enable actuation on the Physical Entity, which, in the simplest case, may correspond to setting the value of the Domain Attribute. In more complex cases, the effect of the IoT Service on the Physical Entity modelled by the Virtual Entity has to be specified in more detail. This means that the Association also has to contain the Domain Attribute and what the IoT Service can do with respect to it.



Page 26/70

For each Virtual Entity there can be associations with different Services that may provide different functionalities, like retrieving information or enabling the execution of actuation tasks. Services can also be redundant, i.e., the same type of Service may be provided by different instances (e.g. redundant temperature Services provided by different Devices). In this case, there could be multiple associations of the same kind for the same Virtual Entity. Associations are important in look-up and discovery processes. Figure 11 shows the logical structure of an Association, according to IoT-A virtual entity model: It contains a description of the Virtual Entity, the IoT Service and the VEServiceDescription that describes what the IoT Service provides with respect to the Virtual Entity.

Figure 11. IoT‐A association structure

4.4 Other models This section describes the models further defined by SocIoTal. These include the Community, User, and Context Models. It has to be noted that these descriptions are high-level, while their detailed, final versions will be provided in the final version of the SocIoTal architecture. 4.4.1 Community Model One of the innovations driven by SocIoTal is the definition and creation of communities of users and smart objects to share information within. The concept of community and its different views will be deeper detailed and evolved in D2.1 [12] and along Task 3.2 of the project, but, in main lines, we will work with two differentiated sort of communities:

The driven communities (or just communities in a broad sense), created beforehand by an “owner” to add users and resources with concrete and common predefined objectives or with a clear existing relationship, and

The opportunistic community based on a specific set of security policies and created spontaneously when interesting circumstances or relationships conditions to do so arise. This one is a kind of dynamic sharing group that is not registered as community statically anywhere.

From the first kind of communities, and most interesting from the point of view of model definition (as it would be the most complex), we can consider the Platform-based Community, that involves users and smart objects all connected to an infrastructure network



Page 27/70

or platform. This common platform can provide centralized services to community members, registering and user management, data storage and processing capabilities, complex event pre-processing, service development and composition framework and so on.

Community: Platform_Comm

Community_ID

Owner

<<Interface>>

Interface: Community_API

Resource Directory: list of community's smart objects/resources

Storage Element: Cloud Community Space

User: Owner

‐User_ID

‐Profile

User's Directory: community users (list)

Security Policies

Figure 12. SocIoTal Platform Community Model

According to this Platform-based community description, the initial standard model for communities within SocIoTal (Figure 12) will be defined by the union of different capabilities provided by different functional modules or blocks from the common platform. The community will have:

An owner, as the user that initially created the community, defined its scope, initial policies, etc. Previously, this owner has been registered as a user, creating its profile within the platform’s User’s Directory (UD).

The community will include a link or access to the platform’s UD, in order to have an updated list of registered “users” (users can be considered as physical people or devices) and/or identities, with their associated profiles, that are allowed to share information within the community. A user that wants to belong to a concrete community needs first to register on it and be accepted.

The storage element, depending on the platform, will keep certain set of data (e.g. weather measurements, associated events info such photos, etc.) that, for example, need to be available for community users 24x7. It can be seen as a concrete storage place in the platform’s storage cloud.

The platform’s Resource Directory (RD) will provide the community with a list of registered resources and/or smart objects belonging to the community or that are available, in a specific time, for its users.

A set of Security Policies, provided by the Security & Trust module, will define how users will be identified and data will be shared within the community.

The community interface will define an API [12], [13] to create and define the community, as well as to perform all the management activities needed.

Other types of communities, such the opportunistic one or those further defined in D2.1 [12] and evolved during the SocIoTal progress, will adopt a similar or more simplified model to the one described here.



Page 28/70

4.4.2 User Model In a User Model, it should be possible to define the SocIoTal user personal data, to search, discovery and matching of specific user. The selection of one or the other representation will be also based according to the selected platform or existing models/profiles. We start from Portable Contacts as an open protocol. The focus of the protocol is to increase data portability by creating a common and open specification to bridge proprietary contacts APIs such as Google's GData Contacts API, Yahoo's Address Book API, and Microsoft's Live Contacts API. It combines OAuth, which is an open standard for authorization that provides a secure access to server resources on behalf of a resource owner, XRDS-Simple (an XML format for discovery of metadata about a web resource) and a wire-format based on vCard harmonized with schema from OpenSocial [66]. As notable implementation of this Portable Contacts here we mention Passport User Profile. Passport [14] is an authentication middleware for Node [67] (implementatios are available for other languages too). To make integration with third-party services (such as main social networks) easier, Passport normalizes profile information to the extent possible. Normalized profile information conforms to the contact schema established by Portable Contacts. The normalization will be functional for the integration of different SocIoTal components. The common fields available in Passport User Profile are outlined in the following list:

provider {String} The provider with which the user authenticated (facebook, twitter, etc.).

id {String} A unique identifier for the user, as generated by the service provider.

displayName {String} The name of this user, suitable for display.

name {Object} o familyName {String}

The family name of this user, or “last name” in most Western languages. o givenName {String}

The given name of this user, or “first name” in most Western languages. o middleName {String}

The middle name of this user. emails {Array} [n]

o value {String} The actual email address.

o type {String} The type of email address (home, work, etc.).

photos {Array} [n] o value {String}

The Uniform Resource Locator (URL) of the image. Note that not all of the above fields are available from every service provider. Some providers may contain additional information not described here. This representation could be extended and combined with the selected platform. 4.4.3 Context Model For the Context Model, SocIoTal does not aim to reinvent the wheel, as significant progress has been made already in the area of context modelling [16]. The main SocIoTal innovations will reside in using existing models to model new context that can be inferred with the new SocIoTal provided enablers and will allow to better characterize different contexts also in relation to the security and privacy issues they could be exposed. In order to support context sharing among different and heterogeneous devices, including smartphones and embedded devices, featuring different computation and storage capabilities, the most suitable choice for



Page 29/70

a context model for the SocIoTal framework could reside in Markup-based modelling scheme. This approach models data using tags, by storing context within tags. This technique is an improvement over the key-value modeling technique. The advantage of using markup tags is that it allows efficient data retrieval. Further, validation is supported through schema definitions. Sophisticated validation tools are available for popular markup techniques such as XML. Range checking is also possible up to some degree for numerical values. Markup languages do not provide advanced expressive capabilities which allow reasoning. However, it is expected that SocIoTal will define specific and unique context inference modules that will run directly on selected user devices or in distributed network components and that will leverage the new context information that the SocIoTal enablers will be able to extract (i.e., indoor localization position, Face-to-face interactions). The main role envisioned for a context model is the possibility to support search, discovery and matching of specific context. For this reason it is expected that a markup-based context model will suffice to SocIoTal needs for expressing specific context and it is envisioned that either XML or JSON based language will be considered. The selection of one or the other representation will be also based according to existing Context Communication module (i.e., Context Broker) that SocIoTal aims to reuse and adapt from existing projects (i.e., Fi-WARE). In case more candidate Context Communication modules could be used, particular attention will be devoted to make the selected context model interoperable among them. For all these reasons, within the WP3 activities, which will focus among the others in defining new SocIoTal contexts and context inference module, using SocIoTal enablers, the suitability of ContextML [17] will be evaluated and extension to it in order to support SocIoTal contexts considered. ContextML presents a light weight XML based context representation schema that can be supported by smartphones and more powerful IoT devices. Through ContextML the context information is categorized into scopes and related to different types of entities (e.g., user, device). The schema is also applied for encoding management messages in order to allow for a flexible framework supporting gradual plug & play extendibility and mobility. ContextML is tailored to be used for Representational state transfer (REST)-based communication between the framework components.

Figure 13 Entity‐scope relationship

Figure 13 shows the main elements composing the ContextML model. Every exchange of context data is associated to a specific entity, which can be a complex group of more than



Page 30/70

one entity. An entity is the subject of interest (e.g. user or group of users), which context data refers to, and it is composed of two parts: a type and an identifier. The type refers to the category of entities. The entity identifier specifies a particular item in a set of entities belonging to the same type. Specific context information in ContextML is defined as scope and is a set of closely related context parameters. Every context parameter has a name and belongs to only one scope. The scope will be used by SocIoTal to model context such as presence of friendly devices, as detect from Face-to-face interactions, presence in specific indoor positions, and so on. More detailed definition of context and associated scopes will be provided as part of WP3 activities. In addition, depending on a more detailed evaluation of the devices envisioned in the SocIoTal scenarios, WP3 will evaluate adaptations of the selected context model in order to support its communication and processing also in case of more resource constrained devices.



Page 31/70

Section 5 - Deployment Constraints In this section, the deployment constraints, if any, of the modules introduced by the SocIoTal framework are described. Specifically, the potential deployment side of each module, i.e., server, gateway, and/or device, is identified. Moreover, other potential deployment constraints of these modules are briefly summarized.

Module Deployment

Other Constraints Server Gateway Device

Process Modelling: Composition

(Trigger/Action) X

Process Execution: Scheduler

X

Visualisation module

X X Visualization is modelled on the server and provided by the device.

VE Service: Communities

X

VE Service: VE History Storage

X

VE Service: F2F Interaction Detection

X

IoT Broker X

IoT Service: Discover Request

X X Devices request the discovery through the gateway to access the server.

IoT Service: Registering Device

Request X X

Devices register themselves to the server through the gateway.

IoT Service: Subscription

Request X

IoT Service: Post Request

X X

Devices that push data are using gateway to POST data to the server. Other POST requests are sent directly to the server

IoT Service: DirectionData

X

IoT Service: NearbyDevicesData

X

Group Manager X X X

In the device it can be responsible for encrypt and decrypt shared information within groups.

In case of very constrained devices the group manager can



Page 32/70

be deployed in the gateway. The group manager could be also

deployed in the server and share user’s information in a secure way.

Authorization X X X

In the server it acts as Policy Decision Point (PDP), evaluates Authorization policies and makes authorization decisions. It also generates AuthTokens.

In the devices when acting as consumers the authorization client gets tokens from the server.

In the devices when acting as producers the authorization Policy Enforcement Point (PEP) verifies the authTokens obtained before.

The AuthPDP and AuthzPEP could be also deployed in the gateway.

Authentication X X

In the server it validates devices and users identity. Either by traditional authentication methods or by anonymous credential systems.

In devices the AuthNClient obtains authnAssertions.

Identity Management

X X

In the server it manages pseudonyms and credentials. It can act as Verifier of anonymous credentials when a device requests data from the server.

In the server it can also act as Issuer of credentials.

In the device it acts as Recipient to ask for anonymous credentials from an Issuer.

In the device it can also act as Prover of credentials against at the Verifier (e.g., IoT service) being accessed.

KEM X X X

In the device the KEM enables to obtain encryption keys.

In the device it allows establishing secure channels.



Page 33/70

In the server it generates keys (either for symmetric and asymmetric cryptographic schemes)

In the gateway it can act as intermediate component to provide and deploy keys in devices.

Context Manager X X X

Module for Context Communication should reside on server;

Module for Context Acquisition, Context Reasoning and Prediction could run on Gateways and Servers and paired by lightweight counterpart module in case of constrained devices.

Context Manager: Mobility Learning &

Reliability X X X -

Context Manager: Location based

T&R Rating X X X

Location data can be provided by: Absolute positioning means, e.g.,

GPS, positioning wrt. localization infrastructure, such as Impulse-Radio Ultra-Wideband (IR-UWB) or Zigbee/IEEE 802.15.4 wrt. anchors or WiFi Access Points (APs) or Real Time Locating System (RTLS) Base Stations (BSs).

Relative peer-to-peer ranging or cooperative positioning means, e.g., Round Trip - Time of Flight (RT-TOF) over IR-UWB links, RSSI over Zigbee/IEEE 802.15.4 links or WiFi direct links.

Identity Management:

Location based Pseudonym generation

X X X

Location data can be provided by: Absolute positioning means (e.g.

GPS, positioning wrt. localization infrastructure such as IR-UWB or Zigbee/IEEE 802.15.4 wrt. anchors or WiFi APs or RTLS BSs)

Relative peer-to-peer ranging or cooperative positioning means (RT-TOF over IR-UWB links, RSSI over Zigbee/IEEE 802.15.4



Page 34/70

links or WiFi direct links)

Policy Manager

The Policy Manager will oversee behaviour of different other components, such as Authorization, Identity Management, Group Manager and as so will be deployed in conjunction with such components.



Page 35/70

Section 6 - Selection of existing platform In this section, the process followed in order to select an existing architecture to be used as base for the development of the envisioned SocIoTal innovations is described. A first shortlist of platforms has been proposed in D1.1 [3] based on an extensive range of criteria, following different dimensions, such as among others, architecture type, support for security and privacy aspects, dimension of the supporting community and so on. At this stage, as the a first version of the SocIoTal architecture is envisioned and some of the required components are identified and described, a set of more pragmatic criteria have been proposed in order to select the final existing architecture among the ones shortlisted. The identified criteria try to maximize the overlap of already implemented standard components, between the selected architecture and the ones required by SocIoTal standard components, thus allowing the project to focus on the development and integration of those components that represent the SocIoTal innovations. 6.1 Criteria for selection The considered criteria are the following:

Open source: This is an important criterion, as this will allow also the SocIoTal platform to be open source and most importantly will allow to gain access to the source code of the existing selected architecture, which will simplify the integration activities and will facilitate the re-distribution of the developed components;

Space for SocIoTal innovations: Thus identifying how easily in the existing architecture and how useful will result the integration of the SocIoTal envisioned architecture in covering existing gaps;

Collaboration and support with platform owner: This will make possible to establish collaboration with on-going projects in order to foster in-house support from existing platform in order to make easier the integration with SocIoTal components;

Closeness to the IoT-A architecture: This criterion is useful to identify platform that already follow the IoT-A methodology for architecture definition, thus making easier to identify the overlap between SocIoTal required components and functionalities and those already provided by the existing architectures;

Reuse of most of components and functionalities: This represents the most important criterion as it allows to establish how large is the overlap of existing architecture and the one envisioned by SocIoTal. The selection of the existing platform with a large overlap will be preferred among the others in order to allow the project mainly focus on the development of the main envisioned SocIoTal novelties.

6.2 Review of existing platforms In this section, we review the candidate platforms with respect to the identify criteria.

Table 1. Review of the BUTLER platform

BUTLER [18] Open source The main reusable components from BUTLER will be the

ones related to the IoT platform such as Service/Resource Discovery, Service/Resource Lookup, Service/Resource resolution, Resource Access, Southbound IoT Connectivity (CoAP, Zigbee, SmartTv, enOcean, etc.), Northbound cloud connectivity (HTTP Rest, JSON-RPC, CDMI, MQTT, etc.). A smart mobile framework that provides easy ways of building applications is also provided and can be useful. The components for security and privacy, mainly implemented by Gemalto, can be used freely but the code is not opened.

Space for SocIoTal Yes, inclusion of the security, trust and reputation concepts



Page 36/70

innovation in the platform Collaboration and Support with platform owner

CEA is the technical coordinator of the project.

Closeness to IoT-A BUTLER project had many interactions with the IoT-A project and built its architecture based on the IoT-A.

Reuse of most components and functionalities

BUTLER platform is based on a modular framework and adopts a service oriented approach, which makes it a very flexible and extensible platform.

Table 2. Review of the OpenIoT platform

OpenIoT [19] Open source Yes Space for SocIoTal innovation

Yes (privacy perspective)

Collaboration and Support with platform owner

No

Closeness to IoT-A

Yes (the OpenIoT is concrete architecture for IoT application that leverages several principles of the IoT-A ARM)


Components of the platform in general can be reused/upgraded.

Table 3. Review of the FI‐WARE/FI‐LAB platform

FI-WARE/FI-LAB [37] Open source API specifications of platform and building blocks, General

Enablers (GEs), are open and completely free of royalties and are supported by an open source reference implementations. The specification of the API is free but commercial use of some GE implementations may be subject to payment.

Space for SocIoTal innovation

FI-WARE reference architecture considers enablers for Security monitoring, Identity Management, Privacy, Data Handling and Context-Based Security that can be designed and implemented within SocIoTal. In the same way, Context Management and Context Aware enablers are also envisioned.


UC and UNIS are partners of FI-WARE project. FI-WARE, through its Open Innovation Lab (FI-LAB), provides information, tutorials, support and access to working instances of its architecture and GE implementations (GEis) for experimentation. Some GEis are also available to be downloaded.

Closeness to IoT-A

The FI-WARE IoT Services Enablement Architecture chapter is based on IoT-A reference implementation to define and build the GEis that expose devices and IoT resources to services developers.

Reuse of A continuously growing set of functionalities and components are



Page 37/70

most components and functionalities

available (through different open source licenses) for experimentation and implementation. Includes IoT gateway IoT broker, Context Management, Big Data, Service Repositories, Market place and security enablers.

Table 4. Review of the Webinos platform

Webinos [20] Open source Yes, the source code of its tools is fully available on:

https://developer.webinos.org/ and https://github.com/webinos Space for SocIoTal innovation

Yes (perhaps for critical security and reliability issues)


No

Closeness to IoT-A

No


Partially Yes

Table 5. Review of the DeviceHive platform

DeviceHive [21] Open source Yes, code available on: https://github.com/devicehive Space for SocIoTal innovation

Yes, as the cloud architecture focus on providing a communication layer among things, while the SocIoTal innovations can be developed at Gateway, client and server/cloud side.


Small and not very active community.

Closeness to IoT-A

Limited. The architecture follows a basic three-tier architecture.


Yes, implementations for all the components of the architecture (device, gateway, client, server) are provided. Basic security functionalities based on role based authentication. However a very limited number of required SocIoTal components are provided.

Table 6. Review of the di.me platform

di.me [22] Open source Yes, but it is not an IoT platform. Space for SocIoTal innovation

Yes



Page 38/70


Not directly. But it could be asked, in case the platform were a strong candidate.

Closeness to IoT-A

None, it follows its own architecture.


Ideas and perhaps some software could be incorporated to our project, but not the framework as a whole.



Page 39/70

Section 7 - Selected Platform Description In D1.1 [3] and sections above, a set of six different platforms were analysed according to different criteria as shown in Section 6 - . Some of these platforms fulfil the requirements to a greater extent than others. Webinos, DeviceHive and di.me were discarded because they do not offer strong collaboration and support with the platform owner and because of their lack of closeness to the IoT-A architecture. From the remaining options, SocIoTal selected FI-WARE as the core platform, motivated by the advantages offered when laying the foundations for the development of the SocIoTal tools. However, this choice remains open to include other elements or enablers from other platforms to perform or develop SocIoTal functional blocks, in order to create an open, flexible and independent IoT architecture. This section will describe the FI-WARE platform, from the point of view of SocIoTal’s criteria selection, providing the links to expand this information with all the specific and available data. 7.1 FI-WARE introduction FI-WARE is an innovative, open cloud-based infrastructure for cost-effective creation and delivery of Future Internet applications and services. In few words, it specifies an overall Reference Architecture [23] divided in several sub-reference architectures related to “chapters”:

Cloud Hosting Data/Context Management IoT Services Enablement Applications/Services Ecosystem and Delivery Framework Security Interface to Networks and Devices (I2ND)

These architectures are composed by different building blocks that define the APIs and the functionalities belonging to every chapter. These components are known as General Enablers (GE), so the Reference Architecture associated to each FI-WARE chapter can be instantiated into a concrete architecture by means of selecting and integrating products implementing the corresponding FI-WARE GEs. 7.2 Open Source Specifications of APIs (FI-WARE API Open Specifications [24]) and Interoperable Protocols (FI-WARE GE Open Specifications [25]) supported by FI-WARE Generic Enablers will be public and Royalty-free. GE Open Specifications will contain all the information required in order to build compliant products, which can work as alternative implementations of GEs developed in one particular FI-WARE chapter. GE Open Specifications will typically include, but not necessarily will be limited to, information such as:

Description of the scope, behavior and intended use of the GE. Terminology, definitions and abbreviations to clarify the meanings of the specification. Signature and behavior of operations linked to APIs (Application Programming

Interfaces) that the GE should export. Signature may be specified in a particular language binding or through a RESTful interface.

Description of protocols that support interoperability with other GE or third party products

The FI-WARE consortium intends to deliver a reference implementation for each of the Generic Enablers defined in the FI-WARE Architecture. Some components of these reference implementations may be closed source while others may be open source.



Page 40/70

Currently, FI-LAB [26], a working instance of FI-WARE available for experimentation, provides a catalog [27] with available GEis including their description, documentation and download links. All of them are available for experimentation within FI-LAB and some of them are open source (basic SocIoTal requirements such IoT Broker, Resource Directory or storage capabilities, are handled by open source GEis like the DCA/IDAS Backend Device Management, Orion Context broker, Cosmos Big Data, etc.).

7.3 Space for SocIoTal innovation If privacy, security and trust, as well as context aware applications and services oriented to citizens can be considered as the main focus for SocIoTal innovations, FI-WARE provides three chapters where SocIoTal can develop GEs implementing the desired functionalities, assisted by other GEs not relevant for SocIoTal but needed for its purposes:

Security [28]: Security, Privacy and Trust in FI-WARE is mainly focusing on delivering tools and techniques to have the above-mentioned security needs properly met. The high-level Reference Architecture is formed by four main blocks of GEs: Security monitoring, Generic Security Services like Identity Management, Access Control, Privacy, Data Handling; Context-Based Security and Compliance and optional Generic Security Services: DB Anonymizer, Secure Storage Service, Malware Detection Service, Android Flow Monitoring and Content-based Security. The current catalogue of available security GEis [29] include some dealing with identity management and Privacy-preserving.

Data/Context Management [30] chapter aims at providing outperforming and platform-like GEs that will ease development and provision of innovative Applications that require gathering, publication, processing and exploitation of information and data streams in real-time and at massive scale. FI-WARE Data/Context Management GEs allow to gather information from context and other sources (Context Broker), mediate metadata among GEs and applications (Metadata pre-processor) query stored information through an homogeneous layer (Query Broker), generate new data from compressed video services (Compressed Domain Video Analysis - CDVA), annotate existing information (Semantic Annotation), store and manage semantic information (Semantic Application Support), generate new knowledge from big data stores using a Map & Reduce paradigm (Big Data analysis) and react to different types of scenarios (Complex Event Processing). Moreover, it provides a Middleware to allow flexible and efficient communications among GEs and applications. The current catalogue of available Data/Context Management GEis [31] include Big Data analysis, Complex Event Processing and Context Broker.

Applications/Services Ecosystem and Delivery Framework [32] & Developer Community and Tools (DCT) [33] build an ecosystem of applications, services and tools that is sustainable and fosters innovation as well as cross-fertilization. In particular the Apps Generic Enablers supports managing services in a business framework across the whole service life cycle from creation and composition of services to monetization and revenue sharing. The DCT offers a multi-functional development environment - FI-CoDE - enabling the development and management of the Future Internet Applications (FIApp) built to address the needs of the Future Internet and based on the adoption and integration of the Generic Enablers Implementations. The Apps&Services catalog [34] includes open sourced GEis for service repositories, service and apps mashup, business modelling, market place and so on. Different tools [35] for developers are also provided.



Page 41/70

7.4 Collaboration and Support with platform owner Related to this aspect, FI-WARE project, in order to pave the way for a successful exploitation and sustainability, is currently providing an Open Innovation Lab: FI-LAB [26] based on the FI-WARE testbed after the second release of FI-WARE, implementing now its third release. This FI-LAB supports community involvement beyond the initial partner Use Case projects, offering a space where future innovations on top of the generic enablers provided by FI-WARE can be nurtured. The availability of FI-LAB per se does not guarantee innovation as such, therefore FI-LAB comprises all what is needed to stimulate awareness among target application providers and users so that they feel attracted to participate and build a community. It also brings tools helping members of the community to share their experiences, needs, etc. Through the FI-LAB, a developer or an R+D project such SocIoTal, can get open access to a fully operative instance of the FI-WARE architecture to experiment with all implemented GEs. It also provides [36] descriptions, instruction manuals and all documentation needed to operate (or even download and install its own GEi instance) of every published and available GEi. As far as UC and UNIS are members of FI-WARE/FI-LAB project, further support is guaranteed. Apart of the platform and support availability, FI-LAB community [37] organizes events such hackatons [38] in all over the world (not only Europe) and diverse e-learning sessions (like webinars and tutorials) to reinforce community engagement. These FI-WARE efforts could be interesting also to promote SocIoTal among different communities. In this educational line, FI-LAB provides an e-learning platform [39] including complete tutorials, “how-tos” and planned courses to work with the complete FI-WARE platform, organized by chapters and GEis. This simple tutorial [40] shows an easy way to connect to FI-LAB and share information, introducing the basis to create our own IoT deployment according to IoT perspective. 7.5 Closeness to IoT-A The FI-WARE Reference Architecture and its building chapters come up from a particular view of the IoT-A RM and can be easily mapped on its functional groups according to the functionalities provided:

IoT-A Functional Group FI-WARE Chapter Communication Interface to Networks and Devices (I2ND) IoT Service Internet of Things (IoT) Services Enablement + Data/Context

Management IoT Process Management Virtual Entity Cloud Hosting Service Organisation Applications/Services Ecosystem and Delivery Framework Security Security Management Internet of Things (IoT) Services Enablement



Page 42/70

Figure 14. Fi‐WARE platform with all major chapters

FI-WARE will build the relevant Generic Enablers for Internet of Things Service Enablement [41], in order for things to become citizens of the Internet –available, searchable, accessible, and usable – and for FI services to create value from real-world interaction enabled by the ubiquity of heterogeneous and resource-constrained devices. FI-WARE IoT approach follows the Thing-Device-Service-Resource concepts promoted by IoT-A using the same data models to describe them:

A device is a hardware entity, component or system that either measures properties of a thing/group of things or influences the properties of a thing/group of things or both measures/influences. Sensors and actuators are devices.

IoT Resources are computational elements (software) that provide the technical means to perform sensing and/or actuation on the device. The resource is usually hosted on the device.

Thing (Virtual Entity) can be any object, person, or place in the real world. Things are represented as virtual things having an entity ID, a type and several attributes. Sensors can be modelled as virtual things, but other real-world things like rooms, persons, etc. can be modelled as virtual things as well. So thing level data consists of descriptions of things and their attributes, while information on how the data has been obtained might be contained as meta-data, but is in general out of scope.

The deployment of the architecture of the IoT Service Enablement chapter is typically distributed across a large number of Devices, several Gateways and the Backend.



Page 43/70

IoT GEs have been spread in two different domains: Gateway and Backend. While IoT Gateway GEs provide inter-networking and protocol conversion functionalities between devices and the IoT Backend GEs, the IoT Backend GEs provide management functionalities for the devices and IoT domain-specific support for the applications.

7.6 Reuse of most components and functionalities This is a first list of different enablers or functional blocks currently available within FI-LAB and considered interesting for SocIoTal, based on the requirements shown in [3] and [13]. There is a bigger set of available software and tools through its catalogue [27].

IoT Gateway: an optional element in the FI-WARE IoT architecture providing inter-networking and protocol conversion functionalities between devices and the IoT Backend plus overall optimization (reduce traffic load to the Backend, improve response time). Open source implementations of this GE could be found in DeviceManagement GE [42]; DataHandling GE [43] ProtocolAdapter GE [44]. Implements: Device Gateway

IoT Backend Management [45]: is a component for retrieving and aggregating information from the Internet of Things. The underlying data model of this GE is based on the OMA NGSI (Next Generation Service Interface) Context Management Information Model, which is centred on the concept of context entities. In the context of IoT, context entities are used for representing devices like sensors and the values they measure, but also - and more importantly - arbitrary physical objects (Things) like rooms, persons, etc. and their attributes like temperature, geo-location, etc. NEC IoT Broker [46] is an open source GEi. The TID Device Management GEi [47] (open source) implements the IoT Backend Management. Implements: IoT Broker + Publish/Subscribe module + Resource Directory + VE Resolution

Context Broker [48]: will enable publication of context information by entities, referred as Context Producers, so that published context information becomes available to other entities, referred as Context Consumers, which are interested in processing the published context information. Events in FI-WARE based systems refer to something that has happened, or is contemplated as having happened. Changes in context information are therefore considered as events that can be handled by applications or FI-WARE GEs. The most extended CB GEi within FI-LAB (open source) is the Orion Context Broker [49]

Complex Event Processor (CEP): analyses event data in real-time, generates immediate insight and enables instant response to changing conditions. While standard reactive applications are based on reactions to single events, the CEP GE reacts to situations rather than to single events. A situation is a condition that is based on a series of events that have occurred within a dynamic time window called processing context. The IBM Proactive Technology Online (Proton) [50] is an open source implementation of the FI-WARE CEP GE.

Big Data [51]: the Big Data Analysis Support GE offers a continuous solution for both Big Data Crunching (process huge amounts of previously stored data) and Big Data Streaming (process continuous unbounded and large streams of data extracting relevant insights on the go). A key characteristic of this GE is that it would present a unified set of tools and APIs allowing developers to program the analysis on large amount of data and extract relevant insights in both scenarios using a standard programming paradigm (Map&Reduce, see below). Open source GEi for this is COSMOS [52]. Implements: Data manager and storage



Page 44/70

Query Broker [53]: provides a smart, abstracting interface for retrieval of data from the FI-WARE data management layer. This is provided in addition to the publish/subscribe interface (e.g. Context Broker (Publish/Subscribe Broker) GE) as another modality for accessing data. Principal users of this GE include applications that require a selective, on-demand view on the content/context data in the FI-WARE data management platform via a single, unified API, without taking care about the specifics of the internal data storage and DB implementations and interfaces. Siemens Query Broker [54] is a free GEi of this component.

Object Storage [55]: offers persistent storage for digital objects, important cloud-based functionality that has been specifically requested by Use Cases. Objects can be files, databases or other datasets which need to be archived. Objects are stored in named locations known as containers. Containers can be nested thus objects can be stored hierarchically. This is an open source GEi [56]

Service Repository: the service repository provides a consistent uniform API to USDL service descriptions and associated media files for applications of the business framework. A service provider can use the Repository to publish the description of various aspects of the service according to a uniform description language. FI-LAB provides an open source GEi [57].

Security Monitoring [58]: the Security Monitoring GE was designed to be offered as a services suite. The services provided, even if they can be used in isolation offer their most when used conjointly to cover the whole & primary usage pattern. Hereafter is the list of services offered by the Security Monitoring: MulVAL Attack Paths Engine; Scored Attack Paths; Remediation; Service Level SIEM; Visualisation; IoT Fuzzer; Android Vulnerability Assessment; GE implementation [59].

Context-based security [60]: provide the security layer of FI-WARE with context-aware capabilities to support additional security requirements through the optional security enablers developed in FI-WARE (DBAnonymizer, Secure Storage Service, Malware Detection Service, Android Flow Monitoring, Content-based Security, etc) not provided by the generic FI-WARE security services (Security Monitoring, Identity Management, Privacy, Data Handling), because Core GE's are the ones that by essence are also there by design since demanded by most application (As Security by design or Privacy by design). We could even think of making security by design have the capacity to be extended thanks to CBS&C offer that can add the additional optional services requested by the applications at hands. CBS will also provide, together with optional security services search and deployment, run-time reconfiguration that will allow Use cases both deal with unpredictable context changes and ensure the compliance with the security requirements. Implementation available here [61].

Privacy-Preserving Authentication: this enabler provides the code to implement the various components of a privacy-preserving authentication system. In particular, it allows (a) identity providers to setup an online service for issuing privacy-preserving attribute-based credentials (aka anonymous credentials) (b) end users to generate privacy-preserving tokens (on the basis of a given access policy) to anonymously yet accountably authenticate to service providers (c) service providers to verify the user-generated tokens with respect to a given access policy. An Open source GEi is available here [62].



Page 45/70

Section 8 - Success indicators This document also aims to assess if the relevant outcomes of task T1.2 described in the SocIoTal description of work have been reached: “An architecture for a citizen-centric IoT deeply embedding privacy and security by design which is aligned with emerging IoT reference architecture”. This assessment is performed through tangible success indicators, which can determine at first sight if the goals are achieved. Architecture for SocIoTal use cases

Percentage of D1.1 use cases covered by the architecture: 100% All the use cases described in D1.1 were utilized to generate the architecture. The information views of those use cases can be seen in the annex of this document.

Architecture based on IoT-A Architecture Reference Model Number of functional components from IoT-A ARM: 21

ARM specifies 23 functional components which are almost all reused in SocIoTal except 2 components of management of the system

Number of innovative SocIoTal functional components: 7 Specific IoT services were not counted in this survey since their impact are already taken into account in IoT-A

Reuse of existing platform components

Number of reused functional components in FI-WARE This will depend on the final implementations provided by SocIoTal and the progress supported by FI-WARE, but currently there are 6 identified components: Device Gateway; IoT Broker; Publish/Subscribe module; Resource Directory; VE Resolution; Data manager and storage (see section 7.6).

Number of functional components not yet implemented in FI-WARE All related to SocIoTal innovations (security & trust functional blocks, communities management and discovering enablers).

Security and Privacy by design

Is there a Keys Exchange and Management component in the architecture? YES This component already present in the ARM will also be used in SocIoTal.

Is there an Authorization mechanism in the architecture? YES A distributed authorization mechanism will be implemented in SocIoTal.

Is there an Authentication mechanism in the architecture? YES An authentication functional block is present in SocIoTal architecture.

Is there an Identity Management in the architecture? YES Privacy is the core concept of SocIoTal, thus an IdM is mandatory.

Is there a mechanism to preserve privacy of users and data in the architecture? YES Preserving privacy in the whole system is a major concern for SocIoTal: IdM for anonymization and CP-ABE (see D2.1) managed by the Group Manager to ensure unlinkability and untraceability of data are the cornerstones of SocIoTal.

Is there an integration of contextual Security and Privacy in the architecture? YES A specific component named Context Manager has been added in the security functional group.

Is there an assessment of Trust and Reputation of things and users in the architecture? YES Like in the ARM a T&R component will be implemented.

Does all security and privacy functional components can interact? YES We have developed specific information views to show how the security functional components interact in the different use cases.



Page 46/70

Citizen centric and communities based architecture: Is there a group manager in the architecture? YES

There is a Group Manager in the architecture to deal with communication of data in groups of devices or users. There is also a VE service named Communities which will ensure the management of Communities.

Is there a specific security for group of people and things in the architecture? YES Specific cryptographic scheme CP-ABE (see D2.1) will be developed in the Group Manager to ensure the security within a group of things or users.

Does the architecture ensure interoperability of devices? (can any kind of devices communicate together?) YES The architecture is based on the ARM which ensures interoperability

Does the architecture ensure scalability? (does a new device or user can easily enter in the SocIoTal system?) YES Also, one advantage to follow reference architecture is to maintain scalability.



Page 47/70

Section 9 - Conclusion This deliverable defined and described in detailed the initial version of the SocIoTal architecture. As described in the project Description of Work, a major objective of the project is “to design a socially-aware citizen centric architecture for an IoT eco-system providing services for cities, citizens and their communities”. In order to meet this objective, following the defined requirements, scenarios and use-cases of Task 1.1, the proposed architecture was built using the principles and the framework developed in the IoT-A research project. Its aim was to strengthen its foundations to support the requirement of massively crowd-sourced citizen-centric IoT infrastructures alongside more traditional application domain dependent IoT deployments. The close compliance with the IoT-A framework, also allowed SocIoTal to emphasize on its novel context- and privacy-aware characteristics, not needing to re-design already existing modules. The architecture description consists of detailed definition of the interactions that take place between the functional modules introduced by SocIoTal, with particular emphasis on the security interactions, in the form of IoT-A information views. The architecture description is completed by the provision of the Data, Community, User and Context Models, as well as an overview of the deployment constraints of the identified modules. Since the SocIoTal innovations will be deployed using an already existing platform, six candidate platforms were reviewed, using criteria of interest to the SocIoTal consortium. The platform that was selected to be used as the foundation for the development of the SocIoTal innovations is FI-WARE. However, in order to ease the development phase and to increase the efforts dedicated to implement the SocIoTal novelties, it has been agreed that existing and useful components could be also adopted and adapted from other existing platforms, such as BUTLER. Finally, in order to assess whether the relevant outcomes of this activity, and the initial architecture in particular, reach the main objective of this Task, a number of success indicators are introduced and discussed, clearly showing that the proposed architecture clearly satisfies the objective of a “socially-aware citizen centric architecture for an IoT eco-system providing services for cities, citizens and their communities”.



Page 48/70

References

[1] FP7 257521 IoT-A Project, “Internet of Things Architecture, http://www.iot-a.eu/ [2] IoT-A Deliverable D1.5, “Final Architectural Reference Model for the IoT”. [3] SocIoTal Deliverable D1.1, “SocIoTal scenarios and requirements definition report”. [4] IoT-A Deliverable D4.3, “Concepts and Solutions for Entity-based Discovery of IoT

Resources and Managing their Dynamic Associations”. [5] Bethencourt, J., Sahai, A., & Waters, B. (2007, May), Ciphertext-policy attribute-

based encryption. In Security and Privacy, 2007. SP'07. IEEE Symposium on (pp. 321-334).

[6] E. Rissanen, extensible access control markup language (xacml) version 3.0 oasis standard (2012).

[7] Dey, A. K., “Understanding and using context”, Journal of Personal and Ubiquitous Computing, Volume 5, Num. 1, p.p. 4-7, 2001

[8] S. De, T. Elsaleh, P. Barnaghi, S. Meissner, “An Internet of Things Platform for Real World and Digital Objects”, Journal of Scalable Computing: Practice and Experience, vol. 13, no.1, 2012

[9] M. Compton, P. Barnaghi, L. Bermudez, R. Garca Castro, O. Corcho, S. Cox, J. Graybeal, M. Hauswirth, C. Henson, A. Herzog, V. Huang, K. Janowicz, W. D. Kelsey, D. Le Phuoc, L. Lefort, M. Leggieri, H. Neuhaus, A. Nikolov, K. Page, A. Passant, A. Sheth, and K. Taylor. The SSN Ontology of the Semantic Sensor Networks Incubator Group. JWS, 2012

[10] S. Meyer et al. “Towards modeling real-world aware business processes”, In Proceedings of Web of Things, 2011.

[11] IoT-A Deliverable D1.2, “Initial Architectural Reference Model for IoT”. [12] SocIoTal Deliverable D2.1, “IoT Communities and Identity Management”. [13] SocIoTal Deliverable D1.3.1, “First version of API Specification”. [14] Passport, User Profile, http://passportjs.org/guide/profile/ [15] Passport, Overview, http://passportjs.org/guide/ [16] C. Perera, A. Zaslavsky, P. Christen, D. Georgakopoulos, “Context Aware Computing

for The Internet of Things: A Survey”, IEEE Communications Surveys & Tutorials, vol.16, no.1, pp.414-454, First Quarter 2014.

[17] M. Knappmeyer, S.L. Kiani, C. Fra, B. Moltchanov, N. Baker, “ContextML: A light-weight context representation and context management schema”, 2010 5th IEEE International Symposium on Wireless Pervasive Computing (ISWPC), pp.367-372, May 2010.

[18] FP7 287901 BUTLER Project, “uBiquitous, secUre inTernet-of-things with Location and contExt-awaReness”, http://www.iot-butler.eu/

[19] FP7 287305 OpenIoT Project, “Open Source cloud solution for the Internet of Things”, http://openiot.eu/

[20] The Webinos Foundation, http://webinos.org/ [21] DeviceHive, http://www.devicehive.com/ [22] FP7 257787 di.me Project, “Integrated digital.me Userware for the Intelligent,

Intuitive, and Trust-Enhancing Management of the User s Personal Information Sphere in Digital and Social Environments”, http://www.dime-project.eu/

[23] FI-WARE Architecture Overview. http://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/FI-WARE_Architecture

[Accessed 16 July 2014] [24] FI-WARE API Open Specifications. http://forge.fi-

ware.org/plugins/mediawiki/wiki/fiware/index.php/Summary_of_FI-WARE_API_Open_Specifications [Accessed 16 July 2014]

[25] FI-WARE GE Open Specifications. http://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/Summary_of_FI-WARE_Open_Specifications [Accessed 16 July 2014]

[26] FI-LAB Website. https://account.lab.fi-ware.org/ [Accessed 16 July 2014]



Page 49/70

[27] FI-WARE Catalogue. http://catalogue.fi-ware.org/ [Accessed 16 July 2014] [28] FI-WARE Security Architecture. https://forge.fi-

ware.org/plugins/mediawiki/wiki/fiware/index.php/Security_Architecture [Accessed 16 July 2014]

[29] FI-WARE Catalogue – Security Generic Enablers. http://catalogue.fi-ware.org/enablers?chapter_tid=6 [Accessed 16 July 2014]

[30] FI-WARE Data/Context Management Architecture. https://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/Data/Context_Management_Architecture [Accessed 16 July 2014]

[31] FI-WARE Catalogue - Data/Context Management Generic Enablers. http://catalogue.fi-ware.org/enablers?chapter_tid=3 [Accessed 16 July 2014]

[32] FI-WARE Architecture of Applications and Services Ecosystem and Delivery Framework. https://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/Architecture_of_Applications_and_Services_Ecosystem_and_Delivery_Framework [Accessed 16 July 2014]

[33] FI-WARE Developer Community and Tools Architecture. https://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/Developer_Community_and_Tools_Architecture [Accessed 16 July 2014]

[34] FI-WARE Catalogue – Applications/Services Ecosystems and Delivery Framework Generic Enablers. http://catalogue.fi-ware.org/enablers?chapter_tid=1 [Accessed 16 July 2014]

[35] FI-WARE Catalogue – Tools. http://catalogue.fi-ware.org/tools [Accessed 16 July 2014]

[36] FI-WARE Catalogue – Generic Enablers. http://catalogue.fi-ware.org/enablers [Accessed 16 July 2014]

[37] FI-WARE Website. http://www.fi-ware.org/ [Accessed 16 July 2014] [38] FI-WARE Hackatons. http://www.fi-ware.org/2014/06/27/mexico-first-latin-american-

country-to-deploy-fi-ware/ [Accessed 16 July 2014] [39] FI-LAB e-learning platform. http://edu.fi-ware.org/ [Accessed 16 July 2014] [40] Connect your own “Internet of Things” to FI-LAB. http://www.fi-

ware.org/2014/06/18/connect-your-own-internet-of-things-to-fi-lab/ [Accessed 16 July 2014]

[41] FI-WARE Internet of Things (IoT) Services Enablement Architecture. https://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/Internet_of_Things_(IoT)_Services_Enablement_Architecture [Accessed 16 July 2014]

[42] FI-WARE Catalogue – (Backend) Device Management. http://catalogue.fi-ware.org/enablers/backend-device-management [Accessed 16 July 2014]

[43] FI-WARE Catalogue – Data Handling General Enabler. http://catalogue.fi-ware.org/enablers/gateway-data-handling-ge-esper4fastdata [Accessed 16 July 2014]

[44] FI-WARE Catalogue – Protocol Adapter-MR CoAP. http://catalogue.fi-ware.org/enablers/protocol-adapter-mr-coap [Accessed 16 July 2014]

[45] FI-WARE Architecture Description IoT Backend IoT Broker. https://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/FIWARE.ArchitectureDescription.IoT.Backend.IoTBroker [Accessed 16 July 2014]

[46] FI-WARE Catalogue – NEC IoT Broker. http://catalogue.fi-ware.org/enablers/nec-iot-broker [Accessed 16 July 2014]

[47] FI-WARE Catalogue – (Backend) Device Management. http://catalogue.fi-ware.org/enablers/backend-device-management [Accessed 16 July 2014]

[48] FI-WARE Architecture Description Data Context Broker. https://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/FIWARE.ArchitectureDescription.Data.ContextBroker [Accessed 16 July 2014]

[49] FI-WARE Catalogue – Configuration Manager-Orion Context Broker. http://catalogue.fi-ware.org/enablers/configuration-manager-orion-context-broker [Accessed 16 July 2014]



Page 50/70

[50] FI-WARE Catalogue – Complex Event Processing (CEP)-IBM Proactive Technology Online. http://catalogue.fi-ware.org/enablers/complex-event-processing-cep-ibm-proactive-technology-online [Accessed 16 July 2014]

[51] FI-WARE Architecture Description Data BigData. https://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/FIWARE.ArchitectureDescription.Data.BigData [Accessed 16 July 2014]

[52] FI-WARE Catalogue – BigData Analysis-Cosmos. http://catalogue.fi-ware.org/enablers/bigdata-analysis-cosmos [Accessed 16 July 2014]

[53] FI-WARE Architecture Description Data Query Broker. https://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/FIWARE.ArchitectureDescription.Data.QueryBroker [Accessed 16 July 2014]

[54] FI-WARE Catalogue – Media-enhanced Query Broker. http://catalogue.fi-ware.org/enablers/media-enhanced-query-broker-querybroker [Accessed 16 July 2014]

[55] FI-WARE Architecture Description Cloud Object Storage. https://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/FIWARE.ArchitectureDescription.Cloud.ObjectStorage [Accessed 16 July 2014]

[56] FI-WARE Catalogue – Object Storage GE FI-WARE Implementation. http://catalogue.fi-ware.org/enablers/object-storage-ge-fi-ware-implementation [Accessed 16 July 2014]

[57] FI-WARE Catalogue – Repository SAP RI. http://catalogue.fi-ware.org/enablers/repository-sap-ri [Accessed 16 July 2014]

[58] FI-WARE Architecture Description Security Monitoring. https://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/FIWARE.ArchitectureDescription.Security.Security_Monitoring [Accessed 16 July 2014]

[59] FI-WARE Catalogue – Security Monitoring. http://catalogue.fi-ware.org/enablers/security-monitoring [Accessed 16 July 2014]

[60] FI-WARE Architecture Description Security Context-based security & compliance. https://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/FIWARE.ArchitectureDescription.Security.Context-based_security_%26_compliance [Accessed 16 July 2014]

[61] FI-WARE Catalogue – Content Based Security – CBS. http://catalogue.fi-ware.org/enablers/content-based-security-cbs [Accessed 16 July 2014]

[62] FI-WARE Catalogue – Privacy-Preserving Authentication. http://catalogue.fi-ware.org/enablers/privacy-preserving-authentication [Accessed 16 July 2014]

[63] J. L. Hernández-Ramos, A. J. Jara, L. Marín, and A. F. Skarmeta, “Dcapbac: Embedding authorization logic into smart things through ecc optimizations,” International Journal of Computer Mathematics, no. just-accepted, pp. 1–22, 2014.

[64] Specification of the Identity Mixer Cryptographic Library. Version 2.3.40 IBM Research, Zurich January 30, 2013. Available http://www.zurich.ibm.com/idemix/

[65] U-Prove Cryptographic Specification V1.1. Revision 3. Microsoft Corporation Authors: Christian Paquin, Greg Zaverucha, December 2013. Available at http://research.microsoft.com/en-us/projects/u-prove/

[66] The OpenSocial Foundation, http://opensocial.org/ [67] Node js, http://nodejs.org/



Page 51/70

Abbreviations and Acronyms AP Access Point API Application Programming Interface ARM Architecture Reference Model BS Base Station BT-LE Bluetooth-Low Energy CDVA Compressed Domain Video Analysis CEP Complex Event Processor CP-ABE Ciphertext-Policy Attribute-Base Encryption DCT Developer Community and Tools FG Functional Group FIApp Future Internet Applications GE General Enabler GEi General Enabler Implementation GNSS Global Navigation Satellite System GPS Global Positioning System I2DN Interface to Networks and Devices IdM Identity Management IoT Internet of Things IoT-A Internet of Things Architecture IP Internet Protocol IR-UWB Impulse-Radio Ultra-Wideband JSON JavaScript Object Notation KEM Key Exchange and Management NGSI OAuth

Next Generation Service Interface Open Authorization

OGC Open Geographical Consortium PDP Policy Decision Point PEP Policy Enforcement Point Proton Proactive Technology Online RD Resource Directory REST Representational state transfer RFID Radio-Frequency Identification RTLS Real Time Locating System RT-TOF Round Trip - Time of Flight SSN Semantic Sensor Network SWE Sensor Web Enablement UD User’s Directory UML Unified Modelling Language URI Uniform Resource Identifier URL Uniform Resource Locator VE Virtual Entity XACML XRDS

eXtensible Access Control Markup Language eXtensible Resource Descriptor Sequence



Page 52/70

Annex I Security Information Views IoT Service Request This information flow shows how the security components interact when a user or application is requesting an IoT Service



Page 53/70

VE Service Request This information flow shows how the security components interact when a user or application is requesting a Virtual Entity Service



Page 54/70

IoT Service Push Data This information flow shows how the security components interact when device pushes data towards an IoT Service



Page 55/70

Group Sharing This information flow shows how the security components interact when a user or application wants to share data within a group



Page 56/70

Context Manager access to a VE Service This information flow shows how the security components interact when the context manager wants to access to a Virtual Entity Service to retrieve contextual data



Page 57/70

Use case Information views



Page 58/70



Page 59/70



Page 60/70



Page 61/70



Page 62/70



Page 63/70



Page 64/70



Page 65/70



Page 66/70



Page 67/70



Page 68/70



Page 69/70

.



Page 70/70

Documents

SOCIOTAL D1.2.1 FINALsociotal.eu/sites/default/files/docs/deliverables/SOCIOTAL_D1.2.1... · Section 1 - Introduction to IoT-A methodology ... review, FI-WARE was considered as the