5 ms·

OAuth 2.0 standard editor quits, takes name off spec

90 points by llambda 14y ago

apawloski 14y ago
This is disappointing to hear. For something so important to our immediate future, OAuth 2.0 is currently a mess. There are many different versions of the protocol -- some of which aren't backwards compatible -- and losing a leader like this is only going to make the situation worse.
- ecaron 14y ago
  I think the best hope of getting OAuth back on course is getting the current spec-writers to separately right a mechanism that interfaces with Google, Facebook, Twitter and LinkedIn. After they've each done that, they can get together and talk about how to rectify the train-wreck.
- aaron-lebo 14y ago
  Do you mind explaining why it is a mess? I'm not doubting what you are saying is true, it is just that recently I used a Clojure library to connect to Facebook, Google, and github, and the code to do so is simple and more or less the same for each site, with one of the sites being slightly different. Is the mess on the side of a library writer's perspective? Or in running it on the server?
  - ecaron 14y ago
    > more or less the same for each site, with one of the sites being slightly different That's because the Clojure library isolated you from the vastly different interpretations that those providers have of the spec. Had you written your connectors from scratch, you would have experienced the "mess."
bryanh 14y ago
I don't blame him, what a mess. IMO, a standards push of any sort needs a single, in-touch BDFL to say: "Here is how it is going to be, here are your limited options. Maybe, here are the official libraries and test suites." The current pattern of design by committee is severely broken.
hesselink 14y ago
See also http://news.ycombinator.com/item?id=4294959 http://news.ycombinator.com/item?id=4294959
paulsutter 14y ago
The solution is to come up with an OAUTH 1.1 spec that accomplishes what's really needed. The more modest version number will keep the complexifiers focused on "2.0" which will either never be finished or never be adopted.
- sunir 14y ago
  In my view, the most important goal for OAuth 2 was mandate SSL/TLS. That means it could remove timestamp and nonce, and only use plaintext signatures. Any implementation can do this and be backwards compatible with OAuth 1.0A clients by simply requiring SSL and plaintext signing and ignoring timestamp and nonce. Many days I am of mind to declare that a wildcat 1.1. I would like to see any changes iterate smaller, not to mention ignore enterprise use cases completely since they already have an excellent framework called SAML 2.0 and OAuth is mostly good to accelerate the development of self-served web apps (ie consumer apps and SaaS).
deleted 14y ago
[deleted]
tlogan 14y ago
The main problem of OAuth is not really the specs: it is tendency of us engineers to implement something different - even though there is no need to reinvent the wheel. Meaning, why does not a new service X model their implementation as Facebook - or maybe Twitter? But no - every new service starts from scratch and tries to reinvent the wheel. Even wrapper libraries cannot keep up with all these "understanding" of the protocol. (This rant is valid for APIs in general)

90 points by llambda 14y ago

This is disappointing to hear. For something so important to our immediate future, OAuth 2.0 is currently a mess. There are many different versions of the protocol -- some of which aren't backwards compatible -- and losing a leader like this is only going to make the situation worse.

ecaron 14y ago
I think the best hope of getting OAuth back on course is getting the current spec-writers to separately right a mechanism that interfaces with Google, Facebook, Twitter and LinkedIn. After they've each done that, they can get together and talk about how to rectify the train-wreck.
aaron-lebo 14y ago
Do you mind explaining why it is a mess? I'm not doubting what you are saying is true, it is just that recently I used a Clojure library to connect to Facebook, Google, and github, and the code to do so is simple and more or less the same for each site, with one of the sites being slightly different. Is the mess on the side of a library writer's perspective? Or in running it on the server?
- ecaron 14y ago
  > more or less the same for each site, with one of the sites being slightly different That's because the Clojure library isolated you from the vastly different interpretations that those providers have of the spec. Had you written your connectors from scratch, you would have experienced the "mess."

bryanh 14y ago

I don't blame him, what a mess. IMO, a standards push of any sort needs a single, in-touch BDFL to say: "Here is how it is going to be, here are your limited options. Maybe, here are the official libraries and test suites." The current pattern of design by committee is severely broken.

hesselink 14y ago

See also http://news.ycombinator.com/item?id=4294959 http://news.ycombinator.com/item?id=4294959

paulsutter 14y ago

The solution is to come up with an OAUTH 1.1 spec that accomplishes what's really needed. The more modest version number will keep the complexifiers focused on "2.0" which will either never be finished or never be adopted.

sunir 14y ago
In my view, the most important goal for OAuth 2 was mandate SSL/TLS. That means it could remove timestamp and nonce, and only use plaintext signatures. Any implementation can do this and be backwards compatible with OAuth 1.0A clients by simply requiring SSL and plaintext signing and ignoring timestamp and nonce. Many days I am of mind to declare that a wildcat 1.1. I would like to see any changes iterate smaller, not to mention ignore enterprise use cases completely since they already have an excellent framework called SAML 2.0 and OAuth is mostly good to accelerate the development of self-served web apps (ie consumer apps and SaaS).

deleted 14y ago

[deleted]

tlogan 14y ago

The main problem of OAuth is not really the specs: it is tendency of us engineers to implement something different - even though there is no need to reinvent the wheel. Meaning, why does not a new service X model their implementation as Facebook - or maybe Twitter? But no - every new service starts from scratch and tries to reinvent the wheel. Even wrapper libraries cannot keep up with all these "understanding" of the protocol. (This rant is valid for APIs in general)