First off, congratulations on the release of OAuth Core 1.0. :) Well done!
As I've mentioned to a few people over the last few months, we at Mashery are very interested in getting behind OAuth, and providing it as seamlessly as possible to our clients.
I've read through several drafts of the Core spec, and am re-reading the final 1.0 spec today. In doing so, a nagging question remains unanswered for me.
Everything I've read, starting with [Section 6], is based on the premise of Section 6's opening sentence.
"OAuth authentication is the process in which Users grant access to their Protected Resources without sharing their credentials with the Consumer."
This goal is very much in line with programmatically allowing access to Protected Resources, such as "I want SomeApp to be able to access my Google Calendar, but I don't want to tell SomeApp my Google credentials."
I get that.
What I don't see clearly within the OAuth core is the more pedestrian API authentication flow that we deal with often at Mashery. I refer to this as the "two-legged" scenario.
1. SomeCompany has an API. It issues credentials to interested parties (Developers) to access that API.
2. Developers access the SomeCompany API, authenticating in the process. (Various companies have different sensitivity preferences -- some just match on key, some have signatures based on shared secrets and keys, some have a 'login and get a token, use the token, then log out' procedure.)
... and that's it. There is no "User" -- in this scenario, the User and Consumer (as defined by the Core spec) are the same person.
My question: is OAuth intended to be used by the two-legged scenario?
Given that *most* of the scenarios out there that I've come across in my time doing Mashery do NOT include a three-legged scenario (SP +Consumer+User), I fear that widespread adoption of OAuth by companies in the two-legged scenario I'm describing may not happen ... if for no other reason that reading the spec (and the Getting Started documents) go directly to the more complicated three-legged scenario.
In the two-legged scenario, the Developer has already gotten a set of credentials from SomeCompany to use with SomeCompany's API. There's no need or desire on behalf of either party for there to be some additional "yeah, it's ok" UI with a browser.
I love the idea of OAuth, but it seems like a major pain to use for a two-legged scenario.