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.
Difference between revisions of "PDS Architecture"
| Line 1: | Line 1: | ||
{{#eclipseproject:technology.higgins|eclipse_custom_style.css}} [[Image:Higgins.funnell.PNG|right]] __NOTOC__ | {{#eclipseproject:technology.higgins|eclipse_custom_style.css}} [[Image:Higgins.funnell.PNG|right]] __NOTOC__ | ||
| − | + | The catchy term '''Personal Data Store''' lies at the heart of a Personal Data '''Service''' (PDS). This page describes both the PDS and the personal and 3rd party managed data stores that it manages. | |
| − | A | + | A PDS provides a central point of control for information about a person, their lives, friends, interests, affiliations and so on. It provides a web portal and a dashboard of the user’s data. It includes the ability update self-asserted data and a way to manage authorizations and set policies under which 3rd parties gain access to portion of the user’s information. It implements a Discovery API that allows you to be discoverable by other people, organizations, apps and exchanges whose inquiries that meet criteria you specify |
| − | + | A personal data '''store''' is a data storage service managed by the PDS where self-asserted information about the user is stored and protected. | |
| − | + | A PDS enables the user to participate as a peer within what we anticipate will be a distributed personal data ecosystem of interoperable PDSes developed and operated by a wide variety of organizations. We share a vision with other projects of an internetwork of PDSes that can freely exchange information of a wide variety of types. Some will be based on Higgins code, some based on other technologies entirely. Until a single protocol emerges as the universal standard, we anticipate implementing whatever protocols get traction in the wild. A PDS centralizes control by providing the person with a dashboard, but it does not centralize storage. Quite the opposite. At the heart of the PDS concept is the idea of a distributed architecture. Theoretically every person could run their own PDS in their home in or in the cloud. Alternatively, a PDS may be operated by an organization, but in this case the notion is that that organization works as an agent of the individual and does as the individual dictates. | |
| − | + | What's not shown below is that a person might have a pointer into a data object stored in a friend's PDS. These pointers, taken together, form the social graph that is physically distributed across the PDSes. | |
| − | [[Image: | + | [[Image:PDS intro 2.0.121.png|center]] |
| − | + | === PDS === | |
| − | + | The PDS is shown in the top 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. | |
| − | + | A PDS: | |
| − | + | * 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 gain access to portion of the user’s information | ||
| + | * Implements a Discovery API that allows you to be discoverable by other people, organizations, apps and exchanges whose inquiries that meet criteria you specify | ||
| + | * Provides an identity provider (IdP) endpoint (e.g. OpenID OP) | ||
| + | * Implements two factor authentication | ||
| + | * Provides a run-time environment for apps that run within the PDA itself | ||
| + | * 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. | ||
| + | *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 | ||
| − | + | ==Personal data service=== | |
| + | * 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. | ||
| + | * 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 | ||
| − | + | ==Managed data service=== | |
| + | *Gives you control over your information stored in hundreds of external silos | ||
| + | *Provides a personal data abstraction layer mapping internal and external data sources into a consistent data model based around notions of personas | ||
| − | |||
| − | + | 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. | |
| − | |||
| − | + | In the diagram above we show a person's PDS and some apps and service providers acting as relying parties across the top. Across the bottom we show some external sources of a person's attribute data. Note that a given party may well play BOTH the role of being a relying party AND a data source. In the former role they act as a consumer of attributes and in the latter role they act as an authority for attributes. | |
| − | + | Among many benefits, the PDS architecture tends to shifts control to the individual over their own data. On the other hand the new architecture also introduces a number of new challenges related to governance, access control, interchange standards, authorization, auditing and so on. These challenges are being addressed by the wider ecosystem within which Higgins plays its role as a provider of a PDS codebase. | |
| − | + | === Contextualized data model=== | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | At the heart of the personal data store and managed data stores are a set of data objects called contexts, each of which holds a set of attributes. These contexts are usually rendered as digital cards 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 friends and colleagues, not just about you. | |
| − | + | 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. | |
| − | + | The user can group a set of these partial identities into something called a ''persona''. 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. | |
| − | + | What's more, if the user desires, the user can give a semi-permanent (revocable) permission to the relying site, app or system to be able to access an approved set of attributes from the user's PDS whenever needed. The user can basically send a "pointer" to these cards to the relying site. The relying site can de-reference the pointer and read (and in some cases update) selected attributes. | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
=== Native PDS Clients === | === Native PDS Clients === | ||
Revision as of 14:13, 10 October 2010
{{#eclipseproject:technology.higgins|eclipse_custom_style.css}}
The catchy term Personal Data Store lies at the heart of a Personal Data Service (PDS). This page describes both the PDS and the personal and 3rd party managed data stores that it manages.
A PDS provides a central point of control for information about a person, their lives, friends, interests, affiliations and so on. It provides a web portal and a dashboard of the user’s data. It includes the ability update self-asserted data and a way to manage authorizations and set policies under which 3rd parties gain access to portion of the user’s information. It implements a Discovery API that allows you to be discoverable by other people, organizations, apps and exchanges whose inquiries that meet criteria you specify
A personal data store is a data storage service managed by the PDS where self-asserted information about the user is stored and protected.
A PDS enables the user to participate as a peer within what we anticipate will be a distributed personal data ecosystem of interoperable PDSes developed and operated by a wide variety of organizations. We share a vision with other projects of an internetwork of PDSes that can freely exchange information of a wide variety of types. Some will be based on Higgins code, some based on other technologies entirely. Until a single protocol emerges as the universal standard, we anticipate implementing whatever protocols get traction in the wild. A PDS centralizes control by providing the person with a dashboard, but it does not centralize storage. Quite the opposite. At the heart of the PDS concept is the idea of a distributed architecture. Theoretically every person could run their own PDS in their home in or in the cloud. Alternatively, a PDS may be operated by an organization, but in this case the notion is that that organization works as an agent of the individual and does as the individual dictates.
What's not shown below is that a person might have a pointer into a data object stored in a friend's PDS. These pointers, taken together, form the social graph that is physically distributed across the PDSes.
PDS
The PDS is shown in the top 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.
A PDS:
- 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 gain access to portion of the user’s information
- Implements a Discovery API that allows you to be discoverable by other people, organizations, apps and exchanges whose inquiries that meet criteria you specify
- Provides an identity provider (IdP) endpoint (e.g. OpenID OP)
- Implements two factor authentication
- Provides a run-time environment for apps that run within the PDA itself
- 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.
- 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
Personal data service=
- 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.
- 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
Managed data service=
- Gives you control over your information stored in hundreds of external silos
- Provides a personal data abstraction layer mapping internal and external data sources into a consistent data model based around notions of personas
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.
In the diagram above we show a person's PDS and some apps and service providers acting as relying parties across the top. Across the bottom we show some external sources of a person's attribute data. Note that a given party may well play BOTH the role of being a relying party AND a data source. In the former role they act as a consumer of attributes and in the latter role they act as an authority for attributes.
Among many benefits, the PDS architecture tends to shifts control to the individual over their own data. On the other hand the new architecture also introduces a number of new challenges related to governance, access control, interchange standards, authorization, auditing and so on. These challenges are being addressed by the wider ecosystem within which Higgins plays its role as a provider of a PDS codebase.
Contextualized data model
At the heart of the personal data store and managed data stores are a set of data objects called contexts, each of which holds a set of attributes. These contexts are usually rendered as digital cards 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 friends and colleagues, not just about you.
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.
The user can group a set of these partial identities into something called a persona. 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.
What's more, if the user desires, the user can give a semi-permanent (revocable) permission to the relying site, app or system to be able to access an approved set of attributes from the user's PDS whenever needed. The user can basically send a "pointer" to these cards to the relying site. The relying site can de-reference the pointer and read (and in some cases update) selected attributes.
Native PDS Clients
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).
Representing a Person
A natural person is represented in a PDS 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.
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 PDS 2.0 and to external data stores.
Components
- PDS 2.0: Personal Data Store core service
- PDA: We have not even started developing this component 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.
- PDS Client 2.0: 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.
- 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:
IdAS
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