CVS update: openprivacy/htdocs/notes/reputations

From: cvs@openprivacy.org
Date: Mon Dec 11 2000 - 16:52:49 PST

Date: Monday December 11, 19100 @ 16:52
Author: burton
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:/tmp/cvs-serv16630

Modified Files:
        requirements.txt
Log Message:
...

*****************************************************************
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.11

CVSWeb: View this file: http://openprivacy.org/cgi-bin/cvsweb/cvsweb.cgi/openprivacy/htdocs/notes/reputations/requirements.txt?rev=1.11&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.11&r2=1.10

-----------------------------------

Index: openprivacy/htdocs/notes/reputations/requirements.txt
diff -u openprivacy/htdocs/notes/reputations/requirements.txt:1.10 openprivacy/htdocs/notes/reputations/requirements.txt:1.11
--- openprivacy/htdocs/notes/reputations/requirements.txt:1.10 Mon Dec 11 14:23:07 2000
+++ openprivacy/htdocs/notes/reputations/requirements.txt Mon Dec 11 16:52:49 2000
@@ -1,4 +1,4 @@
-$Id: requirements.txt,v 1.10 2000/12/11 22:23:07 burton Exp $
+$Id: requirements.txt,v 1.11 2000/12/12 00:52:49 burton Exp $
 
 Reputation Server Requirements: top level feature list
 
@@ -16,13 +16,20 @@
     a. creation of identity I (public/private key pair)
        (may have multiple identities)
     b. creation of child J (public/private key pair spawned from N)
- c. ability to sign/encrypt data packet with J[s]
+ (kab) what do you mean (spawned from N???... it should not be based on
+ anything)
+ . ability to sign/encrypt data packet with J[s]
     d. ability to verify/decrypt data packet with J[p]
     e. N has ability to create new J as owner of several J data packets
 
 2. Object validation
     a. does the object that was grafted to still exist
+ (kab) this depends on the object actually being network addressable instead
+ of just a URI. IE not possible in all situations.
     b. has the object that was grafted to changed?
+ (kab) again... this depends on being network addressable... it may work if
+ it is time based... IE "this is valid as of Dec 7 but may have changed since
+ them. "
     c. are signatures valid
     d. are signatures reputable?
 
@@ -91,7 +98,8 @@
         payload (data conformant to the data format spec)
         session key (e.g., a pseudo-random number)
         some sort of TTL-like value (e.g., Freenet's hops-to-live)
-
+ (kab) session key will be the J
+
 works with any message-based asynchronous data transport mechanism
     (e.g., UDP, SMTP, ICQ, Carrier Pigeon, etc.)
 

This archive was generated by hypermail 2b30 : Mon Jan 22 2001 - 15:52:14 PST