From: cvs@openprivacy.orgCVS update: openprivacy/htdocs/notes/reputations
Date: Wednesday December 13, 19100 @ 13:45
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/reputations
-----------------------------------
Update of /usr/local/cvsroot/openprivacy/htdocs/notes/reputations
In directory openprivacy.org:/home/fen/projects/openprivacy/htdocs/notes/reputations
Modified Files:
requirements.txt
Log Message:
merged some updates
*****************************************************************
File: openprivacy/htdocs/notes/reputations/requirements.txt
CVSWEB Options: -------------------
CVSWeb: Annotate this file: http://openprivacy.org/cgi-bin/cvsweb/cvsweb.cgi/openprivacy/htdocs/notes/reputations/requirements.txt?annotate=1.32
CVSWeb: View this file: http://openprivacy.org/cgi-bin/cvsweb/cvsweb.cgi/openprivacy/htdocs/notes/reputations/requirements.txt?rev=1.32&content-type=text/x-cvsweb-markup
CVSWeb: Diff to previous version: http://openprivacy.org/cgi-bin/cvsweb/cvsweb.cgi/openprivacy/htdocs/notes/reputations/requirements.txt.diff?r1=1.32&r2=1.31
-----------------------------------
Index: openprivacy/htdocs/notes/reputations/requirements.txt
diff -u openprivacy/htdocs/notes/reputations/requirements.txt:1.31 openprivacy/htdocs/notes/reputations/requirements.txt:1.32
--- openprivacy/htdocs/notes/reputations/requirements.txt:1.31 Wed Dec 13 12:37:52 2000
+++ openprivacy/htdocs/notes/reputations/requirements.txt Wed Dec 13 13:45:04 2000
@@ -1,18 +1,9 @@
-*- indented-text -*-
-$Id: requirements.txt,v 1.31 2000/12/13 20:37:52 burton Exp $
+$Id: requirements.txt,v 1.32 2000/12/13 21:45:04 fen Exp $
Reputation Server Requirements: top level feature list
-(KAB) We need to put in a requirement that all J/Ps have Public Keys.
-(KAB) We should start breaking this down into a specification document.
-Requirements should be something like a database, that we dont' worry about this
-problem. The spec should be that we need to implement X feature and document how
-we will do it.
-
- "The OpenPrivacy Platform enables a distributed, secure marketplace
- for anonymous user demographic and profile information."
-
A. === Definitions ===
An agent
@@ -37,9 +28,8 @@
B. === General ===
1. decentralized, peer-to-peer
- a. agent => reputation server [ => broker ]
- b. agents aren't programmed to one reputation server, the server to connect
- with is dynamically determined (based on load, price, reputation, etc)
+ a. agent is the base for a reputation server [ is the base for a broker ]
+
2. a reputation can be attached (grafted) to any URI
a. note URIs can reference non-networked resources (books, cars, etc.)
b. all reputations are URL-addressable
@@ -50,15 +40,13 @@
agent/computer resources can not be certain that a given reputation
server holds the value it needs... Reputation server reputation can
grow based on this.
-[(kab) it is only 'possible' that a reputation may be addressable, an
-agent/computer resources can not be certain that a given reputation server
-holds the value it needs... Reputation server reputation can grow based on
-this.]
-[(fen) on the contrary, I believe that all reputations must be addressable
-- they must in fact be XML DSigs of the sort we have defined in /src/xml/
-reputation-opinion-example.xml. It may not be accessible (the server may be
-down or it may have been deleted), but it must be addressable.]
+Note: a reputation may not be publicly addressible/accessible when stored on
+ a server/agent that does not wish to share it. Of course, the owning
+ server/agent may use the information contained within in order to
+ direct a course of action, including grafting additional reputation to
+ it.
+
C. === Security, Authentication, Privacy, Validation ===
Key:
@@ -105,7 +93,7 @@
c. intra-server communications can be signed and encrypted
Note: Getting data in and out of the system securely is not part of this spec
-(KAB) Fen... this is a requirement document. Gettind data in and out IS a
+(KAB) Fen... this is a requirement document. Getting data in and out IS a
requirement.
D. === Data store facility ===
@@ -126,17 +114,13 @@
ii. insufficient_permissions_for_operation
iii. timeout
iv. (what else?)
- e. define admin features
- i. size of database (Kb)
- ii. number of objects
- iii. (what else?)
- iv. generally this is out-of-scope for a reputations system. it should
- be provided by an underlying database facility.
- [(fen) kab: are you saying that admin features are
- out-of-scope? should we not define a minimum set required?]
- f. should uses a standardized interface.
+ e. should uses a standardized interface.
i. SOAP, XQL, etc. (TBD: this technical area is very limited to-date)
+Note: database admininstration features such as database.size and
+ database.numberOfObjects are outside the scope of these requirements
+ and are left to the implementation
+
2. Standardized data format specification
a. based on the xmldsig namespace (xmlns="http://www.w3.org/2000/09/xmldsig#")
b. extended by:
This archive was generated by hypermail 2b30 : Mon Jan 22 2001 - 15:52:14 PST