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,
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.
- mechanisms must exist such that the entity can positively identify
- other entities have the ability to authenticate messages as having
positively originated from it
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
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.
- 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
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
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.
- 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 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:
Additional fields may exist that give additional information to the reputation:
- 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
- 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
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
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.
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.