|Authors:||Fen Labalme <fen at openprivacy.org>|
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.
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.
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
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 OpenPrivacy.org.||http://www.openprivacy.org/papers/200104-repcap.html|