Reputation Framework Introduction

Enterprise Computing Laboratory
Brigham Young University

Phillip J. Windley, Ph.D., Director

Document Version: 1.0
May 17, 2006

The Enterprise Computing Laboratory (ECLab) at BYU is developing a framework for building reputation systems. As a framework, the system, called RepKept, does not calculate the reputation for any specific application without the addition of code, in the form of plug-ins, that specializes it to a specific application.

RepKept was designed and built by students in the CS601R (Middleware) class during Winter term, 2006. The students reviewed and presented dozens of papers on reputation and built the reputation framework as a class project using an agile methodology using 3 two-week interactions. The system is now being used as the basis for research into reputation and identity in the ECLab.

Underlying Concepts and Assumptions

RepKept was designed in accordance with several underlying principles. While we recognize that these principles are not necessarily universally acknowledged, we believe that they are important to the kind of system we wanted to build

Reputation is directed. First, we believe that reputation is "your story about me." This implies that you should be able to tell that story however you like and without my permission using whatever publicly available facts you have. We call the reputation creator the relying party and the entity that is the subject of the reputation the user.

Reputation is based on identity. Reputation is based on and tied to identifiers. Identity credentials can be used to transfer trust from one context to another.

Reputation is calculated. For our purposes, reputation is a function as follows:

R_u = F_rp(I_u,Tx_u,u',R_u)

where

rp == replying party id
u == user id
u' == all users
I_u == a vector of verified identifiers for u
Tx_u,rp == a vector of transactions between u and rp
R_u == a vector of ratings and endorsements for u

Transactions are jointly owned. Transactions are between two parties and contain facts pertinent to the interaction and a timestamp. As implied in the preceding function, transactions are jointly owned by the parties to the transaction. Both can see them.

Transactions are persistent. Once the system has recorded a transaction, it cannot be deleted by either party to the transaction. A later transaction may record that it was nullified, but cannot remove it.

Transparency is important. While reputation is someone else's story about you, our system is designed to allow users to see any information the system knows about them (e.g. transactions they are party to) and to see any reputation queries about them, what the results were, and how the result was arrived at.

Architecture

The architecture of RepKept is based on the foregoing principles. Figure 1 shows the high-level block diagram architecture for RepKept.

Figure 1: Architecture of reputation framework showing plugin for blog comments

The framework is identity system neutral. RepKept is not an identity system, but is meant to rely on one or more existing identity systems for authentication and user IDs.

The framework allows users to claim and verify identifiers. At present, these identifiers are limited to email addresses and URLs, but this is only an implementation limitation. Email addresses are verified by sending the email address a message asking the user to click on a URL to claim the email address in RepKept. URLs are verified using MicroIDs (see http://www.windley.com/archives/2006/03/microid_a_micro.shtml).

Replying parties can use the built-in rules engine to create rule sets for calculating reputation based on information in the system as well as other reputation information from the Internet. A global set of system-defined rules can be used as-is or customized by relying parties for their particular purpose.

The plugin architecture is the device for allowing the framework to be specialized for a particular task. The plug-in defines domain specific transactions that are to be recorded, the API that replying parties will use to record transactions, and any functions that are added to the rules-engine specific to the domain.

Current Implementation

RepKept was implemented in Ruby on Rails. The system includes the Rools rules engine (see http://rools.rubyforge.org/). The system uses OpenID as the underlying identity system. The system does not store or use ratings or endorsements in calculating.

As part of the development and testing, we created a plug-in for blog comment reputation. The plug-in allows the framework to be used to query the reputation of people leaving comments on the relying party's blog. Any actions taken by the relying party with respect to the comment (e.g. deleting it, approving it, etc.) are recorded as transactions.

Future Work

Here are some of the directions that we have considered as future work:

• Add the ability for users to rate or endorse other users and for those ratings and endorsements to be used as part of a reputation calculation.
• Develop a system for users to specify their relationship to each other. This could be based on other social networks, OMPL from Bloglines or other sites, FOAF data, and so on.
• Extend the system to include data from other sites on the Web. For example, much data is available about URLs. This could be useful in determining the reputation of those URLs and the other identifiers associated with them.

Conclusion

Reputation is important many domains and while a lot of research has been done on calculating reputation, no general purpose, flexible platform for experimenting with reputation exists. RepKept has been designed to serve that purpose.

Last Modified: Thursday, 18-May-2006 21:03:20 UTC