Skip to main content
Jump to: navigation, search

Difference between revisions of "Data Sharing With Alice And Bob"

(Introduction)
 
(22 intermediate revisions by 2 users not shown)
Line 5: Line 5:
 
This document describes a use case wherein Alice offers to enter into a data sharing relationship with Bob.  
 
This document describes a use case wherein Alice offers to enter into a data sharing relationship with Bob.  
  
A cursory knowledge of the concept of a [[Personal Data Store 2.0]] and of the [[Persona Data Model 2.0]] (PDM 2.0) is assumed. Although not mentioned explicitly the graph of objects being shared are described in the PDM 2.0 model.
+
A cursory knowledge of the concept of a [[Attribute Data Service 2.0]] and of the [[Persona Data Model 2.0]] (PDM 2.0) is assumed. Although not mentioned explicitly the graph of objects being shared are described in the PDM 2.0 model.
 
+
This use case assumes that there is an active client providing a little bit of UI and the ability to kick off sending an email to Bob. But the reality is that 95% of the implementation of this use case is done by the [[PDS Client 2.0]], so a webapp (built on the PDS client library/service) could just as easily have provided the UI instead of an active client with its so-called dashboard UI. Best of all if both kinds of clients existed they would of course interoperate seamlessly.  
+
  
 
=== Overview  ===
 
=== Overview  ===
  
Alice wishes to delegate to her friend Bob authority over the record in Alice's Google Contacts (think gmail) account that is about him, to him. In inviting Bob to do this she simultaneously offers him read-only access to the record about herself.
+
Alice wishes to grant access to one of her contexts to her friend Bob. In accepting this invite, Bob will grant access to Alice to an equivalent context owned by Bob.  
 
+
The social protocol is that Alice sends an offer to "stay in sync" to Bob. The offer contains two gifts: (i) a link to the record about Alice so Bob can always have her latest information and (ii) a link to Bob's record so that anytime Bob's information changes Alice gains a copy.  
+
  
 
=== Initial Condition  ===
 
=== Initial Condition  ===
  
 
Alice has:
 
Alice has:
* A Higgins-based active client
+
* An account on a Higgins-based ADS
* A PDS that supports "sharable" contexts (e.g. exposing them via XDI)
+
* A Higgins-based PDS
* A gmail account wherein at least her friend Bob is listed.
+
* A share-able context, call it context-A1
* A PDS provisioned with a Google Contacts Context Provider (CP). This CP syncs with the Google Contacts API and exposes a Higgins PDM 2.0 compatible context.
+
* A sharing_inbox contex, which is read/writeable by Alice, and appendable by all.
 +
* Bob's email address
  
 
Bob has:
 
Bob has:
  
* No active client
+
* No ADS account
 
* No PDS
 
* No PDS
* No gmail account
+
* An email address
 
+
=== Alice Opens Her Google Contacts  ===
+
 
+
As shown below, Alice opens a Google Contacts context, providing her gmail username/password credentials. If Alice does not have an entry for herself in Google, then an empty one is created. If Alice does have an entry for herself this is somehow found.<ref>I don't know enough about Google Contacts to know if this can be done automatically or if the active client's UI (the so-called dashboard) must display a list of Alice's contacts and ask her to select the one that is her. We could allow her to specify multiple entries and tag them as personas too in the future.</ref>
+
 
+
[[Image:Anb 1.png|center]]
+
 
+
A note about the images in this document. The round cornered boxes are Higgins contexts. The dotted lines are <code>foaf:knows</code> attributes. The solid lines are <code>h:subCorrelation</code> links--which very roughly means "this is another facet of me"
+
 
+
=== Generalize  ===
+
 
+
Since no <code>h:subCorrelation</code> link exists between Alice's root entity in the root context and the root node in the Google Contacts (GC) context, then this correlation needs to established.
+
 
+
This involves creating the <code>h:subCorrelation</code> link itself as well as walking the graph from the root in the Google Contacts context and merging it into either a new or an existing persona context under the root (aka RootMe) node.
+
 
+
The result of this generalization process is shown below. The dotted lines are <code>foaf:knows</code> links.
+
 
+
For clarity all of Alice's contacts (other than herself and Bob) have been omitted for simplicity in Figure 2 below.
+
 
+
[[Image:Anb 2.png|center]]
+
 
+
=== Share Alice's (Alice and Bob) with Bob  ===
+
 
+
In the UI of the active client Alice selects the Bob persona node. One of the operations she can perform on this node is to share it with someone. She chooses to share this Persona node with Bob. And by Bob we mean here Bob's email address (which is an attribute of the Bob node). For social protocol reasons Alice will simultaneously offer to share her own contact info with Bob. (See the "Stay in Sync?" email below).
+
 
+
The [[PDS Client 2.0]] needs to add Bob to the access control list for the contexts. Since at this point we only know Bob as his email address, so that must (for now) be his identifier. The access control list is maintained by the PDS, so Alice's PDS Client must communicate with the PDS to add Bob to the "allow access" list of the "alice" context and the "bob context. We add "Bob has full read/write access" to the bob context's ACL. And we add "Bob has read-only access" to the "alice's context" ACL.
+
 
+
The last step is for the active client to arrange that an email be sent to Bob. The email contains what we call an ''i-link''.
+
 
+
The i-link (URI) encodes (a) a link to an active client download site (b) the UDI of the Bob entity (c) the UDI of the Alice entity on r-card1
+
 
+
The text of the email says something like:
+
<blockquote>'''Subject: Stay in sync?''' </blockquote> <blockquote>I'd like to stay in sync with you. By clicking on the link below please accept my offer to always having my latest contact/profile information. You have the option of <u>Click here to accept my offer</u>. Note: If you don't already have a Higgins active client, clicking here will bring you to a download page where you can get one. I've started using Higgins to stay in sync with co-workers, friends and family. With Higgins everything stays up-to-date because everyone who uses Higgins '''''only has to update their own contact info'''''--and all the changes are automatically reflected it everyone else's address book.</blockquote>
+
 
+
=== Bob clicks on the i-link  ===
+
 
+
Since Bob's browser doesn't have the Higgins BX installed when he clicks on the i-link it just takes him to the Higgins download site. Bob downloads and installs an active client. Now Bob has a root context as shown in Figure 4 below.
+
 
+
[[Image:Anb 3.png|center]]
+
 
+
=== Bob processes the i-link  ===
+
  
Bob extracts the UDI of Alice's Bob entity on r-card2 as well as the UDI of Alice's Alice entity on r-card1.
+
=== Alice Initiates Sharing  ===
  
Alice not only delegates ''control'' over her representation of Bob to Bob but also the ''data management ''of this representation.
+
* Alice opens her sharable context in her PDS, call it context-A1.
 +
* Alice clicks the "share via email" button, and enter's Bob's email address.
 +
* The PDS system does the following:
 +
** Generates a GUID for this invitation, call it GUID-1
 +
** Makes the following entries in the sharing_inbox context:
 +
*** GUID-1, invited_to, context-A1
 +
*** GUID-1, invited_timestamp, {timestamp}
 +
*** GUID-1, invited_method, email
 +
*** GUID-1, identified_by, bob@bob.com
 +
** Sends an email  message to Bob that contains an invitation message, and a link back to the PDS that embeds these pieces of data:
 +
*** Alice's user ID
 +
*** The URI to the context that Alice shared
 +
*** The URI to the template for the context that Alice shared
 +
*** The invitation GUID-1
 +
 +
=== Bob Clicks the Link ===
 +
* Bob retrieves the email message
 +
* Bob clicks the link
 +
* The link opens the PDS to a page that offers Login or Create Account, and saves the GUID-1 in a session variable.
 +
* Bob creates an account.
 +
* Bob sees some UI that asks if he want to accept sharing of Alice's context, and in turn, share his equivalent context.
 +
* The PDS creates a context for Bob using the template URI from the link, call it Context-B1.
 +
* The PDS grants read-access to Alice to Context-B1 (since it knows her root ID).
 +
* Creates a pointer form Context-B1 to Context-A1.
 +
* Bob's PDS creates a GUID-2 for the reciprocal invitation to Alice, and creates the following statements in Alice's sharing_inbox context:
 +
** GUID-1, accepted_by, bob
 +
** GUID-1, accepted_timestamp, {timestamp}
 +
** GUID-2, invited_to, Context-B1
 +
** GUID-2, invited_timestamp, {timestamp}
 +
** GUID-2, invited_method, internal
 +
** GUID-2, identified_by, alice
 +
* Bob's PDS creates the following statements in Bob's sharing_inbox context:
 +
** GUID-2, invited_to, Context-B1
 +
** GUID-2, invited_timestamp, {timestamp}
 +
** GUID-2, invited_method, internal
 +
** GUID-2, identified_by, alice
  
The result would be:
 
  
[[Image:Anb 4.png|center]]
+
=== Alice finalizes the sharing ===
 +
Alice's PDS reads Alice's sharing_inbox and does the following:
 +
* Creates an ACL entry in Context-A1 granting read-access to {bob's user ID}
 +
* Creates a pointer from Context-A1 to Context-B1
 +
* Write the following entries into Bob's sharing_inbox context:
 +
** GUID-2, accepted_by, alice
 +
** GUID-2, accepted_timestamp, {timestamp}
  
''Note: If Bob also had a gmail (or interestingly any other kind of context!) account of his own that contained nodes for himself and/or Alice he could later open this context and push a "Correlate" button on the PDS Client to compare graphs and infer/suggest new <code>h:subCorrelation</code> links.''
+
[[Category:Higgins 2]]

Latest revision as of 20:09, 15 May 2011

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

Introduction

This document describes a use case wherein Alice offers to enter into a data sharing relationship with Bob.

A cursory knowledge of the concept of a Attribute Data Service 2.0 and of the Persona Data Model 2.0 (PDM 2.0) is assumed. Although not mentioned explicitly the graph of objects being shared are described in the PDM 2.0 model.

Overview

Alice wishes to grant access to one of her contexts to her friend Bob. In accepting this invite, Bob will grant access to Alice to an equivalent context owned by Bob.

Initial Condition

Alice has:

  • An account on a Higgins-based ADS
  • A Higgins-based PDS
  • A share-able context, call it context-A1
  • A sharing_inbox contex, which is read/writeable by Alice, and appendable by all.
  • Bob's email address

Bob has:

  • No ADS account
  • No PDS
  • An email address

Alice Initiates Sharing

  • Alice opens her sharable context in her PDS, call it context-A1.
  • Alice clicks the "share via email" button, and enter's Bob's email address.
  • The PDS system does the following:
    • Generates a GUID for this invitation, call it GUID-1
    • Makes the following entries in the sharing_inbox context:
      • GUID-1, invited_to, context-A1
      • GUID-1, invited_timestamp, {timestamp}
      • GUID-1, invited_method, email
      • GUID-1, identified_by, bob@bob.com
    • Sends an email message to Bob that contains an invitation message, and a link back to the PDS that embeds these pieces of data:
      • Alice's user ID
      • The URI to the context that Alice shared
      • The URI to the template for the context that Alice shared
      • The invitation GUID-1

Bob Clicks the Link

  • Bob retrieves the email message
  • Bob clicks the link
  • The link opens the PDS to a page that offers Login or Create Account, and saves the GUID-1 in a session variable.
  • Bob creates an account.
  • Bob sees some UI that asks if he want to accept sharing of Alice's context, and in turn, share his equivalent context.
  • The PDS creates a context for Bob using the template URI from the link, call it Context-B1.
  • The PDS grants read-access to Alice to Context-B1 (since it knows her root ID).
  • Creates a pointer form Context-B1 to Context-A1.
  • Bob's PDS creates a GUID-2 for the reciprocal invitation to Alice, and creates the following statements in Alice's sharing_inbox context:
    • GUID-1, accepted_by, bob
    • GUID-1, accepted_timestamp, {timestamp}
    • GUID-2, invited_to, Context-B1
    • GUID-2, invited_timestamp, {timestamp}
    • GUID-2, invited_method, internal
    • GUID-2, identified_by, alice
  • Bob's PDS creates the following statements in Bob's sharing_inbox context:
    • GUID-2, invited_to, Context-B1
    • GUID-2, invited_timestamp, {timestamp}
    • GUID-2, invited_method, internal
    • GUID-2, identified_by, alice


Alice finalizes the sharing

Alice's PDS reads Alice's sharing_inbox and does the following:

  • Creates an ACL entry in Context-A1 granting read-access to {bob's user ID}
  • Creates a pointer from Context-A1 to Context-B1
  • Write the following entries into Bob's sharing_inbox context:
    • GUID-2, accepted_by, alice
    • GUID-2, accepted_timestamp, {timestamp}

Back to the top