[OAUTH-WG] On splitting the spec and the scope of signatures

[Skylar Woodward <[e-mail]>]

Apologies in advance for adding a new thread, but I've only just switched from digest mode. I'm jumping into the middle of the discussion as our organization (kiva.org) is in the process of becoming an OAuth provider and we're planning to start with a OAuth 2.0-based API (or nearly so) out of the gate. As such, we have an interest in seeing 2.0 finalized, and hopefully in a way that suits Kiva's needs (protecting user's and partner's financial data, and being agile - we're a small non-profit compared to many organizations active in the discussion).

+1 for signatures (If I may be so bold on the first post).  I'll withhold other votes until we've had time to digest more of this.


Meanwhile, I'd like to throw out a strawman for splitting the specification in a different way - that is, by guarantee-able security contexts rather than by sequence, as in getting vs. using tokens. (I'm know everyone has voted on Eran's proposal and I don't mean to impede progress - this suggestion is easily enough ignored if it's found to be without sufficient merit.)

In OAuth 1.0, it always troubled me that two dramatically different use cases co-existed in the same specification. For discussion purposes can call these two the Web Server use case and the User App use case. In terms of OAuth mechanics, you might see these two as apps that can protect a client secret, and those that can't. In the pre-OAuth days at Yahoo! this had evolved as BBAuth and CBAuth (client-based auth), since we had decided that the inability of (consumer device-base) clients to keep secrets justified an independent spec and set of best practices.

Now, I'm going to digress a bit and talk our history with all this in building Fire Eagle at Yahoo!... When the team first committed to OAuth and was digesting the specification, it took a while for the team as a whole to get our head around the fact that we couldn't offer the same level of security/privacy to users of User Apps (desktop, iPhone, etc.) vs. users of Web Server apps (dopplr, etc.). The OAuth spec presented a single system for everyone based on mechanics most of us knew well (flickr, bbauth, etc.) and most people on the team knew webs apps well but few had experience building downloadable client apps. That meant we often focused on the flows and security provided by Web Server apps. After struggling through it all and the evolving OAuth spec, we hand a good handle on the differences, and thus, in the end, we supported different capabilities to Web apps vs. Desktop/Mobile apps. We also forced developers to choose their type of app on sign-up because we thought it was important they also understood this difference too so they could best uphold the contract they had conveyed to their users (and ours) both in their UI and in how they might use their client secrets.

The unfortunate part of all this is that desktop apps and smartphone apps were unnecessarily complex based on the contract they provided. At the same time we were just ahead of a tidal wave of new User App development that few people would have expected as Apple's app store (and all the trends that followed) didn't exist yet. So being a minority, there wasn't much of a push to create a different flow for User App types - they were just to use the same mechanics as Web Server apps. A bit of a compromise was PLAINTEXT signing, which let apps (who already had their client secrets in the clear) just put them in the API calls to avoid complex signatures. This worked for us as we also eventually committed to SSL-based connections for everything on the basis that all data we were transmitting was user-private anyway.  However, User Apps still had to do the whole OAuth dance which I'm guessing has become more and more annoying as smartphone client development has increased.

Thus, what you guys are doing is great because OAuth 2.0 lets those unable to protect their secrets dismiss all the crud designed for server-server systems. v10 proposes something so simple, you might not even need a client lib to get your API off  the ground. However, I'm afraid what has been lost is all the extra security and potential that is still offered by OAuth 1.0.

In a sense, the split I would propose is already achieved by OAuth 2.0 and OAuth 1.0.  The problem is that most people will see 2.0 as an "upgrade" to 1.0 rather than a reduced and simplified security model. If you add signatures, it's 1.0 but with the focus on the less secure transactions out of the gate.  If you split the spec on access token/usage it seems to weaken the system entirely to something that needs to be brought back together in a parent spec (as the ICE spec did for all the disparate P2P/VoIP specs) for it to have value. Then, I'd fear you actually end up with two parent specs - one that ties things together for apps that can keep secrets, and another for those that can't.

Another alternative strawman to my own strawman would be to postpose the final OAuth 2.0 and start with "OAuth for Devices." That is, it's OAuth without client identity enforced. This allows Google, Facebook and others to proceed with something equally secure to WRAP or similar implementations they have now. Then, you could proceed by adapting 1.0 mechanics for apps with client identity in the 2.0 style (including other improvements/provisions made) to a final spec and resolve all the tension with how to combine these very different experiences and contracts into one spec. Hopefully, you'll also end up with two basic mechanics that work for lots of people rather than one mix of rules that are highly adapted on a case-by-case basis resulting a myriad of resulting mechanics that aren't interoperable and likely also devalue at the end of the day what it means to be "OAuth compliant."

In any case, thanks to everyone here for working hard to hammer out something for the rest of the world. Our resources are limited, but I'll contribute where it seems helpful or if what's evolving seems contrary to Kiva's API security needs.

skylar