Hi all,
The lead author of Oauth 2.0, Eran Hammer, has withdrawn his name from the OAuth 2 spec:
http://hueniverse.com/2012/07/oauth-2-0-and-the-road-to-hell/
That's a very sad news, IMHO, and it probably means we really should reconsider what protocol we want to support Oauth 1.0 / Oauth 2.0 / SAML or something else if we want to allow interoperability with our sites.
Best, Diederik
Thank you for share the news.
Best regards.
Fingerprint 35C0 49D6 E879 1F30 2FC3 0313 58C0 8857 4681 A236 Luis Antonio Galindo Castro (FunkyM0nk3y) funkymonster@gmail.com
The lead author of Oauth 2.0, Eran Hammer, has withdrawn his name from the
OAuth 2 spec:
http://hueniverse.com/2012/07/oauth-2-0-and-the-road-to-hell/
On Thu, 26 Jul 2012 06:13:52 -0700, Diederik van Liere dvanliere@gmail.com wrote:
Hi all,
The lead author of Oauth 2.0, Eran Hammer, has withdrawn his name from the OAuth 2 spec:
http://hueniverse.com/2012/07/oauth-2-0-and-the-road-to-hell/
That's a very sad news, IMHO, and it probably means we really should reconsider what protocol we want to support Oauth 1.0 / Oauth 2.0 / SAML or something else if we want to allow interoperability with our sites.
Best, Diederik
I thought OAuth 2 would have stayed dominant for a little while longer. But this just circles right back to something I've said from the start. We need to implement the Application registration, authorization/revocation handling, and spam tools in a completely abstract way that allows any protocol to be plugged in using an extension. ie: Everything that lets you revoke an App and see what app is responsible for an edit would be part of core. While the OAuth2 flow would be part of an OAuth2 extension.
This post actually feels almost like an invitation to re-read OAuth 1 (I read OAuth 2 in much more depth than OAuth 1). Look over all the advantages of each and come up with some real flows. And write a new protocol based of the best of each. Try to write a simple usable standard based off of that. And then ship MediaWiki with it hoping others will pick up on the same protocol. This kind of pushes me to want to write it myself. Though given my past, that won't go well unless I have people behind me supporting it.
Btw, before anyone decides to use some short-sighted argument in favor of OAuth 2 let's be clear about this. OAuth 2 is a protocol designed entirely for proprietary APIs like Facebook. We absolutely SHOULD NOT treat our goal as just a (proprietary) API for people to access Wikipedia. But aim for a protocol that would work cleanly for all MediaWiki installations.
On Thu, 26 Jul 2012 16:37:16 -0700, Daniel Friesen lists@nadir-seen-fire.com wrote:
On Thu, 26 Jul 2012 06:13:52 -0700, Diederik van Liere dvanliere@gmail.com wrote:
Hi all,
The lead author of Oauth 2.0, Eran Hammer, has withdrawn his name from the OAuth 2 spec:
http://hueniverse.com/2012/07/oauth-2-0-and-the-road-to-hell/
That's a very sad news, IMHO, and it probably means we really should reconsider what protocol we want to support Oauth 1.0 / Oauth 2.0 / SAML or something else if we want to allow interoperability with our sites.
Best, Diederik
I thought OAuth 2 would have stayed dominant for a little while longer. But this just circles right back to something I've said from the start. We need to implement the Application registration, authorization/revocation handling, and spam tools in a completely abstract way that allows any protocol to be plugged in using an extension. ie: Everything that lets you revoke an App and see what app is responsible for an edit would be part of core. While the OAuth2 flow would be part of an OAuth2 extension.
This post actually feels almost like an invitation to re-read OAuth 1 (I read OAuth 2 in much more depth than OAuth 1). Look over all the advantages of each and come up with some real flows. And write a new protocol based of the best of each. Try to write a simple usable standard based off of that. And then ship MediaWiki with it hoping others will pick up on the same protocol. This kind of pushes me to want to write it myself. Though given my past, that won't go well unless I have people behind me supporting it.
Btw, before anyone decides to use some short-sighted argument in favor of OAuth 2 let's be clear about this. OAuth 2 is a protocol designed entirely for proprietary APIs like Facebook. We absolutely SHOULD NOT treat our goal as just a (proprietary) API for people to access Wikipedia. But aim for a protocol that would work cleanly for all MediaWiki installations.
I went back and read through the final OAuth rfc. Saw some stuff I didn't like of course. And there were some valid reasons for trying to replace OAuth 1 (even though what they came up with was a failure).
Anyone want me to go back through the specs and make a list of some of the things that are wrong with both specs?
On 28/07/12 15:38, Diederik van Liere wrote:
Anyone want me to go back through the specs and make a list of some of the things that are wrong with both
Yes! I think that would be hugely helpful! Diederik
Maybe more appropiate for a wiki page, though, where you can easily and provide links to the issues and incrementally improvinng the overview.
On Sat, 28 Jul 2012 04:15:39 -0700, Daniel Friesen lists@nadir-seen-fire.com wrote:
On Thu, 26 Jul 2012 16:37:16 -0700, Daniel Friesen lists@nadir-seen-fire.com wrote:
On Thu, 26 Jul 2012 06:13:52 -0700, Diederik van Liere dvanliere@gmail.com wrote:
Hi all,
The lead author of Oauth 2.0, Eran Hammer, has withdrawn his name from the OAuth 2 spec:
http://hueniverse.com/2012/07/oauth-2-0-and-the-road-to-hell/
That's a very sad news, IMHO, and it probably means we really should reconsider what protocol we want to support Oauth 1.0 / Oauth 2.0 / SAML or something else if we want to allow interoperability with our sites.
Best, Diederik
I thought OAuth 2 would have stayed dominant for a little while longer. But this just circles right back to something I've said from the start. We need to implement the Application registration, authorization/revocation handling, and spam tools in a completely abstract way that allows any protocol to be plugged in using an extension. ie: Everything that lets you revoke an App and see what app is responsible for an edit would be part of core. While the OAuth2 flow would be part of an OAuth2 extension.
This post actually feels almost like an invitation to re-read OAuth 1 (I read OAuth 2 in much more depth than OAuth 1). Look over all the advantages of each and come up with some real flows. And write a new protocol based of the best of each. Try to write a simple usable standard based off of that. And then ship MediaWiki with it hoping others will pick up on the same protocol. This kind of pushes me to want to write it myself. Though given my past, that won't go well unless I have people behind me supporting it.
Btw, before anyone decides to use some short-sighted argument in favor of OAuth 2 let's be clear about this. OAuth 2 is a protocol designed entirely for proprietary APIs like Facebook. We absolutely SHOULD NOT treat our goal as just a (proprietary) API for people to access Wikipedia. But aim for a protocol that would work cleanly for all MediaWiki installations.
I went back and read through the final OAuth rfc. Saw some stuff I didn't like of course. And there were some valid reasons for trying to replace OAuth 1 (even though what they came up with was a failure).
Anyone want me to go back through the specs and make a list of some of the things that are wrong with both specs?
I've back through the specs and went over most of the issues in both specs and a little bit on top with things we'll need that don't exist anywhere: https://www.mediawiki.org/wiki/OAuth/Issues
Btw here's a little tidbit about existing /implementations/ of OAuth 2:
To use the client_secret credentials OAuth 2 defines a way of using a HTTP Authorization: header with "Basic" HTTP auth. And a way of including the client_secret as a client_secret parameter inside of a POST body, while strongly recommending that method not be used.
Surveying the documentation for Facebook, Google, and Meetup's OAuth 2 implementations the way they support client_secret is quite consistent. They *all* violate the spec. The three of them exclusively make use of the client_secret as URI query parameter. This was never valid in any draft of OAuth 2. Not even old drafts these providers are supposed to have implemented.
So not even is OAuth 2 problematic from a security perspective and defines itself as non-interoperable framework rather than a protocol. Half the major providers that say they support OAuth 2 actually aren't even following the spec. ;) In other words, OAuth 2 is looking pretty worthless right about now.
wikitech-l@lists.wikimedia.org