Mark Vinkovits
email: mark.vinkovits@fit.fraunhofer.de

René Reiners
email: rene.reiners@fit.fraunhofer.de

Andreas Zimmermann
email: andreas.zimmermann@fit.fraunhofer.de

TrustMUSE: A Model-Driven Approach for Trust Management

Keywords: Trust Management, Model-Driven Architecture, User-Centered Design, Meta Model, Usable Security 1

With the increasing acceptance of Trust Management as a building block of distributed applications, the issue of providing its benefits to real world applications becomes more and more relevant. There are multiple Trust Management frameworks ready to be applied; however, they are either unknown to developers or cannot sufficiently be adapted to applications' use cases. In our research, we have defined a meta model to modularize Trust Management, where each element in the model has clearly defined dependencies and responsibilities -also enforced by a complete API. Based on this model, we were able to develop a process supported by a number of tools that enables non-security expert users to find an applicable Trust Management solution for their specific problem case. Our solution -collectively called the TrustMUSE system -has evolved over an iterative user-centered development process: starting with multiple focus group workshops to identify requirements, and having multiple prototypes to conduct usage observations. Our user evaluation has shown that our system is understandable for system designers, and is able to support them in their work.

Introduction

During recent years, Trust Management has gained increasing attention and is becoming more and more accepted as an essential building block of distributed systems, especially for the Internet of Things [START_REF]IoT-A FP7 Project: Final Architectural Reference Model for the IoT[END_REF]. There is a vast number of research results in the field, and a variety of use cases is covered by these. However, these solutions rarely find their way into real-world applications. One possible explanation for this, as already identified by others, is the general lack of security expertise present during the development of applications [START_REF]Cisco 2014 Annual Security Report[END_REF]. As a result, even though Trust Management frameworks provide sound procedures for common threats, they are not integrated into systems, because developers simply are not aware of them. To avoid this problem, two basic steps are necessary: first, we need to ensure that designers of these applications have a general understanding of Trust Management and of available solutions; secondly, developers need support with regard to developing or integrating Trust Management frameworks. These are the points we address with our research by developing a model-driven process that helps selecting and integrating applicable Trust Management solutions into specific application use-cases.

We organized our research according a user-centered design methodology [START_REF] Gould | Designing for usability: key principles and what designers think[END_REF]: first, we identified our users to be non-security expert developers. Focusing on this user group, we arranged a number of requirement sessions with focus groups using different scenarios as presented in [START_REF] Vinkovits | Towards requirements for trust management[END_REF][START_REF] Vinkovits | Defining a Trust Framework Design Process[END_REF]; this way we gained a broad view on the challenges developers had. During the development of our approach, we concentrated on regularly evaluating also intermediate results to ensure that we did not lose focus of our target end users. Within this user-centered design process, this paper presents the state at the end of the first large iteration, where all intermediate results of the individual components have already been evaluated once, and the first evaluation of the whole integrated system took part.

From the first requirements workshops, that were the first step of our user-centered process, we found that there already was a general understanding of Trust Management [START_REF] Vinkovits | Towards requirements for trust management[END_REF] and that a structured, hierarchical view was requested to gain an overview of available solutions. Therefore, we chose to develop model-driven approach for working with Trust Management, called the TrustMUSE system (Trust Management Usable Software suitE). By applying grounded theory, we first composed a meta model of Trust Management as underlying structure of our system (The definition process, a first version and a validation of the elements of the model have already been presented in [START_REF] Vinkovits | TrustFraMM: Meta Description for Trust Frameworks[END_REF]). This meta model identified common aspects of different Trust Management frameworks; thereby, it enabled a more structured and focused view on the benefits and characteristics of distinct realizations. To be able to use the conceptual elements of the meta model in a more specified model-driven approach, we improved the concept into the TrustMUSE Model by defining the APIs of each element; these APIs not just abstract the functionality of the individual elements, but also concentrate on integration and implementation issues.

Looking at the TrustMUSE Model as the shaping structure of our approach, as next step towards our complete TrustMUSE system, we defined the TrustMUSE Process as an easily understandable process for interacting with the model. The TrustMUSE Process, as specified in [START_REF] Vinkovits | Defining a Trust Framework Design Process[END_REF], provides the means to systematically browse Trust Management state of the art. It enables developers to think in terms of their application, and in return be provided with a Trust Management framework. The software part of our system is the TrustMUSE Builder, which guides our target users through the TrustMUSE system and automates its processes.

With having a first integrated prototype of the whole TrustMUSE system available, we executed a first evaluation where target end users not just provided feedback about the intermediate concepts, but were asked to solve a specific application design task with our integrated approach. All of our test users were able to find an appropriate Trust Management framework based on TrustMUSE, and also understood what had been suggested to them. Even if this was only a first evaluation, its results were significant as they provided a first valid indication of whether TrustMUSE was able to solve the previously mentioned challenges.

The remaining paper is structured as follows: section 2 contains state of the art in the areas of modelling and usable security; section 3 describes the TrustMUSE Model and presents its APIs; section 4 deals with the TrustMUSE Process and TrustMUSE Builder implementation, which is then evaluated in section 5. Section 6 concludes the paper and outlines future work.

State of the Art

There is a large number of Trust Management frameworks available -all designed for different specific domains [START_REF] Marti | Limited reputation sharing in P2P systems[END_REF][START_REF] Zouridaki | Byzantine robust trust establishment for mobile ad hoc networks[END_REF][START_REF] Blaze | Decentralized trust management[END_REF]. Similarly, there exist multiple surveys collecting and categorizing Trust and Reputation Management frameworks and identifying common aspects [START_REF] Josang | A survey of trust and reputation systems for online service provision[END_REF][START_REF] Artz | A survey of trust in computer science and the Semantic Web[END_REF]. As evident from these examples, Trust Management has thoroughly been researched, and there are many approaches ready to be used for finding trustworthy service providers in distributed environments. A consequence of this vivid research is the recent attempt to standardize Trust Management, and achieve interoperability between individual frameworks. There are multiple aspects where such standardization has started: common taxonomy [START_REF] Viljanen | Towards an ontology of trust. Trust, Privacy, and Security in Digital Business[END_REF], generic models [START_REF] Kinateder | Towards a Generic Trust Model -Comparison of Various Trust Update Algorithms[END_REF], meta models [START_REF] Vinkovits | TrustFraMM: Meta Description for Trust Frameworks[END_REF][START_REF] Saadi | Composing Trust Models towards Interoperable Trust Management[END_REF] and identification of common procedures [START_REF] Gómez Mármol | Towards pre-standardization of trust and reputation models for distributed and heterogeneous systems[END_REF]. However, these standardization approaches are still at their start and are barely applied -also because of their lack of formal application method. Even if standardization of Trust Management were at its full extent, developers of distributed applications, who are less acquainted with security, would still have a hard time in knowing which solutions are the most appropriate for their challenges. On the one hand, this is due to the well-known problem of users having difficulties understanding security concepts [START_REF] Whitten | Why Johnny Can ' t Encrypt: A Usability Evaluation of PGP 5 .0[END_REF]; on the other hand, this is caused by the lack of welldefined processes for finding a Trust Management solution applicable to a problem [START_REF] Vinkovits | Defining a Trust Framework Design Process[END_REF]. In order to solve the first problem, the field of user-centered security had risen [START_REF] Zurko | User-centered security[END_REF]. It identifies the need to approach users, and support them in securely using software. This is generally achieved by applying an iterative user-centered design methodology [START_REF] Gould | Designing for usability: key principles and what designers think[END_REF], as we also did for our own approach. For achieving the desired understanding of security at the developers, Model-Driven Security (MDS) is one potential solution [START_REF] Basin | Model driven security: From UML models to access control infrastructures[END_REF]. MDS aims at creating clear and understandable models of applied security procedures: this helps to clearly separate aspects of the software, improving overview and understanding of functionality. Additionally, during development, MDS enables code to be better structured and stay in accordance with specification and documentation.

Individual smaller steps of our approach had been presented previously: we presented the requirements from the initial workshops in [START_REF] Vinkovits | Towards requirements for trust management[END_REF]; in [START_REF] Vinkovits | TrustFraMM: Meta Description for Trust Frameworks[END_REF], we presented the conceptual meta model which is further improved into the TrustMUSE Model in this paper; the TrustMUSE Process that enables non-security experts to find an appropriate Trust Management solution for an application has been shown in [START_REF] Vinkovits | Defining a Trust Framework Design Process[END_REF].

TrustMUSE Model

The TrustMUSE Model is a meta model with accompanying APIs for Trust Management frameworks. It is based on the original TrustFraMM concept that has been published in [START_REF] Vinkovits | TrustFraMM: Meta Description for Trust Frameworks[END_REF]. Over the past years, we have continued to work with this model: we implemented specific Trust Management frameworks based on the model's elements, we have defined generic interfaces over which services can be consumed and interchanged, and we defined design patterns for the integration of the system into arbitrary applications. The experience gained through this process has matured the TrustMUSE Model into the version we present in this chapter. First, we provide an overview of the meta model -a detailed description of the elements can be found in [START_REF] Vinkovits | TrustFraMM: Meta Description for Trust Frameworks[END_REF] -and the accompanying APIs as seen in Fig. 1; after that, we briefly describe two systems we implemented in accordance with the model.

Description of the Model

There is no proper way to describe Trust Management functionality in a sequential way; therefore our sequential presentation of the TrustMUSE Model should not be considered as a restriction on the operation of describable frameworks. We start our description from Trust Evidence: the raw pieces of data -like observations, recommendations and certificates -that guide the system in deciding whom to trust. Trust Evidences have assigned Trust Scopes -used similarly at other places of the systemto distinguish received data according to aspects or contexts of entities' behavior.

Trust Discovery and Distribution defines where, how to search for and eventually also share evidences, and it places them into the Evidence Storage: a typed database providing querying functionality to the rest of the system. Trust Evaluation takes this data, filtered by entities, and passes it to the associated Trust Model. This model describes the rules and procedures that turn raw data into assessed Trust Values. The output from this step is placed into the Trust Storage, which is the counterpart of the Evidence Storage, just for interpreted information. This information is then used by Trust Enforcement -the act of trusting: deciding if for a given service an entity is to be trusted, selecting a fitting provider for an action, or simply notifying the application about changes in someone's trust. Compared to using pure assessed Trust Values, this act includes considering contexts, risks, alternatives and priorities. After an interaction with another entity, it is possible to provide feedback into the system by the means of Interaction Evaluation. It places any feedback into the Evidence Storage and additionally, depending on its implementation, initiates Trust Update: the procedures that keep the status of the system fresh. The APIs of the elements introduced so far represented the services of the underlying functionality; for this reason we did not discuss them in detail. However, the next element requires more introduction as its behavior is more bound to a specific design pattern: Trust Representation is the element holding information related to the formats applied in any of the TrustMUSE Model's elements. We did not indicate this in the class diagram, but almost every component may be dependent on it. It is needed to enable the integration of different procedures with their accompanying formats -as is intended by TrustMUSE. To implement this, Trust Representation is a repository for factory objects 1 where every element can register a class that is able to parse its respective formats; these factories are then used by other elements when required. The API of Trust Representation reflects this role as it provides methods to find specific factories based on input data, constructor parameters or names.

We implemented the here presented API in Java in form of OSGi 2 Declarative Services; this enforced us to clearly follow the defined dependencies. In the next section, we will see how we used our implementation to integrate Trust Management functionality into two specific applications.

Developing Software with the Model

In order to validate the APIs of the TrustMUSE Model, we continued elaborating it to see how it can be integrated into applications. We searched for two applications with distinct trust requirements: by this, we aimed to stress that different Trust Management implementations can be modeled and consumed over the same APIs. In this section, we first present the two applications we have selected for this purpose and show what kind of Trust Management functionality we implemented for them; after this, we provide an additional API that is necessary to integrate implementations done in accordance with TrustMUSE into applications.

Reputation Module for Expert Network. This application was an existing product that dealt with connecting human or software experts, providing specific services online, with consumers searching for those services -e.g. a lawyer providing online consultation in multiple fields for possible clients. The owner of this application wished to indicate a reputation score per expert to enable further differentiation of them.

The scenario where the application had been deployed possessed some interesting requirements that needed to be considered while selecting an appropriate Trust Management implementation: reputation scores had to be stored directly at the entity they were about, thus determining how Trust Discovery and Distribution had had to be implemented. The Trust Model simply took the average of positive and negative ratings; it was executed every time a new rating came in -as defined in Trust Update. Reputation scores, as well as the feedback provided about received services, were presented as a five-star scale -a question of Trust Representation. There was no Trust Enforcement component, and Interaction Evaluation was done by enquiring the user.

Trust Module for Mesh Network. The application had the purpose of monitoring and debugging a mesh network consisting of nodes with different capabilities; it was not intended to actually intervene with the routing. Typically for such applications, our solution was to run on each device, sharing observations across the network. Our Trust Management solution was based on the framework described by [START_REF] Buchegger | A Robust Reputation System for P2P and Mobile Ad-hoc Networks[END_REF]; the TrustMUSE division of it was as presented in [START_REF] Vinkovits | TrustFraMM: Meta Description for Trust Frameworks[END_REF]: Trust Discovery and Distribution was implemented to exchange own observations, Trust Update initiated this regularly, the Trust Model dealt with calculating the parameters of the Beta function, Trust Enforcement compared each Trust Value to a specified threshold.

Integrating TrustMUSE based solutions into applications.

As identified during the requirements process [START_REF] Vinkovits | Towards requirements for trust management[END_REF], developers would like to mainly build on a basic set of services in their applications -only when required, did they want to customize Trust Management functionality. Therefore we created the TrustMUSE integration layer as seen in Fig. 2: a set of interfaces and utility classes that wrap the Trust Management implementation, and simplify it for the user to consume trust information. The main interface an application works with is the Trust Oracle: it consists of the four main

TrustMUSE Process

In this section we briefly summarize the TrustMUSE Process, and show how its development fits into the methodology used for the overall TrustMUSE system. The detailed presentation of this can be found in [START_REF] Vinkovits | Defining a Trust Framework Design Process[END_REF].

In the TrustMUSE Process, it is all about attributes: characteristics, conditions or services of Trust Management implementations. For the process, each author providing an implementation, defines the attributes that apply for the developed solution. When executing the process, the user is presented with the set of all author defined attributes, sorted by TrustMUSE Model elements. Developers are now able to focus on one element at a time, select and exclude attributes that seem relevant for the application's scenario -thereby actually selecting between Trust Management implementations that are applicable for it. After having finished the selection of attributes, the TrustMUSE Process suggests those implementations that have the largest overlap with the attributes selected by the user.

Fig. 3. Overview of the TrustMUSE system

The benefit in the TrustMUSE Process is that developers receive a Trust Management solution without having read the whole state of the art in the field. Even if the first suggestion does not fit completely, developers can quickly change the attributes to receive an alternative candidate; this still significantly reduces the number of frameworks necessary to be read, before finding a fitting one. An example of possible attributes for different TrustMUSE Model elements can be seen in Table 1.

The definition of the TrustMUSE Process had been based on requirements we collected beforehand in focus group workshops. From the requirements, we developed two paper prototypes and compared them during multiple user interviews using a specific development scenario, and manually simulating the process's operation with multiple sheets of prepared paper templates. The feedback collected from these user interviews than finalized the process, and guided the implementation of the Trust-MUSE Builder.

Standardization and Tooling

To achieve the model-driven process we aim for, a certain level of standardization of Trust Management has been necessary; this includes the APIs we have seen but it also includes formats and tools that are presented in this section. As described in the previous section, to enable the TrustMUSE Process, Trust Management experts have to provide attributes for their developed solutions; additionally, these attributes have to be in the same format for all solutions to be able to integrate them into one tool. To enable this uniform representation of attributes we defined the TrustMUSE Element Markup Language (TEML), based on which attributes and their dependencies can be provided, sorted by TrustMUSE Model elements, in machine readable XML format. A TEML document is composed as follows: the author starts with defining a trustMUSEElement with a freely chosen name attribute and the className of the TrustMUSE Model element the solution is for. As a next step, the characterizing attributes are given to the solution through a number of attribute XML elements. In case the solution has no collisions with other elements, the TEML document is finished; else these collisions also have to be defined in the same document. To do so, it is necessary to define further trustMUSEElements: these will have no name but only a className attribute. The attributes, which are placed into these latter trustMUSEEl- ements, define the collisions of the solution. Finally, the identifiers of the colliding trustMUSEElements have to be provided as dependencies to the original solution's XML element. The DTD of TEML can be seen in Fig. 4.

In order to facilitate the cumbersome process of creating correct XML documents by hand, we developed a GMF 3 based utility in which TEML documents can be generated automatically: the author simply pulls the respective TrustMUSE Model elements onto the canvas, and types attributes into them. Collisions can also be defined by simply connecting two elements. When saved, the utility generates two files: one file containing the diagram layout and one containing the TEML document.

TrustMUSE Builder Prototype

With the presented concepts at hand, we are able to create the tool that automates the execution of the TrustMUSE Process: the TrustMUSE Builder, implemented as a standalone .NET WPF4 desktop application. At start-up, it reads its working directory for stored TEML documents and additional informative text files -short descriptions, lists of references and implementation libraries. Parsing these files, the application builds up its model of possible TrustMUSE Model element implementations, their attributes and dependencies; then it prepares and shows the GUI as it has been specified in [START_REF] Vinkovits | Defining a Trust Framework Design Process[END_REF].

The first view of the GUI is called the composition state: this is the state where the user can select and exclude attributes by clicking the checkboxes next to the attributes. After each selection, the application logic checks which candidate implementa- tions are to be excluded, based on the defined collisions, and disables them. For each TrustMUSE Model element, the user can view a short help description; also for each attribute there is a tool tip providing an explanation of the presented term. A screenshot of this view can be seen in Fig. 5. If the user feels happy with the selection and has nothing more to add, she can go to the next view -called the composed state.

The composed state has the same layout as the previous one; the difference is that instead of showing attributes, it shows specific implementations for the elements. An implementation suggestion consists of a name, as specified in the TEML, a short description, and a list of additional references. The user can review whether the suggested framework looks sane for the application's purpose, and decide whether to go back to the composing state and change the attributes, or to acknowledge the framework.

If the suggested framework is acknowledged, which is done by clicking a button in the GUI, TrustMUSE Builder copies the implementation libraries from the respective elements into one specified folder. From this point on, the development process for the user, building on OSGi, looks as follows: as first step, the folder with the implementation libraries has to be set as target platform; second, missing code has to be filled in -like the TMuseFactory for the used trust representation, the network and communication handling, and the consumption of the API's integration layer; finally, the configurations for the different implementations have to be set. If all this is done, the Trust Management framework will be ready to be used.

First Qualitative User Evaluation and Threads to Validity

We evaluated the implementation of the integrated prototypic TrustMUSE system with application developers in a final set of interviews. Our aim was to find out whether our solution is able to support our target users finding a Trust Management solution when given a specific problem: that is, can users based on our system do the transition from specification to solution. Although our system was still in a very early stage of implementation, the evaluation held great significance as it had the potential of providing first valid feedback about the usefulness of the TrustMUSE approach. In this section we present our interview set up and present the collected responses; at the end of the section we interpret the results, and identify lessons learnt and future work.

Experiment

The main question of the final evaluation was, whether our target users, non-security expert developers, are able find an appropriate Trust Management framework with the support of TrustMUSE. Accordingly, for the evaluation, we first developed a scenario and produced an application specification with very clear Trust Management requirements: our scenario described a company that signed half year contracts with other companies to provide access to its distributed services. To ensure that users did not try to solve the task with regular requests to a server, we included a clause, stating that the company's server was not to be contacted too often, into the specificationout of scalability reasons. With this scenario, we approached five users: each of them had multiple years of software design experience but little to no security qualification. At the beginning of the test, we presented them with the specification and asked them to draft a solution based on their knowledge, without any support. Following this, we presented them the TrustMUSE Builder software: we provided a brief description of the TrustMUSE Process and explained that the presented software is not fully implemented; therefore the participants were allowed to ask questions during the experiment, however, we only answered if the misunderstanding was caused by the prototypic nature of the tool. For a better understanding of the developers' mindset, we asked our participants to think aloud, explain their decisions and state any ambiguities they encounter. Also, after they received the framework suggestion from the tool, they were asked to describe how they interpret the proposed solutions, and whether they think it is appropriate for their original problem. In the experiment, they were only asked to go as far as to click the framework generation button; we did not intend to evaluate the code integration aspects of the TrustMUSE system at that moment. Finally, we did a structured interview consisting of twelve statements with five-point Likert scale -strongly disagree, disagree, undecided, agree, strongly agree -responses, categorized into three topics: how clear were the components and dependencies of the model, how well was the process able to help them, how much did they benefit from the tool. Additionally, we also collected some open feedback for future extensions of the tool.

5.2

Results

The participants, when asked to provide a solution for the specification based on their own knowledge, all foresaw a certificate based system -except for one user who could not come up with a solution; however, they were not able to provide any more details regarding the realization of their idea. Subsequently, with the support of TrustMUSE, each user was able to find an appropriate solution for the problem, and understood how the proposed framework solved the specification. Additionally, our users stated to have gained a deeper understanding of Trust Management, and to have understood the relations defined in the TrustMUSE Model.

While the above statements remain valid for the overall experiment, there were statements in the interviews where the responses were much diffused and often had outliers. To be able to make sense and exclude invalid results, we applied statistical evaluation methods to the response sets: we checked the interquartile ranges (IQR) and made statistical hypothesis tests. First, we excluded all statements where the responses' IQR was more than 2; this step excluded four statements out of the twelve. Afterwards, for the remaining statements, we made the null hypothesis that our participants disagreed with them; testing our data against this null hypothesis excluded one additional statement. The statements remaining valid after our tests, with accompanying p-values, are presented in Table 2.

Lessons Learnt and Future Work

Reviewing our results from the evaluation, we found that our approach started on a sound track: developers were able to solve the task with the support of TrustMUSE The difficulty in defining attributes is that they have to be detailed enough to describe fine operational details of implementations; however, they should not be too technical, so that our target users still understand them. Additionally, as we have learnt from our user tests, attributes have to be unambiguous: even if we provide explanations, users tend to interpret terms to accommodate their own beliefs. Therefore, it will be necessary to execute a separate user-centered design process, where the appropriate set of attributes shall be found through multiple iterations. The overall process shall consist of analyzing multiple frameworks, dividing them by TrustMUSE Model elements, attributing them, and then talking to developers about their understanding.

Our users expressed some additional wishes towards the TrustMUSE Builder tool: they wished to see what effects their decisions had on the final framework suggestion. They sometimes felt lost during the use of the tool, and did not know whether what they did made sense; they could not clearly see the relation between their input and the application's output. Therefore, future developments should address these issues: find visual features that could tackle the lack of transparency, provide better indication of what the tool is doing currently, and generally better involve the user into the decision process.

Conclusions

In this paper we presented TrustMUSE (Trust Management Usable Software suitE): a model-driven approach for integrating Trust Management into applications. Building on the experience from the state of the art in user-centered security and model-driven security, our approach aims at supporting non-security expert application designers to find appropriate Trust Management frameworks for their application domains. We first presented the TrustMUSE Model: a meta model for Trust Management with accompanying APIs. Based on OSGi based implementation experience, we also provided an API for an integration layer that wraps Trust Management functionality, and only exposes main services that are needed by the relying distributed application. Built on top of the TrustMUSE Model, we presented the concept of the Trust-MUSE Process and its implementation: the TrustMUSE Builder. This tool first reads different Trust Management implementations that are described using TEML (Trust-MUSE Element Markup Language) documents; these implementations are then presented in an abstract format to the users of the tool. They can then describe their application specification by means of attributes, and subsequently receive a Trust Management framework suggestion tailored to their needs.

We closed this paper with the evaluation of our system, where users were asked to solve a Trust Management task based on the TrustMUSE Builder software. Each user was able, within a limited time span, to come up with an appropriate solution; additionally, they felt confident in the validness of the proposed framework for their problem. Based on the collected user feedback after the experiment, we conclude, that we should further increase the abstraction level of the representations used in Trust-MUSE. Future work needs to address the design of a more straight forward process that better supports our target end users in incorporating Trust Management into their application designs.

Fig. 1 .

 1 Fig. 1. UML class diagram of the TrustMUSE Model.

Fig. 2 .

 2 Fig. 2. TrustMUSE integration layer class diagram

<Fig. 4 .

 4 Fig. 4. DTD of TEML

Fig. 5 .

 5 Fig. 5. Screenshot of the composition state of TrustMUSE Builder

Table 1 .

 1 Example attributes for the TrustMUSE Process

	TrustMUSE Model element	Example standard attributes
	Trust Discovery and Distri-	Trusted third party; Personalized view on entities;
	bution	Requires continuous Internet connectivity.
	Trust Model	Trusted third party; Uncertainty handling; Continu-
		ous forgetting.
	Trust Enforcement	Weighted aggregation.
	Interaction Evaluation	Rule based feedback; multi-level feedback.
	Trust Update	Calendar based; Number of interactions based.

Table 2 .

 2 Results of the user evaluation

	Statement	Mean answer	P-Value
	You understand the concept of Trust Management.	Agree	0.0002
	You understand the sub-processes present in Trust	Undecided	0.0332
	Management.
	You understand the connection between the Trust	Agree	0.0001
	Management components.
	You think the concept of attributes is a good way to	Undecided	0.0004
	describe your scenario.
	You understand the Trust Management solution that	Agree	0.0002
	has been proposed.
	You think the proposed framework is appropriate	Agree	0.0001
	for your problem.
	You could explain the proposed framework to	Agree	0.0002
	someone else.

http://www.oodesign.com/factory-pattern.html Last visited

22nd January 2014 2 http://www.osgi.org/Main/HomePage Last visited 22nd January 2014

http://www.eclipse.org/modeling/gmp/ Retrieved 27th January 2014

http://msdn.microsoft.com/en-us/library/ms754130(v=vs.110).aspx Retrieved 27th January 2014

Acknowledgements. This work has been performed within the ALMANAC project, co-funded by the EC within the FP7, theme ICT-2014.1.4 Future Internet and smart Internet of Things, grant agreement No. 609081. Possible inaccuracies of information are under the responsibility of the project. This report reflects solely the views of its authors. The European Commission is not liable for any use that may be made of the information contained therein.


Johannes Sänger
email: johannes.saenger@wiwi.uni-regensburg.de

Günther Pernul
email: guenther.pernul@wiwi.uni-regensburg.de

Reusability for trust and reputation systems

Keywords: trust, reputation, reusability, trust pattern

Reputation systems have been extensively explored in various disciplines and application areas. A problem in this context is that the computation engines applied by most reputation systems available are designed from scratch and rarely consider well established concepts and achievements made by others. Thus, approved models and promising approaches may get lost in the shuffle. In this work, we aim to foster reuse in respect of trust and reputation systems by providing a hierarchical component taxonomy of computation engines which serves as a natural framework for the design of new reputation systems. In order to assist the design process we, furthermore, provide a component repository that contains design knowledge on both a conceptual and an implementation level.

Introduction

In the last decade, trust and reputation have been extensively explored in various disciplines and application areas. Thereby, a wide range of metrics and computation methods for reputation-based trust has been proposed. While most common systems have been introduced in eCommerce, such as eBay's reputation system1 that allows to rate sellers and buyers, considerable research has also been done in the context of peer-to-peer networks, mobile ad hoc networks, social networks or ensuring data accuracy, relevance and quality in several environments [START_REF] Yao | Addressing Common Vulnerabilities of Reputation Systems for Electronic Commerce[END_REF]. Computation methods applied range from simple arithmetic over statistical approaches up to graph-based models involving multiple factors such as context information, propagation or personal preferences. A general problem is that most of the new introduced trust and reputation models use computation methods that are designed from scratch and rely on one novel idea which could lead to better solutions [START_REF] Tavakolifard | A Taxonomy to Express Open Challenges in Trust and Reputation Systems[END_REF]. Only a few authors built on proposals of others. Therefore, approved models and promising approaches may get lost in the shuffle.

In this work, we aim to encourage reuse in the development of reputation systems by providing a framework for creating reputation systems based on reusable components. Design approaches for reuse have been given much attention in the software engineering community. The research in trust and reputation systems could also profit from benefits like effective use of specialists, accelerated development and increased reliability. Toward this goal, we propose a hierarchical taxonomy for components of computation engines used in reputation systems. We, thereto, decompose the computation phase of common reputation models to derive single building blocks. The classification based on their functions serves as a natural framework for the design of new reputation systems. To facilitate the reuse of the identified components we, moreover, set up a component repository containing artifacts on both a conceptual and an implementation level. On the conceptual level, we describe each building block as a design pattern-like solution. On the implementation level, we provide already implemented components by means of web-services.

The rest of this paper is based on the design science research paradigm involving the guidelines for conducting design science research by Hevner et al. [START_REF] Hevner | Design Science in Information Systems Research[END_REF] and organized as follows: Firstly, we give an overview of the general problem context, the relevance and motivation of our work. We, thereby, identify the research gap and define the objectives of our research. In the following section, we introduce our hierarchical component taxonomy of computation engines used in reputation systems. Subsequently, we point out how our component repository is conceptually designed and implemented. Finally, we summarize the contribution and name our plans for future work.

Problem context and motivation

With the success of the Internet and the increasing distribution and connectivity, trust and reputation systems have become important artifacts to support decision making in network environments. To impart a common understanding, we firstly provide a definition of the notion of trust. At the same time, we explain the properties of trust that are important with regard to this work. Then, we point out how trust can be established applying computational trust models. Focusing an reputation-based trust, we explain how and why the research in reputation models could profit from reuse. We, thereby, identify the research gap and define the objectives of this work.

The notion of trust and its properties

The notion of trust is a topic that has been discussed in research for decades. Although it has been intensively examined in various fields, it still lacks a uniform, generally accepted definition. Reasons for this circumstance are the multifaceted terms trust is associated with like credibility, reliability or confidence as well as the multidimensionality of trust as an abstract concept that has a cognitive, an emotional and a behavioral dimension. As pointed out by [START_REF] Mcknight | The meanings of trust[END_REF], trust has been described as being structural in nature by sociologists while psychologists viewed trust as an interpersonal phenomenon. Economists, however, interpreted trust as rational choice mechanism. The definition often cited in literature regarding trust and reputation online that is referred to as reliability trust was proposed by Gambetta in 1988 [START_REF] Gambetta | Can We Trust Trust?[END_REF]:

"Trust (or, symmetrically, distrust) is a particular level of the subjective probability with which an agent assesses that another agent or group of agents will perform a particular action, both before he can monitor such action (or independently of his capacity ever to be able to monitor it) and in a context in which it affects his own action."

Multiple authors furthermore include security and risk which can lead to more complex definitions. Anyway, it is generally agreed that trust is multifaceted and dependent on a variety of factors. Trust is dynamical, context specific, subjective, propagative, non-transitive, composable and event sensitive as Sherchan et al. [START_REF] Sherchan | A survey of trust in social networks[END_REF] point out. These properties are important with respect to this work, since they form the basis for many applied computation techniques in trust and reputation systems described in section 3.2. Reusable components could extend current models by the ability to gradually include these properties.

Reputation-based trust

In the recent years, several trust models have been developed to establish trust. Thereby, two common ways can be distinguished, namely policy-based and reputation-based trust establishment [START_REF] Artz | A survey of trust in computer science and the Semantic Web[END_REF]. Policy-based trust is often referred to as a hard security mechanism due to the exchange of hard evidence (e.g. credentials). Reputation-based trust, in contrast, is derived from the history of interactions. Hence, it can be seen as an estimation of trustworthiness (soft security). In this work, we focus on reputation-based trust. Reputation is defined as follows:

"Reputation is what is generally said or believed about a person's or thing's character or standing." [START_REF] Jøsang | A survey of trust and reputation systems for online service provision[END_REF] It is based on referrals, ratings or reviews from members of a community and can, therefore, be considered as a collective measure of trustworthiness [START_REF] Jøsang | A survey of trust and reputation systems for online service provision[END_REF]. Trustworthiness as a global value is objective. The trust an agent puts in someone or something as a combination of personal experience and referrals, however, is subjective.

Research gap: Design of reputation systems with reuse

It has been argued (e.g. by [START_REF] Tavakolifard | A Taxonomy to Express Open Challenges in Trust and Reputation Systems[END_REF]) that most reputation-based trust models proposed in the academic community are built from scratch and do not rely on existing approaches. Only a few authors continue their research on the ideas of others. Thus, many approved models and promising thoughts go unregarded. The benefits of reuse, though, have been recognized in software engineering for years. However, there are only very few works that proposed single components to enhance existing approaches. Rehak et al. [START_REF] Rehak | Representing Context for Multiagent Trust Modeling[END_REF], for instance, introduced a generic mechanism that can be combined with existing trust models to extend their capabilities by efficiently modeling context. The benefits of such a component that can easily be combined with existing systems are obvious. Nonetheless, research in trust and reputation still lacks in sound and accepted principles to foster reuse.

To gradually close this gap, we aim to provide a framework for the design of new reputation systems with reuse. As described above, we thereto propose a hierarchical component taxonomy of computation engines used in reputation systems. Based on this taxonomy, we set up a repository containing design knowledge on both a conceptual and an implementation level. The uniform and well-structured artifacts collected in this repository can be used by developers to select, understand and apply existing concepts on the one hand, as well as encourage researchers to provide novel components on a conceptual and an implementation level, on the other hand. In this way, the reuse of ideas, concepts and implemented components as well as the communication of reuse knowledge should be achieved.

A hierarchical component taxonomy for computation methods in reputation systems

To derive a taxonomy from existing models, our research includes two steps: (1) the analysis of the generic process of reputation systems and (2) the identification of logical components of the computation methods used in common trust and reputation models. A critical question is how to determine and classify single components. We thereto follow an approach to function-based component classification, where the taxonomy is derived from the functions identified components fulfill.

The generic process of reputation systems

The generic process of reputation systems, as depicted in Figure 1, can be divided into three steps: (1) collection & preparation, (2) computation and (3) storage & communication. Those steps were adapted from the three fundamental phases of reputation systems identified by [START_REF] Swamynathan | The design of a reliable reputation system[END_REF] and [START_REF] Resnick | Reputation systems[END_REF]: feedback generation/collection, feedback aggregation and feedback distribution. Feedback aggregation as the central part of every trust and reputation system was furthermore divided into three process-steps filtering, weighting and aggregation taken together as computation. The context setting consists of a trustor who wants to build a trust relation toward a trustee by providing context and personalization parameters and receiving a trustee's reputation value.

Collection and preparation

In the collection and preparation phase, the reputation system gleans information about the past behavior of a trustee and prepares it for subsequent computing. Although personal experience is the most reliable, it is often not sufficiently available or nonexistent. Therefore, data from other sources needs to be collected. These can be various, ranging from public or personal collections of data centrally stored to data requested from different Fig. 1. Generic process of a reputation system, inspired by [START_REF] Swamynathan | The design of a reliable reputation system[END_REF] peers in a distributed network. After all available data is gathered, it is prepared for further use. Preparation techniques include, for instance, a normalization.

Once the preparation is completed, the reputation data serves as input for the computation phase.

Computation The computation phase is the central part of every reputation system which takes the reputation information collected as input and generates a trust/reputation value as output. This phase can be divided into the three generic process-steps filtering, weighting and aggregation. Depending on the computation engine, not all steps have to be implemented. The first two steps, filtering and weighting preprocess the data for the subsequent aggregation. The need for these steps is obvious: The first question to be answered is which information is useful for further processing (filtering). The second process-step concerns the question of how relevant the information is for the specific situation (weighting).

In line with this, Zhang et al. [START_REF] Zhang | Robustness of Trust Models and Combinations for Handling Unfair Ratings[END_REF] pointed out that current trust models can be classified into the two broad categories filtering-based and discounting-based. The difference between filtering and weighting is that the filtering process reduces the information amount while it is enriched by weight factors in the second case. Filtering can, therefore, be seen as hard selection while weighting is more like a soft selection. Finally, the reputation values are aggregated to calculate one or several reputation scores. Depending on the algorithm, the whole computation process or single process steps can be run through for multiple times.

Storage and communication After reputation scores are calculated, they are either stored locally, in a public storage or both depending on the structure (central/decentralized/hybrid) of the reputation system. Common reputation systems not only provide the reputation scores but also offer extra information to help the end-users understand the meaning of a score-value. They should furthermore reveal the computation process to accomplish transparency.

In this work, we focus on the computation phase, since the first phase (collection & preparation) and the last phase (storage & communication) strongly depend on the structure of the reputation system (central or decentralized). The computation phase, however, is independent of the structure and can look alike for systems implemented in both central and decentralized environments. It, therefore, works well for design with reuse.

Hierarchical component taxonomy

In this section, the computation process is examined in detail. We will introduce a novel hierarchical component taxonomy that is based on the functional blocks of common reputation systems identified in this work. Thereto, we clarify the objectives of the identified classes (functions) and name common examples. Our analysis and selection of reputation systems is based on different surveys [8, 13, 6, 2, 1]. Figure 3.2 gives an overview of the primary and secondary classes identified. Besides the initial filtering of input data, it is often applied after the weighting phase in order to filter referrals that have been strongly discounted. An example of an attribute often constrained, is time, since it is desirable to disregard very old ratings. eBay's reputation system, for instance, only considers transactions having occurred in the last 12 months for their overview of positive, neutral and negative ratings.

Other models such as Sporas [START_REF] Zacharia | Collaborative reputation mechanisms for electronic marketplaces[END_REF] ignore every referral but the latest, if one party rated another party more than once. In this way, simple ballot stuffing attacks can be prevented. In ballot stuffing attacks, parties improve their reputation by means of positive ratings after fake transactions. 2. Statistic-based filtering: Further techniques that are used to enhance the robustness of trust models against the spread of false rumors apply statistical patterns. Whitby et al. [START_REF] Whitby | Filtering out unfair ratings in bayesian reputation systems[END_REF], for example, proposed a statistical filter technique to filter out unfair ratings in Bayesian reputation systems applying the majority rule. The majority rule considers feedback that is far away from the majority's referrals as dishonest. In this way, dishonest or false feedback can easily be detected and filtered. 3. Clustering-based filtering: Clustering-based filter use cluster analysis approaches to identify unfair ratings. These approaches are comparatively expensive and therefore rarely used as filtering techniques. An exemplary procedure is to analyze an advisors' history. Since a rater never lies to himself, an obvious way to detect false ratings is to compare own experience with advisors' referrals. Thus, both fair and unfair ratings can be identified. iCLUB [START_REF] Liu | iCLUB: An Integrated Clustering-based Approach to Improve the Robustness of Reputation Systems[END_REF], for example, calculates clusters of advisors whose evaluations against other parties are alike. Then, the cluster being most similar to the own opinion is chosen as fair ratings. If there is no common experience (e.g. bootstrapping) the majority rule will be applied. Another example for an approach using cluster filtering was proposed by Dellorcas [START_REF] Dellarocas | Immunizing online reputation reporting systems against unfair ratings and discriminatory behavior[END_REF].

Once all available information is reduced to those suitable for measuring trust and reputation in the current situation, it becomes clear that various data differ in their characteristics (e.g. context, reliability). Hence, the referrals are weighted in the second process-step based on different factors. In contrast to the filtering, applied techniques strongly differ. For that reason, our classification of weighting techniques is based on the properties of referrals that are analyzed for the discounting. We identified the following classes:

1. Context comparability: Reputation data are always bound to the specific context in which it was created. Ratings that were generated in one application area might not be automatically applicable in another application area. In eCommerce, for instance, transactions are accomplished involving different prices, product types, payment methods, quality or time. The nonconsideration of this context leads to the value imbalance problem where a malicious seller can build a high reputation by selling cheap products while cheating on expensive ones. To increase comparability and avoid such situations, context has become a crucial attribute for many current approaches like [START_REF] Zhang | A trust vector approach to transaction contextaware trust evaluation in e-commerce and e-service environments[END_REF] or [START_REF] Rehak | Representing Context for Multiagent Trust Modeling[END_REF]. 2. Criteria comparability: Besides the context in which feedback was created, the criteria that underlie the evaluation are important. Particularly, if referrals from different application areas or communities are integrated, criteria comparability can be crucial. In file-sharing networks, for instance, a positive rating is often granted with a successful transaction independent of the quality of service. On eCommerce platforms, in contrast, quality may be a critical factor for customer satisfaction. Other distinctions could be the costs of reviews, the level of anonymity or the number of peers in different communities or application areas. Weighting based on criteria comparability can compensate these differences. 3. Credibility/propagation: In network structures such as in the web-oftrust, trust can be established along a recommendation or trust chain. Obviously, referrals that have first-hand information about the trustworthiness of an agent are more credible than referrals received at second-hand (with propagation degree of two) or higher. Several models, therefore, apply a propagation (transitivity) rate to discount referrals based on their distance.

The biometric identity trust model [START_REF] Obergrusberger | Biometric Identity Trust: Toward Secure Biometric Enrollment in Web Environments[END_REF], for instance, derives the reputationfactor from the distance of nodes in a web-of-trust. 4. Reliability: Reliability or honesty of referrals can strongly affect the weight of reviews. The concept of feedback reputation that measures the agents' reliability in terms of providing honest feedback is often applied. As a consequence, referrals created by agents having a low feedback reputation will have a low impact on the aggregated reputation. The bases for this calculation can be various. Google's PageRank [START_REF] Brin | The Anatomy of a Large-Scale Hypertextual Web Search Engine[END_REF], for instance, involves the position of every website connected to the trustee in the web graph in their recursive algorithm. Epinions2 , on the other hand, allows users to directly rate reviews and reviewers. In this way, the effects of unfair ratings are diminished. 5. Rating value: Trust is event sensitive. For stronger punishment of bad behavior, the weight of positive ratings compared to negative ratings can be calculated asymmetrically. An example for a model using an "adaptive forgetting scheme" was proposed by Sun et al. [START_REF] Sun | Attacks on Trust Evaluation in Distributed Networks[END_REF], in which good reputation can be built slowly through good behavior but easily be ruined through bad behavior. 6. Time: Due to the dynamic nature of trust, it has been widely recognized that time is one important factor for the weighting of referrals. Old feedback might not be relevant for reputation scoring as new referrals. An example measure for time-based weighting is the "forgetting factor" proposed by Jøsang [START_REF] Jøsang | The Beta Reputation System[END_REF]. 7. Personal preferences: Reputation systems are used by various end-users (e.g. human decision makers, services). A reputation system must, therefore, allow the adaptation of its techniques to subjective personal preferences. Different actors might, for example, have different perceptions regarding the importance of direct experience and referrals, the significance of distinct information sources or the rating of newcomers.

The tuple of reputation data and weight-factor(s) serve as input for the third step of the computation process -the aggregation. In this phase, one or several trust/reputation values are calculated by composing the available information. In some cases, the weighting and the aggregation process are run through repetitively in an iterative manner. However, the single steps can still be logically separated. The list of proposed algorithms to aggregate trust and reputation values has become very long during the last decade. Here, we summarize the most common aggregation techniques and classify them into the five blocks simple arithmetic, statistic, heuristic, fuzzy and graph-based models:

1. Simple arithmetic: The first class includes simple aggregation techniques like ranking, summation or average. Ranking is a very basic way to measure trustworthiness. In ranking algorithms, ratings are counted and organized in a descending order based on that value. This measure has no exact reputation score, however, it is frequently used as a proxy for the relative importance/trustworthiness. Examples for systems using ranking algorithms are message boards like Slashdot3 or citation counts used to calculate the impact factor in academic literature. Other aggregation techniques that are well known due to the implementation on eBay or Amazon4 are the summation (adding up positive and negative ratings) or the average of ratings. Summation, though, can easily be misleading, since a value of 90 does not reveal the composition of positive and negative ratings (e.g. +100,-10 or +90,0). The average, on the other hand, is a very intuitive and easy to understand algorithm. 2. Statistic: Many of the prominent trust models proposed in the last years use a statistical approach to provide a solid mathematical basis for trust management. Applied techniques range from Bayesian probability over belief models to Hidden Markov Models. All models based on the beta probability density function (beta PDF) are examples for models simply using Bayesian probability. The beta PDF represents the probability distributions of binary events. The a priori reputation score is thereby gradually updated by new ratings. Result is a reputation score that is described in a beta PDF function parameter tuple (α, β), where α represents positive and β represents negative ratings. A well known model using the beta PDF is the the Beta Reputation system [START_REF] Jøsang | The Beta Reputation System[END_REF]. A weakness of Bayesian probabilistic models, however, is that they cannot handle uncertainty. Therefore, belief models extend the probabilistic approach by DempsterShafer theory (DST) or subjective logic to include the notion of uncertainty. Trust and reputation models involving a belief model have been proposed by Jøsang [START_REF] Jøsang | A logic for uncertain probabilities[END_REF] or Yu and Singh [START_REF] Yu | An evidential model of distributed reputation management[END_REF]. More complex solutions that are based on machine learning, use the Hidden Markov Model, a generalization of the beta model, to better cope with the dynamic behavior. An example was introduced by Malik et al. [START_REF] Malik | Web Services Reputation Assessment Using a Hidden Markov Model[END_REF]. 3. Heuristic: Since statistical approaches are very complex, a shift towards heuristic-based trust modeling has become visible in scientific literature. Heuristic approaches try to provide custom-designed practical and easy to understand and implement solutions. Thereby, the filtering and weighting phases are of high importance as the aggregation is mostly based on a combination of rating and weights. Exemplary models were proposed by Xiong and Liu [START_REF] Xiong | A reputation-based trust model for peer-to-peer e-commerce communities[END_REF] or Zhang and Wang [START_REF] Zhang | A trust vector approach to transaction contextaware trust evaluation in e-commerce and e-service environments[END_REF]. 4. Fuzzy: Aggregation techniques classified as fuzzy models use fuzzy logic to calculate a reputation value. In contrast to classical logic, fuzzy logic allows to model truth or falsity within an interval of [0,1]. Thus, it can describe the degree to what an agent/resource is trustworthy or not trustworthy. Fuzzy logic has been proven to deal well with uncertainty and mimic the human decision-making process [START_REF] Song | Trusted P2P Transactions with Fuzzy Reputation Aggregation[END_REF]. Thereby, a linguistic approach is often applied. REGRET [START_REF] Sabater | Reputation and social network analysis in multi-agent systems[END_REF] is one prominent example of a trust model making use of fuzzy logic. 5. Graph-based: A variety of trust models employ a graph-based approach.

They rely on different measures describing the position of nodes in a network involving the flow of transitive trust along trust chains in network structures. As online social networks have become popular as a medium for disseminating information and connecting people, many models regarding trust in social networks have lately been proposed. Graph-based approaches use measures from the field of graph theory such as centrality (e.g. Eigenvector, betweenness), distance or node-degree. Reputation values, for instance, grow with the number of incoming edges (in-degree) and in-or decrease with the number of outgoing edges (out-degree). The impact of one edge on the overall reputation can depend on several factors like the reputation of the node an edge comes from or the distance of two nodes. Popular algorithms using graph-based flow model are Google's PageRank [START_REF] Brin | The Anatomy of a Large-Scale Hypertextual Web Search Engine[END_REF] as well as the Eigentrust Algorithm [START_REF] Kamvar | The Eigentrust algorithm for reputation management in P2P networks[END_REF]. Other examples are the web-of-trust or trust models particularly designed for social networks as described in [START_REF] Sherchan | A survey of trust in social networks[END_REF].

As mentioned above, due to the incremental nature of these algorithms, the weighting and aggregation phases are incrementally run through for several times.

The classification of the computation engine's components used in different trust models in this taxonomy is not limited to one component of each primary class. Depending on the computation process, several filtering, weighting and aggregation techniques can be combined and run through more than once. Malik et al. [START_REF] Malik | Web Services Reputation Assessment Using a Hidden Markov Model[END_REF], for instance, introduced a hybrid model combining heuristic and statistical approaches. However, our taxonomy can reveal the single logical components, a computation engine is built on. It, moreover, serves as an overview of existing approaches. Since every currently known reputation system can find its position, to the best of our knowledge, this taxonomy can be seen as complete. Though, an extension by new classes driven by novel models and ideas is possible. Our hierarchical component taxonomy currently contains 3 primary component classes, 15 secondary component classes, 26 component terms and 36 subsets. Table 1 shows an excerpt of the hierarchical component taxonomy with building blocks of the primary class "weighting".

The component taxonomy as a framework for design with reuse

The hierarchical component taxonomy introduced in the former section, serves as a natural framework for the design of reputation systems with reuse. To support this process, we set up a component repository combining a knowledge and a service repository. Thus, it does not only contain information about software components on implementation level but also provides extensive descriptions of the ideas applied on a conceptual level. This comprehensive set of fundamental component concepts and ideas combined with the related implementation allows the reuse of both ideas and already implemented components.

In this section, we first describe the conceptual design of our component repository in detail. Then, we show how we implemented a web application using our thorough repository to provide design knowledge for reuse on a conceptual and an implementation level.

Conceptual design of the component repository

Reuse-based software engineering can be implemented on different levels of abstraction, ranging from the reuse of ideas to the reuse of already implemented software components for a very specific application area. In this work, we want to apply our taxonomy for reuse on two levels -a conceptual level and an implementation level. The developed repository, therefore, provides design knowledge for reuse on two logical layers, as depicted in Figure 3. Reuse on conceptual level When reusing an implemented component one is unavoidably constrained by design decisions that have been made by the developer. A way to prevent this, is to conceive more abstract designs that do not specify the implementation. Thus, we provide an abstract solution to a problem by means of design pattern-like concepts. Design patterns are descriptions of commonly occurring problems and a generic solution to the problems that can be used in different settings [START_REF] Gamma | Design patterns: Elements of reusable object-oriented software[END_REF]. Our design pattern-like concepts consist of essential elements that are exemplary depicted on Table 2.

Reuse on implementation level On implementation level we provide fully implemented reusable components by means of web-services in a service-orientated architecture. These services encapsulate the concepts' logic and functionality in independent and interchangeable modules to achieve the separation of concerns. The web-services are incorporated via well-defined interfaces. All service provided are registered as artifacts in the service repository. An artifact contains essential information about one live reachable service such as ID, type (REST or ws), URL, description, parameters, example calls, example output and the design pattern that is implemented by the service.

Implementation of the repository

We prototypically implemented our repository as a web-based application in a three-tier client-server-architecture5 . On client-side (presentation layer) we employed the current web standards HTML5, JavaScript and CSS (Bootstrap). On server-side the logic was implemented in PHP on an Apache server (logic layer) Problem description Reputation data is always bound to the specific context in which it was created. Ratings that were generated in one application area might not be automatically applicable in another application area which can result in the value imbalance problem.

Solution description

Apply similarity measurement between context ci (reference context) and context cj of referrals in the referral set to deliver a weight-factor for each item of the referral set using the following formula: connecting to a MySQL-Database (persistent layer). All webservices were created in PHP an registered as artifacts in our service repository. This web-application is planned to become a platform for researchers to make their concepts and implementations publicly available.

w(c1, c2) := k(ci) ∩ k(cj ) k(ci) ∪ k(cj ) k(ci)

Contribution and Future work

Many surveys of trust and reputation systems give an overview of existing trust and reputation systems by means of a classification of existing models and approaches. In contrast to that, we provide a collection of ideas and concepts classified by their functions. Furthermore, these ideas are not only named but also clearly described in well-structured design pattern-like artifacts which can easily be adapted to a specific situation. Therewith, we reorganized the design knowledge for computation techniques in reputation systems and translated the most common ideas to a uniform format. To directly make use of novel components, the webservices created on implementation level can instantly be reused and integrated in existing reputation systems to extend their capabilities. This approach, to publicly provide implemented computation components as webservices may help to better spread innovative ideas in trust and reputation systems and to give system builders a better choice allowing to experiment with different computation techniques. We, moreover, encourage researchers to focus on the design of single components by providing a platform, where concepts and their prototypical implementation can be made publicly available. However, there are still many unexplored areas regarding the design with reuse in trust and reputation systems. The following list gives an overview of those issues that will be topic for our future research: Reusability could also play a role in other process steps run through in a reputation system. To clarify the opportunities, further research is necessary in this area. 2. Additional views on the component repository: Currently, our hierarchical taxonomy provides a functional view on the identified components. However, a developer could also benefit from additional views, like an attack view, in which the components are classified as possible solutions in a taxonomy of attacks on reputation systems. 3. Generic testbed and evaluation criteria: To measure the quality of a component, a testbed for comparison and a set of sound evaluation criteria such as robustness, efficiency or complexity is needed. 4. Software-supported selection of components: The selection and interpretation of adequate components for new reputation systems in a specific application area requires time, effort and to some extend knowledge of this research area. To increase usability and simplicity, a software application is needed to support a user in this development process. 5. Advanced meta information and machine readability: To take one step further, the most qualified composition could be automatically found and assembled by a software program based on the reputation data (input) provided. The research involves the development of sound principles for automated component composition.

Conclusion

The research in trust and reputation systems is still growing. In this paper, we presented concepts to foster reuse of existing approaches. We provided a hierarchical taxonomy of computation components from a functional view and described the implementation of a component repository that serves as both a knowledge base and a service repository. In this way, we communicate design knowledge for reuse, support the development of new reputation systems and encourage researchers to focus on the development of single components that can be integrated in various reputation systems to easily extend their capabilities by new features.

Fig. 2 .

 2 Fig. 2. Classes of filtering-, weighting-and aggregation-techniques

Fig. 3 .

 3 Fig. 3. Logical layers of the component repository for design with reuse

1 .

 1 Reusability in collection & preparation and storage & communication: The work in hand considers the design of computation techniques with reuse.

Table 1 .

 1 Excerpt of the hierarchical component taxonomy

	Primary	Secondary	Component	Subset	Description
	compo-	component	term
	nent class	class
		credibility/	propagation		Discount referrals along trust chains
		propagation	discount
			subjective re-	property	Discount based on similarity of personal prop-
			liability	similarity	erties
				rating	Discount referrals based on similarity of rat-
				similarity	ings toward other agents
	weighting	reliability		Explicit	Discount based on explicit reputation infor-
					mation like referrals or certificates
			objective re-	Implicit	Discount based on implicit reputation infor-
			liability		mation like profile age, number of referrals or
					position
	...	...	...	...	...

Table 2 .

 2 Design pattern on the conceptual level (example)

	Component term	Context similarity
	Subset	Absolute congruence
	Description	This component uses an absolute congruence metric as similarity measure
		to identify context similarity.

  denotes the total number of keywords describing context ci.

	Applicability	Set of nominal context attributes.
	Code example (php)
		function calculate_values ( $reference , $context_sets ) {
		$ re f er en c e_ c on te x t = $reference [ ' co n te xt _ at t ri bu t es ' ];
		$return_values = array () ;
		while (! empty ( $context_sets ) ) {
		... shortened ...
		}
		return $return_values ;
		}
	Implementation	Context similarity-based weighting service (absolute congruence)
	Literature
		-Mohammad Gias Uddin, Mohammad Zulkernine, and Sheikh Iqbal
		Ahamed. 2008. CAT: a context-aware trust model for open and dy-
		namic systems. In Proceedings of the 2008 ACM symposium on Ap-
		plied computing (SAC '08). ACM, New York, NY, USA, 2024-2029.
	Tags	weighting, context, similarity, congruence

http://www.ebay.com

http://www.epinions.com/

http://www.slashdot.org/

http://www.amazon.com/

http://trust.bayforsec.de

Acknowledgments

The research leading to these results was supported by the "Bavarian State Ministry of Education, Science and the Arts" as part of the FORSEC research association.