- From: Blaine Cook <romeda@gmail.com>
- Date: Sun, 13 May 2012 13:28:05 +0100
- To: "jeff@w3.org" <jeff@w3.org>, "public-socialweb@w3.org" <public-socialweb@w3.org>
- Message-ID: <CAAz=sckR-tbwQH185Xj7LoZS0kNSC_y-7rPuX3MnTGXVdLiA_w@mail.gmail.com>
Oops, forgot to attach the updated stack document. Attached here. b. On 13 May 2012 13:21, Blaine Cook <romeda@gmail.com> wrote: > 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.
Attachments
- text/html attachment: snlayers.html
Received on Sunday, 13 May 2012 12:28:57 UTC