Decision-Making in the Reputation Management System (RMS)

Decision-making in the Reputation Management System (RMS) is enacted on behalf of an Internet auction user deciding whether or not to bid on an item or whether or not to sell an item to a given high bidder. The decision-making process is different in each case, and each process is described as follows.

3.5.4.1 Decision to Bid

The Application Program Interface (API) links an Internet auction user, p, in the role of buyer to the SECURE decision-making process at the point when the user is determining whether or not to place a bid on an item that auction user, q, is selling. The request passes from the API to the SECURE Request Analyzer (RA), and contains all of the information SECURE needs to initialise decision- making, as illustrated in Figure 38.

Bid request Request query Should I place a bid?

Identification information Authenticated username of principal q

Role context, i.e., q’s role Seller

Environmental context (category) Item category number Environmental context (price) Current price of item

Temporal context Current date/time

Context information

Interaction dynamic context Current bidders {b1, b2, …bn}

Figure 38: Bid request

The bid request contains the query ‘should I place a bid’, which means ‘what is the likelihood based on evidence about q that q, interacting in the role of seller of an item in the specified item category of the specified price at the specified date and time will behave in a trustworthy manner and that q is not colluding with any other current bidder, b?’ In our application, trustworthy means that a seller ships an item as described, i.e., {i, s, d}.

The RA passes the request to the Entity Recognition (ER) component, which allocates 100% reliability to q’s username and passes the request to the Trust Calculator (TC).

The TC queries the Trust Lifecycle Manager (TLM) for evidence about p’s observations about q, i.e.,

pq

obs

T , and about other user’s recommendations about q, i.e.,

rq

rec

T , where r is a recommender of q. The TC also queries the Interaction Calculator (IC) for Φ_qb about each seller-bidder pair in the current auction.

The TLM requests evidence about q from the Evidence Manager (EM), which retrieves evidence about q from the auction system reputation database. Evidence is returned to the TLM in the form of interaction histories Hpq, i.e., event configurations comprising p’s observations of q, and Hrq, i.e.,

recommender of q.) The TLM also queries the Interaction Manager (IM) for πl_pr for each recommender of q for which it has received an interaction history, and is returned l

pr

π for each recommender.

The TLM evaluates Hpq and Hrq using the eff and eval functions. The eff function analyses the effect

of each piece of evidence, i.e., event configuration, in an interaction history to determine whether the evidence is supporting, contradicting, or inconclusive about the request proposition {i, s, d}, as well as whether or not the piece of evidence is contextually relevant to the request according to role and item category. Additionally, for each interaction history, Hrq, the eff function applies recommendation

weighting using πl_pr to discount recommendations. The eval function sums the effects of all evidence for Hpq and Hrq, independently of one another, and applies time fading. This process results

in trust values, i.e., (s, i, c)-triples

pq

obs

T and

rq

rec

T , which are returned to the TC.

In addition to dealing with the TLM’s request for πl_pr, the IM receives a request from the IC to evaluate the likelihood of collusion between q and each current bidder, b. The IM requests evidence in the form of auction system observations about interactions between q and b, i.e., the interaction history Hqb, and applies the eff and eval functions (no contextual relevance, recommendation

weighting, or time fading occur in this application of these functions, as we are interested in all of q’s potential colluding interactions with b and as they are system observations rather than recommendations). The resulting collusion factors, Р, В, Т, and Λ are passed to the IC.

The IC weights Р, В, Т, and Λ according to its weighting policy and combines them to produce Φ_qb, which it passes to the TC.

The TC combines pq obs T and rq rec T to produce pq ov

T , a trust value that represents p’s overall trust in

q. The TC passes

pq

ov

T and Φ_qb to the Risk Evaluator (RE).

The RE queries the Risk Configurator (RC) for the contextual risk of interacting in the item category specified in the request. The RC queries the EM for updated information regarding the category risk and returns category risk to the RE. The RE calculates the risk of interacting with q in this context as well as the likelihood of collusion in the current auction. It passes the results to the Access Control (AC) component.

The AC enacts policy to determine whether or not p should enter into an interaction with q and the current bidset based on the risk levels of q acting in an undesirable manner and of collusion between q

and any bidder, b. The decision, as well as a statement about the risk of exposure to untrustworthy behaviour and colluding behaviour, is passed to the RA, which outputs the decision to the user via the API.

3.5.4.2 Decision to Sell

The Application Program Interface (API) links an Internet auction user, p, in the role of seller to the SECURE decision-making process at the point when p is determining whether or not to accept a high bid made by q at the end of the auction. This request is illustrated in Figure 39.

Sale request Request query Should I accept a bid?

Identification information Authenticated username of principal q

Role context, i.e., q’s role Buyer

Environmental context (category) Item category number Environmental context (price) Current price of item Context information

Temporal context Current date/time

Figure 39: Sale request

The sale request contains the query ‘should I accept a bid’, which means ‘what is the likelihood based on evidence about q that q, interacting in the role of buyer of an item in the specified item category of the specified price at the specified date and time will behave in a trustworthy manner, i.e., {i, p} meaning pays for the item?’

The RA passes the request to the Entity Recognition (ER) component, which allocates 100% reliability to q’s username and passes the request to the Trust Calculator (TC).

The TC queries the Trust Lifecycle Manager (TLM) for evidence about p’s observations about q, i.e.,

pq

obs

T , and about other user’s recommendations about q, i.e.,

rq

rec

T , where r is a recommender of q. The Interaction Calculator is not invoked for this type of decision.

The TLM requests evidence about q from the Evidence Manager (EM), which retrieves evidence about q from the auction system reputation database. Evidence is returned to the TLM in the form of interaction histories Hpq, i.e., event configurations comprising p’s observations of q, and Hrq, i.e.,

event configurations comprising recommender r’s observations of q. (Hrq is returned for each

recommender of q.) The TLM also queries the Interaction Manager (IM) for πl_pr for each recommender of q for which it has received an interaction history, and is returned πl_pr for each recommender.

The TLM evaluates Hpq and Hrq using the eff and eval functions. The eff function assess each piece of

evidence, i.e., event configuration, in an interaction history to determine whether the evidence is supporting, contradicting, or inconclusive about the request proposition {i, p}, as well as whether or not the piece of evidence is contextually relevant to the request according to role and item category. Additionally, for each interaction history, Hrq, the eff function applies recommendation weighting

using l pr

and Hrq, independently of one another, and applies time fading. This process results in trust values, i.e., (s, i, c)-triples pq obs T and rq rec

T , which are returned to the TC. The TC combines pq obs T and rq rec T to produce pq ov

T , a trust value that represents p’s overall trust in

q. The TC passes

pq

ov

T to the Risk Evaluator (RE).

The RE queries the Risk Configurator (RC) for the contextual risk of interacting in the item category specified in the request. The RC queries the EM for updated information regarding the category risk and returns category risk to the RE. The RE calculates the risk of interacting with q in this context. It passes the result to the Access Control (AC) component.

The AC enacts policy to determine whether or not p should enter into an interaction with q based on the risk levels of q acting in an undesirable buyer manner. The decision, as well as a statement about the risk of exposure to untrustworthy behaviour, is passed to the RA, which outputs the decision to the user via the API.