A DISTRIBUTED REPUTATION MANAGEMENT SCHEME FOR MOBILE AGENT- BASED APPLICATIONS

Bamasak & Zhang: A Dstrbuted Reputaton Management Scheme for Moble Agent-Based Applcatons A DISTRIBUTED REPUTATION MANAGEMENT SCHEME FOR MOBILE AGENT- BASED APPLICATIONS Omama Bamasak School of Computer Scence Unversty of Manchester, UK obamasak@cs.man.ac.uk Nng Zhang School of Computer Scence Unversty of Manchester, UK nzhang@cs.man.ac.uk ABSTRACT Ths paper proposes a new dstrbuted reputaton management scheme to support agent-based applcatons. The scheme uses a transacton feedback system and fve metrcs to real-tme evaluate the reputaton of Trusted Thrd Party (TTP) hosts that are selected and employed to support an agent n performng ts transactonal tasks. The scheme exhbts two nterestng features not seen n prevous works: frstly, t offers better effcency and robustness, and secondly, t credts/penalzes a TTP-host accordng to ts transactonal response, the transacton value and the reputaton of the source of feedback. In addton to facltatng TTP-host selecton based upon ts reputaton, ths mechansm of credt and penalsaton s expected to deter dshonesty or msbehavour by the enttes nvolved. Keywords: Dstrbuted reputaton management, e-commerce securty, moble agent securty. 1. Introducton Moble agents offer a new computng paradgm that allows us to gan a greater access to resources on the Internet n a more effcent and automatc manner. By delegatng tasks to moble agents, users can accomplsh extended or complcated tasks that they, otherwse, would rather not or cannot perform themselves. Moreover, by sendng moble agents close to nformaton sources, we can reduce network traffc and applcaton latency. However, the success n usng the moble agent paradgm depends on the level of securty t offers. Wthout adequate securty provson, securty-senstve tasks cannot be delegated to an agent that may execute the tasks n a remote and possbly malcous host. To llustrate the securty rsks faced by a moble agent n the Internet envronment, we here analyse an e- Commerce applcaton scenaro. A busnessman s to search for an arlne tcket for a busness trp on the Web. As the search may take a lttle whle and he s too busy to do the search n person hmself, he has decded to delegate ths task to a moble agent. The busnessman specfes some requrements for ths purchase. For example, he may specfy that the purchase should only proceed f the prce of a tcket s no more than 200, and f such an offer s found, then the agent should book the flght at once on hs behalf. It s clear that, n such a scenaro, a remote arlne host has the ncentve to msbehave or to attack the agent. For example, the host may force the agent to sgn a deal that s above the specfed prce threshold, or the host may forge the agent sgnature(s) altogether by spyng on the sgnature key carred by the agent so that the busnessman wll be lable for the deal(s). Prevous research works [Km et al. 2001, Kotzankolaou et al. 2000, Lee et al. 2001, Mambo et al. 1996a, Mambo et al. 1996b, Reagle 1998] have proposed some solutons to address ths problem, or, n a more generc term, the problem of securng the sgnature key (also called proxy key) carred by a moble agent. However, there are rooms for mprovements n these solutons. Some of these solutons do not support the securty servce of nonrepudaton of sgnature recept [Kotzankolaou et al. 2000, Mambo et al. 1996a, Mambo et al. 1996b, Reagle 1998], whle others do not provde suffcent protecton for the proxy key aganst msuse by a remote malcous (merchant) host [Lee 2001]. In addton, some of the solutons that provde a good level of securty protecton, e.g. the Km s protocol [Km et al. 2001], are neffcent n terms of computatonal costs. Recently, Bamasak and Zhang [Obamasak & Zhang 2004] have proposed a more secure and effcent scheme for sgnature delegaton to a moble agent amed at addressng the weaknesses mentoned above. Ths scheme makes use of a Trusted Thrd Party (TTP) to assst the moble agent n sgnature generaton and dspute resoluton to support the non-repudaton of sgnature recept. The scheme assumes that a sngle host plays the role of ths TTP. The downsde of ths centralzed TTP based approach s that t s a potental performance/relablty bottleneck ntroducng a sngle pont of falure for protocol executon. The fact that t s ncreasngly dffcult to protect any sngle system aganst the sort of attacks prolferatng on the Internet today has made ths assumpton a weakness n our desgn. One way of overcomng ths weakness s to dstrbute the role of the TTP among a set of Page 154

Journal of Electronc Commerce Research, VOL 7, NO.3, 2006 trusted hosts rather than relyng on a sngle host. In ths way, the robustness of the protocol s strengthened as a majorty of, or all of, the trusted hosts would have to be compromsed before the system as a whole s compromsed. An mportant queston rased at ths stage s: how can the agent owner decde on the group of hosts that can be trusted to jontly perform the role of the TTP? In other words, what should be the selecton crtera on whch the agent owner makes the decson as whether or not a host should be selected to play the role of the TTP? Obvously, the agent owner should select the TTP-hosts that have an acceptable level of reputaton. Conventonal securty solutons and cryptographc methods, such as the use of passwords and dgtal certfcates, alone are not suffcent for us to evaluate the trustworthness of a TTP-host. They can help us to establsh whether a party s authentcated and authorzed to take certan actons. They can not guarantee that a party (even authorsed) wll perform as promsed and delver a trusted servce. In ths paper, we nvestgate current solutons to reputaton management, and present the desgn of our dstrbuted reputaton scheme suted to the sgnature delegaton model proposed n [Obamasak & Zhang 2004]. The remanng part of ths paper s organzed as follows. Secton 2 presents an analyss of related work n reputaton management. Secton 3 defnes the metrcs for evaluatng the reputaton of a TTP-host n e-commerce context. Secton 4 descrbes our Dstrbuted Reputaton Management scheme along wth the two algorthms used by the scheme. Fnally, Secton 5 draws the conclusons of ths paper. 2. Related Work Reputaton s defned as the amount of trust nspred by a partcular person n a specfc settng or doman of nterest by Marsh [Marsh 1994]. In [Reagle 1996], reputaton s defned as asset creaton and t s evaluated accordng to ts expected economc returns. Recently, a number of trust/reputaton systems and mechansms have been proposed for on-lne tradng and agent systems [Ketchpel & Garca-Molna 1996, Zachara & Maes 2000, Xong & Lu 2003, Bryant & Colledge 2002]. The approach used n [Ketchpel & Garca-Molna 1996] employs one or more TTP-hosts to acheve a far exchange securty servce. Ths work, however, assumes that the TTP-hosts are trustworthy, and never msbehave. The authors n [Zachara & Maes 2000] have developed a collaboratve reputaton mechansm allowng personalzed evaluaton of ratngs assgned to partcpatng enttes. Based upon these ratngs, the relabltes of the enttes are estmated. However, the work does not clearly state the evaluaton metrcs, or on what crtera, the ratngs (.e. reputaton values) are calculated. The methods presented n [Malaga 2001, Xong & Lu 2003, Jøsang & Ismal 2002] only deal wth peer-to-peer trust. They do not provde a soluton for the selecton of a group of TTP-hosts that can jontly performs a securty-senstve task. In the Internet-based electronc marketplace, there are a few workng on-lne reputaton systems. Examples nclude the ebay [ebay 2004] and Yahoo! Aucton [Yahoo 2004] feedback systems. These systems allow partcpants of a transacton to rate each other wth a value of +1 for a postve feedback, 0 for beng neutral, and - 1 for a negatve feedback. Only wnnng bdders and sellers may submt a feedback for ther completed transactons. A ratng from an ebay partcpant only contrbutes once to another partcpant s ratng. For example, f partcpant A gves 3 postve ponts to another partcpant B (for 3 dfferent transactons), partcpant B s ratng can only ncrease by +1. However, f A gves two negatve and one postve ponts to B, the negatve ratng wll count once and so wll the postve ratng. A transacton partcpant s also allowed to submt a wrtten response. The reputaton value of a partcpant s then calculated as the sum of all ponts ths partcpant has receved snce s/he started dealng n the marketplace. Any partcpant wth a reputaton value of -4 wll be suspended from further dealngs on ebay. Ths approach s lnear and sngle-factor based,.e. postve or negatve feedback, and often fals to capture the behavor of the partes nvolved effectvely. For example, a partcpant who has 100 postve feedback ponts wll have the same ratng as a user who has had 300 postve and 200 negatve ponts. The Dstrbuted Reputaton Management scheme to be proposed n ths paper has addressed these weaknesses. Namely, the scheme has defned clear crtera for reputaton calculaton. It s also embedded wth an algorthm, the TTP-hosts Subset Selecton (TSS) algorthm, that selects one or more (or a subset of) TTP-hosts based upon the crtera such that the aggregated reputaton value of these selected TTP-hosts satsfes the trust level specfed by an agent owner. The trust level s, n turn, determned by the value of the transacton to be performed. In addton, the scheme has also got an algorthm, the Trust and Relablty Updatng (TRU) algorthm, by whch the agent owner calculates and updates reputaton values assocated wth each of the TTP-hosts nvolved n a transacton. The algorthm uses a non-lnear approach to transacton feedback sent by merchant hosts. Fgure 1 shows an overvew of the Dstrbuted Reputaton Management scheme. Page 155

Bamasak & Zhang: A Dstrbuted Reputaton Management Scheme for Moble Agent-Based Applcatons (3) Request (4) Response TTP-host1 Agent owner A (1) TSS algorthm (7) TRU algorthm (2) Moble Agent (AS) (6) Moble Agent (TM) Merchant host B (5) Creates TM (3) Request (4) Response (3) Request (4) Response (3) Request TTP-host2 TTP-host3 (4) Response TTP-hostY Fgure 1. An Overvew of the Dstrbuted Reputaton Management Scheme 3. Reputaton Metrcs In our dstrbuted trust model, a TTP-host s reputaton s measured by two values, a trust level and a relablty level. Both values are the results of the TTP-host s aggregated transactonal behavours (reflected by ts responses) over a specfc past perod. The trust level reflects the truthfulness of the TTP-host n performng the transactons and the relablty level reflects ts avalablty n provdng the TTP servce. Both values are the functon of the followng parameters. (1) Transacton outcome feedback. Upon the executon of each transacton, the remote (merchant) host assgns a feedback measured n terms of trust and relablty values to each partcpatng TTP-host. The values assgned are related to the message reply sent by the TTP-host n relaton to ths transacton. For example, f the reply can pass ts verfcaton process postvely, the trust value wll be Yes. Otherwse, f the message reply fals the verfcaton process, perhaps due to a malcous ntent by the TTP-host or due to channel errors (repeated transmssons are appled), then the trust value wll be No. For the relablty value, f the merchant host dd not receve an expected message from the TTP-host after a certan perod of tme, the merchant wll assgn No to the relablty value assocated wth the TTP-host. Otherwse, f the expected message s receved, the relablty value wll be Yes. The per-transacton trust and relablty values reflect how well and relable ths TTP-host has fulflled ts part of the protocol executon n performng ths transacton. The overall trust and relablty values of a TTP-host are the aggregaton of the per-transacton trust and relablty values gven to the host n all the transactons nvolved by the TTP-host over a specfed past tme perod T h. (2) Total number of transactons performed. A smple aggregaton of feedbacks may fal to capture the true record of a TTP-host s transactonal behavour. For example, a TTP-host that has performed dozens of transactons but cheated on 1 out of every 4 occasons wll have a hgher aggregated reputaton value n comparson wth a TTP-host that has only performed 10 transactons and has been fathful n all of these occasons. In other words, the total number of transactons that the TTP-host has performed over the specfc past perod s also an mportant ndcator of ts reputaton and should be taken nto account for the calculaton of ts reputaton value. In our model, the average feedback value, measured as the rato of the sum of the feedbacks the TTP-host has receved over tme perod T h to the total number of transactons the TTP-host has taken part over the same perod, s used nstead of a smple sum. (3) Transacton value. The value of a transacton undertaken by a TTP-host s another mportant metrc for ts reputaton evaluaton [Km & Benbasat 2003]. Helpng wth a transacton wth a value of 1000 certanly worth more credts than that wth a value of 10. Smlarly, falure to perform a transacton of 1000 should be penalsed more than falng a 10 one. The soluton used by e-bay fal to address ths observaton, whch may let away a TTP-host that develop a sound reputaton value by beng honest n performng small value transactons, but behavng malcously wth large value ones. Our reputaton evaluaton algorthm has overcome ths weakness by havng an embedded rsk factor n the reputaton calculaton. The rsk factor s proportonal to the transacton value, and s used to wegh the feedback of the transacton gven by a merchant to a TTP-host. (4) Total number of faled ncdents. To further enhance farness n assessng transactonal behavour of a TTPhost, we have also ntroduced a counter to record the total number of faled or ncorrect responses made by the TTP-host wthn a specfed perod. A TTP-host wth ths counter value reachng a certan threshold wll have ts reputaton value reduced to the mnmum. In ths case, the TTP-host wll have to perform a consderable volume of honest transactons n order to rebuld ts reputaton. Page 156

Journal of Electronc Commerce Research, VOL 7, NO.3, 2006 (5) Source of the feedback. As the author n [Malaga 2001] stated: when consderng reputaton nformaton, we often account for the context and the source of the nformaton, the feedback from a party (.e. a merchant) who has a better reputaton should be weghed more n calculatng reputaton. 4. A Dstrbuted Reputaton Management Scheme To dynamcally select a subset of TTP-hosts among a set of N trusted hosts, {TTP-host, {1,..., N}}, based upon ther real-tme transactonal behavour and relablty to assst a moble agent to perform securty senstve tasks, two algorthms are requred. The frst, called TTP-hosts Subgroup Selecton (TSS) algorthm, allows the agent owner to select a subset of Y (<N) most trustworthy TTP-hosts from N avalable ones. The second algorthm, called Trust and Relablty Updatng (TRU) algorthm, allows the agent owner to evaluate and assgn trust and relablty values to each TTP-host that has taken part n a transacton based upon the feedback receved from hs/her merchant host. The two algorthms consttute our dstrbuted reputaton management scheme. 4.1 Assumptons The Dstrbuted Reputaton Management Scheme s desgned based upon the followng assumptons: The agent owner mantans a table TA (Trust Assessment) contanng trust and relablty values assocated wth each of the TTP-hosts that the agent owner has dealt wth n the past perod T h. An example TA s gven n Table 1. In the table, each row corresponds to one TTP-host contanng eght attrbutes: {TTP -ID, Trust, Rel, Sat, TotalTran, T-C, R-C, Fee}. The TTP -ID s the unque dentfer of host TTP-host, e.g. ts dstngushed name 1 [ITU-T 1997]. Trust and Rel are ts aggregated trust and relablty values, respectvely. The Trust attrbute ndcates the level of TTP-host s trustworthness (or honesty) n performng ts job. The Rel attrbute ndcates ts relablty level n servce provson. It s assumed that the ntal values of Trust and Rel are set to zeros ndcatng that the agent owner has not yet had any experence n dealng wth the TTPhost. These ntal values are greater than the values ndcatng a malcous TTP-host ( -1). In ths way, a newly deployed TTP-host wll not be treated unfarly. Sat refers to the average value of Trust and Rel,.e. Sat = Ω Trust + λ Rel, where Ω + λ = 1. The parameters, Ω and λ, represent the mpacts of Trust and Rel n calculatng the value of Sat, respectvely. The choce of values gven to these parameters s of the agent owner s preferences. For example, f an agent owner feels that Trust should wegh more than Rel, then he may assgn 0.7 for Ω and 0.3 for λ (these values are used n the example gven n table 1). The hgher the value of Sat, the more confdence the agent owner has n the TTPhost. TotalTran refers to the total number of transactons taken part by the TTP-host wth the agent owner durng the past perod T h. T-C s the total number of transactonal responses sent by TTP-host, whch have faled to pass the ntegrty verfcaton. R-C s the total number of occasons when TTP-host I fals to respond durng the perod. Fee specfes the amount of money TTP-host charges for provdng the TTP servce [Wang et al. 2005]. Ths attrbute may nfluence an agent owner s decson as whether or not a partcular TTP-host should be chosen to jon the AS (Actve Subgroup) lst. We also assume that table TA s sorted n a descendng order accordng to the satsfacton (Sat) values. Thus, the TTP-host wth the hghest satsfacton value shall be n the frst row of the table. The agent owner may decde an upper-lmt for the trust and relablty values accordng to hs/her preferences. Table 1. An example of a sngle row n table TA TTP -ID Trust Rel Sat TotalTran T-C R-C Fee 1. www.versgn.com 2. VerSgn Lmted 3. IT Department 4. South Melbourne 5. Vctora 6. AU 2 3 5.1 10 0 1 100 The agent owner also mantans a table MR (Merchant Reputaton) contanng reputaton values assocated wth each of the merchants that the agent owner has dealt wth n the past tme perod T m. As shown n table 2, each row of the MR table corresponds to one merchant contanng two attrbutes: {Merchant -ID, Rep }. Merchant -ID 1 The dstngushed name specfed n [3] conssts manly of sx felds: Common name (CN), Organsaton Name (O), Organsaton Unt (OU), Localty (L), State (S), and Country (C). Page 157

Bamasak & Zhang: A Dstrbuted Reputaton Management Scheme for Moble Agent-Based Applcatons s the merchant s unque dentfer. Smlarly, the dentfer can be the dstngushed name of the merchant. Rep specfes the level of reputaton Merchant has accumulated from ts prevous dealngs wth the agent owner durng perod T m. The ntal value assgned to Rep s zero (neutral), whch ndcates that the agent owner has no experence n dealng wth the Merchant yet. The value of Rep s updated by the agent owner as follows: +1 s added f the transacton outcome s postve, 0 f no response s receved from the merchant, and -1 f the transacton outcome s negatve. Table MR, mantaned by the agent owner, represents only the agent owner s opnon on the merchants he has dealt wth. Alternatvely, table MR may be stored at a publcly accessble server, n whch case the value Rep can be modfed by multple authorzed agent owners or customers. In the latter case, Rep wll represent the accumulated opnon about Merchant among the communty. The choce of the locaton of the MR table,.e. at the agent owner sde or n a publc server, s left to the users preferences. In our scheme, we adopt the former approach where the agent owner mantans ts own table MR. Table 2. An example of a table MR Merchant ID 1. www.dxons.co.uk 2. DSG Retal Lmted 3. Sales Department 4. Hemel Hempstead 5. Hertfordshre 6. UK Rep 2 The merchant, once agreed on a deal wth the moble agent, creates a table, TM, contanng the trust and relablty values for all the partcpatng TTP-hosts. Each entry n the table, correspondng to a TTP-host, conssts of three attrbutes: the frst refers to the TTP-host s ID; the second s ts trust value; and the thrd s ts relablty value. The trust attrbute wll be assgned wth one of the followng values (Yes, No, Unknown) and the relablty attrbute wll be assgned wth ether Yes or No, dependng on the outcome of the transacton nvolved wth the TTP-host. Table 3 gves an example of value settngs for table TM. Table 4 summarzes exemplar scenaros for the transacton outcomes and the trust and relablty values assocated to these outcomes. Table 3. An example of table TM Trust Rel TTP 1 -ID No Yes TTP 2 -ID Unknown No. TTP N -ID Yes Yes Table 4. The value settng for Trust and Relablty n varous scenaros Metrc Values Scenaros Trust Rel Yes No Unknown Yes No TTP-host sends a vald expected data to the merchant host. TTP-host sends an nvald expected data, or an unexpected data, or smply a token that cannot pass a specfed verfcaton, to the merchant host. The merchant has not receved a response from the TTP-host durng the protocol run. Therefore, he cannot make judgment whether ths TTP-host s trustworthy or not. The merchant host has receved a response, ether postve or negatve, from TTP-host. The merchant host has not receved any response from TTP-host durng the protocol run even f repeated requests have been made. Ths may be due to that the TTP-host s out of servce or the communcaton lnk between the merchant host and the TTP-host s broken down, etc. Once the values n the table are set, the merchant then passes t to the agent owner, va the moble agent, for hm to update table TA accordngly. Tables TA and MR are controlled by the valdty perods T h and T m, respectvely, to mantan the freshness of the relevant data and to reduce memory and computatonal expenses. 4.2. The TTP-hosts Subset Selecton (TSS) Algorthm Page 158

Journal of Electronc Commerce Research, VOL 7, NO.3, 2006 When an agent owner s ready to delegate a sgnature-sgnng task to hs agent, the frst thng s/he needs to do s to decde a subgroup of TTP-hosts that wll take part n performng the task collectvely and jontly wth the agent. Ths subgroup s called the actve subgroup (AS). To select the AS, the agent owner specfes a reputaton threshold Thr1 that s proportonal to the transacton value to be undertaken. Table 5 shows exemplar settngs of Thr1 n relaton to transacton values. Table 5. Exemplar settngs of Thr1 Transacton value Thr1 < 10 1 10-50 2 50-100 3 100-200 4.... 2000-2100 20 From the table, t can be seen that the hgher the transacton value the hgher the threshold Thr1 should be. The TSS algorthm then takes Thr1 and table TA as ts parameters to generate one or more (N>a subset >1)) TTPhosts such that ther aggregated Satsfacton value, computed usng equaton (1), s equal to or greater than Thr1. That s, Agg = j = 1 Sat (1) where, j s the number of TTP-hosts n the AS lst. The selecton process uses a top-down approach choosng the most trustworthy host frst. Ths decson s made ntutvely and other orders of selecton are possble dependng on customers preferences. If the frst TTP-host chosen has the satsfacton level that matches wth the threshold correspondng to the transacton value, then ths sngle TTP-host s suffcent. Otherwse, more TTP-hosts are chosen untl ther aggregated Satsfacton value reaches or exceeds Thr1. The pseudo code for the TSS algorthm s gven below. TTP-hosts Subset Selecton (TSS) Algorthm Input: table TA, Thr1 Output: AS member(s) Method: Intalze Agg to 0 For each row n TA do Compute Agg = Agg + Sat /* the Satsfacton value for TTP-host s added to the aggregated average Agg */ Insert TTP -ID n AS lst Increment TotalTran If Agg equals to or greater than Thr1 then Ext the loop Else Increment and start the next loop teraton As the members of the AS lst are chosen as the most trusted and relable among all N TTP-hosts, they are most lkely to perform the transacton securely and relably. In addton, accordng to the algorthm, the hgher the transacton value, the hgher the threshold Thr 1 wll be. As a result, the more TTP-hosts wll be selected to execute the transacton. It s therefore more dffcult for any sngle TTP-host to successfully forge a proxy sgnature or to manpulate the transactonal process. In other words, the transacton outcome wll be more lkely to come to a satsfactory concluson. 4.3. The Trust and Relablty Updatng (TRU) Algorthm The TRU algorthm s used by an agent owner to update trust and relablty values for each TTP-host upon the completon of each transacton. A merchant, once agreed on a deal wth the moble agent, creates a table TM and flls t wth the trust and relablty values of all the partcpatng TTP-hosts dependng on the transacton outcome, as descrbed n Secton 4.1. The merchant then passes table TM to the moble agent. Page 159

Bamasak & Zhang: A Dstrbuted Reputaton Management Scheme for Moble Agent-Based Applcatons The agent then comes back from the shoppng trp wth the TM table and submts t to the agent owner. The agent owner refreshes the contents of table TA accordng to the values receved n table TM by executng the TRU algorthm that takes tables TM, TA and the merchant s ID (Merchant-ID) as ts nput parameters. The algorthm performs a search to fnd a TTP-host n table TA untl a matchng TTP-host s found. Once found, the algorthm updates the Trust and Relablty values assocated wth the TTP-host n TA accordng to the values n TM and the reputaton value Rep k of the merchant Merchant k -ID (extracted from table MR) usng the equatons gven n table 6. Table 6. Equatons for updatng Trust and Relablty value n TA Values n TM Updates n table TA Yes NewTrust = OldTrust + (( Rep )/TotalTran ) k Trust No NewTrust = OldTrust (( Repk )/ TotalTran ) Unknown NewTrust = OldTrust Yes NewRel = OldRel + (( Repk )/ TotalTran ) Rel No NewRel = OldRel (( Rep )/ TotalTran ) k NewTrust s the latest value assgned to Trust n table TA. OldTrust refers to the aggregated Trust value from all prevous transactons. In other words, t s the value mantaned n table TA before ths transacton takes place. The same nterpretaton s applcable to NewRel and OldRel. If the total number of untrustworthy or unrelable transactons, as ndcated by T-C or R-C, reaches a certan threshold Thr 2, then the maxmum penalty γ, e.g. γ = -5, s appled to the values of NewTrust or NewRel, accordngly. ndcates a rsk factor specfed by the agent owner and t s n proportonal to the transacton value. The pseudo code for the TRU algorthm s gven as follows. Trust and Relablty Updatng (TRU) algorthm Input: table TM, table TA,, Thr 2, γ, Merchant-ID Output: updated table TA Method: Intalze k and to 0 For each row k n MR Search for Merchant k -ID that matches Merchant-ID If Found then /* Fetch the reputaton value assocated wth Merchant k -ID */ Rep = Rep k Ext the loop Increment k and start the next loop teraton For each row n TA Search for TTP -ID that matches TTP -ID n TM If Found then /* Update the Trust value n table TA */ If Trust _TM s Yes then NewTrust _TA = OldTrust _TA + (( Rep)/TotalTran ) If Trust _TM s No then Increment T-C If T-C = Thr 2 then Trust _TA = γ Else NewTrust _TA = OldTrust_TA - (( If Trust _TM s Unknown NewTrust = OldTrust Rep)/TotalTran ) /* Update the Relablty value n table TA */ If Rel _TM s Yes then NewRel _TA = OldRel _TA + (( Rep)/TotalTran ) If Trust _TM s No then Increment R-C Page 160

Journal of Electronc Commerce Research, VOL 7, NO.3, 2006 If R-C = Thr 2 then Else Rel _TA = γ NewRel _TA = OldRel_TA - (( Rep)/TotalTran ) An mportant feature of ths algorthm s that the step value of award/penalty for Trust and Relablty s not lnear. It gets smaller as the number of transactons performed by the TTP-host gets larger. In addton, the step value s also lnked to the transacton value through rsk factor. The larger the transacton value, the hgher the rsk the agent owner has to endure, and the more reward/penalty the TTP-host wll get shall the transacton succeed/fal. If a TTP-host repeatedly msbehaves or are unrelable, say, for Thr 2 tmes, ts Trust or Relablty values wll drop to γ. Furthermore, the step value s weghed accordng to the reputaton (Rep k ) of the source of the feedback (Merchant k ). A feedback from a hghly reputable merchant weghs more than that from a less reputable one. We beleve that these features have captured users expectaton and acceptance n real lfe. The followng example llustrates the mplcatons of these features. When a customer has performed many vald deals wth a specfc merchant, the customer wll be less lkely to move away from ths merchant f only a couple of deals wth small values (small ) have ended up n an unsatsfactory manner. However, havng a transacton wth a large value gone wrong may completely put the customer off. Ths s why the effect of a transacton outcome on the overall Trust or Relablty value and subsequently the satsfacton (.e. the reputaton) of a TTP-host should be dependent on the three factors: the value of a transacton; the total number of transactons that have been performed n the past perod concerned; and the reputaton of the merchant host. The two algorthms mentoned above jontly facltate ths non-lnear reputaton model. Accordng to our best knowledge, there has not been any such non-lnear reputaton model proposed n the lterature. 4.4 A workng example In ths secton, we use a workng example to llustrate the use of the TSS and TRU algorthms. The example wll show the state of the TA table before and after performng a partcular transacton by the agent owner. Let us assume the agent owner has been dealng wth four TTP-hosts n past tme perod T. The parameters Ω and λ are each assgned wth the value of 0.5. Table 7 shows the nformaton correspondng to each of the four TTP-hosts n table TA. Table 7. table TA pror to performng the transacton TTP-ID Trust Rel Sat TotalTran T-C R-C TTP 1 8 12 10 5 0 1 TTP 2 6 10 8 10 4 0 TTP 3 5 5 5 7 0 0 TTP 4 3 3 3 2 1 1 The agent owner now wants hs agent to perform a transacton worth of 150 on hs behalf, so the value of Thr 1 s set to 4. The TSS algorthm n ths case wll generate an AS lst, contanng only TTP 1 as ths TTP-host s satsfacton value (Sat) alone s greater than Thr 1. (It s worth notng that, f the transacton value s 2000, then Thr 1 would be 20, and the outcome of executng TSS algorthm wll be an AS lst contanng the frst three TTPhosts n table TA as ther aggregated Satsfacton value (23) s greater than Thr 1 ). The agent owner wll set the values of the requred parameters as follows: Thr 2 = 5, = 4, and γ = -5. Once the transacton s performed, the agent comes back wth a TM table (gven by Merchant that the agent has performed the transacton wth). Table 8 shows the contents of table TM. Table 8. Table TM receved from Merchant TTP-ID Trust Rel TTP 1 Yes Yes TTP 2 No Yes TTP 3 Unknown No The agent owner wll pck up Merchant s reputaton value Rep from table MR, whch s n ths example set as 6. Then the agent owner wll update table TA by executng the TRU algorthm. The updated TA s shown n table 9. Page 161

Bamasak & Zhang: A Dstrbuted Reputaton Management Scheme for Moble Agent-Based Applcatons Table 9. Table TA after performng the transacton TTP-ID Trust Rel Sat TotalTran T-C R-C TTP 1 12.8 16.8 14.8 6 0 1 TTPB 2-5 12.4 3.7 11 5 0 TTP 3 5 1.58 3.29 8 0 0 TTP 4 3 3 3 2 1 1 5. Concluson In ths paper, we have crtcally analysed the related work n the topc area of dstrbuted reputaton management. Based upon the analyss, fve mportant reputaton metrcs are defned to acheve a farer evaluaton of one s reputaton. A novel Dstrbuted Reputaton Management scheme s subsequently desgned based upon these metrcs. The scheme allows a party A, e.g. a customer, to dstrbute a securty senstve task among several most trustworthy TTP-hosts. Ths s acheved by frst choosng a subset of TTP-hosts wth the hghest trust and relablty levels. The scheme then credts/penalzes each TTP-host accordng to the feedback receved by A from party B, e.g. a merchant. Incorporatng ths reputaton management scheme n e-commerce applcatons can not only support secure delegaton of securty senstve tasks, such as sgnature sgnng, but also deter cheatng or msbehavng by e-commerce partcpants, thus mprovng our e-busness envronment. In addton, the dstrbuted dea used n the scheme allows the provson of robust securty servces As our future work, we plan to buld an agent-based sgnature delegaton framework by ntegratng the Dstrbuted Reputaton Management scheme wth the agent-based threshold proxy sgnature scheme proposed n [Obamasak 2004] to facltate robust and secure agent-based e-commerce actvtes. REFERENCES Bamasak, O. and N. Zhang, A Secure Proxy Sgnature Protocol for Agent-Based M-Commerce Applcatons, Proceedngs of the 9 th IEEE Symposum on Computer and Communcatons, IEEE Computer Socety, pp. 399-406, Alexandra, Egypt, July 2004. Bryant, A. and B. Colledge, "Trust n Electronc Commerce Busness Relatonshps," Journal of Electronc Commerce Research, Vol. 3, No. 2, pp. 32-39, 2002. ebay, 2004. Avalable at http://www.ebay.com (accessed 20-8-2004). ITU-T Recommendaton X.500, ISO/IEC 9594-1, 1997, Informaton technology - Open Systems Interconnecton - The Drectory: Overvew of concepts, models and servces. Jøsang, A. and R. Ismal, The Beta Reputaton System, Proceedngs of the 15 th Bled Electronc Commerce Conference, Bled, Slovena, 2002. Ketchpel, S. and H. Garca-Molna, Makng Trust Explct n Dstrbuted Commerce Transactons, Proceedngs of the 16 th IEEE Internatonal Conference on Dstrbuted Computng Systems (ICDCS96), pp. 270-281, 1996. Km, H., J. Baek, B. Lee and K. Km, Secret Computaton wth Secrets for Moble Agent usng One-Tme Proxy Sgnature, Proceedngs of the 2001 Symposum on Cryptography and Informaton Securty (SCIS2001), pp. 845-850, 2001. Km, D. and I. Benbasat, "Trust-Related Argument n Internet Stores: A Framework for Evaluaton," Journal of Electronc Commerce Research, Vol. 4, No. 2, pp 49-64, 2003. Kotzankolaou, P., M. Burmester, and V. Chrsskopoulos, Secure Transactons wth Moble Agents n Hostle Envronments, Proceedngs of the Ffth Australan Conference on Informaton Securty and Prvacy (ACISP 2000), LNCS, Vol. 1841, pp. 289-297, 2000. Lee, B., H. Km and K. Km, Strong Proxy Sgnature and ts Applcatons, Proceedngs of the 2001 Symposum on Cryptography and Informaton Securty (SCIS2001), pp. 603-608, 2001. Malaga, R., Web-based Reputaton Management Systems: Problems and Suggested Solutons, Electronc Commerce Research, Vol. 1, pp. 403-417, 2001. Mambo, M., K. Usuda and E. Okamoto, Proxy Sgnatures for Delegatng Sgnng operaton, Proceedngs of the Thrd ACM Conference on Computers and Communcatons Securty, pp. 48-57, 1996a. Mambo, M., K. Usuda and E. Okamoto, Proxy Sgnature: Delegaton of the Power to Sgn Messages, IEICE Trans. Fundamentals, E79-A, pp. 1338-1353, 1996b. Marsh, S. P., Formalzng trust as a computatonal concept, Ph.D. Thess, Unversty of Strlng, Strlng, UK, 1994. Reagle, J. M., Trust n a cryptographc economy and dgtal securty deposts: Protocols and polces, Master Thess, Massachusetts Insttute of Technology, Cambrdge, MA, 1996. Page 162

Journal of Electronc Commerce Research, VOL 7, NO.3, 2006 Sander, T. and C. Tschudn, Protectng Moble Agents aganst Malcous Hosts, Moble Agents and Securty, LNCS, Vol. 1419, pp. 44-60, 1998. Wang, C. L., L. Ye, Y. Zhang and D. Nguyen, "Subscrpton to Fee-Based Onlne Servce: What Makes Consumer Pay for Onlne Content?," Journal of Electronc Commerce Research, Vol. 6, No. 4, pp. 304-311, 2005. Xong, L. and L. Lu, A Reputaton-Based Trust Model for Peer-to-Peer ecommerce Communtes, Proceedngs of the IEEE Internatonal Conference on E-Commerce (CEC 03), pp. 275-284, 2003. Yahoo! Auctons, 2004. Avalable at http://auctons.yahoo.com. (Accessed 20/8/2004). Zachara, G. and P. Maes, Trust Management through Reputaton Mechansms, Appled Artfcal Intellgence, Vol. 14, pp. 881-908, 2000. Page 163