Skip to main content

Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

PDS Architecture

Revision as of 23:00, 5 November 2010 by Unnamed Poltroon (Talk)

{{#eclipseproject:technology.higgins|eclipse_custom_style.css}}
Higgins.funnell.PNG

A PDS is a new architectural component for the Internet. Its purpose is to give the individual user as much control as possible over who can see what aspects of their personal data. The challenge of course is that an individual's data is stored in thousands of databases distributed across the Internet, are stored under a wide variety of policies including access control rights, are described using few common data models, and cannot be accessed using common protocols.

Control. A PDS attempts to provide a central point of control for information about a person, their lives, friends, interests, affiliations and so on. The PDS is a place where the user can control data flows between services that provide data and services that wish to consume it. In these cases the data itself flows directly between the data source and the data consumer.

Data Management. In other cases the PDS acts as an intermediary. Data flows from a data source to the PDS and then as a second flow from the PDS to the data consumer. There are also cases where the data source is the PDS itself. In these cases where the PDS is providing data to the data consumer, it can map the data into a normalized data model, provide the ability to see the data values, and in some cases be able to edit and update them. Data stored locally in the PDS is called a personal data store. Data from external sources are called managed data stores.

Discovery. A PDS supports a discovery API that allows the user to be discoverable by other people, organizations, apps and exchanges when the incoming inquiries meet criteria the user specifies.

PDS 2.0.124.png

Interoperability. A PDS enables the user to participate as a peer within a distributed personal data ecosystem of interoperable PDSes developed and operated by a multiple organizations. We share a vision with other open source projects of an internetwork of PDSes that can exchange personal information under the control of the individual. A person's PDS will include links to data objects stored in their friend's PDSes. These links, taken together, form a social graph that is distributed across these PDSes. Every person could choose to host their own PDS or have it operated by an trusted organization; hopefully one that acts as an agent of the individual.

PDS

Information from a variety of data sources (e.g. social networks, telco and health data sources) are virtually integrated by the PDS and presented in a "dashboard" application in a browser or in desktop and mobile clients. The PDS gives you control over your own information by allowing you to share selected subsets of it with other people and organizations that you trust.

  • Is a service that enables the user to participate as a peer within a distributed personal data ecosystem
  • Provides a web portal that provides a dashboard view of the user’s data, the ability update self-asserted data, and a way to manage authorizations (e.g. using something like an UMA Authorization Manager) and set policies under which 3rd parties (e.g. apps) gain access to portion of the user’s information
  • Implements a Discovery API that allows the user to be discoverable by other people, organizations, apps and exchanges whose inquiries that meet user-defined criteria
  • Provides an identity provider (IdP) endpoint (e.g. OpenID OP)
  • Implements two factor authentication
  • Provides a run-time environment for Kynetx-like apps that run within the PDS itself
  • Decrypts data from the user's personal data stores (using a local key) to allow their attributes to be managed in the PDS's dashboard UI.

Personal data store

  • Provides a personal data abstraction layer mapping internal data into a consistent data model
  • Manages a set of your personas (e.g. Work, Home & Friends, Citizen, Health, Anonymous)
  • Provides an encrypted "lock box" in the cloud such that certain internally stored data in the store (e.g. persona definitions) cannot be read by the store's operator
  • Backs up personal data stored on your desktop and mobile devices
  • Synchronizes personal data to other devices and computers owned by the person using a variety of network protocols.
  • Links information from personas to accounts (profiles) that the user has at services providers, websites, social networking sites, etc. and over which the user has joint control and rights
  • Links information from the user's personas with the personas of the user's friends and colleagues

Managed data store

  • Is a data abstraction layer that maps external data sources into a consistent data model
  • Each external data service is represented as a context container within which are one or more persona objects and their attributes. For example the user's profile on Facebook could be represented as a persona object within a Facebook context. The user's friends would also be represented as other persona objects link to the user's persona object.

PDS Apps

The following kinds of apps are shown in the diagram above:

  • PDS App. A web app that consumes data from the PDS
  • Exchange. A kind of PDS App that is involved in creating personal data exchanges analogous to a stock exchange. An exchange itself is a platform that supports yet another layer of apps above it [this is not shown above].
  • Data Refinery. A kind of PDS App that reads datasets from the PDS, refines them, and writes them back to the PDS user. The refinery process includes analytics, inferencing, segmentation, etc. Refineries generally to create higher value, more refined data from the more raw forms of data, while often also making the data sets less personally identifying.

Active Clients

Shown at the top left of the diagram above are Windows, Mac and mobile active clients. These clients have two advantages over the web-based PDS. First, data stored on these devices is entirely under your control without the need to rely on third party hosted services. Second, the client is integrated with the browser and other local apps. This allows the client (i) to capture information about the user as they browse and (ii) can augment the user's web experience via web augmentation (overlaying context-specific information within the browser) and automatic form filling (e.g. filling in passwords).

Persona Data Model

People play different roles and share different sub-sets of their social graphs and attributes depending on who they are interacting with. For this reason a single person is represented as a set of partial identities that are used in different situations. The heart of the model used by the personal data store and managed data stores is based on a set of containers called contexts. Each context holds a partial digital identity called a persona. Each persona instance has a set of attributes and values. The contexts, personas and attributes adhere to the Higgins Persona Data Model 2.0, a general purpose vocabulary for describing identity and social networking data.

These contexts are usually displayed as digital card metaphors in a user interface. A context/card could hold the attributes of a person's driver's license, home address, credit card. They might simply hold a verified assertion that a person is over 21 years of age. Contexts may also be about the user's friends and colleagues.

The user can choose to collect sets of these cards (partial identities) into a persona-set. For example the user could group together a home address card, an AMEX credit card, a proof of age-over-21 and a card holding a set of "shopping friends" into an "eCommerce" persona. This is done by tagging each of these cards with the "eCommerce" label. When the user goes to a new eCommerce site, it can "project" (either by form filling or something more sophisticated!) the minimal set of required attributes from these "eCommerce" cards to the site without tedious data entry.

If the user desires, they can give a semi-permanent (revocable) permission to the relying site, app or system to be able to access an approved set of attributes. The user can basically send a "pointer" to these cards to the relying site. The relying site can dereference the pointer and read (and in some cases update) selected attributes.

Components

  • PDS: Planned for Higgins 2.0. We developed something similar in Cloud Selector from Higgins 1.1. Similar in that it was a pure web app and that it was a "client" of the core PDS.
  • Personal Data Store 2.0: Personal and managed data store services
  • PDS Client 2.0: a library used to access the Personal Data Store 2.0. It is incorporated into the PDS as well as PC and mobile active clients.
  • Authentication Service 2.0: is an OAuth web service that authenticates PDS users and returns an access token that is relied on by the PDS Agent and the PDS Vault.

Data Models

Data models used in Higgins code and services:

Higgins data models.png

IdAS 

The IdAS solution is a testbed for exercising the IdAS Java framework.

XDI4J

XDI4J is a java library for working with XDI.

Back to the top