Rachid Saadi

Mohammad Ashiqur Rahaman

Valerie Issarny

Alessandra Toninelli

Composing Trust Models towards Interoperable Trust Management ⋆

Computational trust is a central paradigm in today's Internet as our modern society is increasingly relying upon online transactions and social networks. This is indeed leading to the introduction of various trust management systems and associated trust models, which are customized according to their target applications. However, the heterogeneity of trust models prevents exploiting the trust knowledge acquired in one context in another context although this would be beneficial for the digital, ever-connected environment. This is such an issue that this paper addresses by introducing an approach to achieve interoperability between heterogeneous trust management systems. Specifically, we define a trust meta-model that allows the rigorous specification of trust models as well as their composition. The resulting composite trust models enable heterogeneous trust management systems to interoperate transparently through mediators.

Introduction

With people getting increasingly connected virtually, trust management is becoming a central element of today's open distributed digital environment. However, existing trust management systems are customized according to specific application domains, hence implementing different trust models. As a result, it is nearly impossible to exploit established trust relations across systems. While a trust relation holding in one system does not systematically translate into a similar relation in another system, it is still a valuable knowledge, especially if the systems relate to the same application domains (e.g., e-commerce, social network). This is such an issue that we are addressing in this paper.

To the best of our knowledge, little work investigates interoperability between heterogeneous trust models. The closest to our concern is the work of [START_REF] Suryanarayana | PACE: an architectural style for trust management in decentralized applications[END_REF], which describes a trust management architecture that enables dealing with a variety of trust metrics and mapping between them. However, the architecture deals with the composition at the level of trust values and do not account for the variety of trust models. In particular, one may want to differentiate between direct trust values and reputation-based ones when composing them. In general, what is needed is a way to formalize heterogeneous trust models and their composition. Such a concern is in particular addressed in [START_REF] Kaffille | Engineering Autonomous Trust-Management Requirements for Software Agents: Requirements and Concepts[END_REF][START_REF] Vercouter | An experience on reputation models interoperability based on a functional ontology[END_REF], which introduce trust meta-models based on state of the art trust management systems. Nevertheless, little detail is given and the paper does not describe how to exploit the meta-model for composing heterogeneous trust models and this achieve interoperability. Dealing with the heterogeneity of trust models is also investigated in [START_REF] Fullam | A specification of the Agent Reputation and Trust (ART) testbed[END_REF][START_REF] Suryanarayana | SIFT: A Simulation Framework for Analyzing Decentralized Reputation-based Trust Models[END_REF]. However, the study is for the sake of comparison and further concentrates on reputation-based models. Summarizing, while the literature is increasingly rich of trust models, dealing with their composition remains a challenge.

Towards overcoming the interoperability challenge faced by trust management systems, this paper introduces a comprehensive approach based on the definition of a reference trust meta-model. Specifically, based on the state of the art (Section 2), the trust meta-model formalizes the core entities of trust management systems, i.e., trust roles, metrics, relations and operations (Section 3). The trust meta-model then serves specifying the composition of trust models in terms of mapping rules between roles, from which trust mediators are synthesized (Section 4). Trust mediators transparently implement mapping between respective trust relations and operations of the composed models. While this paper introduces the composition approach from a theoretical perspective, we are currently implementing it as part of the CONNECT project 1 on next generation middleware for interoperability in complex systems of systems (Section 5).

Trust Model Definition

As in particular defined in [START_REF] Grandison | A survey of trust in internet applications[END_REF]: i.e., A trustor trusts a trustee with regard to its ability to perform a specific action or to provide a specific service. Hence, any trust model may basically be defined in terms of the three following elements:

1. Trust roles abstract the representative behaviors of stakeholders from the standpoint of trust management, in a way similar to role-based access control model [START_REF] Ferraiolo | Proposed nist standard for role-based access control[END_REF]. 2. Trust relations serve specifying trust relationships holding among stakeholders, and 3. Trust assessment define how to compute the trustworthiness of stakeholders.

We further define trust relations and assessment below.

Trust relations

We identify two types of trust relationships, i.e., direct and indirect, depending on the number of stakeholders that are involved to build the trust relationship: Direct trust: A direct trust relationship represents a trust assertion of a subject (i.e., trustor) about another subject (i.e., trustee). It is thus a one-to-one trust relation (denoted 1:1)) since it defines a direct link from a trustor (1) to a trustee [START_REF] Abdul-Rahman | A distributed trust model[END_REF]. One-to-one trust relations are maintained locally by trustors and represent the trustors' personal opinion regarding their trustees [START_REF] Kautz | Referral Web: combining social networks and collaborative filtering[END_REF]. For example, a one-to-one relation may represent a belonging relationship (e.g., employees trust their company), a social relationship (e.g., trust among friends), or a profit-driven relationship (e.g., a person trusts a trader for managing its portfolio).

Recommendation-based trust:

As opposed to a direct trust relationship, a recommendation-based relationship represents a subject's trustworthiness based on a third party's opinion. This can be either (i) transitive-based or (ii) reputation-based.

Transitive-based trust relations are one-to-many (denoted 1:N). Such a relation enables a trustor (1) to indirectly assess the trustworthiness of an unknown trustee through the recommendations of a group of trustees(N). Hence, the computation of 1:N relations results from the concatenation and/or aggregation of many 1:1 trust relations. The concatenation of 1:1 trust relations usually represents a transitive trust path, where each entity can trust unknown entities based on the recommendation of its trustees. Thus, this relationship is built by composing personal trust relations [START_REF] Abdul-Rahman | A distributed trust model[END_REF][START_REF] Saadi | Establishing trust beliefs based on a uniform disposition to trust[END_REF]. Furthermore, in the case where there exist several trust paths that link the trustor to the recommended trustee, the aggregation can be used to aggregate all given trust recommendations [START_REF] Jøsang | Semantic constraints for trust transitivity[END_REF].

Reputation-based trust relations are many-to-one (denoted N:1) and result from the aggregation of many personal trust relationships having the same trustee. Hence, the N:1 trust relation allows the definition of the reputation of each trustee within the system. Reputation systems may then be divided into two categories depending on whether they are (i) Centralized or (ii) Distributed. With the former, the reputation of each participant is collected and made publicly available at a centralized server (e.g., eBay, Amazon, Google, [START_REF] Nurmi | A bayesian framework for online reputation systems[END_REF]). With the latter, reputation is spread throughout the network and each networked entity is responsible to manage the reputation of other entities (e.g., [START_REF] Jøsang | Semantic constraints for trust transitivity[END_REF][START_REF] Zhou | Gossiptrust for fast reputation aggregation in peer-to-peer networks[END_REF]).

Trust Assessment

Trust assessment, i.e., assigning values to trust relationships, relies on the definition of: (i) trust metrics characterizing how trust is measured and (ii) operations for composing trust values.

Trust metrics: Different metrics have been defined to measure trust. This is due to the fact that one trust metric may be more or less suitable to a certain context. Thus, there is no widely recognized way to assign trust values. Some systems assume only binary values. In [START_REF] Zimmermann | The official PGP user's guide[END_REF], trust is quantified by qualitative labels (e.g., high trust, low trust etc.). Other solutions represent trust by a numerical range. For instance, this range can be defined by the interval [-1..1] (e.g., [START_REF] Marsh | Formalising Trust as a Computational Concept[END_REF]), [0..n] (e.g., [START_REF] Abdul-Rahman | A distributed trust model[END_REF][START_REF] Saadi | Establishing trust beliefs based on a uniform disposition to trust[END_REF]) or [0..1] (e.g., [START_REF] Jøsang | Semantic constraints for trust transitivity[END_REF]). A trust value can also be described in many dimensions, such as: (Belief, Disbelief, Uncertainty) [START_REF] Jøsang | Semantic constraints for trust transitivity[END_REF].

In addition, several definitions exist about the semantics of trust metrics. This is for instance illustrated by the meaning of zero and negative values. For example, zero may indicate lack of trust (but not distrust), lack of information, or deep distrust. Negative values, if allowed, usually indicate distrust, but there is a doubt whether distrust is simply trust with a negative sign, or a phenomenon of its own.

Trust operations: We define four main operations for the computation of trust values associated with the trust relations given in Section 2.1 (see table 1): bootstrapping, refreshing, aggregation, and concatenation.

The bootstrapping operation initializes the a priori values of 1:1 and N:1 trust relations. Trust bootstrapping consists of deciding how to initialize trust relations in order to efficiently start the system and also allow newcomers to join the running system Bootstrapping Aggregation Concatenation Refreshing One-to-One (1:1) X X One-to-Many (1:N) X X Many-to-One (N:1) X X X Table 1: Trust assessment operations [START_REF] Quercia | TRULLO-local trust bootstrapping for ubiquitous devices[END_REF]. Most existing solutions simply initialize trust relation with a fixed value (e.g., 0.5 [START_REF] Haque | An omnipresent formal trust model (FTM) for pervasive computing environment[END_REF], a uniform Beta probabilistic distribution [START_REF] Jsang | The beta reputation system[END_REF]). Other approaches include among others: initializing existing trust relations according to given peers recommendations [START_REF] Rahman | Supporting trust in virtual communities[END_REF]; applying a sorting mechanism instead of assigning fixed values [START_REF] Saadi | Establishing trust beliefs based on a uniform disposition to trust[END_REF]; and assessing trustees into different contexts (e.g., fixing a car, babysitting, etc.) and then inferring unknown trust values from known ones of similar or correlate contexts [START_REF] Quercia | TRULLO-local trust bootstrapping for ubiquitous devices[END_REF][START_REF] Ahamed | CCTB: Context correlation for trust bootstrapping in pervasive environment[END_REF].

All the solutions dealing with 1:N trust assessment mainly define the concatenation and the aggregation operations, in order to concatenate and to aggregate trust recommendations by computing the average [START_REF] Saadi | Establishing trust beliefs based on a uniform disposition to trust[END_REF], the minimum or the product [START_REF] Abdul-Rahman | A distributed trust model[END_REF] of all the intermediary trust values. In the case of Web service composition, some approaches (e.g., [START_REF] Paradesi | Integrating Behavioral Trust in Web Service Compositions[END_REF]) evaluate the recommendation for each service by evaluating its provider, whereas other approaches (e.g., [START_REF] Kim | Trust Type based Semantic Web Services Assessment and Selection[END_REF]) evaluate the service itself in terms of its previous invocations, performance, reliability, etc. Then, trust is composed and/or aggregated according to the service composition flow (sequence, concurrent, conditional and loop).

Aggregation operations such as Bayesian probability (e.g., [START_REF] Mui | Ratings in distributed systems: A bayesian approach[END_REF]) are often used for the assessment of N:1 (reputation-based) trust relations. Trust values are then represented by a beta Probability Density Function [START_REF] Jsang | The beta reputation system[END_REF], which takes binary ratings as inputs (i.e., positive or negative) from all trustors. Thus, the reputation score is refreshed from the previous reputation score and the new rating [START_REF] Nurmi | A bayesian framework for online reputation systems[END_REF]. The advantage of Bayesian systems is that they provide a theoretically sound basis for computing reputation scores and can also be used to predict future behavior.

Finally, refreshing operations are mainly trigged by trustors to refresh 1:1 and N:1 trust relations, after receiving stakeholders' feedback.

Trust Meta-Model

Following the above, we formally define the trust meta-model as: T M =< R, L, M, O >, where R, L, M and O are the finite sets of trust roles, relations, metrics and operations.

Trust Meta-Model Formalization

As detailed below, each set of T M consists of elements where an element can have a simple value (e.g., string) or a complex value. A complex value of an element is either an exclusive combination of values (only one of the values) ∨v (e.g., v 1 ∨ v 2 ∨ v 3 ) or an inclusive combination of values (one or more elements) ✸v (e.g.,

v 1 ∧ v 2 ∧ (v 3 ∨ v 4 )) of elements.
Role set R: The role set contains all the roles r played by the stakeholders of the trust model. A role r of R is simply denoted by its name:

r =< name:string > (1)
where: the attribute name of type string represents the name or the identifier of the role 2 . In our meta-model, a stakeholder is represented as a Subject s, playing a number of roles, r 1 , r 2 ...and r n , which is denoted as s ⊲ r 1 , r 2 ...r n .

Metric set M:

The metric set describes all the trust metrics that can be manipulated by the trust model. A metric is formally denoted as a pair:

m =< name:string, type:string > (2)
where: name and type are strings and respectively define the name and the type. The type can be a simple type (e.g., probability([0..1]), label(good, bad), etc.) or a composition of simples ones (e.g., tuple (believe([0..1]), uncertainty([0..1])).

Relation set L: A relation set L contains all the trust relations that are specified by the trust model. We specifically denote a trust relation as a tuple:

l =< name:string, ctx:string, type:string, trustor:∨r i , trustee:∨r j , value:

m k > with r i , r j ∈ R and m k ∈ M (3)
where: (i) name identifies the relation; (ii) ctx describes the context of the relationship in terms of the application domain (e.g., selling); (iii) type represents the cardinality of the relation and is denoted by one of the following arities: 1:1, 1:N or N:1; (iv) trustor and trustee are roles where a trust relation relates a trustor role with a trustee role; (v) value is an element from the metric set and thus reflects the trust measure given by the trustor to the trustee through this relation. In the above, note that different trustors can establish the same type of relationship with different trustees. Thus, as a trust relation is binary and between a trustor role and a trustee, the exclusive combination of roles (e.g., r 1 ∨ r 2 ∨ r 3 ) is used to describe these elements Operation set O: The operation set specifies the operations that can be performed over relations by a subject, either to assess the trustworthiness of another subject or to communicate (i.e., request/response) trust values associated with desired subjects (see Figure 1). As defined in Section 2, trust assessment relies on the bootstrapping, aggregation, concatenation and refreshing operations, whereas, the communication of a trust value relies on the request and response operations. An operation is formally denoted as:

o =< name:string, host:∨r i , type:string, input:✸l j , output:✸l k , via:✸l n , call:✸o > Where

r i ∈ R, l j , l k , l n , ∈ L, and o ∈ O (4)
where: (i) name identifies uniquely an operation; (ii) host instantiates the role(s) that hosts and executes the operation; (iii) type defines the operation (i.e., request, response, bootstrapping, aggregation, concatenation, and refreshing); (iv) input gives the trust relations that are required to perform an assessment operation or are received by a communication operation; (v) output gives the trust relations that are provided, as the result of either an assessment operation or a communication; (vi) via specifies the trust relationship that should hold with the role with which the communication happens, while its value is self in the case of assessment; and (vii) call denotes a continuation (see Figure 1). Note that input and output are complex values, i.e., logical conjunction of one or more relations.

Example

We illustrate the expressiveness of our trust meta-model by considering the specification of representative trust models associated with two selling transaction scenarios. Precisely, we introduce the specification of an eBay like centralized trust model (see Table 2) and of a fully distributed one (see Table 3). Both trust models aim at assessing transaction behaviors of sellers. Figure 2 depicts the trust graphs of both models; the centralized trust model, i.e., T M C (on the left in the figure), is defined with three roles, i.e., r S =Seller, r B =Buyer, and r M =M anager, whereas the distributed trust model, i.e., T M D (on the right in the figure), is defined with the unique role r C =Customer, which can be either a seller or a buyer.

Focusing on the specification of T M C in Table 2 , the roles Buyer and Seller have a direct trust relationship (i.e., l 0 ) with the M anager that manages the sellers' reputation (i.e., l 3 ). Thus, any Buyer can: (i) query the M anager about the reputation of a Seller (i.e., l 1 ), and (ii) provide the M anager with its feedback (i.e., l 2 ) after a selling transaction. Hence, a Buyer has to perform a request operation (i.e., o 4 ) to get the reputation of the seller, so that it can compute locally the trustworthiness of the seller (i.e., o 1 ). After a transaction is completed, a Buyer can provide its feedback to the M anager by triggering a request operation (i.e., o 8 ). The M anager in turn processes (i.e., o 9 ) this feedback request to compute and refresh the reputation of the concerned Seller (i.e., o 3 ).

Role set R r S = <name="Buyer"> r B = <name="Seller"> r M = <name="Manager"> Metric set M m0 = <name="Reputation", type="Probability"> m1 = <name="Recommendation", type="Probability"> m2 = <name="Rate", type= "Five Semantic labels"> Relation set L l0 = < name="ServerRecommendation", ctx= "Selling", type=1:1, trustor=(r S ∨ r B ), trustee=r M , metric=m1> l1 = < name= "SellerTrustworthiness", ctx= "Selling", type=1:N, trustor=r S , trustee=r B , metric=m1 > l2 = < name="BuyerFeedback", ctx= "Selling", type=1:1, trustor=r S , trustee=r B , metric=m2 > l3 = < name="SellerReputation", ctx= "Selling", type=N:1, trustor=r B , trustee=r M , metric=m0 > Operation set O o0 = <name="getManagerTrustworthiness", host=(r S ∨ r B ), type=request, in=l0, out=l0 > o1 = <name="assessSellerTrustworthiness", host=r S , type=concatenation, in=(l0 ∧ l3) , out=l1 > o2 = <name= "assessBuyerFeedback", host=r S , type=update, in=l2, out=l2, call=o8 > o3 = <name="setSellerReputation", host=r M , type=aggregation, in=l2, out=l3 > o4 = <name="getSellerTrustworthiness", host=r S ,type=request, via=l0, out=l1, in=l3, call=o1 > o5 = <name="getSellerReputation", host=r M ,type=response, in=l3, out=l3 > o6 = <name="sendSellerReputation", host=r M ,type=response, via=l0, in=l1, out=l3, call=o5 > o7 = <name="getBuyerFeedback", host=r S ,type=request, in=l2, out=l2 > o8 = <name="sendBuyerFeedback", host=r S ,type=request, via=l0, out=l2 > o9 = <name="updateSellerReputation", host=r M ,type=response, via=l0, in=l2, call= o3 >

Composing Trust Models

Given the specification of trust models, their composition relies on mapping their respective roles so that: (i) the trustworthiness of the various roles can be assessed, (ii) existing trust relations can be queried, and (iii) trust feedbacks can be propagated transparently from one trust model to another. Further, the existing trust relations and operations are extended to relate roles from the composed models, and new assessment operations are required to map trust relations from one model to another. Finally, the resulting mapping and extensions are implemented through mediation [START_REF] Wiederhold | Mediators in the architecture of future information systems[END_REF] so as to make composition transparent to existing systems, which leads us to introduce the corresponding mediator role.

Formally, the composition, denoted , of two trust models T M x and T M y , which introduces the trust model T M xy , is defined as follows:

T M xy = T M x Ψ xy T M y = < R x , M x , L x , O x > Ψ xy < R y , M y , L y , O y > = R xy = R x ∪ R y ∪ µR xy M xy = M x ∪ M y L xy = L + x ∪ L + y O xy = O + x ∪ O + y ∪ µO xy (5)
where:

-Ψ xy is the set of mapping rules over roles that enables the composition of T M x and T M y ; -µR xy and µO xy are the new sets of mediator roles and mediation operations, respectively; -(L + x and L + y ) and (O + x and O + y ) are the extended relations and operations, respectively.

In the following, we elaborate on the mediation process to generate the sets of mediator roles, and mediation operations (i.e., µR xy , and µO xy ) and extended relations and operations (i.e., L + The mapping of roles from 2 distinct models is explicitly defined through a set of mapping rules defined as follows:

x , O + x L + y , O + y ).
ψ st k = (r s : T M s ) ⊙ (r d : T M t ) (6)
where, ⊙ is asymmetric and maps the source role r s of T M s to the target role r t of T M t . We further refine ⊙ into two mapping operators:

-The See operator, noted "≻", simply associates a source role with a target role so as to define that the role r t of T M t is seen as r s in T M t . For instance, in the -The M imic operator, noted "✶ µr ", specifies that r s should be able to request trust values of T M t as if it was r t . This is practically achieved through the mediator role µr that translates r s requests into r t requests. For instance, the rule (r C : T M D ) ✶ µr (r S : T M A ) means that any customer is able to request trust values as if it was a buyer in the centralized trust management system, thanks to the mediation achieved by µr.

The computation of the composition of trust models T M x and T M y is detailed in Algorithm 1. The algorithm iterates on mapping rules for each of which it invokes Relation M ediation (see line 5) so as to extend relation sets, namely: L +

x and L + y , (see Section 4.2). Then, according to the definition of M imic rules, mediator roles (i.e., µr) are added to the set of mediator roles (see lines 7-8), and Operation M ediation is invoked so as to perform mediation over the communication operations (see line 9) of the composed trust models (see Section 4.3). The aim of relation mediation is to extend the trust relations of the original models to roles of the other. More precisely, for any trust relation: l =< name:string, ctx:string, type:string, trustor:∨r i , trustee:∨r j , metric:m k > of L x and L y of the composed models T M x and T M y , its trustee and trustor elements are possibly extended to account for mapping between roles.

Relation Mediation

Algorithm 2 details the corresponding extension where: (i) function e ❂ v returns true if v is in e, and (ii) e vi ←v j replaces the value v i in e with the value v j . As shown in the algorithm, the extension of trust relations depends on the type of the mapping operator. The See operator defines which local trustee (target role r t ) corresponds to the source role (r s ). Therefore, all the relations l i (from the source trust model) that consider the source role as a trustee (l i .trustee ❂ r t ) are extended with the target role (see lines 2-5). The M imic operator introduces a new mediator role that plays trustees of the source role as a trustee in the source trust model, and plays the target role as a trustor in the target trust model. This leads to the corresponding extension of the trust models relations of L x (see lines 7-9) and L y (see lines [START_REF] Kautz | Referral Web: combining social networks and collaborative filtering[END_REF][START_REF] Kim | Trust Type based Semantic Web Services Assessment and Selection[END_REF][START_REF] Marsh | Formalising Trust as a Computational Concept[END_REF]. 4 details the associated trust roles, metric and relations where new mediator role and extended relations are highlighted in grey. The composition relies on two mapping rules that allow a Customer of T M D to assess a seller of T M C . The rule using the See operator represents how sellers are perceived in T M D , while the second rule using the M imic operator introduces a mediator role that enables Costumers to request T M C as Buyers. Thus, "r B : T M C ≻ r C : T M D " leads to extend the trustee element of l a and l b by replacing r C with (r C ∨ r B ). The mapping rule "r C : T M D ✶ µr r S : T M C " extends the relations that sink into the role Customer (i.e., l a and l b ) with the mediator role µr. In addition, all the relations that originate from the role Buyer (i.e., l 0 , l 1 and l 2 ) also originate from the mediator role µr.

Roles set R r S = <name="Buyer"> r B = <name="Seller"> r M = <name="Manager"> r C = <name="Customer "> µr = <name="Customer Mediator"> Metric set M m0 = <name="Reputation", type="Probability"> m1 = <name="Recommendation", type="Probability"> m2 = <name="Rate", type= "Five Semantic labels"> ma = <name="Recommendation", type="Probability"> Relation set L l0 = < name="ServerRecommendation", ctx= "Selling", type=1:1, trustor=((r S ∨ µr) ∨ r B ), trustee=r M , metric=m1> l1 = < name= "SellerTrustworthiness", ctx= "Selling", type=1:N, trustor=(r S ∨ µr), trustee=r B , metric=m1 > l2 = < name="BuyerFeedback", ctx= "Selling", type=1:1, trustor=(r S ∨ µr), trustee=r B , metric=m2 > l3 = < name="SellerReputation", ctx= "Selling", type=N:1, trustor=r B , trustee=r M , metric=m0 > la = < name="DirectCustomer Trustworthiness", ctx= "auction", type=1:1, trustor=r C , trustee=((r C ∨ r B ) ∨ µr), metric=ma > l b = < name="TransitiveCustomer Trustworthiness", ctx= "auction", type=1:N, trustor=r C , trustee=((r C ∨r B )∨µr), metric=ma > Table 4: T M C and T M D Composition: Role, Metric, and Relation sets

Operation Mediation

Operation mediation serves translating request operations from one model into requests in the other model, according to the mappings between roles defined using the Mimic operator. More precisely, consider a request operation by r s for a relation:

<name="l", ctx="c", type="t", trustor="r s ", trustee="tee", metric="v"> of T M s where l ∈ L s , tor ∈ R s , while tee ∈ R t and r s :T M s ✶ µr r t :T M t . Then, operation mediation first identifies the matching relations: <name: string, ctx="c", type: string, trustor="r t ", trustee="tee", metric: m> of T M t that should be requested in the target model using a request operation of O t . Replies are finally normalized using the mediation operation given by µO xy for use in the source trust model. Operation mediation is practically implemented in a transparent way by the mediator that intercepts and then translates r s requests, as given in Algorithm 3. In the algorithm, the mediator interacts with r s (see lines 2-4) and r t (see lines 5-7). Then, the mediator computes the matching relation for each output relation (see lines [START_REF] Kim | Trust Type based Semantic Web Services Assessment and Selection[END_REF][START_REF] Marsh | Formalising Trust as a Computational Concept[END_REF][START_REF] Mui | Ratings in distributed systems: A bayesian approach[END_REF][START_REF] Nurmi | A bayesian framework for online reputation systems[END_REF][START_REF] Paradesi | Integrating Behavioral Trust in Web Service Compositions[END_REF][START_REF] Quercia | TRULLO-local trust bootstrapping for ubiquitous devices[END_REF][START_REF] Rahman | Supporting trust in virtual communities[END_REF][START_REF] Saadi | Establishing trust beliefs based on a uniform disposition to trust[END_REF] of the reply, where we assume that there is only one such relation (see lines 12-13) and requests its value using the appropriate request operation (see lines [START_REF] Quercia | TRULLO-local trust bootstrapping for ubiquitous devices[END_REF][START_REF] Rahman | Supporting trust in virtual communities[END_REF][START_REF] Saadi | Establishing trust beliefs based on a uniform disposition to trust[END_REF]. We further consider that the mediator (µr) embeds a library of mediation functions that translate and normalize heterogeneous trust metrics, which are invoked by mediation operations µo (see lines [START_REF] Marsh | Formalising Trust as a Computational Concept[END_REF][START_REF] Mui | Ratings in distributed systems: A bayesian approach[END_REF][START_REF] Nurmi | A bayesian framework for online reputation systems[END_REF]. Finally, for each update (i.e., bootstrapping and refreshing) triggered by the response, as specified in the corresponding call element (see lines [START_REF] Suryanarayana | PACE: an architectural style for trust management in decentralized applications[END_REF][START_REF] Suryanarayana | SIFT: A Simulation Framework for Analyzing Decentralized Reputation-based Trust Models[END_REF], the matching relations is sought in L t (see line 23) and its value requested (see lines 25-28). Figure4 depicts the basic mediation process (left hand side) and its extension with update (right hand side), as performed by the mediator. First, the mediator receives the request in (step 1). Then, it invokes the corresponding request in the target model As an example, Table 5 gives the operation set O 1,2 resulting from the composition of T M C and T M D .

Operation set O o0 = <name="getManagerTrustworthiness", host=((r S ∨ µr) ∨ r B ), type=request, in=l0, out=l0 > o1 = <name="assessSellerTrustworthiness", host=(r S ∨ µr), type=concatenation, type="product", in=(l0 ∧ l3) , out=l1 > o2 = <name= "assessBuyerFeedback", host=(r S ∨ µr), type=update, type="rating", in=l2, out=l2, call=o8 > o3 = <name="setSellerReputation", host=r M , type=aggregation, in=l2, out=l3 > o4 = <name="getSellerTrustworthiness", host=r S ,type=request, via=l0, out=l1, in=l3, call=o1 ∨ µo1 > o5 = <name="getSellerReputation", host=r M ,type=response, in=l3, out=l3 > o6 = <name="sendSellerReputation", host=r M ,type=response, via=l0, in=l1, out=l3, call=o5 > o7 = <name="getBuyerFeedback", host=(r S ∨ µr),type=request, in=l2, out=l2, call=µo2 > o8 = <name="sendBuyerFeedback", host=(r S ∨ µr),type=request, via=l0, out=l2 > o9 = <name="updateSellerReputation", host=r M ,type=response, via=l0, in=l2, call= o3 > oa = <name="getLocalCustomerTrustworthiness", host=r C , type=request, in=la, out=la > o b = <name="assessCustomerTrustworthiness1", host=(r C ∨ µr), type=concatenation, in=(la ∧ (la ∨ l b )) , out=l b , call=oc > oc = <name="assessCustomerTrustworthiness2", host=(r C ∨ µr), type=aggregation, , in=l b , out=l b > o d = <name="getRemoteCustomerTrustworthiness", host=r C ,type=request, via=la, out=l b , in=(la ∨ l b ), call=o b > oe = <name="sendCustomerTrustworthiness", host=(r C ∨ µr),type=response, via=la, in=l b , out=(la ∨ l b ), call=(oa ∨ o d ) ∨ o4 ∨ o7 > o f = <name="sendCustomerFeedback", host=r C ,type=request, via=la, out=la > og = <name="setCustomerTrustworthiness", host=(r C ∨ µr),type=update, in=la, out=la, call=o f > o h = <name="updateCustomerTrustworthiness", host=(r C ∨ µr),type=response, via=la, in=la, call= og ∨ µo3 > µo1 = <name="Translatel1l b ", host=µr,type=mediation, in=l1, out=l b > µo2 = <name="Translatel2la", host=µr,type=mediation, in=l2, out=la > Table 5: T M C and T M D Composition: Operation set

The response operation o e should be able to assess Sellers of T M C since its outputs (i.e., l a and l b ) contain relations that sink into the Seller role (see Table 4). To do so, o e is extended (see lines [START_REF] Kaffille | Engineering Autonomous Trust-Management Requirements for Software Agents: Requirements and Concepts[END_REF][START_REF] Kautz | Referral Web: combining social networks and collaborative filtering[END_REF][START_REF] Kim | Trust Type based Semantic Web Services Assessment and Selection[END_REF][START_REF] Marsh | Formalising Trust as a Computational Concept[END_REF][START_REF] Mui | Ratings in distributed systems: A bayesian approach[END_REF][START_REF] Nurmi | A bayesian framework for online reputation systems[END_REF][START_REF] Paradesi | Integrating Behavioral Trust in Web Service Compositions[END_REF][START_REF] Quercia | TRULLO-local trust bootstrapping for ubiquitous devices[END_REF][START_REF] Rahman | Supporting trust in virtual communities[END_REF][START_REF] Saadi | Establishing trust beliefs based on a uniform disposition to trust[END_REF] to enable the mediator role µr (when it performs this operation) to retrieve similar o e output relations in T M C , i.e., the relations l a and l b that are respectively similar to l 1 and l 2 . The operation o e can hence call o 4 or o 7 to search for l 1 or l 2 . Then, as for o e , the called operations are extended as well, by calling the mediation operations µo 1 and µo 2 to translate respectively l 1 and l 2 into l b and l a . Thus, o e is able to reply the appropriate trust relationships which are interpretable by Customers. Moreover, Algorithm 3 (see lines [START_REF] Suryanarayana | PACE: an architectural style for trust management in decentralized applications[END_REF][START_REF] Suryanarayana | SIFT: A Simulation Framework for Analyzing Decentralized Reputation-based Trust Models[END_REF][START_REF] Vercouter | An experience on reputation models interoperability based on a functional ontology[END_REF][START_REF] Wiederhold | Mediators in the architecture of future information systems[END_REF][START_REF] Zhou | Gossiptrust for fast reputation aggregation in peer-to-peer networks[END_REF][START_REF] Zimmermann | The official PGP user's guide[END_REF][25][26][27][28] enables Customers feedback to be propagated to the M anager of the target model T M C , so that the reputation of Sellers can be refreshed with the source model feedback. According to the resulting operation set (see Table 5), when the mediator role µr performs the response operation o h , it calls µo 3 to translate the feedback denoted by the relation l a into Buyer feedback, I.e., l 2 . Then, µo 3 is able to call o 2 with the l 2 to advertise its feedback to T M C M anager.

Conclusion

In this paper, we have introduced a trust meta-model as the basis to express and to compose a wide range of trust models. The composition of trust models enables assessing the trustworthiness of stakeholders across heterogeneous trust management systems. Such a composition is specified in terms of mapping rules between roles. Rules are then processed by a set of mediation algorithms to overcome the heterogeneity between the trust metrics, relations and operations associated with the composed trust models. We are currently implementing our approach as part of the Connect project 3 where we have defined an XML-based description of the trust meta-model, which we call TMDL (i.e., Trust Model Description Language). Thus, mediators are synthesized on-the-fly given the TMDL description of Trust models.

As future work, we are also considering the implementation of a simulator to a priori assess the behavior of trust composition of given trust models and thus allows fine tuning of the mapping rules. We are also investigating the use of ontologies to specify the semantics of trust model elements and thus possibly infer the mapping rules as well as infer the similarity of trust relations from the semantics.

Fig. 1 :

 1 Fig. 1: Operation continuation

Fig. 2 :

 2 Fig. 2: Trust graphs of the centralized (T M C ) and the distributed (T M D ) trust models.

  (i.e., l a ) and can then ask trustee Customers to get their recommendation about unknown Customers that are sellers (i.e., l b ). Hence, a Customer can perform a request operation (i.e., o d ) to get a recommendation of an unknown Customer seller, so that the requester Customer can compute locally the trustworthiness of the Seller (i.e., o b and o c ). After the transaction is completed, the requester Customer can provide its feedback to other Customers by triggering a request operation (i.e., o f ). The recipient Customer can process (i.e., o h ) this feedback to refresh its relationship with the concerned Seller (i.e., o g ) and can also in turn propagate this feedback by calling the o f . Role set R r C = <name="Customer "> Metric set M ma = <name="Recommendation", type="Probability"> Relation set L la = < name="DirectCustomer Trustworthiness", ctx= "auction", type=1:1, trustor=r C , trustee=r C , metric=ma > l b = < name="TransitiveCustomer Trustworthiness", ctx= "auction", type=1:N, trustor=r C , trustee=r C , metric=ma > Operation set O oa = <name="getLocalCustomerTrustworthiness", host=r C , type=request, in=la, out=la > o b = <name="assessCustomerTrustworthiness1", host=r C , type=concatenation, in=(la ∧ (la ∨ l b )) , out=l b , call=oc > oc = <name="assessCustomerTrustworthiness2", host=r C , type=aggregation, in=l b , out=l b > o d = <name="getRemoteCustomerTrustworthiness", host=r C , type=request, via=la, out=l b , in=(la ∨ l b ), call=o b > oe = <name="sendCustomerTrustworthiness", host=r C ,type=response, via=la, in=l b , out=(la ∨l b ), call=(oa ∨o d > o f = <name="sendCustomerFeedback", host=r C ,type=request, via=la, out=la > og = <name="setCustomerTrustworthiness", host=r C ,type=update, in=la, out=la, call=o f > o h = <name="updateCustomerTrustworthiness", host=r C ,type=response, via=la, in=la, call= og >Table 3: Distributed Trust model: T M D .

Algorithm 1 : 1 /Ly 2 O 6 if µr k ∈ µRxy then 7 µRxy = µRxy ∪ {µr k } 8 9 Rxy = Rx ∪ Ry ∪ µRxy 10 Mxy = Mx ∪ My 11 Lxy = L + x ∪ L + y 12 Oxy

 1126789101112 Trust Models Composition(T M x , T M y , Ψ xy ) Input(s) : Trust models T Mx and T My The set of Mapping rules Ψ xy Output(s): The trust model composition T Mxy =< Rxy, Mxy, Lxy, Oxy > begin / Initialize trust models sets for composition L + x = Lx ; L + y = + x = Ox ; O + y = Oy 3 foreach (ψ xy k = (ψ xy k = (ri : T M m={x,y} ) ⊙ (rj : T M n={x,y},m =n )) ∈ Ψ xy ) do 4 Relation M ediation(ri, L + m , rj, L + n , Operation M ediation(ri, L + m , O + m , rj, L + n , O + n , µr k )

  selling transaction scenarios, (r B : T M C ) ≻ (r C : T M D ) means that Buyers (i.e., r B : T M C ) of the centralized trust model are seen by the distributed trust model (T M D ) as Customers (r C : T M D ).

Algorithm 2 : 1 if 7 if l i .trustor ❂ r s then 8 l

 2178 Relation Mediation(r s , L + s , r t , L + t , ⊙) Input(s) : Roles r s and r t ; Relation sets L + s and L + t ; Mapping operation ⊙ Output(s): The source and the target relation sets: L + s and L + t begin ⊙ = " ≻ " then / * Ψ xy is defined with the "See" Operator * / 2 foreach (l i ∈ L + t ) do / * Find relations with the trustee rs * / 3 if l i .trustee ❂ r t then 4 l i .trustee rt ← ---(r t ∨ r s ) / * Add rs as a trustee * / 5 if ⊙ = " ✶ µr " then / * Ψ xy is defined with the "M imic" Operator * / 6 foreach (l i ∈ L + s ) do / * Find relations with the trustee rs * / i .trustee li.trustee ← ------(l i .trustee ∨ µr) / * Add µr as a 9 trustee * / foreach (l i ∈ L + t ) do / * Find relations with the trustor rt * / 10 if l i .trustor ❂ r t then 11 l i .trustor rt ← ---(r t ∨ µr) / * Add µr as a trustee * / 12 end

Fig. 3 :

 3 Fig. 3: Trust graph T G CD

Fig. 4 :

 4 Fig. 4: Operation mediation process

Table 2 :

 2 Centralized Trust model: T M C . Regarding the distributed model T M D specified in Table 3, the role Customer of the distributed model can maintain a direct trust relationship with other Customers

Algorithm 3 :

 3 Operation Mediation(r i , L + m , O + m , r j , L + n , O + n , µr k ) Input(s) : Source role r s , relation L + s and operation set O +

		s t and operation set O + Target role r t , relation L + t
		The mediator role µr
		Output(s): The source, the target and the mediation operation sets: O + s , O + Request t and µO st Operation
			(o*)
	1	begin
	2	foreach (o i ∈ O + s ) do	/ * Find operation with the host rs * /
	3	if o i .type = "response" ∧ o i .via.trustor ❂ r s then
	4	o i .host	oi.host ←----(o i .host ∨ µr)	/ * Add µr as a host * /
	5	foreach (o i ∈ O + t ) do	/ * Find relations with the host rt * /
	6 7	if o i .type = "response" ∧ o i .host ❂ r t then o i .host rt ← ---(r t ∨ µr) / * Add µr as a host * /
	8	foreach (o i ∈ O + s ) do	/ * Find operation with the host rs * /
		// Request mediation
	if o 25
	26		µo.call = o *
	27		µO st = µO st ∪ {µo}
	28		o i .call	oi.call ← ----(o i .call) ∨ µo
	29	end

i .type = "response" ∧ o i .host ❂ µr then 9 if (o i .out = null) then 10 foreach l k ❂ o i .out do 11 // Create a new mediated operation µo µo.host=µr ; µo.type="mediation" 12 // Find a similar output relation into Lt l * = f indSimilarRelation(l k , L + t ) 13 µo.in = l * ; µo.out = l k 14 µO st = O st ∪ {µo} 15 // The relation l * need to be requested o * = f indOperation(type = "request", l * , O + t ) 16 o * .call o * .call ← ----(o * .call) ∨ µo 17 o i .call oi.call ← ----(o i .call) ∨ o * 18 // Update mediation foreach o k ❂ o i .call do 19 if o k .type = "ref resh" ∨ o k .type = "booststrap" then 20 foreach l p ❂ o k .in do 21 µo.host=µr ; µo.type="mediation" 22 l * = f indSimilarRelation(l p , L + t ) 23 µo.in = l p ; µo.out = l * 24 o * = f indOperation(type = o k .type, l * , O + t )

http://connect-forever.eu/

Note that the name can in particular be specified by an ontological concept that formally describes this role into a given trust ontology although this is not longer discussed in this paper.

http://connect-forever.eu/

⋆ Work supported by EU-funded project FP7-231167 CONNECT and by EU-funded project FP7-256980 NESSOS.


Amir Seyedi

Rachid Saadi

Valérie Issarny

Proximity-Based Trust Inference for Mobile Social Networking

Keywords: Trust bootstrapping, mobile social network, small worlds

The growing trend to social networking and increased prevalence of new mobile devices lead to the emergence of mobile social networking applications where users are able to share experience in an impromptu way as they move. However, this is at risk for mobile users since they may not have any knowledge about the users they socially connect with. Trust management then appears as a promising decision support for mobile users in establishing social links. However, while the literature is rich of trust models, most approaches lack appropriate trust bootstrapping, i.e., the initialization of trust values. This paper addresses this challenge by introducing proximity-based trust initialization based on the users' behavioral data available from their mobile devices or other types of social interactions. The proposed approach is further assessed in the context of mobile social networking using users behavioral data collected by the MIT reality mining project. Results show that the inferred trust values correlate with the self-report survey of users relationships.

Introduction

Portable devices have gained wide popularity and people are spending a considerable portion of their daily life using their mobile devices. This situation together with the success of social networking lead to the emergence of mobile social networking. However, anytime and anywhere interactions have a built-in risk factor. Development of trust-based collaborations is then the solution to reduce the vulnerability to risk and to fully exploit the potential of spontaneous social networking [START_REF] Capra | Engineering human trust in mobile system collaborations[END_REF]. In our work, we aim at developing a trust management method for mobile social networking. Then, the challenge we are addressing here is how to initiate trust values and how to evaluate unknown mobile users using initiated trust values, to enable impromptu social networking.

Computational trust brings the human concept of trust into the digital world, which leads to a new kind of open social ecosystem [START_REF] Marsh | Formalising trust as a computational concept[END_REF]. In general, the notion of trust can be represented by a relation that links trustors to trustees. The literature [START_REF] Sabater | Review on Computational Trust and Reputation Models[END_REF] includes two main categories of relations to set trust values for trustees, namely: (i) direct-based and (ii) recommendation-based relation.

Most existing trust models focus on assessing recommendation-based relationships [START_REF] Walter | A model of a trust-based recommendation system on a social network[END_REF] and lack the bootstrapping stage, which is how to initialize direct trust in order to efficiently start the trust model operation. This is very problematic and challenging, since recommendation-based relationships are built upon bootstrapped direct-based relationships. Indeed, most solutions that address trust assessment make one of the following assumptions:

-Trust initialization is not a problem of the model; it is the responsibility of the actors of the system [START_REF] Golbeck | Filmtrust: movie recommendations using trust in webbased social networks[END_REF]. However, this task remains challenging, especially when it comes to evaluating trustees numerically (e.g., 0.1, 0.2, 0.15, etc.). -The trust model initially evaluates trust relationships with a fixed value (e.g., 0.5 [START_REF] Haque | An Omnipresent Formal Trust Model (FTM) for Pervasive Computing Environment[END_REF], a uniform Beta probabilistic distribution [START_REF] Jøsang | Semantic constraints for trust transitivity[END_REF], etc.) or according to the trust disposition of the trustor [START_REF] Perich | In reputation we believe: Query processing in mobile ad-hoc networks[END_REF] (i.e., pessimistic, optimistic, or undecided). In [START_REF] Saadi | T2D: A Peer to Peer trust management system based on Disposition to Trust[END_REF], trust is initialized by asking trustors to sort their trustees rather than assigning fixed trust values. There are other bootstrapping solutions [START_REF] Ahamed | Towards Secure Trust Bootstrapping in Pervasive Computing Environment[END_REF][START_REF] Ahamed | CCTB: Context correlation for trust bootstrapping in pervasive environment[END_REF][START_REF] Quercia | TRULLO-local trust bootstrapping for ubiquitous devices[END_REF] that assess trustees into different contexts (e.g., fixing a car, babysitting, etc.) and then automatically infer unknown trust values from known ones of similar or correlative contexts. However, if no prior related context exists, these solutions lack initialization of trust.

We have developed our trust model based on the hypothesis that it is possible to measure and bootstrap trust from human social behavior. Therefore, in this paper, we investigate a formal approach that quantifies human proximity from which possible trust relationships are transparently and automatically inferred and assessed on behalf of the trustor. We choose proximity between people as an effective measure for trust. Because, proximity between people is not only a matter of trust, but it increases trust affinity as well [START_REF] Bruneel | Building Trust: A Matter of Proximity? Babson College Entrepreneurship Research Conference[END_REF]. In other words, people spend more time with those whom they trust and, at the same time, if they start spending time with new people, it is likely that trust relationships will arise and evolve.

In order to better understand the contribution and evolution of proximity in the human society, consider the fact that a society is initiated by people who live in the same territory. Fukuyama [START_REF] Fukuyama | Trust : the social virtues and the creation of prosperity[END_REF], describing the role of trust in a society, mentions that people can build efficient economy and social organization, if they have wide and efficient trust networks. It shows clearly how trust and proximity of people are tied together to initiate a successful society. As a result, today we have different cultures and societies in the world simply because of their founders being at different location and proximity. Building on this social knowledge, this paper introduces a method for bootstrapping trust values in mobile environments, based on the proximity of people. However, in today's virtual world expanding the physical one, proximity is not just about the physical distance between people. Practically, while people who are physically close maybe detected using technologies such as Bluetooth [START_REF] Eagle | Inferring friendship network structure by using mobile phone data[END_REF], other types of proximity like phone calls, emails, social network interactions, etc. can be detected by the implementation of virtual sensors. We classify the range of proximity-based trust values semantically for further judgments based on these values. Then, the initiated trust values can be used to calculate similarity between people from the standpoint of trust. Similar people can make good recommendations to each other. Hence, they can evaluate not-directly-known users on each others behalf. So, when mobile users are about to interact with unknown users, they may acquire the trust knowledge through known similar users. The process should be feasible in a limited number of hops because of the small world phenomenon [START_REF] Newman | Random graph models of social networks[END_REF]. The next section characterizes proximity towards trust assessment and is then followed by proposed proximity-based trust initialization in Section 3. Then, we evaluate the effectiveness of the proposed approach using the MIT reality mining dataset. Finally, we conclude in Section 5, summarizing our contribution and sketching our future work.

Trust and Proximity

We make the assumption that there is a strong correlation between proximity observations and real social relationship [START_REF] Eagle | Inferring friendship network structure by using mobile phone data[END_REF]. Proximity itself can be considered as a consequence of trust relationship, while at the same time the longer users are in proximity, the higher the probability of their friendship increases. Moreover, as noted by [START_REF] Bruneel | Building Trust: A Matter of Proximity? Babson College Entrepreneurship Research Conference[END_REF], proximity is a measure of trust as well as a cause to trust between users.

Thus, we argue that proximity is the nearness of any two persons in space or time. Let P be the proximity between two persons. Two persons are in physical proximity if the nearness happens in the same space and time. Two persons are in virtual proximity if the nearness happens only in the time dimension. Physical proximity can be detected by various technologies (e.g., blue-tooth, Wi-Fi, etc.) and likewise virtual proximity through monitoring of social activities (e.g., chat, SMS, voice call, liking a content on facebook etc.). The collected proximityrelated data provides information such as when, where, how frequently, and for how long people were in the proximity of each other.

In general, the definition of proximity takes several forms (from physical to virtual) and differs according to context (work, home, etc.) as well as it can be quantified by duration or frequency. From a social point of view, from the context in which proximity happens, we may identify a quality difference between the observed proximities. For instance, if the proximity happens at home, it is more intimate than a proximity in a professional meeting. Hence, in order to be able to aggregate of different types of proximity and consider the value difference between them, we characterize a proximity data type, namely η, as a tuple: η =< p, l, t, d s , d d , s, m > where, -Proximity type (p): Proximity type has two modes, virtual and physical.

For instance, this helps distinguishing between a face-to-face interaction and virtual proximity. -Location (l): Location is the position in physical space, in which the proximity happens. Location meaning can be expanded semantically, by looking to social semantic aspects of different definitions for location. For instance, home is a location in which trust is included by definition. Location has an effect on intimacy, e.g., the difference between outdoor and indoor proximity. -Time (t): The time context is the temporal measurement of an instance in which the proximity happens. However time definition can be expanded semantically. For instance, weekend or working time has different social values. We take into account the quality difference of proximity as time changes, e.g., during weekend, being in the proximity of friends is more likely and therefore is a more valuable proximity. -Source device type (d s ): Device type helps to includes the nature of device in terms of mobility etc. e.g., mobile device like smart-phone versus laptop).

The observed proximity from a mobile device is more reliable as people are more likely to have their mobile device always with them. Then, d s is the source device that belongs to the observer user. -Destination device type (d d ): d d is the destination device of a user who has been observed. -Sensing method (s) (e.g., physical sensors, virtual sensors): Sensing methods take into account the technology effect on measurement method. or example bluetooth detects people in a shorter range than wifi does. So the detected proximity by bluetooth is more reliable as it catches the closer users. -Measurement type (m): Measurement type indicates the difference between duration and frequency of a proximity. Hence, we introduce a proximity coefficient, which is necessary for combining different types of proximity.

Proximity data types enable us to consider value difference between proximities. We in particular assign a coefficient for each proximity data. This can be done using techniques such as fuzzy logic; logic can decide the weight of specific proximity data types in terms of trust. Thus, several sources of proximity can be combined by a weighted average using their coefficients. Let k ηi be the coefficient for an observed proximity of type η i . k ηi is calculated for any given η i by logical aggregation of proximity data type parameters. Given the above types of proximity we define proximity records as:

K = {k η1 , k η2 , k η3 , ...}
ProximityRecord=<UserID,η, Value>
where the Proximity tuple is composed by the UserID, which is the unique identifier of the observed user, η is the data type of the observed proximity; and value is the observed proximity, which is duration or frequency based on the data type. Hence, each user's device is assigned with a set of Proximity tuples called observed set, as exemplified in Table 2.

UserID η Value B η1 200h C η1 20h D η1 80h E η1 30h F
η1 0,5h Table 2. An example of proximity duration data provided by user A device

Proximity-based Trust Initialization

Proximity-based trust initiates trust values between nodes with a one-to-one trust relationship. Using an appropriate conversion method for various proximity data is the most challenging part of trust calculation. As a matter of fact, it is a difficult task to make a conversion from varied types of observed proximity to a range of trust values that are meaningful. For the conversion of proximity records to Proximity-based trust values, we use standard score formula. Standard score has a normalization effect on the amount of observed proximities according to the observer(user's) average activity.

Definitions

Normalization has several positive outcomes. First, social interaction quantity varies a lot according to user personality in a social network [START_REF] Kumar | Structure and evolution of online social networks[END_REF]; as a result the amount of proximity varies substantially for different nodes [START_REF] Eagle | Inferring friendship network structure by using mobile phone data[END_REF]. Second, there are multiple types of proximity; normalized scoring eases the process of combining trust values according to different proximity data types.

Definition 1 (Standard Score). A standard score [START_REF] Aron | Statistics for the behavioral and social sciences[END_REF] indicates how many standard deviations (σ), an observation or datum(x) is above or below the mean(µ):

Z = datum-mean standard deviation = x-µ σ (1)
As a result of using standard score, each peer normalizes trust values based on their average proximity duration with anyone. Therefore, each trust value is unbiased and bounded into a determined range, which hides the effect of variation of proximity duration due to peers having various behavior. Hence, by using standard score formula, we process the observed proximity as follows.

Definition 2 (Observed Set). The Observed Set (OS) of a user includes all the users that have been detected in proximity of a given user.

We use a time finite subset of observed proximities for trust evaluation. Therefore, we define the proximity window function as: Definition 3 (Proximity Window Function). The proximity window function P w ηi (A, B) accumulates the proximity of user B monitored by user A during the time window w and with proximity type η i . Definition 4 (Proximity-based Trust Function). Proximity-based trust is basically calculated using standard score formula. The proximity-based trust function is denoted by T t ηi and is formally defined as:

T t ηi : U × U → R U : set of Users (A, B) → T t ηi (A, B) R : set of real numbers T t ηi (A, B) =        -∞ if (B ∈ OS A ) P w η i (A,B)-µ w η i σ w η i if (B∈ OS A ∧ t ≤ w) (1 -α) * T p ηi (A, B) + α * P w η i (A,B)-µ w η i σ w η i if (B∈ OS A ∧ t > w)
(2) where:

-T t ηi (A, B) is the proximity-based trust value given by user A for user B at the instant t with proximity data type of η i .

-T p ηi (A, B) is the past acquired proximity-based trust value by user A for user B at the instant p = t -t%w with proximity data type η i . -P w ηi (A, B) is the cumulative proximity of B in the given period of time w with proximity data type η i .

α is a coefficient which is in range of ]0, 1[ and defines how significant is the impact of new observed proximities on the last calculation of proximity based trust value. -w ηi and σ w ηi are, respectively, the observed period average and the standard deviation during the time window w with proximity data type η i .

Definition 5 (Proximity-based Trust Aggregation Function). The proximitybased trust aggregation function is for combining trust values, which is inferred from different proximity data types. It is formally defined as:

T t : U × U → R U : set of Users (A, B) → T t (A, B) R : set of real numbers T t (A, B) =                      -∞ if (B ∈ OS A ) |K A B | i=1 k ηi * T t ηi (A, B) |K A B | i=1 k ηi if (B∈ OS A ) (3)
where T t ηi and k ηi are the trust value and the coefficient for proximity type η i , respectively K A B is the set of coefficients for all the observed proximity types between users A and B. Thus, by using the equation 2, we consider only the proximity that occurs during time window w. Then, for a new time window, the latest assessed trust value (T p ηi ) is used to serve as an input for new trust assessment.

Semantical Trust Inference

Given T t , we are able to infer trust relationships between users. For the moment we do so by splitting the trust scale equally into four sections with respect to the normal distribution probability density in each area and according to the experiments of trust calculation we did using real proximity data from [START_REF] Eagle | Inferring friendship network structure by using mobile phone data[END_REF] (Illustrated in Figure 2), we define four trust levels and each level includes 25 percent of the observed peers, namely: Unknown Trust, Slightly trusted, Moderately trusted and Highly trusted. Unknown Trust represents all the persons whose trust (T t ) is assessed into interval ] -∞, -0.67[. For this category, we consider that the system has insufficient information to infer trust. All the other that are assessed over -0.67 are considered as trusted entities and they are classified into three Then, according to our classification, which is based on density of peers in each score interval and exprimental results, we consider that a proximity-based trust relationship is established if an inferred proximity-based trust value is higher than -0.67. We define this relation as follows: From the defined relationship, we introduce two trust concepts, namely, the trustee set (Definition ??) and the trustor set (Definition ??). Those sets are defined for each user and gather respectively his trustees and his trustors.

Example: To explain our approach, we use the following example. User A has a mobile device with a proximity logging application. The observed set of user A is composed by: OS A = {B, C, D, E, F }. Table 2 introduced in Section 2 shows an example of cumulative proximity duration that can be provided by user A device with η 1 proximity data type. For instance: P w η1 (A, B) = 200h. Considering an unbounded time window (i.e., w = +∞), the proximity duration average is: µ w η1 = 66.1. For calculating the standard deviation, we first compute the difference of each data point from the mean, and then square the result: (200 -66.1) 2 = 17929.21, (80 -66.1) 2 = 193.21. We repeat the same process for the other values. Then, we calculate the standard deviation by dividing the sum of these values by the number of values and take the square root:

σ w η1 = 17929.21+2125.21+193.21+1303.21+4303.36 5 = 71.90
The proximity-based trust value for the user B with 200 hours of proximity is then calculated using Formula: 3, T t ηi (A, B) = 200-66.1 71.90 = 1.86

Therefore, a one-to-one trust relation is established between users A and B (i.e., A T → B), which means that B ∈ T ee(A) and A ∈ T or(B). Moreover, A may highly trust B because T t (A, B) ≥ 0.67.

In next section we evaluate our approach experimentally using the MIT real mobility data.

Experimental Evaluation

A full-fledged evaluation of our approach needs a large-scale proximity dataset with different data types, in order to have possibilities for combining trust values from different types of observed proximity. Also, for a multi-hop trust estimation, large number of users is needed. That aside, a survey of trust and/or other social facts such as friendship between the observed users is needed to make a comparison between inferred trust values and real social facts. While to the best of our knowledge there is no such kind of vast proximity dataset publicly available, we have used the reality mining dataset 1 [START_REF] Eagle | Inferring friendship network structure by using mobile phone data[END_REF] as the only existing public dataset of mobile phone proximity records with self-report survey data. The reality mining project was developed by the MIT Media Lab during years 2004-2005 by using 100 Nokia 6600s with Context logging software. They have gathered 330,000 hours of continuous behavioral data logged by the mobile phones of the subjects. They also did a survey in which they asked users about friendship and whom are they going to meet.

To illustrate the capability of our approach, we answer the following question: To what extent the bootstrapped trust values are in correlation with real social facts(e.g. friendship)?

We run the evaluation with the following steps. First, we calculate the proximitybased trust values between users. Then, by comparing the calculated proximitybased trust values of each user to the answers he provided in the survey, we verify if the inferred trust values are coherent with friendship.

From the reality mining dataset, we can calculate the proximity duration between two persons which has been detected by bluetooth. We apply the proximity-based trust function (Equation 2) to the proximity durations in order to obtain proximity-based trust values, T t (A, B), of each user. From the survey, each person predicts his possible future proximity with a friend, or if they are going to meet any other person inside or outside the lab. From this survey, we may tell that mentioned persons are either friends or they are important from Group Average of minimum trust Average of trust values Friends 1.4070 2.0209 inLab -0.3079 0.7696 outLab 0.0068 1.0460 Table 3. Average T t (A, B) value for reported people in survey the user point of view. We can make the judgment that it is probable that trust relationships exist between the reported users. For these groups (Friends, inLab, outLab), average trust value is shown in Table 3. To find out the relevance of the proximity-based trust values, as we can perceive, highest average of trust values are assigned to friends. Based on the given definitions (Figure 2), friends are assigned with highly trusted notion. For inLab group, which is the people that users meet inside the MIT Lab, the values are overall located in slightly trusted and moderately trusted classification. For outLab group, which usually consist of friends, family and friends of friends, that a person meets outside of working area, the values are around the barriers of highly trusted group. This experiment shows that trust values are related to the social strength of a relationship. For instance, highest values belong to friends. Additionally, we calculated similarity between users, which is used for the trust transitivity calculation. Table 4 shows that similarity values are behaving very similar to the proximity-based trust values, and they change with the characteristics of relationship. Knowing that similarity is a measure of trust, this arrangement evidences the social fact that friends are similar in their relationships and they are favorite recommender to each other.

The average of minimums is for showing the minimum value that is inferred by a user for each group.

Group Average of minimum similarities Average of similarities Friends 0.2913 0.4828 inLab -0.0858 0.2520 outLab 0.0089 0.3372 Table 4. Average of similarity for reported people in survey Figure 3 shows the percentage of trust values in each semantical classification of trust, for the trust that is inferred for users in different groups of friends and known people inside and outside MIT Lab. Friends are removed from both inLab and outLab groups. As we see, friends have the highest percentage of nodes assessed as highly trusted peers(36%), while inLab peers (e.g. colleagues) are often moderately trusted(46%). For the outLab group, the highly trusted nodes are more than inLab group, but the slightly trusted nodes are increasing. This can be commented by the fact that users meet more random people out of their working place and at the same time more intimate persons are around them than work. In this paper, we proposed a novel method to bootstrap trust values from proximity between the people which can also be used for trust inference for unknown users. This approach is suitable for mobile social networking applications. We formalized different types of proximity and introduced proximity data types.

The evaluation using real proximity data shows that inferred values are correlated with real social facts. For future work, we aim at creation and evaluation of large dataset of different types of proximity. At the same time, user opinions of trust should be surveyed and included in such kind of dataset. We aim at using fuzzy logic for aggregation of different proximity, according to the level of contribution they can provide to trust value. Also, a large body of work exists in the domain of estimation and recommendation, they may be adapted and evaluated for trust recommendation and transitivity within this approach. Hence, for further evaluation of our approach, and in order to better investigate other available possibilities in trust assessment, we are looking into the deployment of this approach as part of the yarta middle ware framework2 . Yarta middle ware support the development of mobile social applications.

?Fig. 1 .

 1 Fig. 1. User A evaluates others based on the observed proximity with others

Fig. 2 .

 2 Fig. 2. Trust Scale for normalized Trust values

Definition 6 (

 6 Proximity-based Trust relationship). Let A and B be two users. If T (A, B) ≥ 0.67, we say that the Trust relation is verified between A and B. Formally: if T (A, B) ≥ -0.67 then A T → B

Fig. 3 .

 3 Fig. 3. Trust value distribution in different context of proximity

Table 1 .

 1 is the set of coefficients for different types of proximity, coefficients are bounded to the range of [0, 1] . Accordingly, K A B is the set of all proximity coefficients between users A and B. An example of three different proximity data types is shown in Table1. Proximity Data Types

	η	p	l	t	ds	d d	s	m
	η1 physical anywhere anytime mobile mobile bluetooth duration
	η2 physical office working time mobile laptop WiFi	duration
	η3 virtual anywhere	night	mobile mobile SMS frequency

http://reality.media.mit.edu/

https://gforge.inria.fr/projects/yarta/

Work supported by EU-funded project FP7-231167 CONNECT and by EU-funded project FP7-256980 NESSOS.