OpenPrivacy Initiative

Essentials:
   Overview
   White Paper
   News
   License

Technical:
   Reputations
   Requirements
   Platform

Projects:
   Talon
   Sierra
   Reptile (SCDS)
   User Content License

Resources:
   Definitions
   Background
   Bibliography

Credits:
   Acknowledgements
   Founders

OpenPrivacy Requirements

The following facilities, capabilities and mechanisms are required for a compliant OpenPrivacy system:

Secure, Distributed Identity Management

Entities within any social environment must contain a characteristic known as identity in order to be able to participate in the community in meaningful ways. To prevent fraud and forgery, this identity must be secure, that is,

mechanisms must exist such that the entity can positively identify itself
other entities have the ability to authenticate messages as having positively originated from it

Further, the storage and maintenance facilities must not be centralized, as this enables at the very least a denial of service attack if the central server is ever compromised or otherwise unreachable.

Profile Management

Identities become increasingly useful as they develop profiles that describe properties relating to their interactions - externally visible, private among a defined group or "personal" (not yet divulged) - in the community. Profile management is an internal (within an identity) task which entails the following capabilities:

collection and storage of information pertinent to an entity
sorting, indexing, filtering and pruning to manage access to an ever-growing profile database
selective publication - only portions of the profile may be made available for external use

A profile is essentially information that an entity maintains about itself. Other entities may create and maintain information about a particular entity, which we call reputation.

Nym Creation and Maintenance

There are many privacy implications implicit with identity and profile management, perhaps most clearly visible when considering the powerful concept of profile publication. Enter nyms (short for pseudonym) which enable the creation of anonymous entities that can themselves develop and publish profiles while protecting the identity of their true owner.

The OpenPrivacy system employs nyms both for privacy and as part of a trustable and secure anonymous demographic marketplace. Using one or more nyms, an entity can publish parts of her profile in order to (say) register a particular interest without the usual concurrent loss of privacy or control over who knows what about her. Entities within the OpenPrivacy system must be able to "understand" the semantics of nyms to enable useful transactional operations including:

creation - entities will create nyms for various operations they may want to be temporarily or permanently disassociated from themselves
authentication - is this nym owned or created by a known source?
reputation query - what do we know about this nym, and from whom?
reputation attachment - adding new or modifying existing reputation capital to an entity
association - entities can associate groups of data from the same nym, or potentially groups of nyms created by the same entity
lifetime - when was this nym created? has this nym expired?

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 locally unique hash or pseudo-random number. Because of this - and generally because of name conflicts in any large community - it can be confusing for humans to differentiate between entities unless they can keep track of them in a way that fits their world view. For this purpose we employ the concept of pet names. Each nym/entity can suggest a default pet name of ther own and the user can either acept that or modify it perhaps to avoid name conflicts or simply to better distingush between entities within the user's namespace.

Reputations

Nyms are very useful for the protection of one's privacy, and are made more useful through the growth of knowledge about - or reputation - that can be attached to them.

Reputations are first class objects - based on XMLDSig - that can be applied to any entity within the OpenPrivacy system. In a sense, all objects derive from class reputation. Reputations have several static component parts, including:

Reference - the entity URI to which this reputation is attached
Identity - a unique URL (used for naming and assigning additional reputation)
Signature - the signature of the assigning party

Additional fields may exist that give additional information to the reputation:

Payload - one or more semantic names, types and/or values for this reputation
Ontology - provides semantic categorization for the payload
KeyInfo - provides direct reference to assigner
CreatedDate - date when this reputation was created
ExpiryDate - date when this reputation is no longer valid
Eternity_checksum - persistent, time-stamped value that ensures non-repudiation (definition TBD)

Message-based Asynchronous Data Transport

The data transport is abstracted, so most any reliable, asynchronous communications mechanism for inter-entity communication can be made to work (e.g., SMTP, ICQ, Carrier Pigeon, etc.). In practice, however, we expect messages to be communicated between nodes using 128-bit TLS encryption. Values encapsulated contained within a message may include:

capability to use (e.g., via a URI to a schema or DTD)
payload (data conformant to the data format specification)
session key (e.g., a pseudo-random number)
some sort of TTL-like value (e.g., Freenet's hops-to-live)

Data format specification

Entities will receive payloads containing profile, reputation, and/or other data in versioned formats to provide for legacy data types as well as XML support. We have been targeting MIME encoded PGP-signed messages with a simple XML payload for a proof of concept and are considering JXTA's Content Management System for release 1.

Profile data storage/manipulation and query mechanism

OpenPrivacy will publish guidelines and examples of data formats and query protocols that enable inter-entity data communication. While it is possible that entities may store and access data in proprietary formats, using the OpenPrivacy recommendations/specifications will greatly ease entity creation and portability.

Phase II

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.

Data Verification

Profile data, agents, reputations and other entities can be verified by first, second and third-party entities using mechanisms such as blind signatures and/or reputation attachment. This process, from authentication request through verification of signature validity is required for security, trust and accountability. (TBD)

Mobile agents support

Some entities within the OpenPrivacy mechanism will be mobile in one fashion or another. At the least, signed, reputable payloads containing queries for remote processing are expected to be commonplace. If actual code is expected to be run on remote platforms, the signature/reputation mechanism will be utilized to ensure safe computing. Persistent handles will exists for all entities involved in such communication/processing.

Profile management

Provide a mechanism so that users can think of and manage their profiles in a semantic manner (temporal, categorical, source, by reputation), etc. While this is generally in the domain of applications built on top of the OpenPrivacy platform, we wish to specify the basic requirements to enable such user-entity transactions.

OpenPrivacy satisfies one of the requirements for Broadcatch systems
and supports the Principles of the Identity Commons
Historical note: OpenPrivacy closed its virtual doors in May of 2002.

I wish this
site were