Friday, October 03, 2008

Subscribing to Activity streams

Yesterday Paul asked a good question about subscriptions and identifiers in this push model for activity. If we take an explicit use case regarding how Paul subscribes to George's activity feed, the key is that Paul has to have at least one identifier for George that can be used to discover his activity service.

Leveraging XRDS, OpenID, OAuth and Portable Contacts this should be doable. Here is a graphic and flow.



  1. Paul logs into his SocialStream collector (with his OpenID)
  2. The SocialStream collector discovers Paul's PortableContacts service (via XRDS)
  3. Paul authorizes his SocialSteam collector to access his's PortableContacts service (via OAuth)
  4. The SocialStream collector asks Paul if he wants to subscribe to any of his contact's activity feeds (retrieved from the Portable Contacts service)
  5. Paul selects his friend George
  6. The SocialStream collector uses the identifier(s) for George to discover George's activity service (via XRDS discovery)
  7. The SocialStream collector subscribes to George's activity service
    • If subscribing to a public feed, no other information is needed
    • If subscribing to a protected feed, then OAuth can be used to determine if Paul is allowed access to the feed
    • Membership determination can leverage Portable Contacts tags as described here


2 comments:

Paul Madsen said...

Hi George, it's

"If subscribing to a protected feed, then OAuth can be used to determine if Paul is allowed access to the feed"

that I don't have a grasp of

OAuth allows a User to authorize a Consumer at an SP. But, the above would have you (as User) authorizing the Consumer (my SSC) to access your Activity Service on my behalf.

When you are at the SP ready to make the authorization, how do you refer to me? How will the Consumer get an access token for me?

paul

George Fletcher said...

I think I see the confusion. In this case OAuth is being used as the mechanism to get Paul's authenticated identifier so that George's Activity service can verify that Paul's identifier is a member of the allowed "authorization" group.

It would allow Paul's SocialStream collector to poll for updates at George's Activity service in the normal OAuth way. However, it also allows Paul's SocialStream collector to register an end point for push updates.

These push updated could be protected with 2-legged OAuth if required.

From a normal flow perspective, Paul's SocialStream collector would attempt to subscribe to George's Activity service.

George's activity service would respond that authorization is required.

At which point the normal OAuth flow would ensue.