W3C home > Mailing lists > Public > public-socialweb@w3.org > May 2012

Re: social new full set ( was: RE: Bassetti slides for AC meeting)

From: Blaine Cook <romeda@gmail.com>
Date: Sun, 13 May 2012 13:21:51 +0100
Message-ID: <CAAz=sc=GRt2TU5iKuDjpJgBrX=L-otS7LR3H_sSavW4ne+=26w@mail.gmail.com>
To: "jeff@w3.org" <jeff@w3.org>, "public-socialweb@w3.org" <public-socialweb@w3.org>
Here's a very slightly modified update to my social layers document.
I've filled in the data bit a tiny bit, and swapped Transport and
Identity as a result of attempting to do the stack walk-throughs.

A walk-through of "Update Personal Information" and "Share Information":

1. Update Personal Information:

Let's say that a user is on their mobile phone, and has just obtained
a new phone number that they'd like to share with their friends. Their
phone provides an address book application that will automatically
update their contact information.

- First, the user opens address book application (Layer 5,
Application), which is actually a website wrapped to appear as an
application (Layer 1, Infrastructure, Layer 2 Data [html]).
- The user must prove their identity to the application (Layer 4,
Session), which they do using their email address as an identifier
(Layer 3), fetched and parsed using webfinger (Layer 2 [xrd] and Layer
1 [http]).
- Having initiated a valid session, the address book application
proceeds to interact server-to-server with a new application, the
user's hosted profile server, which they discover via the user's
identity provider (webfinger):

     - The address book application makes a request to the profile
server (Layer 5, Application) using the OpenID Connect token (Layer 4,
Session), the user's profile URL (Layer 3, Identity), and an updated
Portable Contacts document to update the profile data (Layer 2, data)
using HTTP (Layer 1).

- The address book application then notifies the user that the update
has been made.

2. Share Information:

Asynchronously, the profile server will share the new phone number
with the user's friends.

Let's assume for sake of brevity that the user has created a few lists
on the profile server: "friends", "co-workers", "acquaintances", and
that "friends" are configured to be able to view phone numbers, but
co-workers and acquaintances are not without specific approval. We'll
call those people who are co-workers or acquaintances but also have
permission to see the user's phone number "approved users".

Upon receiving the updated phone number, the profile server finds the
union of the "friends" and "approved users" sets; for each member of
that set, identified by an email address, the profile server does the
following:

- In order to send the phone number update to the friend, the profile
server must find the profile server that handles each friend's contact
database  (Layer 5, Application).
- Taking the email address, the profile server does a webfinger lookup
to obtain the relevant URL (Layer 3, Layer 2, Layer 1). We'll assume
for the sake of simplicity that Layer 4 is unnecessary since this
information is public, however we could imagine a scenario where the
profile server must initiate a session between itself and the
webfinger server.
- Having obtained the address book provider, the profile server sends
a PubSubHubbub update, along with a signed JWT token (OAuth), using
the Portable Contacts format, to the friend's address book server
(Layer 1, 2, 3, 4).
- The friend's address book server verifies the validity of the JWT
token by performing a reverse webfinger lookup to obtain the public
cryptography information (Layer 1, 2, 3 in order to establish Layer
4).
- Having verified the validity of the JWT token, the friend's address
book server accepts the new contact information and makes it available
to the friend.

The next time the friend attempts to telephone our user, despite the
user having changed phone numbers, the friend's address book is
already up to date.

Hopefully that helps provide some context for the Layer document for
tomorrow, even if it's too late to have anything new incorporated into
the presentation! Good luck with the presentation!

Best,

b.
Received on Sunday, 13 May 2012 12:22:41 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 13 May 2012 12:22:42 GMT