We use proprietary and third party's cookies to improve your experience and our services, identifying your Internet Browsing preferences on our website; develop analytic activities and display advertising based on your preferences. If you keep browsing, you accept its use. You can get more information on our Cookie Policy
Cookies Policy
FIWARE.OpenSpecification.Security.TrustworthyFactory - FIWARE Forge Wiki


From FIWARE Forge Wiki

Jump to: navigation, search
Name FIWARE.OpenSpecification.Security.


Chapter Security,
Catalogue-Link to Implementation TrustworthyFactory
Owner Thales, Sebastien Keller



Within this document you find a self-contained open specification of a FIWARE generic enabler, please consult as well the FIWARE Product Vision, the website on http://www.fiware.org and similar pages in order to understand the complete context of the FIWARE platform.


Copyright © 2014-2016 by Thales and by OPTET[1] Consortium for the assets developed in OPTET project.

Legal Notice

Please check the following Legal Notice to understand the rights to use these specifications.


Internet users find out an increasing amount of stories of malware, spyware, hackers and security holes every day. Actually, the vast majority of vulnerabilities today are application vulnerabilities, meaning vulnerabilities in the application code. As a result, an increasing number of security-aware users do not know anymore which software to trust, i.e. which software is trustworthy. Therefore, a way to increase this trust and confidence in Internet-based systems, applications and services is to harden the software implementation and prove to potential users that it has been done following the best practices known in the field.

Before we go into further details, in addition to the key definitions given in the Architecture Overview, we provide them here in more extensive form, as well as extra definitions[2] to improve the understanding of the Trustworthy Factory GE’s concepts:

  • Stakeholder: A stakeholder in an application (or any kind of software product) is any entity acting under its own volition that is involved in developing, verifying, operating or using any part of the application (or software product). This includes system designers, developers, providers, operators and end users.
  • Trust in an application (software): A property of a stakeholder, expressed in terms of probabilities and reflecting the strength of their belief that engaging in the system for some purpose will produce an acceptable outcome. Thus, trust characterizes a state where the outcome is still unknown, based on each stakeholder’s subjective perceptions and requirements. Typically, users who don’t trust the system are disinclined to use it.
  • Trustworthiness: An objective property of the application (software), based on the existence (or nonexistence) of appropriate countermeasures that reduce the likelihood of unacceptable outcomes. The stakeholder (e.g. application developer or customer) shall decide to which extent the application should be trustworthy. In other words, the stakeholder gives trustworthiness objectives (see below).
  • Trustworthiness attribute: An attribute derived from software quality attributes (ISO 25010) for the context of trustworthiness that can be quantified by measurement methods applied to the application. Examples of such attribute: safety, reusability, reliability, scalability, confidentiality, etc.
  • Trustworthiness objective: The definition of a (minimum) score to achieve for a specific trustworthiness attribute.
  • Trustworthiness profile: A list of trustworthiness objectives, provided by any stakeholder to the application developer.

Although trust is more subjective, trustworthiness of a system can be measured depending on quantified indicators (metrics). That is why this GE was developed. The Trustworthy Factory GE provides an environment to develop trustworthy applications and to help their certification based on the evaluation of software quality attributes (coming from ISO 25010).

The starting point for this GE is a list of trustworthiness objectives (trustworthiness profile). Based on this, the Trustworthy Factory GE helps the developers to develop his/her application with this goal and to prepare the certification phase.

Although various certification standards already exist that may apply to applications (software), they are either limited to a very specific category of quality attributes. (For example, Common Criteria is a certification framework dedicated to security attributes.) Or they do not take into account the way to build applications; or they are too heavy and time-consuming to be considered seriously by certain companies, especially SMEs. By providing an automatic evaluation of trustworthiness attributes, a complete description of the application environment and the trustworthiness objective, this GE anticipates the information requested by a certification process. An evaluator or certifier would be able to certify the application based on this information. The main features of this GE were developed in the context of FP7 OPTET[1] project. OPTET stands for Operational Trustworthiness Enabling technologies and was set-up as a project embracing FI-PPP and FIWARE Security vision as well as GE definition while focusing on Trust and Trustworthiness aspects.

OPTET has delivered different tools to add and to quantify the trustworthiness in an application. These tools were designed to be integrated in a more global lifecycle (from design to maintenance). The different assets used to build them are re-used and integrated in order to provide more generic tools for FIWARE platform.

One prominent aspect of this GE, as compared to others, relies in the way that application developers will use and benefit from the GE, compared to other GEs. Indeed, most FIWARE GEs provide common functions which can be integrated within new applications and actually used at runtime, i.e. when the application runs. The Trustworthy Factory GE makes a difference by not providing this kind of common function but instead a common function for developing new trustworthy Java applications and therefore used primarily during the development phase. More importantly, this common function is reusable and can be used in a multiplicity of Usage Areas across various sectors. In that perspective, it qualifies as well for a Generic Enabler according to the definition from the Overall FIWARE Vision.

The Trustworthy Factory GE consists of two main features:

Static and Dynamic Application Trustworthiness Assessment: This (coarse-grained) feature helps the developer to write a better Java source code taking into account some design aspects and following various best practices. Miscellaneous tools are integrated together in a development environment and can be used separately or orchestrated to provide intermediate trustworthiness evaluations to the developers. This feature offers a way to consult the trustworthiness objective given as an input by the software provider and to compare it with a current evaluation.

Semi-automated Workflow for Application Trustworthiness Certification: This (coarse-grained) feature is used by the evaluator to prepare the certification phase. For that, this feature takes as an input the application source code and different information provided by the software provider (context of the application, trustworthiness objective). Different tools are used for that and integrated in a dedicated workflow. These tools help the evaluator understand the context of the application, re-define or add new trustworthiness objectives and to evaluate the trustworthiness attributes of an application regarding these objectives. At the end, he/she will be able to quantify the trustworthiness level of an application. The results of this work are stored into an XML file (signed by the evaluator) named “Digital Trustworthiness Certificate (DTwC)”. This file will be used by the certifier to certify the application.

On the figure below the two main features of the Trustworthy factory are displayed: The Development Environment and the Certification Tool.

Business Requirement
Context of the Trustworthy factory

Target Usage: This trustworthy factory GE takes as input different elements to help the developer to write his/her source code:

  • The usual elements like functional specifications, software design, test plan…
  • The specific elements required by the Factory to help the developer to increase the trustworthiness of his/her application:
    1. The trustworthiness profile (list of trustworthiness objectives to achieve).
    2. The constraints or other non-functional requirements impacting the trustworthiness.

At the end, the GE delivers the application with its source code and the associated Digital Trustworthiness Certificate.

Basic Concepts

Example Scenario

The main goal of this factory is to write trustworthy source code for a new application. For that, different trustworthiness objectives are given to the developer at the beginning of the development stage. At any time, he/she should check whether he/she reaches the objectives. When he/she has finished, he/she is able to deliver his/her source code to an evaluator. The evaluator checks the source code and certifies the application if it is compliant with the trustworthiness objectives. This scenario is described below.

Sample Scenario
target usage of the Trustworthy factory

  1. The developer receives different objectives from stakeholders of the application he/she has to develop. These objectives are chosen in order to have a trustworthy application. The table below shows what a list of trustworthiness objectives would look like, with the values to reach for a given application:
    Sample Scenario
    TWAttribute expected values
  2. The developer writes his/her source code and performs the different trustworthiness activities: he/she writes different elements increasing the trustworthiness (e.g. unit tests) in the source code editor by following the relevant best programming practices.
  3. At any time, the developer can check if his/her source code reaches or not the different thresholds of the trustworthiness attributes he/she has to take into account. For that, he/she uses static analysis tools and runtime tools. Static analysis tools are based on existing tools (e.g. PMD, CodePro, Checkstyle) with modifications in order to provide their results in a trustworthiness point of view. For runtime tools, there are based on existing tools (e.g. JUnit) providing their results through their contribution in different Trustworthiness attributes.
  4. The Source code evaluator orchestrates the different tools evaluating the trustworthiness of the application by running the static analysis tools and the runtime tools. It consolidates the results of the different tools in a trustworthiness point of view. At this point, without the Trustworthy Factory, the developer would have to install all the various tools (PMD, CodePro, etc.) one by one, then call each one to analyze his/her code, collect all the results manually for each tool, categorize and map the types of results for each tool to the trustworthiness attributes, define metrics for each result value manually to compute the final trustworthiness attribute value for each attribute, and so on. Considering that we are using at least three different plugins with different APIs, different but sometimes overlapping types of results, this could be clearly unmanageable for most developers; all the more as the developer will have to redo this process very often, going back and forth between code editing/fixing and trustworthiness evaluation, until trustworthiness objectives are satisfied. Now, the Trustworthiness Factories simplifies much this process that allowing the developer to run all the aforementioned tools and get the relevant trustworthiness results (categorized and quantified) with one click of a button from the Eclipse project’s context menu.
  5. The Source code evaluator returns the results of the trustworthiness evaluation in a specific view of the Source code editor, helping the developer to check whether his/her source code is trustworthy. He/she can decide to continue the development and to modify different parts in order to increase the trustworthiness. If the trustworthiness level is reached, he/she delivers his /her source code to the evaluator. An example of anticipated results is given in the figure below. In this example, the red cells indicate where the trustworthiness attribute does not reach the targeted value.
    Sample Scenario
    TWAttribute result values
  6. The evaluator uses the Certification tool to evaluate the application delivered by the developer. The Certification tool will guide him/her through a workflow made of the following steps :
    • Description of the application and its context;
    • Description of the trustworthiness problem, i.e. list of threats to the trustworthiness of specific parts of the application;
    • Specifications of Trustworthiness Properties
    • Collection of trustworthiness evidence;
    • Generation of the Digital Trustworthiness certificate;
  7. The certification tool gets from the Source code evaluator the evidence that trustworthiness objectives have been achieved by the application. The evidence collection is performed automatically by the source code evaluator.
  8. The certification tool pushes back the collected evidence into the certification workflow so that the evaluator can review it.
  9. The evaluator reviews all the data already mentioned, namely the description of the application, the description of the trustworthiness problem, the trustworthiness properties, and finally the evidence of trustworthiness. All are used, at the end, to build the Digital Trustworthiness Certificate.

Main components

The Source code editor

The Source code editor is the IDE used by the developer to write his/her source code. In order to facilitate the adoption of this factory it is based on an existing IDE already adopted by developer’s community. For Java development the selected IDE is Eclipse. This component is not new and not specific but is the entry point for this GE. The figure below shows the well-known IDE Eclipse and confirms we have reused an editor already adopted by the Java developer community.

Java source code editor augmented with trustworthiness evaluation features (Eclipse-based)

The Trustworthy Factory provides a new type of Java project wizard so that your Java project gets ready for trustworthiness evaluation. As a result, you get new trustworthiness-focused views added to the conventional Java editor’s view and these views become visible when you run a trustworthiness evaluation. This type of project also adds specific metadata defined by a trustworthiness data model specific to the GE. The Java project with these metadata can be shared by the developer via a source code repository so that, in particular, an evaluator can retrieve the Java project ready for trustworthiness evaluation. The factory is actually designed so that the evaluator gets a different Eclipse perspective (not the same as the developer), in other words a different view, adapted to evaluation activities and certification.

The Source code evaluator

The Source code evaluator is a set of tools to evaluate the source code. For that, different components are used. For the Java factory, the components use a combination of existing plugins to evaluate the quality of implementation and check whether the specified design requirements are well implemented in the source code. In addition to these exiting plugins, extra plugins were added in order to combine, aggregate, merge and transform their results in a trustworthiness point of view.

The Certification workflow

As soon as the developer has delivered his application, the evaluator can start the evaluation in order to certify the application if it is compliant with the trustworthiness requirements specified as an input. For the evaluation, the evaluator fills in a file (the content for the final certificate) with different information like context, trustworthiness objectives, and trustworthiness evaluation results. This file is updated and enhanced through a specific workflow, the certification workflow, described below:

Certification workflow
Certification Workflow
  1. System description: The System (i.e. application in this context) description view interacts with the evaluator in order to define the description of the context where the application is deployed. This description consists to declare the different components of the system, and to identify which component is under evaluation.
  2. Trustworthiness Problem definition: This step consists to define the problems which could impact a component of the application. The list of components is coming from the previous description of the application. The list of problems is a predefined list (classified by type). The evaluator selects a component and checks the possible problems which could occur on this asset.
  3. Trustworthiness Property Specification: In addition to the Trustworthiness profile (list of objectives) initially given to the developer, the evaluator may associate extra Trustworthiness Attributes to specific components of the application, and define different metrics for each.
  4. Evidence collection: This step allows the evaluator to collect the evidence in order to compute the different metrics and the value for each trustworthiness attribute. The collection can be done automatically by using different tools (static and runtime analysis) or can be collected manually in the case of some evidence are provided manually (for example, test results).
  5. DTwC (Digital Trustworthiness Certificate) creation and editing: This step is used in order to validate the generation of the certificate. During this phase, all the required data is checked and validated in order to generate a complete certificate. This view displays the path where the certificate is and the component must be generated (physical path or marketplace URL).

Main interactions

The users of this GE are any organization being able to develop Java applications and interested to quantify the trustworthiness of their developed applications. These organizations can be departments belonging to a large company, a SME (Small or Medium Enterprise) or a non-profit organization. With this GE, they will provide Java applications to their customers with quantified values for a large number of software quality attributes. These values and the complete description of the application displayed in the Digital Trustworthiness Certificate will help various existing certification process by providing tangible information. This Digital trustworthiness Certificate could be the base of their own labels (e.g. Quality label, Security label, Trustworthiness label).

So the direct users of this factory are the developers and the evaluators working in these organizations. The external actors will be the applicant and the place hosting the application:

  • Applicant: The organization (or people) in charge for providing specification, trustworthiness objective to the people in charge of development.
  • The place hosting the applications: This place could be a Marketplace exposing the Digital trustworthiness Certificates of applications. This feature would allow an end-user to select the better application by comparing their Certificate.

Basic Design Principles

The design and the implementation of the trustworthy Factory were guided following two main principles:

  1. Reuse of an existing popular IDE to maximize adoption by the developer’s community.
  2. Benefit from the existing static and dynamic analysis tools already developed over the last ten years.

Based on these principles, the existing tools were adapted and integrated together in order to provide a unified view of application trustworthiness. These tools are:

  • Development environment: based on Eclipse Luna.
  • Static analysis tools: based on Eclipse plugins PMD, CheckStyle and CodePro.
  • Runtime tools: based on JUnit.

Several additional Eclipse plugins were developed specifically for this Trustworthy Factory in order to:

  • Orchestrate the execution of the various analysis tools mentioned above, process the results of each tool, merge them, classify them according to the various trustworthiness attributes we have defined, compute the aggregated scores according to the metrics we have defined; and finally show the scores per attribute in one single consolidated and consistent view. This assumes a significant preliminary work of modeling where each possible type of rule checked by each of these tools has been mapped to one or more metrics that contributes to the final score for one or more specific trustworthiness attributes, where applicable.
  • Implement a certificate tool that provides a workflow in the form of Eclipse wizard to guide the evaluator and automate to some extent the review of the trustworthiness evaluation results, and at the end, issue a signed certificate using the evaluator’s private key and signing certificate.
  • Manage various user profiles, such as developer and evaluator, to offer different Eclipse perspectives/views giving access to different tools.


  1. 1.0 1.1 FP7 OPTET Project - http://optet.eu/
  2. Source: http://www.optet.eu/wp-content/uploads/2014/01/OPTET_WP3_D3.1_Initial-Concepts-and-Abstractions-to-Model-Trustworthiness_V1.2.pdf

Detailed Specifications

The Trustworthy Java factory is an Integrated Development Environment based on eclipse. This IDE proposes a complet HMI to develop Java application (This HMI doesn't provides API).

Documentation here: https://github.com/TrustworthyFactory/factory

Re-utilised Technologies/Specifications

Most of this GE's API operations regarding Events/Context retrieval and notification are inspired on the OMA (Open Mobile Alliance) NGSI Context Management specifications.

However, the FIWARE team has identified potential updates to the standard to guarantee its correct exploitation in this context, solve some ambiguities and extend its capabilities according to the FIWARE vision. Therefore, we will speak onwards about the FIWARE NGSI specification. FIWARE NGSI specifications differ from the OMA NGSI specifications mainly in the binding, as far as OMA doesn’t have any binding by definition. However FIWARE NGSI improves some of the OMA NGSI aspects, which could be improved in the OMA as well, and finally, thus not all the mandatory/optional definitions may be respected in the FIWARE binding. Therefore the FIWARE NGSI is mainly the technological binding for the OMA specifications with very little omits and differences.

Terms and definitions

This section comprises a summary of terms and definitions introduced during the previous sections. It intends to establish a vocabulary that will be help to carry out discussions internally and with third parties (e.g., Use Case projects in the EU FP7 Future Internet PPP). For a summary of terms and definitions managed at overall FIWARE level, please refer to FIWARE Global Terms and Definitions

  • Software quality attributes inherent properties of the software that contribute to quality (ISO 25010); examples of attributes used in FIWARE: safety, reusability, reliability, scalability, confidentiality, etc.
  • Trust: trust in a given system (application software in the context of FIWARE Security chapter) is a property of an entity (e.g. a user of the system or a developer) reflecting the strength of their belief that engaging in the system for some purpose will produce an acceptable outcome.
  • Trustworthiness: objective evaluation of the relevant set of software quality attributes (trustworthiness attributes), based on the evidence from the ‘black box’ and/or ‘white box’ analysis of the system.
  • Trustworthiness objectives: set of trustworthiness attributes with a defined minimum score (threshold) to achieve for each of them.
  • Trustworthiness certification: process by which a certification authority issues a certificate of the level of trustworthiness of a given software product/application, i.e. the trustworthiness objectives have been met, based on evidence collected from evaluation of the trustworthiness attributes of this application.
  • Trustworthiness Attributes: Software attributes (As described in the ISO 25010) dedicated for the trustworty of an application (defined by the Optet project)
  • Trustworthiness Metrics: Metrics which characterize the TWAttributes. TWMetrics are compute using evidences found into the java development
  • Trustworthiness Profile: Determining trustworthiness requirements by specifying expected target values for Trustworthiness metrics
Personal tools
Create a book