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

Difference between revisions of "PDS Architecture"

(→‎Introduction)
(→‎HBX)
 
(194 intermediate revisions by the same user not shown)
Line 1: Line 1:
−
{{#eclipseproject:technology.higgins|eclipse_custom_style.css}}
+
{{#eclipseproject:technology.higgins|eclipse_custom_style.css}} [[Image:Higgins.funnell.PNG|right]]  
−
[[Image:Higgins.funnell.PNG|right]]
+
−
__NOTOC__
+
  
−
This page describes the Personal Data Store (PDS), a new work area under development for Higgins 2.0. It also includes a ''Building Blocks'' section describing some additional components.
+
This document describes the top level Higgins 2.0 PDS components under active development. Here are the bugzilla component names:
 +
* H2-Client
 +
* H2-HBX
 +
* H2-PDS
 +
* H2-PDS Support
 +
* H2-ADS
 +
* H2-Data Model
  
−
== Introduction ==
+
== Front End  ==
−
A PDS provides a central point of control for information about a person, their lives, friends, interests, affiliations and so on. Both individuals and organizations can have PDSes. An organization's PDS may contain information about individuals as well as about the organization itself. Information from a PDS (either the person's own PDS or an organizations') can be shared with applications.
+
  
−
[[Image:Intro 2.0.110.png|center]]
+
There are two front end components: a web client, and a browser extension.  
  
−
We all play different roles and share different sub-sets of our social graph and attributes depending on who we're interacting with. That's what humans do. For this reason a single person is represented as a set of partial identities that are used in different contexts. Some of these are generic enough that we can curate them as a handful of defined "personas"--that way we can reuse them in a specific context (e.g. buying something at a new eCommerce site) without having to tediously repeat ourselves.
+
[[Image:Higgins client 2.0.222.png|center]]
  
−
== Architectural Overview ==
+
=== Client ===
  
−
[[Image:Higgins 2.0.122.png|center]]
+
The client is written in HTML and JavaScript and runs in any desktop browser (e.g. IE, FF, Safari, Chrome). In the future we also plan to make it display well on the limited screen size of smartphone mobile browser (e.g. iPhone, Android, etc.).
  
−
===PDS ===
+
* [[Org.eclipse.higgins.js.pds.client | .js.pds.client]]
  
−
The PDS is shown in the middle of the diagram above. Information from a wide variety of data sources such as the social network, telco and health data sources are virtually integrated by the PDS and presented in a "dashboard" application in a browser (via the PDA) 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.
+
=== HBX ===
  
−
* Gives you control over your information stored in hundreds of external silos as well data stored internally
+
The Higgins browser extension makes possible functionality like browser-side integration with other web APIs and sites, scraping and form filling.
−
* Provides a personal data abstraction layer mapping internal and external data sources into a consistent data model based around notions of personas
+
−
* 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 PDS (e.g. your persona definitions) cannot be read by the PDS'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.
+
−
* Manages access by external apps (aka service providers) to your data that is stored locally as well data stored in PDSes managed by external organizations
+
−
* Links information from your personas to accounts (profiles) that you have at services providers, websites, social networking sites, etc. and over which you share joint control and rights
+
−
* Links information from your personas with the personas of your friend's and colleague's PDSes
+
  
−
Although in principle you only need a single PDS to work on your behalf, we expect that until the time comes that most people fully trust the architecture's security and privacy characteristics, a significant number will choose to have more than one PDS account. Doing so allows them not to have to trust that the PDS architecture is capable of fully isolating the private, work, health-related, and social dimensions of their lives.
+
* .chrome.bx - Chrome-only Higgins Browser Extension
 +
* .js.pds.cde - Connection Data Engine 1. Loads CDE1-compatible JSON Scripts (See [[App-data vocabulary]]) from templates and uses them to implement auto-login, auto-registration, form filling, etc.
 +
* [[org.eclipse.higgins.js.pds.cde2|.js.pds.cde2]] - Connection Data Engine 2. Loads CDE2-compatible JSON Scripts (See [[App-data vocabulary]]) from templates and uses them to implement auto-login, auto-registration, form filling, etc.
 +
* .js.pds.connector.common
  
−
=== PDA ===
+
====Functionality====
  
−
Shown at the middle left of the diagram above:
+
=====Browser interactions=====
−
* Provides a web client for your PDS (as an alternative to native PDS clients on desktop and mobile devices)  
+
When the user's browser lands on a new webpage it:
−
* Provides a run-time environment for apps that run within the PDA itself
+
* Determines if the current PDS user is currently logged in.
−
* Implements an API that allows you to be discoverable by people and organizations that meet criteria you specify
+
** This requires there be a template for the current site (domain) and that it contains an IsLoggedIn script
−
* Decrypts data from your PDS (using a locally stored key) to allow it to be managed in the PDA's "dashboard" UI. Attribute data stored locally on the PDA are encrypted by the PDS Client using an internally managed key prior to transmission to the PDS. Thus data attribute values on the PDS are blinded from the service operator offering/hosting the PDS.
+
** It is possible that a different PDS user (not the current PDS user) is currently logged in.
−
* Implements two factor authentication
+
* If the user is not logged in then
 +
** It automatically logs the user in (or should it just auto-fill in the userid/password and wait for the user to click?)
 +
* Looks for every appropriate form on the page
 +
** Automatically fills in each form as best it can  -- this requires there be a template for the current site (domain) and that it contains a Fill script for this form (is there one fill script container with lots of per-form-submit-URL scripts? Or are there lots of Fill scripts each with an for-this-form-submit-URL attribute?
 +
* Waits for the user to submit a form (including a login form with or without a custom template?)
 +
** Scrapes the form submit data and writes it into the PDS. If it is a login form then it writes into the proxy object, else the corresponding context
  
−
=== Native PDS Clients ===
+
=====Web client interactions=====
−
As shown at the top of the diagram above, we are developing native Windows, Mac and mobile clients for the PDS. These clients have two advantages over the web-based PDA. '''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 closely integrated with the browser and other local apps. This allows the client to capture information about you as you browse and can augment your web experience through web augmentation (overlaying context-specific information within your browser) as well as through automatic form filling (e.g. filling in your passwords).
+
When the user opens a connection editor page (e.g. to edit the nytimes.com connection):
 +
* The BX immediately starts a background process to login and scrape the latest data values from the site.  
 +
** This is necessary because the user may have gone to the site directly (not using the PDS) and updated data values. A progress bar that shows this background process.
 +
* If the user edits an attribute it writes the updated attribute value to the site.  
 +
** If this "write" operation happens before the background sync completes, there is some possibility for sync collisions and and confusion.
  
−
== What's in a PDS? ==
+
== Back End Components ==
  
−
Within a PDS a natural person is represented as a set of containers called ''contexts'' each of which holds a partial digital identity called a ''persona''. Each persona instance has a set of attributes and values. Thus one individual (natural person, data subject) is represented as multiple personas each in its own context-container.  
+
There are three back end components mostly written in Java and running in the cloud (e.g. Amazon AWS):
  
−
[[Image:Tla intro 2.0.108.png|center]]
+
*PDS
 +
*PDS Support
 +
*ADS
  
−
The data in these contexts adheres to the Higgins [[Persona Data Model 2.0]], which can be used for storing arbitrary (identity and social networking) data. [[UDI]] references are used for representing links between contexts, both inside the [[Personal_Data_Store_2.0]] and to external data stores.
+
[[Image:Higgins server 2.0.230.png|center]]  
  
−
== Components ==
+
===PDS===
 +
PDS Subcomponents:
  
−
=== PDA  ===
+
*.pds.usermanager.ws - simple web service to manage user accounts, change password, etc.
  
−
*An evolution of the [[Cloud Selector 1.1]] from Higgins 1.1 with much broader functionality.
+
===PDS Support===
 +
PDS Support Subcomponents:
  
−
=== PDS  ===
+
*.pds.client - wrapper around Open Anzo java client
  
−
*[[PDS 2.0]] - Personal Data Store
+
===Attribute Data Storage===
 +
ADS Subcomponents:
  
−
=== PDS Client  ===
+
*PLANNED: .ads.ld - Linked Data endpoint
  
−
The [[PDS Client 2.0]] is a library used to access the [[Personal_Data_Store_2.0]]. It is incorporated into the PDS agent as well as PC and mobile PDS clients.
+
== Data Model  ==
  
−
=== Authentication (AuthN) Service  ===
+
Data attributes whether created by the user or imported from an external service are stored in a common data model. This allows them to be consistently displayed to, and in some cases edited by, the user irrespective of its original source. We call this the [[Persona Data Model 2.0]].
  
−
The [[Authentication Service 2.0]] (not shown above) 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.
+
[[Category:Higgins 2]]
−
 
+
−
== Building Blocks ==
+
−
This section describes the data related services, java frameworks and data models that are used by the personal data store service.
+
−
 
+
−
===Data Models===
+
−
Data models used in Higgins code and services:
+
−
 
+
−
[[Image:Higgins data models.png|center]]
+
−
 
+
−
* [[Persona Data Model 2.0]]
+
−
* [[Higgins Data Model 2.0]]
+
−
* [[Context Data Model 2.0]]
+
−
 
+
−
===IdAS Solution ===
+
−
The IdAS solution is a testbed for exercising the IdAS Java framework.
+
−
* Higgins 1.1: See [[Higgins_1.1_Plan#IdAS_Solution_1.1]]
+
−
* Higgins 1.0: [[IdAS Solution 1.0]]: a basic configuration of the [[Identity Attribute Service 1.0]] (IdAS). IdAS is a java framework that provides a common interface to identity, profile, and relationship data from external data sources (e.g. websites, databases, directories).
+
−
 
+
−
=== XDI4J ===
+
−
XDI4J is a java library for working with XDI.
+
−
* Higgins 1.1: [[XDI4j 1.1]]
+

Latest revision as of 12:12, 4 January 2012

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

This document describes the top level Higgins 2.0 PDS components under active development. Here are the bugzilla component names:

  • H2-Client
  • H2-HBX
  • H2-PDS
  • H2-PDS Support
  • H2-ADS
  • H2-Data Model

Front End

There are two front end components: a web client, and a browser extension.

Higgins client 2.0.222.png

Client

The client is written in HTML and JavaScript and runs in any desktop browser (e.g. IE, FF, Safari, Chrome). In the future we also plan to make it display well on the limited screen size of smartphone mobile browser (e.g. iPhone, Android, etc.).

HBX

The Higgins browser extension makes possible functionality like browser-side integration with other web APIs and sites, scraping and form filling.

  • .chrome.bx - Chrome-only Higgins Browser Extension
  • .js.pds.cde - Connection Data Engine 1. Loads CDE1-compatible JSON Scripts (See App-data vocabulary) from templates and uses them to implement auto-login, auto-registration, form filling, etc.
  • .js.pds.cde2 - Connection Data Engine 2. Loads CDE2-compatible JSON Scripts (See App-data vocabulary) from templates and uses them to implement auto-login, auto-registration, form filling, etc.
  • .js.pds.connector.common

Functionality

Browser interactions

When the user's browser lands on a new webpage it:

  • Determines if the current PDS user is currently logged in.
    • This requires there be a template for the current site (domain) and that it contains an IsLoggedIn script
    • It is possible that a different PDS user (not the current PDS user) is currently logged in.
  • If the user is not logged in then
    • It automatically logs the user in (or should it just auto-fill in the userid/password and wait for the user to click?)
  • Looks for every appropriate form on the page
    • Automatically fills in each form as best it can -- this requires there be a template for the current site (domain) and that it contains a Fill script for this form (is there one fill script container with lots of per-form-submit-URL scripts? Or are there lots of Fill scripts each with an for-this-form-submit-URL attribute?
  • Waits for the user to submit a form (including a login form with or without a custom template?)
    • Scrapes the form submit data and writes it into the PDS. If it is a login form then it writes into the proxy object, else the corresponding context
Web client interactions

When the user opens a connection editor page (e.g. to edit the nytimes.com connection):

  • The BX immediately starts a background process to login and scrape the latest data values from the site.
    • This is necessary because the user may have gone to the site directly (not using the PDS) and updated data values. A progress bar that shows this background process.
  • If the user edits an attribute it writes the updated attribute value to the site.
    • If this "write" operation happens before the background sync completes, there is some possibility for sync collisions and and confusion.

Back End Components

There are three back end components mostly written in Java and running in the cloud (e.g. Amazon AWS):

  • PDS
  • PDS Support
  • ADS
Higgins server 2.0.230.png

PDS

PDS Subcomponents:

  • .pds.usermanager.ws - simple web service to manage user accounts, change password, etc.

PDS Support

PDS Support Subcomponents:

  • .pds.client - wrapper around Open Anzo java client

Attribute Data Storage

ADS Subcomponents:

  • PLANNED: .ads.ld - Linked Data endpoint

Data Model

Data attributes whether created by the user or imported from an external service are stored in a common data model. This allows them to be consistently displayed to, and in some cases edited by, the user irrespective of its original source. We call this the Persona Data Model 2.0.

Retrieved from "https://wiki.eclipse.org/index.php?title=PDS_Architecture&oldid=283656"

This page was last modified 12:12, 4 January 2012 by Eclipsepedia anonymous user Unnamed Poltroon.

Back to the top