Trust and Reputation Systems represent a significant trend in decision sup- port for Internet mediated service provision (JIB07; GS00). The basic idea is to let parties rate each other, for example after the completion of a trans- action, and use the aggregated ratings about a given party to derive a trust or reputation score, which can assist other parties in deciding whether or not to transact with that party in the future. A natural side effect is that it also provides an incentive for good behavior, and therefore tends to have a positive effect on market quality. Reputation Systems can also be called Collaborative Sanctioning Systems to reflect their collaborative nature, and are related to Collaborative Filtering (CF) Systems: the assumptions behind CF Systems is that different people have different tastes, and rate things differently according to subjective taste. This can be used to find and help in their decisions those neighbors sharing similar tastes. Reputation Sys- tems are already being used in successful commercial online applications, e.g. e-Bay and Amazon to cite the most famous.
The main differences between trust and reputation systems can be de- scribed as follows: Trust Systems produce a score that reflects the relying party’s subjective view of an entity’s trustworthiness, whereas reputa- tion systems produce an entity’s (public, in this case) reputation score as seen by the whole community. A second difference is that transitivity is considered an explicit component in trust systems (see Fig. 3), whereas reputation systems usually only take transitivity implicitly into account. At last, trust systems usually take subjective and general measures of (reli- ability) trust as input, whereas information or ratings about specific (and objective) events, such as transactions, are used as input in reputation systems. Of course, there can be Trust Systems that incorporate elements
of Reputation Systems and vice versa. Bob Alice Claire referral derived trust trust trust
Figure 3:An example of the trust transitivity principle.
Trust Management, introduced in (BFL96), is a unified approach for specifying and interpreting security policies, credentials, and relation- ships that allows direct authorization of security critical actions. Particu- larly, a Trust Management System (TMS) combines the notion of specifying security policy with the mechanism for specifying security credentials. Credentials describe specific delegations of trust among public keys; un- like traditional certificates, which bind keys to names, trust management credentials bind keys directly to authorizations to perform specific tasks. TMSs support delegation, and policy specification and refinement at the different layers of a policy hierarchy, thus solving to a large degree the consistency and scalability problems inherent in traditional Access Control Lists. Furthermore, TMSs are by design extensible and can express poli- cies for different types of applications. In a Trust Management scenario, a requester submits a request, possibly supported by a set of credentials issued (signed) by other parties, to an authorizer, who specifies access rules governing access to the requested resources. The authorizer then decides whether to authorize this request by stating if the access rules and cre- dentials authorize this request. The digitally signed credentials document authenticated attributes of entities: these attributes may be, for instance,
group membership, membership in a role within an organization, or being delegated of a permission or role. Access rules can specify what attributes are required to access a resource and other access conditions, such as time or auditing requirements.
According to the classification proposed in (JIB07) and (GS00), we can distinguish between a set of different trust classes: i) Provision trust de- scribes the relying party’s trust in a service or resource provider, ii) Access trust describes trust in principals for the purpose of accessing resources owned by or under the responsibility of the relying party, iii) Delegation trust describes trust in an agent (the delegate) that acts and makes deci- sion on behalf of the relying party, iv) Identity trust describes the belief that an agent identity is as claimed, and, finally, v) Context trust describes the extent to which the relying party believes that the necessary systems and institutions are in place in order to support the transaction and provide a safety net in case something should go wrong.
In the next two chapters, we respectively provide an introduction to the metrics used in Trust models (see Ch. 1.4.1) and the strict relation between Trust and Security (Ch. 1.4.2).
1.4.1
Trust Metrics
At its heart, a computational Trust model contains a Trust metric. Some examples of metrics are described in (Lev03; ARH97; Jøs99; Mau96).
There are three inputs to this trust metric: a directed graph, a desig- nated seed node indicating the root of trust, and a target node. We wish to determine whether the target node is trustworthy (see an example in Fig. 4). Each edge from s to t in the graph indicates that s believes that t is trustworthy. The simplest possible trust metric evaluates whether t is reachable from s. If not, there is no reason to believe that t is trustworthy, given the data available. In a cryptographic implementation, each node corresponds to a public key, and each edge from s to t corresponds to a digitally signed certificate. In the usual terminology, s is the issuer, t is the subject. The certificate itself is some string identifying t, along with a digital signature of this string generated by s. The simplest trust metric is
also the weakest. If an attacker is able to generate an edge from any node reachable from the seed to a node under his control, then he can cause arbitrary nodes to be accepted. As the size of the reachable subgraph increases, the risk of any such attack increases as well. Thus, the primary focus in the literature is to present stronger trust metrics that (hopefully) resist attacks better, while still accepting most nodes that deserve trust.
Therefore, a trust metric operates over a certification graph that en- codes the trust (certificate) relationships between keys, and returns a trust value which represents how trustworthy the source deems the target name-key binding to be. The problem is this: an attacker wishes to intro- duce a false name-key binding (to impersonate another entity), known as a forgery. The goal of the trust metric is to resist such attacks by rejecting the forgery.
Trust metrics can be divided in two main classes: a metric is called local if the values it computes are based on local estimates of trust in the graph. Precisely, the trust value Ts,tcomputed by an-local trust metric M(G) on
G is altered by at most by the removal of a node not on a path from the source s to the target t, in G. The general idea behind global metrics is instead to compute the metric over the entire certification graph, to obtain some global solution, rather than a number of local estimates.
To provide an example, the simplest form of computing reputation scores (adopted, for instance, in the reputation forum of e-Bay) is simply to sum the number of positive ratings and negative ratings separately, and to keep a total score as the positive score minus the negative score. Obviously, the advantage is that anyone can understand the principle behind this reputation score, while the main disadvantage is that it is primitive and consequently gives a poor picture of participants reputation.
1.4.2
Trust and Security
Trust and Reputation Systems are perfect examples of “soft” security mechanisms, also called social control mechanisms in general. These mech- anisms take the place of traditional security mechanisms which will typi- cally protect resources from malicious users, by restricting access to only
A
B C
D
E F
G
Figure 4:An example of trust inference from node A to node G.
authorized users. But in many situations we have to protect ourselves from those who offer resources, and thus the problem is reversed: for instance, service providers can act deceitfully by providing false or mis- leading information, and traditional security mechanisms are unable to protect against this kind of threat. The term “hard” security is instead used for traditional mechanisms like authentication (i.e. the process of at- tempting to verify the digital identity) and access control (i.e. the ability to permit or deny the use of something by someone: it includes authentica- tion, authorization and audit). The difference between these two distinct approaches to security was described in (RJ96) for the first time. Authenti- cation provides the so called identity trust, i.e. a measure of the correctness of a claimed identity over a communication channel or in a distributed system. It can be observed that identity trust is a condition for trusting a party behind the identity with anything more than a baseline or default provision trust that applies to all parties in a community. This does not mean that the real world identity of the principal must be known. An anonymous party, who can be recognized from interaction to interaction, can also be trusted for the purpose of providing services.
Another important concept regards the security assurance level, which represents a measure of security. The assurance level (JKD05) can be interpreted as a system strength to resist malicious attacks, and some organizations require systems with high assurance levels for high risk or highly sensitive applications. In an informal sense, the assurance level expresses a level of public (reliability) trustworthiness of given system.