Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Person-Site Relationship Management"

(Alice Clicks Get Card)
(Alice Clicks Get Card)
Line 66: Line 66:
 
# Adds the NYTimes to the "read" access control list in the p:control context associated with the NYTimes context
 
# Adds the NYTimes to the "read" access control list in the p:control context associated with the NYTimes context
  
 +
The data state is now:
 
[[Image:Vrm with alice layer 2 2.0.205b.png|center]]
 
[[Image:Vrm with alice layer 2 2.0.205b.png|center]]
 +
 +
Alice's PDS communicates the URI of the NYTimes person entity back to the NYTimes site (via another redirect)
  
 
=== Final State  ===
 
=== Final State  ===

Revision as of 16:13, 18 July 2011

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

Higgins logo 76Wx100H.jpg

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.
  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.

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.

Data Instance

Initial State

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 and the NYTimes' PDS accounts:

VRM with Alice initial 2.0.205b.png


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 communicates back to Alice's browser (via a browser redirect) the URI of the NYTime template context. Alice's PDS:

  1. Reads the contents of the NYTimes template
  2. 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
  3. If she accepts it 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
  4. Creates an instance of NYTimes context from parameters in NYTimes template
  5. Creates a proxy:resource link to the person instance in the NYTimes context
  6. Adds the NYTimes to the "read" access control list in the p:control context associated with the NYTimes context

The data state is now:

Vrm with alice layer 2 2.0.205b.png

Alice's PDS communicates the URI of the NYTimes person entity back to the NYTimes site (via another redirect)

Final State

Here is the final state after Alice has successfully agreed to get the card:

VRM with alice 2.0.205b.png

Component Architecture

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

Linked data 2.0.104.png

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.

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 & PDS

Preconditions:

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

Back to the top