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

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.

Received on Sunday, 13 May 2012 12:28:57 UTC