• If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

  • You already know Dokkio is an AI-powered assistant to organize & manage your digital files & messages. Very soon, Dokkio will support Outlook as well as One Drive. Check it out today!

View
 

Identity and Activity Notes

Page history last edited by Chris Messina 14 years, 5 months ago

Introduction

This document is a proposal for a handshake process that builds on existing OpenID technologies to provide a means by which an activity provider can advertise the availability of an activity stream for a user at the earliest possible stage of the sign in process.

Definitions

Activity Provider: the service the user is registering for, which produces an activity stream the user may want to share. Same as the Identity Consumer. Identity Provider: the OpenID (or similar) service, where the user already has an account they want to use to login to the Identity Consumer, and where the user has contacts with whom they may want to share activity information.

Flow

  • The user wants to register with the Activity Provider and decides to login with their OpendID Identity Provider rather than registering using the site’s own registration system. The user’s Identity Provider for the sake of argument is also a social activity aggregator (Facebook, Plaxo, TypePad, etc)
  • The user is redirected to the Identity Provider to be authenticated. With the request, the Activity Provider includes a request for an activity callback attribute for the user from the Identity Provider, using SReg or Attribute Exchange.
  • The Identity Provider authenticates the user as usual.
    • If the Activity Provider has included the callback request, the Identity Provider should inform the user that the activity provider (the OpenID Relying Party) ask the user if they want to share their activities from Activity Provider with other members of the Identity Provider service.
    • If the user agrees to share their activities, the Identity Provider responds to the activityhook request with a the URI to a webhook (HTTP callback) on the Identity Provider’s service.
  • If the Identity Provider responds with an activityhook value, the Activity Provider sends an HTTP POST request to the provided URI, providing a feed_uri parameter and value.
    • Upon receiving the post request, the Identity Provider would begin aggregating the user’s activities to the Identity Provider community.
    • Aggregation could take several forms:
      • polling the providers feed
      • subscribing to the feed on a push hub
      • an as-yet undefined straight push from the provider to the aggregator.

Implementation

Mark Paschal and I (mostly Mark, to be fair!) built two demo Django apps that implement both the activity provider and identity provider parts of this handshake:

  • http://activity.neologasm.org is the activity (“Send Thanks!”) side of the equation. The app includes a new AX request with the login request: http://activitystrea.ms/axschema/callback. This tells the identity app that the activity app can provide one or more activity streams for the logging in user.
  • http://identity.neologasm.org is the identity app (“Cloudface”) - an OpenID provider. If the relying party sends along the callback AX request, the identity app prompts the user: "The relying party indicated that it can provide activity updates to this community. Would you like to share your activities with your followers on this community?". If the user confirms it, the identity provider will return a value that points to a user-specific, expiring callback endpoint on the identity site.
  • Once the activity app receives the endpoint URI, it POSTs to that URI a single value: feed_uri. That URI represents the feed for that user.
  • The identity app receives the POST, stores the uri for the user. At this point the “handshake” suggested above is complete. What the identity app (the social agregator) does with the feed is up to the application. In our case, the identity app checks for a pubsubhubbub element in the feed (which the Send Thanks app provides) and subscribes to the feed on pubsubhubbub.
  • The activity app pushes updates to pubsubhubbub, which pushes updates to the identity app.

Go ahead and register on the identity app linked above. Use that OpenID to sign in on the activity app. After you’ve sent a few thanks in the app, you’ll start to see the activity appearing on your profile in the identity app (may take several minutes to start appearing).

Discussion / Enhancements

This is a rough sketch, but I think the flow makes sense and all the pieces are in place to make this happen. The next step would probably be to expand this system to use a hybrid OpenID / Oauth protocol so that postbacks can be signed, but how that would best happen is open for discussion.

My hope with this is that we can get a discussion going that will help clarify the technological issues as well as the user-interaction issues. It isn’t difficult implementation (Mark Paschal and I - mostly Mark - implemented the handshake in a few hours), and I think the benefits to users, activity providers and social aggregators would be significant. Users are given an easy and understandable opportunity to take advantage of the power of sharing one’s activity in the community; activity providers are given more exposure in more communities for their service, and community/social network providers are given a valuable tool to increase members’ investment in the network.

Comments (0)

You don't have permission to comment on this page.