From: cvs@openprivacy.orgCVS update: openprivacy/htdocs/notes
Date: Tuesday February 27, 19101 @ 10:39
Author: fen
CVSWEB Options: -------------------
Main CVSWeb: http://openprivacy.org/cgi-bin/cvsweb/cvsweb.cgi
View this module: http://openprivacy.org/cgi-bin/cvsweb/cvsweb.cgi/openprivacy/htdocs/notes
-----------------------------------
Update of /usr/local/cvs/public/openprivacy/htdocs/notes
In directory giga:/home/fen/projects/openprivacy/htdocs/notes
Modified Files:
whitepaper.shtml
Log Message:
updated and expanded reputation and nym services
probably could use some pseudocode...
now have to expand opinion store, bias and rce...
*****************************************************************
File: openprivacy/htdocs/notes/whitepaper.shtml
CVSWEB Options: -------------------
CVSWeb: Annotate this file: http://openprivacy.org/cgi-bin/cvsweb/cvsweb.cgi/openprivacy/htdocs/notes/whitepaper.shtml?annotate=1.25
CVSWeb: View this file: http://openprivacy.org/cgi-bin/cvsweb/cvsweb.cgi/openprivacy/htdocs/notes/whitepaper.shtml?rev=1.25&content-type=text/x-cvsweb-markup
CVSWeb: Diff to previous version: http://openprivacy.org/cgi-bin/cvsweb/cvsweb.cgi/openprivacy/htdocs/notes/whitepaper.shtml.diff?r1=1.25&r2=1.24
-----------------------------------
Index: openprivacy/htdocs/notes/whitepaper.shtml
diff -u openprivacy/htdocs/notes/whitepaper.shtml:1.24 openprivacy/htdocs/notes/whitepaper.shtml:1.25
--- openprivacy/htdocs/notes/whitepaper.shtml:1.24 Tue Feb 27 01:09:31 2001
+++ openprivacy/htdocs/notes/whitepaper.shtml Tue Feb 27 10:39:03 2001
@@ -9,7 +9,7 @@
</head>
<body bgcolor="#ffffff">
- <!-- $Id: whitepaper.shtml,v 1.24 2001/02/27 09:09:31 fen Exp $ -->
+ <!-- $Id: whitepaper.shtml,v 1.25 2001/02/27 18:39:03 fen Exp $ -->
<h1>OpenPrivacy - Building a Better Internet</h1>
@@ -124,15 +124,26 @@
avail themselves of targeted, high-quality profile information with
the full cooperation and confidence of a pseudonymous user.
</p>
- <h3>Reputation Services</h3>
+ <h3><a name="servant">Reputation Services</a></h3>
<p>
We introduce a set of <i>Reputation Services</i> that form the
- cornerstone of the OpenPrivacy framework. A reputation server -
+ cornerstone of the OpenPrivacy framework. These services provide a
+ standard reputation framework that can be used by any community,
+ supporting an unlimited numbers of mechanisms to create, use and
+ calculate results from accumulated reputation. The implementor of
+ these services can nest or reuse existing reputation calculation
+ engines or roll their own. They gain the ability to query remote
+ RCEs, to perform ontological forwarding, and share all or part of
+ their users profile database with other communities without
+ violating user privacy.
+ </p>
+ <p>
+ A reputation servant - our name for the combined client and server
which implements the reputation services - acts as a peer in a
distributed network, supplying the capability to create, store and
forward opinions (either autonomously or under user control), manage
bias structures (including creation and validation) and calculate
- reputations. A Reputation Server implements the following
+ reputations. A reputation servant implements the following
interfaces:
</p>
<blockquote>
@@ -140,12 +151,31 @@
<p>
OpenPrivacy uses a <i>nym service</i> to to create and manage a
set of pseudonymous virtual users - generally represented by
- public-key pairs - that inhabit OpenPrivacy space. These nyms are
- hierarchically organized within the service, so that a few main
- (parent) nyms can beget a large number of child nyms and child
- nyms can recursively employ a nym service to beget grandchildren.
- A validation mechanism exists that can assert and prove that a set
- of child nyms were created from the same parent.
+ public-key pairs - that inhabit OpenPrivacy space. A primary, or
+ "parent" nym can be created by the nym service, and then use the
+ service to beget any number of child nyms which can then
+ recursively employ a nym service to beget grandchildren. This
+ creates a hierarchical nym-space in which child nyms cannot be
+ linked by a third party as originating from the same parent, but a
+ parent can execute a validation mechanism to create an anonymous
+ certificate proving that a set of child nyms were created from the
+ same parent. (And of course, the parent can do so non-anonymously
+ if it so chose.)
+ </p>
+ <p>
+ This is a key facility (pun intended) of the OpenPrivacy platform,
+ as anonymity can too easily be pierced by what is known as "data
+ triangulation." For example, knowing only the age, zip code, and
+ the make and model of a heretofore anonymous person's car can
+ narrow the population quite a bit. But if each of these data
+ points were stored under a different nym, then the same data
+ exists, but it is unconnected. Others can make opinions as to
+ what data is connected - and gain or lose reputation according to
+ the value and usefulness of their opinions - but only the owner
+ can prove it. Mechanisms exist that allow for such proof to be
+ tied to a single receiving party, such that further dissemination
+ of the proof without permission would directly - and adversely -
+ affect the reputation of the receiver.
</p>
<h4>Opinion Store</h4>
<p>
This archive was generated by hypermail 2b30 : Tue Feb 27 2001 - 10:39:06 PST