This post has been superseded. I missed an important web UI issue which lead me to an incorrect conclusion.
Square peg, round hole
The OpenMicroBlogging Specification (OMB) contains a section on the use of OAuth to authorize a remote service to post to a user’s local service. After spending some time studying the OAuth and OMB specs, it seems to me that this is not the use-case that OAuth was designed to solve. A square peg in a round hole, you might say.
This is not to say that authorization is not needed for allowing post-sharing, only that OAuth was designed to address a different situation. The simplest way I can characterize the difference is that OAuth applies to a “one human, two services” problem and microblogging post-sharing is a “two humans, two services” problem.
OAuth’s intended use-case
So, what problem does OAuth fit? OAuth is intended to solve the problem of a person who has content or resources on Service A and wants to allow his/her account on Service B to access those A resources - without giving Service B his/her login credentials for Service A. Note well that it is the same person having accounts on both A and B. This is the “one-human, two services” aspect.
So, for example, let’s say you have an account on Twitter and want to use one of the many alternate Twitter clients out there, e.g., Twalala. You have an account with Twalala and would like to be able to access your account on Twitter without having to fork over your Twitter password. Using OAuth, you would be able to, in essense, tell Twitter to allow your account on Twalala.com to perform various read or post functions with your Twitter data. By the way, Twitter has been promising for months to implement OAuth for exactly this purpose. Again, note that there is only one person with accounts on both systems.
OMB post-sharing use-case
Now, let’s look at the case of two people on two different OMB-compliant sites who want to share their posts, either unilaterally or bilaterally. Let’s say I have an account “joecascio” on site subscriber.com, and my friend has an account “johnsmith” on poster.com and I would like to follow John’s updates. Note that it should not be necessary for either me to have an account on poster.com nor John to have an account on subscriber.com in order for me to “see” his updates. Indeed, this is the whole point of federated microblogging; that we can share posts without having to have accounts on many different services. So simply from this fact alone, OMB post-sharing is clearly not the “one person, two accounts” use-case. If post-sharing worked by requiring John to have an account on subscriber.com (the second of the “two services”) and then authorizing subscriber.com to let his Poster.com account post there, then yes, that would be the OAuth use-case. But it isn’t!!
So, what is an appropriate protocol or process for enabling and controlling post-sharing? I don’t have the complete answer, and I’m hoping that this post will cause some of the many smart people out there to suggest some. But I can state at least some of the problem characteristics, requirements or constraints.
Post-sharing is subscribing, not cross-posting
When I register my interest in someone else’s microblog posts, when I “follow” them, it means I want to subscribe to their post stream, just like I would subscribe to their traditional blog. If it were a traditional blog, I would do this by polling their RSS feed which is a simple GET by the subscriber. It does not involve the poster initiating a transaction to “send” me anything. But since microblogging implies a much lower latency, which would be inefficient to perform by polling, OMB introduces an optimization. The service on which the post was originally made proactively sends the new post to all subscribers. Great! We can now be notified that a new update is available within a few second without having to poll every few seconds.
BUT this is point of my observation. I would argue that this proactive send is merely an artifice of the optimization and does not change the fundamental relationship of poster and subscriber. From that basic user point of view, the fact that the poster initiates the data transfer is immaterial. The subscriber is still simply seeing something they expressed interest in reading.
This is where I believe OMB goes astray. It lets an optimization detail obscure the higher level concept. Following someone’s posts means I want to see those posts in my view, but it does not require that either party perceive it as cross-posting to my site. I could equally accomplish the same viewing of that post by fetching it on demand, albeit not as efficiently.
Subscribing is implicit authorization
Keeping firmly in mind the fundamental concept of poster and subscriber, what if any authorization needs to happen when I request to follow ‘johnsmith’? I would say that the very fact I am requesting to see John’s posts is an implicit authorization that he can send them to me. Whether he wants to let me see them is a different story and the subject of another post. Let’s assume he will let me see his posts and we want to use the OMB optimization of his service (poster.com) proactively sending them to me.
When I request to subscribe, I need to send a URL of where to send the notifications and a means to verify that the sender is who I granted the privilege to. This could be accomplished to different degrees of security. A fairly loose method would be for the subscriber to send a callback URL in the request that encodes a UID for the poster’s account. If the request transaction is secure, we can be reasonably certain that only the the “real” poster will be sending POSTs to that URL. Of course, this does not prevent the poster from sharing the UID, but the subscriber can always simply invalidate the URL and stop receiving the notifications.
In fact, this is pretty much how the RSS cloud API works and this could be a more proper model for OMB post-sharing.
What do you think?
I would be very interested to hear what others have to say about this post. One thing it does not cover is the complementary function of a subscriber GETting, rather than being sent an update. It also does not cover the perfectly matched use of OAuth to allow a user to grant access to other of his/her services just as described in the Twitter/Twalala example under “OAuth’s intended use-case”.
Tags: authentication, authorization, development, microblogging, OAuth, OpenMicroblogging