We acknowledge the fact that situational details can have impact on the trust that a Trustor assigns to some Trustee. Motivated by that, we discuss and formalize functions for determining context-aware trust. A system implementing such functions takes into account the Trustee's profile realized by what we call quality attributes. Furthermore, the system is aware of some context attributes characterizing additional aspects of the Trustee, of the Trustor, and of the environment around them. These attributes can also have impact on trustor's trust formation process. The trust functions are concretized with running examples throughout the paper.
Context influences the behavior of an agent on multiple
levels. Generally, context is any information
characterizing the situation of an entity. An entity, in turn, can be a
person, place, or object that is considered relevant to the
interaction between a user and an application, including the
user and the application themselves [
Trust is another emerging research subject. Trust is a
fundamental factor in human relationships enabling
collaboration and cooperation to take place. In Computer
Science, Trust Management [
However, the relationship between context and trust has
not received very much attention, apart from some
occasional work, such as the ones reported in [
At an abstract level, trust formation can be described with mathematical functions, which take some phenomena as input, and provide a level of trustworthiness as an output. We formalize such functions by putting emphasis especially on the context attributes. More specifically, the “traditional” aspects influencing trust formation, for example reputation and recommendations, are complemented with contextual information. In addition, we concretize the functions via examples.
The rest of the paper is organized as follows. Section 2 summarizes some of the relevant related work. Section 3 introduces the operational framework where trust is evaluated and proposes a distinction between quality attributes and context attributes based on the trust scope. Additionally, Section 3 illustrates the role of context in the trust evaluation process. Section 4 presents the details of the context-aware trust evaluation function. Moreover, it shows how context information can be used to select, among a set of past experiences and a set of recommendations, those that are relevant with regard to the current context. Section 5 exemplifies the use of context in trust evaluation process through an example. Finally, Section 6 concludes the paper and Section 7 points out some of our future work. 2.
Trust plays a role across many disciplines, including
sociology, psychology, economics, political science, history,
philosophy, and recently also computer science [
Recent approaches to trust management are able to deal
with incomplete knowledge and uncertainty (see for
example the surveys reported in [
We acknowledge several (trust) relationships when
studying the context-dependent trustworthiness of a trustee.
Therefore, we suggest a solution for using context data to
improve the traditional trust establishment, for example when
asking for the trustee’s reputation. This extends for
example the approach reported in [
Inspired by [
In [
Definition 1. Trustor is the entity that calculates the trustworthiness. Trustee is the entity whose trustworthiness is calculated. Trustworthiness is modeled with a trust value. Trust value expresses the subjective degree to which the Trustor has a justifiable belief that the Trustee will comply the trust scope.
To evaluate the Trustee’s trustworthiness for a certain trust scope, the Trustor analyzes two different kinds of input: quality attributes and context attributes.
Quality attributes represent the essential data
characterizing the Trustee. Without quality attributes, a Trustor has
no a priori knowledge of the object of trust, and cannot
start any trustworthiness determination on rational basis.
The only possible decisions in this case are to trust
blindly, that is, to adopt an optimistic approach, or to distrust,
which means adopting a pessimistic approach [
Context attributes represent contextual information that the Trustor may require in addition to the quality attributes, in order to complete the evaluation of the Trustee’s trustworthiness. Context attributes may or may not be available at the moment of trustworthiness evaluation. Their absence does not prevent the trustworthiness evaluation process, but Q quality attributes environment trustor
C context attributes trustee Legend “used by” “describes” can nevertheless affect the result. For example, depending on the scenario, context may express some relevant property characterizing the Trustor, and its impact on the trust evaluation may strongly affect the preliminary result that comes out from the analysis of the quality attributes.
The division of one set of attributes into quality and
context attributes varies case by case. In this paper, we use
the notion of trust scope [
To conclude this section, we introduce one example of context-depended trust scenarios. It will be used later on in the paper when some concepts need to be concretized and discussed.
Example 1 (Messaging). 1 Alice receives an SMS with the content “We have just won one million euros at the bingo. Cheers Bob”. The Trustor is Alice and the Trustee is the message’s content.
If the trust scope is to determine the creator/sender of the message (for example, “Is that really Bob who cheers me?”), quality attributes can be the message header (that includes the phone number from where the message originated), and perhaps the network which delivered the message. Context attributes can be the location of the sender, the location of the receiver, the fact that Alice has bought a lottery ticket in the past, the knowledge (say, from local news) that there has been a winner in the bingo, the reputation of the sender (“he likes making jokes” versus “he never makes jokes”).
Instead, if the trust scope is to trust the message content as
authentic (“Did we really win?”), quality attributes are the
1A more extensive version of this example appeared in [
This section gives a mathematical characterization of the concepts for quality attributes and context attributes illustrated in Figure 1. Moreover, this section characterizes the mathematical structure of a context-aware trust evaluation function in terms of relevant data domains. 4.1
Let us consider the example scenario of trust described in Example 1. Let Attributes represent the information that is potentially involved in this instance of the scenario of trust. Attributes contains all the potential message headers (here only phone numbers), network names, localities, and reputation information about the sender of the message.
Formally, Attributes is a set of typed and structured data over a signature Σ(I) = A1 × . . . × An, where Ak are types and I = ha1, . . . , ani is an array of type names. Ak’s can be atomic or composed, and are not necessarily distinct.
The set of all potential data in our messaging example are described as follows: Σ(I) = number×name×location×location×string×bool×bool
As anticipated in Section 3, within an instance of the scenario of trust and in dependence on the trust scope σ, we can identify two different sets of disjunct sub-tuples in Attributes: • the set Quality of all quality attributes, defined as the set of data over the signature Σ(M(σ)), where M (σ) is a sub-tuple of I (written M (σ) v I ). • the set Context of all context attributes, defined as the set of all data whose signature is Σ(I−M(σ)). Here I − M (σ) is the tuple obtained by orderly removing the M (σ)’s items from I .
We assume Attributes = Quality × Context, without loss of generality.
The division into sub-tuples for quality attributes and context attributes depends on the trust scope σ. In reference to Example 1, if the trust scope of Alice is to evaluate the trustworthiness of the message as authentic from Bob, quality attributes are the message headers and the network names. Formally:
I w M(σ) = hheader, networki ΣM(σ) = number×name Quality = h+390586, TrustFonei, h+316453, MalisFonei, . . .
The remaining attributes define the context: Σ(I−M(σ)) = location×location×string×bool×bool I w I − M(σ) = Context = sender location, receiv location, reputation, bought ticket, winner inthe news hLondon, NY , “hates jokes”, false, truei, hNY , Dublin, “likes jokes”, true, truei, . . . 4.2
This section describes the structure for the proposed trust evaluation function, taking into account contextual data. We also present a partial implementation, although the generality of our functions allows different implementations as well. 4.2.1
According to Definition 1, trustworthiness is modeled with
a value, called trust value, which is the final result of a
trustworthiness evaluation process. A trust value can be used,
in interaction with a risk analysis, to take a decision in the
case of uncertainty [
In this paper, we assume a trust value to be a real number
in the interval [
This section describes the basic version of our
contextaware trust evaluation function. Later, we show how to
cope with reputation and recommendations, which are
generally useful capabilities in trust evaluation, context-aware
or not. The basic function for context-aware trust
evaluation is defined by the following function from attributes to
trust values:
ctrustS,σ : Quality × Context → [
We propose the whole trust evaluation process to be divided into two stages: • the first stage is any traditional trust determination process; • the second stage analyzes contextual information to adjust the output of the first stage.
Formally, we propose that the trust function in (1) has the following shape:
ctrustS,σ(C, Q) , C ⊗ trustS,σ(Q)
The first stage is depicted by the function trustS,σ(Q).
This function can be one of the existing procedures
coping with trust evaluation, for example the ones specialized
for recommendation-based trust management (see for
example [
The second stage is depicted by the operator ⊗. This operator iteratively adjusts the trust value provided at the first stage by evaluating piece of context in the array C of context attributes. To construct the “adjusting operator” ⊗ we first define, for each data type name ak, the following entities: • pk : Ak → bool, a predicate that expresses some relevant properties over values of type Ak (of name ak. • wk ∈ Weights, a numerical weighting wk that expresses the impact of the context attributes of type name ak in process of refinement.
Here, a predicate p will be used to determine whether certain context value c has a positive (true) or negative (false) influence on the trust tuning/adjusting.
Set Weights represents the set of possible weightings. We assume (Weights, >) to be a totally ordered set, with w0 its minimum element. Weightings are used to increase or decrease the impact of context data during the process of adjusting. The larger2 the weight, the larger will the tuning effect be. Note that if the weight is large the adjustment can be quite significant: this reflects situation in which that context data (for example the Trustor’s location) is considered (by the Trustor) to effect strongly a preliminary trust evaluation based on Trustee’s quality attributes only.
The minimum w0, is devoted to represent the “I do not care” weighting, that is, context attributes of weight w0 will not have any impact in the process of refinement.
In addition we define two functions
inc : Weights → ([
Note 1. Chosen a weighting w ∈ Weights, incw and
decw are the functions of type [
Definition 2. inc, and dec are said well behaving defining functions if in their own domain: 2When talking about Weights, any reference to terms that involve a concept of ordering must be intended with regard to the relation >. 1. For any w 6= w0, incw(v) > v and decw(v) < v, for all v ∈ ]0, 1[, that is, they represent positive and negative adjustment as expected. 2. incw0 (v) = decw0 (v) = v, that is, weighting w0 has no impact in the adjustment. 3. When w > w0, incw(v) > incw0 (v) and decw(v) < decw0 (v) for all v ∈]0, 1[, that is, the larger the weighting the more the result of the adjustment.
Note 2. In items 1. and 3., the exclusion of the points
v = 0, 1 is due to two main motivations. The first,
obvious, is that we cannot go beyond [
Other restrictions over inc and dec may be required (for example, incw(decw(v)) = decw(incw(v)), the property of being reciprocally commutative), but here we prefer to define our adjustment functions in the most general way. More specific sub-families of the functions can be introduced caseby-case.
Although we will provide concrete example of adjustment functions in the following section, a comprehensive study over them is beyond the target of this paper and it is left as future work.
Given a trust value v, arrays C = hc1, . . . , cmi of context data, hw1, . . . , wmi of weights, and hp1, . . . , pmi of predicates, the procedure that implements ⊗ consistently with certain incw(v) and decw(v) functions is described by Algorithm 1.
Algorithm 1 Context Tuning procedure ⊗(C, v) for all i ← 1, m do if pk(ck) then v ← incwk (v) else v ← decwk (v) end if end for return v end procedure
An instance of our framework can be specified, for example, by setting Weights any interval [1, N ] of rational number, with N a fixed constant. In this case w0 = 1. The following family of functions are used to calculate the positive and negative adjustment for a certain weighting w: Figure 2 depicts the effect of some example weightings. Note, that inc and dec are well behaving functions according to Definition 2. Moreover they satisfy the following additional properties: 4. incw(decw(v)) = v and decw(incw(v)) = v, that is, they are mutually commutative; 0.8 0.6 5. fw(gw0 (v)) = gw0 (fw(v)) where f, g ∈ {inc, dec}, that is, their are order-independent with regard to the context data array.
Let now suppose to have a trust value t = 0.7, and to analyze the context attributes (c1; c2) = (2.2; 2.5). The associated weighting are (w1, w2) = (2; 32 ), while the relative predicates are p1(c) = p2(c) = (c > 2.4). We apply Algorithm 1 to calculate (2.2; 2.5) ⊗ 0.7, and we obtain the following trace of execution: t0 The analysis of context attributes has changed a trust value (coming from a first phase) from 0.7 to 0.56.
Additional example functions are briefly discussed in Section 7.
In the presence of a context ontology which connects the
context attributes with each other in an appropriate manner,
some reasoning can be made even if assigning the boolean
predicate pk to the context parameter currently under
inspection is not possible. The flexibility enables utilising
context attributes which do not exactly match the query, but
are “close enough” to it [
Suppose that the current network is not pre-evaluated
with regard to its impact on trustworthiness. However, as
its neighbors in the ontology are networks which have
preevaluated trustworthiness values. By using these values as
well as their “semantic distance” to the current network,
the trustworthiness can be estimated. The Object Match
algorithm, outlined in [
Wireless
Wireline
Network
Circuit Switched
GSM
G dec1.1(v) Packet
Switched Bluetooth
UMTS B1
B2 inc/dec? inc1.2(v)
U inc1.5(v)
Furthermore, the networks are organized in a network ontology, as depicted in Figure 3. Say that the current network B1 is a bluetooth network, of which there are no pre-evaluated trustworthiness values. However, there exist trustworthiness values of three other networks, which are as follows: • B2, a bluetooth network which would entail inc1.2(v), semantic distance to B1 ≈ 0.67 • U, a UMTS network which would entail inc1.5(v), semantic distance to B1 ≈ 0.43 • G, a GSM network which would entail dec1.1(v), semantic distance to B1 = 0.25
Considering these networks as equal, that is, without taking into account the semantic distance, would entail tuning the trust with 1.2 1.√5v1.1 ≈ inc1.64(v). Instead, if the semantic distance is incorporated, the calculation goes as follows: 1.2∗0.67 1.5∗0.4√3v(1.1∗0.25) ≈ inc1.89(v). In other words, the trust is increased more, since the kind of network causing the decrement (G) is semantically further away from the current node, and therefore considered less important. This example showed how considering the semantic distance can amplify the increment/decrement effect.
Note that in this example ontology the concepts are organized based on the properties of a network, such as whether the network in question is circuit switched or packet switched. Typically, other details concerning the network, for example its provider, are more important with regard to trust evaluation than its implementation details. That is why the weights assigned for the semantic distance in an ontology such as the one presented in this section should be relatively small. In our approach, the trust related to the the network provider can be considered in terms of reputation and recommendations, both of which will be considered later on in the paper. This section shows how context can be used to complement traditional aspects influencing trust formation. More specifically, we consider reputation and recommendations. Before we can do that, however, we must address the notion of time-line, since it is needed for coping with the historydependent nature of these topics.
We assume a time line for distinguishing between different instances where we apply the trust evaluation procedure. We can generally assume that Time is the set of natural numbers, where 0 ∈ Time is the initial time. With the concept of time we also implicitly assume that the result of a trust evaluation process varies over time. Note that such variation is due to the fact that the input data used by the trust evaluation function changes over time, while the way of reasoning about trust does not. In certain scenarios, even the mechanism of reasoning about trust may change in time, but dealing with this concept of second order dynamism in trust is outside the scope in this paper.
Observation 1. In this case the use of time is part of the operational semantics we are giving to our trust evaluation functions. It must not be confused with contextual information “time” that may be used as an input, that is, as part of Context.
If we assume that the trust evaluation happens at time i, we need to bind the time also with the input that is used by the evaluation procedure. Then we indicate with Attributesi the set of data in the instance of a scenario of trust at evaluation time i
i
We indicate with Qσ ∈ Qσ the vector of quality attributes that are available for the Trustor at time i. Note that Qσ v Attributesi. We work under the simplified assumpi tion that Q0σ = Qiσ, for all i > 0. This means that the quality attributes do not change along a time line of trust evaluation, unless the Trustee itself is changed. In a more general situation the quality attributes may depend on time. For example, a curriculum vitae of a person may be updated. This assumption allows us to concentrate on contextual aspects and problems. However, should there be a need, some of the techniques here restricted to context attributes, i can be applied also to quality attributes. We write Cσ ∈ Cσ to indicate the state of context at time i.
In reference to Example 1 and in case of trust scope “Is that really Bob who cheers me?”) quality attributes and context attributes at a certain time i are represented by the following tuples:
h+300586, MalisFone, NY , Attributesi = { Dublin, “hates jokes”, true, falsei } Qiσ = {h+390586, MalisFonei} Cσi = {hNY , Dublin, “hates jokes”, true, falsei} (4) (5)
As a matter of notation, we indicate with ctrustiS,σ(Q) the evaluation of trust performed at time i ≥ 0:
ctrustiS,σ(Q) , ctrustS,σ(Q, Cσi)
The implementation of this function does not change with respect to the one given in the previous section. We only need to bind the evaluation with time i, as follows: ctrustiS,σ(Q) , Ci ⊗ trustiS,σ(Q) here trustiS,σ(Q) represents the result of a context-independent trust evaluation function, applied at time i. Note that although we have assumed Q to remain constant, trustiS,σ(Q) may provide different results along the time. For example, the recommendations may change in the course of time due to the recommenders’ new experiences of dealing with the trustee. 4.3.2
The next concept we need to consider in trust evaluation
is reputation [
ctrustS : Quality × Context × [
ctrustiS (Q) , ctrustS(Q, Ci, ri)
where ri is an appropriate reputation value, available at time
i. Here the term “appropriate” means that when we look for
a past experience performed in a context that is compatible
with the one considered at the present time i [
We formalize compatibility among two context values c, c0 of type ak, written c ∼ c0, as the following binary predicate: c ∼ c 0 ⇐⇒
pk(c) == pk(c0) Here == means evaluating as the same, that is, c ∼ c0 if and only if the predicate pk( ) returns the same value when applied both to c and c0.
When dealing with an array of context data, we need to calculate their “grade of compatibility”, that is, their closeness in terms of the compatibility function ∼. To this aim we propose the following function d( ): d(C, C0) , m i=k
0 wk · (ck ∼ ck)
W where W = km=1 wk. Function (5) measures the weighted and normalized grade of affinity with regard to the predicates we have defined over context type, of two array of context data.
Our selection of a compatible past experience is based on the quest for the experience performed in the past time M , such that the grade of compatibility with the present context Ci is maximal. In case there exists more than one past experience with this maximum value, the most recent one is chosen. Formally, M is such that: • d(Ci, CM ) = maxik=1{d(Ci, Ck)}
0 0 • 6 ∃ M > M such that d(Ci, CM ) = d(Ci, CM ) As a conclusion, we are now able to specify the term ri, of “appropriate” reputation at time i, as the trust evaluation result of the Trustor S, for scope σ, performed in the most recent past where the context has maximum degree of compatibility with the present one. Formally:
ri = ctrustSM,σ(C) where M is calculated as explained above. 4.3.3
The final concept we need to consider in trust evaluation is recommendation. A recommendation is a kind of communicated reputation:
dation is an attempt at communicating a party’s reputation from one community to another. The parties can be for example human users, devices, software components, or combinations of these.
Despite the intuitive definition given above, there exists
no consensus on the nature of recommendation. In the
literature there are two different complementary trends: either a
recommendation is or is not a trust value. In the first case,
a recommendation is the trust value assessed by the
recommender about the Trustee. This option is, for instance,
used by Abdul-Rahman and Hailes [
In order to consider the recommendation, the Trustor has
to share with its recommender at least a common vision of
trust. This statement is implicitly included in Definition 3,
where the word “attempt” denotes that the source and
target of a recommendation may be incompatible if they belong
to different communities [
Note 3. We assume a recommendation to be a trust value.
The version of the trust evaluation function that considers also recommendations is as follows:
ctrustS : Quality × Context × [
ctrustiS (Q) , ctrustS(Q, Ci, ri, Ri) where ri is an appropriate reputation value available at time i, and where Ri is an appropriate set of recommendations available at time i. Again, to obtain “appropriate” reputations, we resort to the context data. Reputations can be filtered by considering the context compatibility. Let us assume to have a certain acceptance grade of compatibility we require in order to consider a reputation to be significant. Here we can use another set of weights, different from the weights we considered when tuning trust. From the set of recommendations R we prune out those which cannot reach the required grade of compatibility.
Let us assume R = {(ru, Cu)| u ∈ S} to be the set of recommendations from a set R of recommenders. Each recommendation (r, C) carries the context C it relates to. The appropriate set of recommendations we consider in our trustS,σ is the filtered set Ri = {(r0, C0) ∈ R| d(C0, Ci) > T }, where T represents a compatibility threshold decided by the Trustor. Note that here we are not interested in coping with the set of recommendations and reputations according to the trust management practice, because this problem is assumed to be solved by the function trustS,σ we use in the first stage of the evaluation. 5.
A game application running on a gaming device is composed by a game manager component (GM) and by one game scenario component (GS). Figure 4 depicts the scenario of a game application composed of these two components. A new game may be composed by downloading new components. Game managers and game scenarios are available on the Internet and they are supplied by different software providers on their Web sites.
Before downloading and installing a new component, the game application checks the hardware and software characteristics of the new game, to evaluate whether the new composition is trustworthy enough or not when running on the current device. This evaluation can include considering both the quality attributes, and the contextual information describing the current situation. It might be the case that the new component is available by different providers or by different mirror sites of one provider. These sites can have varying context attributes such as the current availability. In addition, the sites can have different versions of the needed component(s), which have impact on the interoperability: For example, the GS Dungeon v103 presupposes GM v112 or higher, whereas GS Dungeon v102 can manage with GM v070 or higher. Furthermore, the different component versions can have varying requirements on the device hard- and software.
We now further concretize the running example by assigning actual values to the context attributes appearing in it. More specifically, we extract two trust scopes (σ1 and σ2) for the user/trustor (S). The scopes differ with regard to context. σ1 has the user on the bus, having access only to a heavily loaded wireless network, and using a small device with limited capabilities (both estimated and actual). σ2, in contrast, has the user at home, having a broadband access to the Internet, and using a PC with lots of available memory and CPU time.
Furthermore, there are two versions of the Game Scenario components available. Both versions perform the same functionalities and are in that sense applicable in both trust scopes. However, they differ in respects that can be significant in terms of the trust scopes σ1 and σ2. Suppose that Game Scenario component version A is large in size, requires ctx trusts ctx composes
provided by ctx
ctx interdependencies composes ctx ctx provided by Quality Attributes Context Attributes
Player / Game Application
trustor - device profile - user profile - ?
Composition a lot of memory and CPU time, its provider has a good reputation based on S’s past experience, and the provider is also recommended by a good friend of S. Component version B, in turn, is small in size, requires little memory and CPU. However, its provider is unknown to S and therefore has no reputation history nor recommendations available to S. Say that the initial trust values for the respective components are tA : 0.6 and tB : 0.5 (tA is a little higher, because A’s provider is known by S to have a good reputation and is also recommended to S).
Based on the trust scopes σ1 and σ2, S’s device can perform the following context-aware trust calculations to the available component versions. In the following we use the definition of inc and dec given in Example 4: • Trust scope σ1 • Trust scope σ2 – Game Scenario component version A ∗ Large in size: dec2(t) ∗ Requires a lot of memory: dec1.5(t) ∗ Requires a lot of CPU time: dec1.5(t) ∗ Good reputation: inc1.25(t) ∗ Recommended by a friend: inc1.25(t) – Game Scenario component version B ∗ Small in size: inc2(t) ∗ Requires little memory: inc1.5(t) ∗ Requires little CPU time: inc1.5(t) – Game Scenario component version A ∗ Large in size: dec1.1(t) ∗ Requires a lot of memory: dec1.1(t) ∗ Requires a lot of CPU time: dec1.1(t) ∗ Good reputation: inc1.5(t) ∗ Recommended by a friend: inc1.5(t) – Game Scenario component version B ∗ Small in size: inc1.1(t) ∗ Requires little memory: inc1.1(t) ∗ Requires little CPU time: inc1.1(t)
Based on this information, we can calculate the contextaware trust value. First, for trust scope σ1 and software version A, we can calculate according to the following steps, starting from trust value t0, which is 0.6:
So the final value for Game Scenario component A is 0.23. In the same way, component version B in trust scope σ1 receives the value 0.89. In trust scope σ2, instead, A receives the value 0.74 and B the value 0.59. In other words, in trust scope σ1 the component version B is valued over component version A, because it better fits the contextual requirements. In scope σ2, the valuations for the components are closer to each other, but this time the component version A is valued over B.
This example clearly verifies the hypothesis presented
earlier, namely that the weights assigned to the context
attributes should be quite small. Here the smallest value
assigned for w was 1.1 and the largest 2, and still the
trustworthiness values varied between 0.23 and 0.89, therefore
consuming a large portion of the scale [
Another way to draw a line between trust scopes would be to consider the game scenario in one scope, and the whole composite game in another. This way the following situations could be extracted: Trust scope focusing on the game scenario: The game application is interested in evaluating the trustworthiness of a single piece of software representing the new game scenario. Quality attributes are the names of the component and the provider, version of the component, reputation of the software provider, recommendations from friends on the provider. Context attributes are the actual size of the component being downloaded, the current download speed of the site from where the software is downloaded, the throughput of the network over which the software is going to be downloaded, and the also the hardware characteristics of the game device (its available RAM memory, and the current CPU load).
Trust scope focusing on the composite game: The game application is evaluating the trustworthiness of the composite game as a whole. Quality attributes are all the quality attributes of the components participating in the composition, as well as their providers’ quality attributes. In addition, the estimated average CPU and memory usage of GS and GM together and the interdependencies between the versions of the GS and GM components are considered as quality attributes in this example. Context attributes, in turn, are the actual size and resource (CPU and memory) consumption of the downloaded and composed components, and the current hardware characteristics of the game device.
Situational details can have impact on how trustworthy a trustor considers the trustee. These situational details can characterize the trustor, the trustee, and the environment around them. Inspired by this observation, we described and formalized functions for context-aware trustworthiness evaluation. Such functions take into account the individual context attributes, and assign them with values influencing the trustworthiness evaluation process. Depending on the importance of a given context attribute, determined by what we call a trust scope, weights can be applied to amplify or weaken the influence.
Trustee’s reputation, that is, the trustor’s past observations of the trustee, can further impact the trustworthiness evaluation. We apply the notion of context also to the reputations by emphasizing more the observations that have taken place under similar conditions as where the trustor currently is. Finally, the trustworthiness evaluation can include recommendations from others. There are two relationships between recommendations and context. First, as was the case with reputation, the contextual details at the time when the recommendation was made can be considered and compared with the trustor’s current context. Note that considering this is not as straightforward as was the case with reputation, since recommendations come from others, not from the trustor. Secondly, the recommendation content can be context-dependent.
We concretized our formalizations with an example concerning a game application, which is composed out of downloaded components. 7.
Our future work includes further refining the trust functions, as well as testing them with real applications. We now present some initial ideas for additional examples of adjusting functions. The first example is an extension of Example 4. We use the same class of functions to define different increment decrement adjustments. The alternative definitions for the positive and the negative adjustment for a weighting w ∈ [1, N ] are defined as follows: inc and dec are well behaving according to Definition 2; moreover, they enjoy the same properties 4. and 5. stated in Example 4.
Another example of families of adjusting functions comes
from considering a beams of functions generated by one
single “kind” of curve. In this case the weightings are used as
amplification/de-amplification factors. For example, if we
choose Weights = [
If we choose w ∈ Weights = [0, √2], another family of
functions can be defined as follows:
restricted on the [
We envisage that working with running examples helps us to extract the truly relevant context attributes, as well as give us guidelines on the weights to be assigned to them. In addition, visualizing the trustworthiness evaluation from the end user’s perspective should receive some attention. The user should be aware of the characteristics and interrelations of the factors which compose the trustworthiness.
The authors have been supported by the European ITEA project Trust4All. The authors would like to thank the anonymous reviewers for their useful suggestions that brought to an improvement of the paper. S. Toivonen thanks H. Helin for his comments on the context ontology. G. Lenzini thanks A. Tokmakoff for his comments on the whole paper, and I. De la Fuente for her hints on alternative functions.