Reputation Capital and Exchange Mechanisms
An OpenPrivacy working paper

Overview

In legacy reputations systems, mechanisms such as trust, ratings, certifications and karma contribute to an entity's reputation capital. These mechanisms, collectively known as trust metrics (examples include Pymmetry, Advogato, and Slashdot moderation) are examples of a Reputation Calculation Engine (RCE), a pluggable component of the OpenPrivacy Reputation Management Framework (RMF). While in use, these RCEs may be themselves evaluated on their efficacy, value, correctness, etc. thus adding to their reputation. Further, reputation exchange mechanisms exist that enable translation of an entity's reputation capital accrued on one system to another.

A reputation exchange is similar to a currency exchange, but trades in reputation capital instead of money. No one can force you to start using a new currency but if all your friends - and you - move to France, you'll want to start using francs. The Reputation Management Framework provides a plug-in architecture for Reputation Calculation Engines that make this sort of "reputation-exchange" feasible. The rules governing the "exchange rate" are set by the administrators of the respective systems - poor exchange rates will discourage newcomers while inflated exchange rates will disgruntle the existing community. A particularly compelling feature is that reputation exchanges - unlike their currency-backed counterparts - are not zero-sum, in that the process of converting a reputation does not destroy the old one - it merely enables some reputation carry-though systems.

Thus, a community that uses e.g. Pymmetry today can easily switch, if and when a better trust metric (or a newer version of Pymmetry ;-) comes along. Or if a person on a Pymmetry-based system wants to move some of their reputation capital to a moderation-based system, they will be able to do so as long as their respective admins have linked in the reputation management framework and have defined some rules for the reputation exchange.

Nym Properties

• T = (Trusted) Parent Nym that can create Child Nyms
• Ci, Cj and Ck are a set of child Nyms created by the same parent T
• Ei is a child Nym from another parent

1. Ci, Cj, and Ck cannot prove that T is their Parent
2. Ci, Cj, and Ck cannot prove they are siblings
3. T can separately prove parenthood of Ci and/or Cj
1. without also leaking information about any other siblings, e.g. Ck
4. T can anonymously prove Ci and Cj are siblings
1. without also leaking information about any other siblings, e.g. Ck
2. and without leaking information that points to T as C's parent
5. T cannot prove anything about Ei

The key feature of these nyms is the ability of a parent nym to be able to beget many independent child nyms and then later anonymously prove any subset are siblings. With respect to the topic of this paper, this enables an owner of two different identities to prove that they are indeed one and the same person, without giving away the owner's true name.

The Reputation Exchange

• Nym = a unique pseudonymous "author"
  it is particularly useful if the author can later prove ownership
• Ref = a component that references the object of interest
  minimally, a URI
• Payload = a generic typed object for holding information
• Val = (Payload)+ = a value, implemented using one or more Payload objects
  additionally, meta-data, such as creation and expiry dates, can be contained in a Payload
• Sig = a signature that guarantees immutability of the reputation object

• Rep = [[Nym, Ref, Val] Sig]

Mapping between RCEs that use different trust metrics (e.g. Advogato and Slashdot) is accomplished by first attaching an OpenPrivacy-style Nym to the local namespace user name, and then by authenticating a match between these secure nyms. A simplified example follows, in which user "broadcatch" on Slashdot is mapped to the same user "fen" in Advogato.

    Notational conventions:
        Ys(foo)  indicates that Y signed "foo" with her secret key

    Given:
        Slashdot user "broadcatch" has earned 13 Karma points
        Advogato user "fen" has earned the certification of "Observer"
        Slashdot user "broadcatch" and Advogato user "fen" are the same person
        Slashdot and Advogato have both linked with the Sierra RMF library

    Thus, Advogato and Slashdot could make these reputational statements:
        As(Ap, "fen",        "certification=Observer")
        Ss(Sp, "broadcatch", "karma=13")

    Goal:
        Fen wants Advogato to know how much karma he has on Slashdot, but
            without giving away his Slashdot identity 

    Claim:
        Any entity that can prove ownership of two nyms from different
        sites can effectively translate their reputation capital from
        one site to the other (assuming the sites allow such swapping).

    Let:
        [Ap, As] = Advogato's [public, secret] key
        [Sp, Ss] = Slashdot's [public, secret] key

    Introduce:
        Fen      = the owner of the two identities to be merged
        [Na, Ns] = public keys (nyms) created by Fen for [Advogato, Slashdot]
        eXchange = a reputation exchange agent

    Protocol part 1:
        Fen -> Advogato:      [uname="fen", pw=xxx, Nym=Na, x=eXchange]
        Advogato -> eXchange: As(Na)
        Fen -> Slashdot:      [uname="broadcatch", pw=yyy, Nym=Ns, x=eXchange]
        Slashdot -> eXchange: Ss(Ns)

    Notes:
        eXchange now has two unrelated nonces for pseudonymous users
        Fen anonymously proves sibling nature of Na and Ns
            Can this proof be revoked?
        While one could ask Slashdot and Advogato to destroy their Nx nyms,
            this is not secure.  Instead, prove only via blinded authentication.

    Exchange request (optional):
        Fen -> Slashdot:      [Ns, getKarma, x=eXchange]

    Protocol part 2:
        Slashdot -> eXchange: Ss(Ns, 13)
        eXchange -> Advogato: [As(Na), Ss(Ns, 13)]

    In addition
        While eXchange knows that Na and Ns are siblings, Advogato doesn't
        Therefore, Fen must prove the sibling nature of [Na, Ns] to Advogato
            Describe mechanism of secure proxied verification
    

Discussion

Now that the exchange is set up and it has proof that two nonces are the same identity, cross-community reputation updates can occur at any time. For example, if Slashdot revised user broadcatch's karma, protocol 2 would be rerun with new values. (This is why the exchange request is optional, as once the communities are aware of the exchange and the exchange knows the sibling nature of the entities involved, reputation exchange can occur asynchronously.)

Attacks

If the communities and exchange all conspire together, then a link between user names could be made. In the given example, this means that it could become public knowledge that the Slashdot user "broadcatch" is the same as the Advogato user "fen." This can be prevented using blinded authentication and zero-knowledge proofs (forthcoming).