Person-Site Relationship Management
This document describes the design of a person-to-site relationship management capability that will be contributed to Higgins 2.0 milestone 2.
- 1 Motivation
- 2 User Experience Overview
- 3 Data Instance
- 4 Component Architecture
- 5 Protocol Overview
- 6 Detailed Use Cases
One of the advantages of a person having a Personal Data Service (PDS) is that the PDS, acting as an agent of the user, can help the user manage the account-data-related aspects of their relationship with websites. Before we describe how a PDS agent can work, let's review the status quo and the current state-of-the-art, SSO.
Today sites that allow login/registration maintain accounts for each registered user. Each account consists of a set of attributes. Some attributes are exposed to the user on their "profile" or "my account" pages. Some attributes are editable by forms on these pages. Some attributes were originally provided with values (usually by filling in a form) during the original registration step.
There are several well known disadvantages of the status quo:
- The user has to choose and remember/manage a password for each site
- Filling in registration forms is both tedious for the user and results in fewer accounts created than might otherwise due to this friction.
- Updating account profiles at every site is inconvenient for the user. Sites often have old and incorrect data
- The site-centric architecture leads to tendency of sites to consider that in some sense they are the owners of the user's data. Many users are not aware, for example, that Facebook holds the copyright on any photos uploaded to the site.
In the past couple of years single sign-on (SSO) solutions have emerged that allow a person to login/register using Google, Facebook or Twitter accounts. Let's review SSO WRT the status quo:
- Partially fixed. Fixed for the common set of attributes (& friends) that Facebook or Twitter or Google can provide. For any attributes beyond this common set, the user will still have to enter values manually.
- Partially fixed. Fixed for the common attributes that the user has most likely already updated at Facebook
- Not fixed.
- New privacy issue: With the current SSO solution your provider (e.g. Facebook) ends up tracking you across the web.
- New fairness issue: Facebook gains monetizeable knowledge about the user. The user gains nothing.
Our hope is that by empowering the user with a PDS the PDS can, acting as an agent of the user (or what is called a fourth party in VRM), provide a complete solution to all issues mentioned above.
User Experience Overview
We now describe at a breezy, high-level way a few use-cases that illustrate how a PDS-powered relationship between a person named Alice and the nytimes.com website would work.
When Alice wishes to register for an account she sees a new option. Near the usual registration form, Alice sees a card-shaped image of a "NY Times Reader" card. The page explains that as an alternative to the usual process, she can instead click on the card image. When she clicks she sees a page that describes the nature of the bi-directional digital relationship that will be created if she accepts the card. This page shows what's in it for her, and what's in it for the NY Times. When she clicks "Get Card" the card is added as a new "relationship" card in her PDS. To the extent that there are some attributes that the site wishes to have that Alice has never provided to any site, the PDS prompts Alice to enter the missing attribute values.
When Alice points her browser at the nytimes.com website, she is instantly and automatically logged in. No typing, no password to remember. A "PDS" button/icon that was added to her browser chrome when she acquired her PDS account indicates her "logged in" status.
At any time Alice can review all of her relationship cards in her PDS by clicking on the PDS button in her browser chrome. If she changes the value of any attribute of any card that is also an attribute of her nytimes.com relationship card, the value of this attribute on her nytimes.com card is updated. The nytimes.com site is notified as to the updated attribute values, and can pull a copy of the updated values at any time.
The following diagram shows (outlined in red) two new components that have been added to the M1 architecture.
The purpose of the HGraph component is to create an abstraction layer above the OpenAnzo client component. The OpenAnzo client is the API that provides access to all data stored within the closed world of the Attribute Data Store (ADS) --an RDF quadstore based on OpenAnzo. The purpose of HGraph is to provide access to the open, external world of Linked Data. As will be mentioned below the other new component (Linked Data Endpoint) exposes a context within the ADS as Linked Data. Thus client code (e.g. the Context Editor) can now, using HGraph, read (although not write) data from another PDS instance.
The basic idea is that HGraph intercepts all calls to the lower OpenAnzo client and examines the URIs of the resources being requested. If the URI is other than the domain of the PDS itself (e.g. azigo.com), then it attempts to dereference the URI, read the RDF document referent, create a cached copy of the document as a (read-only) new context in the ADS, and create a record in a cache metadata context with the timestamp of when the resource was cached.
HGraph is also responsible to flush the cached contexts in the ADS after the time-to-live period has expired and re-copy them from the world of Linked Data into the ADS cache.
Linked Data Endpoint (.ads.ld)
The Linked Data Endpoint (LDE) is a RESTful web service that exposes an (access-control protected) context as a Linked Data file. As mentioned above, this makes every context in an ADS instance accessible by other PDS's HGraph clients.
The flows below are based on OpenID Connect.
The changes are as follows:
- The RF (Request File) includes the following att/val:
"higgins" : <resource-udi>
Where <resource-udi> is the UDI of an entity in a context representing a relationship card within the PDS. An example value might be something like https://azigo.com/nytimes/nytimesreader#123456 (where 123456 is the local entity id of the "Alice" entity.
Detailed Use Cases
@@@This section is a work in progress. Just a few rough notes at present. For each use case we intend to document:
- UI mockups
- sequence diagrams of protocol flow between Alice and NYT PDSes
- a set of before/after data state snapshots
Unregistered Alice Gets Card & PDS
- NYT is PDS-powered
- Alice has no PDS account
- Alice has never registered with nytimes.com in the past
Sequence: Alice-->NYT: GET (no PDS header) NYT-->Alice: 200 Alice-->NYT: POST (card form submit) NYT-->azigo.com: 303?
Registered Alice Gets Card & PDS
- NYT is PDS-powered
- Alice has no PDS account
- Alice already has an account on NYT site