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

Person-Site Relationship Management

Revision as of 21:37, 25 May 2011 by Ptrevithick.gmail.com (Talk | contribs) (Motivation)

{{#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 cool 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.

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:

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

Our hope is that by empowering the user with a PDS the PDS can, acting as an agent of the user, both eliminate the friction and tedium of the traditional approach as well as shift some control to the individual over their own data. This is one of the key ideas behind VRM.

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.

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. We expect that in most cases only a password value needs to be provided.

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

Component Architecture

The following diagram shows new components that have been added to the M1 component architecture.

@@@diagram

Look at the "subject" URIs being passed in to methods. If domain of URI is the domain of this PDS then do nothing, else lookup in cache metadata. If not in cache metadata then attempt to resolve and import a cached copy and add entry to cache metadata.

For each global context resolved and copied into ADS, maintain date-time-of-snapshot

For each context that goes stale, re-copy.

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 something like https://azigo.com/nytimes/nytimesreader#123456

Detailed Use Cases

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