The Future Internet is posing new security challenges as their scenarios are bringing together a huge amount of stakeholders and devices that must interact under unforeseeable conditions. In addition, in these scenarios we cannot expect entities to know each other beforehand, and therefore, they must be involved in risky and uncertain collaborations. In order to minimize threats and security breaches, it is required that a well-informed decision-making process is in place, and it is here where trust and reputation can play a crucial role. Unfortunately, services and applications developers are often unarmed to address trust and reputation requirements in these scenarios. To overcome this limitation, we propose a trust and reputation framework that allows developers to create trust- and reputation-aware applications.
Future Internet (FI) scenarios bring together multiple entities, namely stakeholders and devices, that need to collaborate in order to reach their goals. Should these entities knew each other beforehand, upfront mechanisms could be in place at design-time in order to ensure that these collaborations have a successful ending for all parties. However, this cannot be assumed. Therefore, it is required to guarantee a successful ending even under risky and uncertain conditions, which generally involves making good decisions. These conditions present a breeding ground for trust.
Even when the concept of trust is not standardized, it is agreed that it can be a valuable tool to leverage decision-making processes. The concept and implications of trust are embodied in trust models, which de ne the rules to process trust in an automatic or semi-automatic way within a computational setting. For the last twenty years, many models have been proposed, each one targeting di erent contexts and purposes, and with their own particularities.
One issue with trust models is that they are usually built on top of an existing application in an ad-hoc manner in order to match the speci c needs of the application and its environment, limiting the models' re-usability. Furthermore, most models do not distinguish explicitly between trust and reputation, nor do they provide guidelines to combine these notions to yield more solid results.
We believe that this approach is not adequate and that developers should be provided with some mechanisms to systematically incorporate trust and reputation models into their services and applications.
The rest of the paper is organized as follows. Section 2 describes the goals that we are pursuing. In Section 3 we explain the research methodology that is being followed and discuss the work that has been carried out up to now. Finally, the conclusions and some lines for future research are presented in Section 4. 2
Our main goal is the speci cation, design and implementation of a development framework that allows developers to implement trust- and reputation-aware applications. The framework must expose an Application Programming Interface (API) in order to make its functionalities accessible, and it must also provide hot spots where trust models can be customized to t the application needs.
An important sub-goal that is derived from the main expected contributions is the provision of insight into trust and reputation. It is often the case that these concepts are considered as being synonyms or are used interchangeably, however they are quite di erent notions that need to be considered separately. Building a development framework requires performing a domain analysis in the framework targeted area, in this case, trust and reputation. Not only can this domain analysis shed light on concepts such as trust or reputation, but also on the trust models internal workings.
The main expected contribution of this research to the eld of Engineering Secure Software and Systems is two-fold: on the one hand, by providing developers with a tool like a trust and reputation framework, we foster thinking over trust and reputation requirements from the very beginning. On the other hand, as applications are developed by using the framework, trust and reputation models are naturally incorporated within the application itself, and not as patches added after-the-fact, as it is the standard nowadays. Thus, trust models can use all the information available to the application in a more e cient way. 3
This section summarizes the research methodology that is being followed. It is divided into six phases, each one further elaborated in its own section. For each phase, we state whether it is completed or further work needs to be done, and we also outline their main ndings and results. 3.1
Surveys, such as the one by J sang, Ismail and Boyd [
Some drawn conclusions are that most works do not provide enough margin of customization and lack of a framework-oriented approach. In addition, no existing contributions di erentiate between the notions of trust and reputation, as they tend to focus on just one of them, usually reputation.
Even though this task was already nished, it is required to continuously check out new interesting papers. 3.2
A domain analysis is of paramount importance when building a development
framework [
The main contribution is a conceptual framework that gathers and relates
the most important concepts in trust and reputation models. This framework is
represented in the form of UML diagrams, like the one depicted in Figure 1. As
explained in an earlier contribution [
Trustee's Objective Properties Trustee's Subjective Properties Trustor's Objective Properties Trustor's Subjective Properties Context 1.*
Role Witness
Trustor
Trustee Provider
Trusted Third
Party Policy Model Negotiation
Model Behaviour Model Reputation
Model Propagation
Model Provision
Access
Identiy
Infrastructure plays Trust Class 1.* instantiates
Purpose Factors
Trust influence
Modeling
Method Mathematic
Graphic
Linguistic
Entities 2.* 2
Requester computes has has relates Trust
Trust Model establishes 1.* Relationship
has TrusMtDoedceilsion uses
1.* Assumptions
Trust Evaluation
Model
Fig. 1: Common Concepts for Trust Models
Also, in our earlier work [
Even though this phase is also completed, the analysis should be re ned as new relevant papers arise. 3.3
The previous phase conducted an exhaustive analysis on trust and reputation.
This analysis assisted in determining the requirements that a trust and
reputation framework must ful l. Since accommodating all possible trust models in
a single framework may be a daunting task, we decided to focus on evaluation
models. A list of requirements can be found in an earlier work [
Even though this phase is nalized, some new requirements may arise as a consequence of new relevant literature or due to the architecture and design phases. One of our ndings is that evaluation models are centred around the notion of trust metric. Trust metric uses a computation engine to yield a trust or reputation value given a set of variables. The di erence between many evaluation models stems from (i) the variables used in the computation and (ii) the computation engine used to aggregate these variables into a simple value or a tuple of values. Therefore, one of the most important requirements for a trust and reputation framework is to allow developers to de ne their own metrics. Time and uncertainty are two important factors as well, and developers should be allowed to include them. The former may be used to consider freshness in trust values, whereas the latter refers to how reliable a trust value is. 3.4
This phase consists of sketching the high-level software structure that supports
the requirements elicited in the previous phase. A half-way technical and
conceptual architecture was discussed in earlier works [
At the architectural level, building a trust and reputation framework requires planning in two fronts. On the one hand, we need to carefully design an easy yet exible API that allows connecting any application to a trust server. On the other hand, the framework must provide enough hot spots to support the customization of the trust server behaviour at runtime in order to accommodate new trust and reputation models.
The type of application that we want to build by using the framework determines the design of the aforementioned factors: API and hot spots. In this 1We cannot provide the reference as the work is currently under review. sense, we think of two types of applications that follow two di erent architectural styles: client-server applications and peer-to-peer applications.
The rst one requires the developer to de ne the interactions between an application server and a trust server, and the trust server holds information about the whole system. In the second approach, each peer holds an instance of the trust server, which holds only partial information about the whole system.
The architecture proposed in our recent work1 was originally designed to support the client-server approach, even though we think it can be tailored in order to support the peer-to-peer architectural style. 3.5
This phase elaborates on the architecture in order to re ne the components into sub-components and modules. Inner data structures are also detailed and the database schemas and tables are fully speci ed. This re nement goes on until the implementation of each module is made easy. This phase remains un nished. 3.6
The last phase consists of validating the framework implementation by
developing a trust-aware application in the scope of e-Health and/or SmartGrid, which
have been identi ed as the two main NESSoS2 scenarios [
It is likely that we observe certain de ciencies and limitations of the framework in a real application. Actually, any framework requires iterations in order to be able to accommodate a wide range of applications. Therefore, the output of this phase could help to improve the architecture and design of the framework. 4
New Future Internet applications will need support from trust and reputation services for their successful adoption. Yet these services have been laid aside and are very often considered once an application is already deployed and running. At that moment, adding trust and reputation features may be hard, and may lead to poor and, above all, barely reusable solutions.
We propose a trust framework that assists developers in the task of creating services and applications that need trust and reputation models. Examples of such applications are those proposed in the NESSoS project, and validation is to be done in their scope.
As future work, we are planning to research on how recon guration mechanisms can leverage trust models during the service or application lifetime. The trend in Software Engineering is towards adapting the software at runtime to new requirements or new environmental conditions, changing the architecture itself without the need for re-implementation. We would like to obtain insight into how the trust framework could exploit advances in this direction in order to support self-adapting trust models.