From: cvs@openprivacy.orgCVS update: openprivacy/htdocs
Date: Wednesday October 25, 19100 @ 15:00
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
-----------------------------------
Update of /usr/local/cvsroot/openprivacy/htdocs
In directory openprivacy.org:/home/fen/projects/openprivacy/htdocs
Modified Files:
opr.shtml
Log Message:
separated out Phase II; added som detail from research.txt
*****************************************************************
File: openprivacy/htdocs/opr.shtml
CVSWEB Options: -------------------
CVSWeb: Annotate this file: http://openprivacy.org/cgi-bin/cvsweb/cvsweb.cgi/openprivacy/htdocs/opr.shtml?annotate=1.14
CVSWeb: View this file: http://openprivacy.org/cgi-bin/cvsweb/cvsweb.cgi/openprivacy/htdocs/opr.shtml?rev=1.14&content-type=text/x-cvsweb-markup
CVSWeb: Diff to previous version: http://openprivacy.org/cgi-bin/cvsweb/cvsweb.cgi/openprivacy/htdocs/opr.shtml.diff?r1=1.14&r2=1.13
-----------------------------------
Index: openprivacy/htdocs/opr.shtml
diff -u openprivacy/htdocs/opr.shtml:1.13 openprivacy/htdocs/opr.shtml:1.14
--- openprivacy/htdocs/opr.shtml:1.13 Mon Sep 25 17:19:38 2000
+++ openprivacy/htdocs/opr.shtml Wed Oct 25 15:00:15 2000
@@ -1,7 +1,7 @@
<!--#include virtual="/includes/top.html"-->
<!--#include virtual="/includes/navigation.html"-->
-<!-- $Id: opr.shtml,v 1.13 2000/09/26 00:19:38 fen Exp $ -->
+<!-- $Id: opr.shtml,v 1.14 2000/10/25 22:00:15 fen Exp $ -->
<h3>OpenPrivacy Requirements</h3>
Version: 0.2
@@ -17,12 +17,11 @@
Nyms (short for pseudonym) provide for reputation-enhanced anonymity.
Nyms are generally signed by the private key of an asymmetric key pair,
though in certain usually short-lived cases may simply be identified by a
-unique hash.
+locally unique hash or pseudo-random number.
-</p>
-<p>
+</p><p>
-The OpenPrivacy system employs nyms to create a trustable and secure
+The OpenPrivacy system employs nyms as part of a trustable and secure
anonymous demographic marketplace. Agents within the OpenPrivacy system
must be able to "understand" the semantics of nyms to enable useful
transactional operations including:
@@ -30,29 +29,17 @@
<ul>
<li>creation - agents will create nyms for various operations they may
want to be temporarily disassociated from themselves
- <li>association - agents can associate groups of data from the same nym,
- or potentially groups of nyms created by the same agent
<li>authentication - is this nym owned or created by a known source?
+ <li>semantic categorization - within what realm is this nym asserted?
<li>reputation query - what do we know about this nym, and from whom?
<li>reputation attachment - adding new or modifying existing reputation
capital to an entity
+ <li>association - agents can associate groups of data from the same nym,
+ or potentially groups of nyms created by the same agent
<li>lifetime - when was this nym created? has this nym expired?
</ul>
</p>
-
-<h3>Authentication and verification</h3>
-<p>
-
-Profile data, agents, reputations and other entities can be verified by
-first, second and third-party entities using mechanisms such as <a
-href="http://www.cs.uct.ac.za/courses/CS400W/NIS/papers99/omarte/"> blind
-signatures</a> and/or reputation attachment. This process, from
-authentication request through verification of signature validity is
-required for security, trust and accountability. (TBD)
-
-</p>
-
<h3>Reputations</h3>
<p>
@@ -88,16 +75,22 @@
<li>Eternity_checksum - persistent, time-stamped value that ensures
non-repudiation (definition TBD)
</ul>
-</p>
-<h3>Asynchronous and reliable communications</h3>
+</p>
+<h3>Message-based Asynchronous Data Transport</h3>
<p>
A simple, reliable, asynchronous communications mechanism for inter-agent
-communication is required. (SMTP?)
+communication is required (e.g., SMTP, ICQ, Carrier Pigeon, etc.). Values
+encapsulated contained within a message may include:
+<ul>
+ <li>capability to use (e.g., via a URI to a schema or DTD)
+ <li>payload (data conformant to the data format specification)
+ <li>session key (e.g., a pseudo-random number)
+ <li>some sort of TTL-like value (e.g., Freenet's hops-to-live)
+</ul>
</p>
-
<h3>Data format specification</h3>
<p>
@@ -106,7 +99,6 @@
encoded PGP-signed messages with a simple XML payload.</i> (TBD)
</p>
-
<h3>Profile data storage/manipulation and query mechanism</h3>
<p>
@@ -116,8 +108,27 @@
OpenPrivacy recommendations/specifications will greatly ease agent creation
and portability.
+<h3>Phase II</h3>
+<p>
+
+The following capabilities are not required for a basic OpenPrivacy platform,
+but are considered to be useful enough that they may be implemented in Phase
+II.
+
</p>
+<blockquote>
+
+<h3>Data Verification</h3>
+<p>
+Profile data, agents, reputations and other entities can be verified by
+first, second and third-party entities using mechanisms such as <a
+href="http://www.cs.uct.ac.za/courses/CS400W/NIS/papers99/omarte/"> blind
+signatures</a> and/or reputation attachment. This process, from
+authentication request through verification of signature validity is
+required for security, trust and accountability. (TBD)
+
+</p>
<h3>Mobile agents support</h3>
<p>
@@ -129,12 +140,9 @@
for all entities involved in such communication/processing.
</p>
-
<h3>Profile management</h3>
-
<p>
-
<!--
FIXME (burton): this might be overkill... it might be GUI based but I think it needs
to be written down somewhere... should this just be a view? http://www.broadcatch.com/agents.htm
@@ -147,6 +155,13 @@
enable such user-agent transactions.
</p>
+</blockquote>
<!--#include virtual="/includes/bottom.html"-->
+
+
+
+
+
+
This archive was generated by hypermail 2b30 : Mon Jan 22 2001 - 15:52:14 PST