Reputation Capital and Exchange Mechanisms
An OpenPrivacy working paper

Date: May 2002
Version: 0.4 **DRAFT**
Authors: Fen Labalme <fen at>


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

Privacy is ensured through the use of Nyms that have some very special properties. Given We can show:
  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 proof is forthcoming, largely due to the fact that I really need a good system for writing cryptographic proofs that involve mathematical symbols such as exponentiation, sums, group operations, etc. It's been years since I've used LaTeX, but I can see it again in my future...

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

The process by which reputations are mapped between each other is straightforward. First, some terminology: Definition: a reputation is a signed 3-tuple containing an identifying pseudonymous certificate (Nym), a Reference and a Value. Thus:

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

        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")

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

        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).

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

        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)

        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


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.)


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).

Copyright © 2001 Fen Labalme and