Person-Site Relationship Management

{{#eclipseproject:technology.higgins|eclipse_custom_style.css}}

This document describes the design of a person-to-site relationship management capability that will be contributed to Higgins 2.0 milestone 2.

Motivation

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.

Status Quo

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:

1. The user has to choose and remember/manage a password for each site
2. Filling in registration forms is both tedious for the user and results in fewer accounts created than might otherwise due to this friction.
3. Updating account profiles at every site is inconvenient for the user. Sites often have old and incorrect data
4. 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.

SSO

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:

1. Fixed. (Well, what's really weird is that it seems (unscientifically) that most sites that support OpenID/FB/Twitter/LinkedIn sign in still require a password!)
2. 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.
3. Partially fixed. Fixed for the common attributes that the user has most likely already updated at Facebook
4. Not fixed.
5. New privacy issue: With the current SSO solution your provider (e.g. Facebook) ends up tracking you across the web.
6. New fairness issue: Facebook gains monetizeable knowledge about the user. The user gains nothing.

Summary

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 high-level a few use-cases that illustrate how a PDS-powered relationship between a person named Alice and the nytimes.com website would work.

NOTE: the following injects the card metaphor into this process of creating a connection. We'll have to see how intuitive this really is in practice.

Smoother Registration

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.

Auto-Login

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.

Auto-Profile Update

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.

Getting a Card: Overview

The following introduces the participants in the get card flow: Alice's browser, two websites and two PDS services. A degenerate case of is the scenario in which two PDS services are actually the same service, but we'll ignore that for now.

Sequence diagram:

The next section examines the changes to Alice's and the NYTimes' PDS accounts as we proceed through the process.

Getting a Card: State snapshots

This section looks at the "get card" use case from the point of view of examining the changes to the state of Alice's and the NYTime's PDS accounts. To simplify things we assume that both Alice and the NYTimes are already PDS users.

Initial State

Alice and the NYTimes have pre-existing accounts on some PDS.

Alice comes to the NYTimes website and sees a NYTimes VIP card that they offer. Before Alice clicks to get the card here is the state of her PDS account and the NYTimes' PDS account:

The NYTimes template might look like this (image data truncated):

  :TemplateContext_1
     rdf:type template:TemplateContext ;
     template:desired fp:yearOfBirth ;
     template:image "00ffafdcee224432"^^xsd:base64Binary ;
     template:imageType "PNG"^^xsd:string ;
     template:required fp:email , fp:ageRange , fp:familyName , fp:givenName , fp:postalCode .

See Template vocabulary for more information about templates.

Alice Clicks Get Card

When Alice clicks on the image of the card, she begins the process of establishing a bi-directional data sharing relationship between her account on her PDS and the NYTimes' account on their PDS (which may or may not be provided by the same PDS operator).

When Alice clicks on the card image, the website initiates a redirect containing:

• Location header: http://<alice-pds-domain>/getcard
• URI of NYTimes PDS (e.g. http://nytimes-pds-domain)
• UserId of NYTimes on NYTImes PDS (e.g. "nytimes")
• URI of the NYTimes template

Alice's PDS Portal (website):

1. Authenticates Alice to PDS (hopefully she's cookied with an encrypted cookie and doesn't have to login; else she logs in)
2. Reads the contents of the NYTimes template
3. Displays a UI window that displays the data sharing policy, attributes going back and forth, etc. and allows Alice to either accept the policy or reject it
4. If she accepts it invokes a createcard service on her PDS service.

Alice's createcard service on her PDS service:

1. Creates a (Card class) Proxy instance linked (an h:correlation link) to the root person (#me) in the root context and copies the card image from the NYTimes template into the Card instance
2. Creates an instance of NYTimes context from parameters in NYTimes template
3. Creates a proxy:resource link to the person instance in the NYTimes context
4. Adds the NYTimes to the "read" access control list in the p:control context associated with the NYTimes context (note: we're currently assuming that a nytimes account has been pre-created on Alice's PDS, we'll deal with the fully dynamic case later)

The data state is now:

Alice's PDS service communicates the URI of the NYTimes person entity back to a carduser service (e.g. http://<nytimes-pds-domain>/carduser) on the NYTimes PDS service. It passes the following parameters:

• URI of the p:Person entity within Alice's NYTimes context in Alice's PDS (Alice's PDS id is embedded in the URI)

Penultimate State

When the NYTimes PDS carduser service receives the URI of the person within Alice's NYTimes context the NYTimes PDS account:

1. Instantiates its NYTimes context from the template and links it to the Root context
2. Sets up its associated p:control context
3. Adds a (shown below as green) h:correlation link pointing at Alice's person entity in Alice's NYTimes context

The result is:

The NYTimes PDS service now POSTS to a cardissuer service on Alice's PDS and passes the following information:

• URI of the person entity (shown in red below)

Alice's PDS Portal then forces a redirect of Alice's browser back to the NYTimes website.

Final State

The cardissuer service of Alice's PDS receives the id of the red person and it adds a h:correlation link (shown in green) back to the NYTimes' NYTimes context. Here is the final state:

New Components

The following diagram shows (outlined in red) two new components that have been added to the M1 architecture.

HGraph (.js.hgraph)

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.

Protocol Overview

The flows below are based on OpenID Connect.

• http://public.iwork.com/document/?a=p38694687&d=openID__38__oAauth_2.key
• http://tools.ietf.org/html/draft-ietf-oauth-v2-16

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

Preconditions:

• 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

Preconditions:

• NYT is PDS-powered
• Alice has no PDS account
• Alice already has an account on NYT site