Personal Data Server

Overview

This page documents using the Infusion Personal Data Server as a way to store and retrieve preference information used in the Personal Preferences Approach.

A Personal Data Server can be thought of as a centralized service for storing and retrieving preference data. This allows the user to share preferences across applications/platforms that may otherwise be disconnected. It can also provide additional security and privacy by allowing the user to decide which preferences are shared with which services. In abstract, the preferences server simply provides a means of storing and retrieving user data from a centralized location through a simple RESTful API. 

A Personal Data Server is made up of two primary pieces; the database and web server/API interface. The database holds all of the preferences data and any required information to support authentication and authorization. The web server/API interface provides a means of accessing that information. In most cases a user won't interact directly with the Personal Data Server, but will connect the Personal Data Server to other systems (e.g. embedded instance of UI Options, learning management system, healthcare platform, etc.). As the user interacts with these connected systems, their preferences will be stored and retrieved from the Preferences Server via a RESTful API.

Development

History

The Personal Data Server has roots in previous projects such as GPII. The following are examples of prior art that can be used for inspiration and guidance:

• GPII Preferences Edge Proxy Refinement I

Initial features

The initial implementation will focus on the database and web server, to provide a simple RESTful API to third party systems; making use of OAuth2 authorization and a Single Sign-on (SSO) provider for authentication. For more details on the in progress work see:

• Personal Data Server Repository
• Web API
• Data Model
• Authentication/Authorization flow

Future considerations

Below is a list of features that are being considered for future development work.

• Authenticate directly with the preferences server, rather than through a SSO provider
• Allow users to manage authorizations to the preferences server
• Allow users to restrict which preferences are exposed to which authorized services
• Provide a way to request only specific set of preferences
• Federate preferences stored under various SSO authentications (e.g. combine preferences for sites logged in with Google SSO and from GitHub SSO)

• Support a mechanism for transforming data in/out of the preferences server (e.g. convert "volume: 5" to "sound: medium").

• Allow for persisting preferences without an account. (e.g. will not have the same access/features as an authenticated account)
• Support privileged access to embedded Preferences Servers (Integrated directly into a service/application) by the system it is embedded in.
• Support sharing/access preferences between embedded and external Preferences Servers
  • Support sharing all or a portion of stored preferences.
• Tracking provenance of preferences; that is, a means of determining where preference changes originated. This would allow for prioritization and/or selection of preferences based on origin.

Authentication and Authorization

Please see The OAuth 2.0 Authorization Framework for more details. 

Authentication will be provide through a SSO provider, for example Google, Facebook, GitHub and etc. It is also possible that a platform integrating the Preferences Server may itself be a SSO provider that we may wish to integrate with. The preferences server will expose the set of SSO providers it is configured to work with so that the integrating system (preference consuming system) can render a UI to allow the user to log in to the appropriate SSO. 

After a user has authenticated, the integrated system will be authorized through the preferences server to access the user's preferences. (See: Authorization Code Grant).

In the case of a static site and/or integration directly through UI Options. There will not be a traditional server to process the necessary requests for conducting the authorization workflow and making the requests to the Preferences Server. In this case an Edge Proxy will need to be implemented alongside the site to mediate the requests. This may be through NGINX configuration on the web server, lambda functions on the hosting platform (e.g. netlify), etc.

For more information and details on the workflow depicted in the diagram above, see: Preferences Edge Proxy Workflow.

Alternative Integrations

Embedded Personal Data Server

In addition to integrating with an external Personal Data Server, it may be useful to integrate with an embedded Personal Data Server. That is, a Preferences Server that is hosted alongside the system integrating with it, and thus allows for privileged access to the Personal Data Server. In this case, the initial integration would be to host an instance of the Personal Data Server in the integrating platform. This could later be adapted to either replacing the embedded instance with a connection to an external Personal Data Server, or connecting the embedded and external instances. The latter could allow for portions of preferences to be shared between the two Personal Data Servers, for example, if some of the preferences are declared private and shouldn't be shared outside of the integrating system.

Use Cases

• A means to incrementally build out support for preference sharing. I.e. start with an embedded Personal Data Server to store user preferences and share between the integrating system's applications before moving on to sharing across systems.
• Security/Privacy; could have better control over "confidential" preferences.