Google caused some confusion when they announced OpenSocial will only use some parts of OAuth, and with a few minor adjustments. While the language of the announcement could have been a little clearer, it described a unique OpenSocial need: authenticate Consumers when no user interaction is needed. In the OpenSocial world, when a user installs a widget, they automatically grant Consumer access to their resources. So the OAuth dance of getting the user to agree is not needed (at least in the context of accessing containers).
However, OpenSocial still needs a way to authenticate Consumers. They can’t use HTTP Basic authentication because it is not safe, and they can’t really use HTTP Digest because, well, it is just too complicated. So instead of inventing yet another signature method, Google opted to adopt the OAuth signature protocol, without using the rest of the Consumer-User-Service Provider dance, aka the three-legged scenario. Google’s John Panzer posted a great explanation which Mashery’s Clay Loveless pointed out is not unique to Google, but is something they could use as they usually deal with two-legged scenarios where no user is involved.
Turns out, Nouncer was already doing this for its Consumer management API. Since Nouncer is an API-only framework (no human-accessible HTML pages), it needs to provide a way for Consumers to manage their profiles. Since every Nouncer Consumer already has OAuth credentials, it was a natural choice to use them for the Consumer APIs, which of course have no user involvement. And so, it seems appropriate to formalize this in an OAuth extension. If Nouncer uses it, and Google and Mashery needs it, this sounded like a good idea.
The new extension invents nothing, and proud of it. It uses the OAuth flow with some minor clarifications to create a simple method of using OAuth in a two-legged scenario. It was published today and I expect a very quick path to final version.