31–40 of 73 posts
It saddens me to see OAuth 2.0 in this state. As someone who’s made really minor contributions to 2.0 (and thus listed as a contributor in the spec), I have been really looking forward to it being finished and ready for production use (where production use means no more drafts). I stopped following the mailing list last year because most of the threads seemed all too familiar or out of my realm of knowledge to contri…
What does WS-* mean?
http://en.wikipedia.org/wiki/List_of_web_service_specificati... In short, it's collective name for many Web Services specifications that are still heavily in use in "enterprise" world. It's a mess.
That does not make it a mess.
WS-Trust, WS-Federation etc. have already solved problems that OAuth 2.0 attempts to solve, which doesn't make it bad, as Eran states. Bad is subjective.
Whether someone chooses to use it or not depends entirely on the requirement. Choice is good.
Earlier quoted context omitted.
Tricky and unnecessary crypto code: you mean HMAC, or something else? I've written code for Amazon EC2 that used HMAC and it wasn't too bad, and I'm now trying to evaluate whether to use OAuth 2, OAuth 1 or something else. Is there other cryptographic coding in OAuth 1 apart from the HMAC signature?
No, the HMAC-SHA1 signature is the only crypto needed in OAuth 1.
Just decided with my boss we're going to roll with a hybrid approach. Spent too much time reading through all these standards and not enough time thinking and coding.
Hang on a minute, from where I'm standing as a client developer OAuth 2 is much better than OAuth 1. Firstly, reducing the burden of tricky and unnecessary crypto code on the client is useful. Secondly, some of the article's points don't even make sense, like saying tokens are necessarily unbounded, which isn't true. The issuer can easily include the client_id in the token and check for its revocation when used, as i…
Tricky and unnecessary crypto code: you mean HMAC, or something else? I've written code for Amazon EC2 that used HMAC and it wasn't too bad, and I'm now trying to evaluate whether to use OAuth 2, OAuth 1 or something else. Is there other cryptographic coding in OAuth 1 apart from the HMAC signature?
My point was that OAuth 2 improved in a number of ways for clients and is at least as flexible for the issuer as OAuth 1, so I think the author is just disturbed by the trust of SSL for security, and the crappy, slow standardisation process, and ended up going overboard.
Earlier quoted context omitted.
This is simply brilliant. It's fascinating. I sometimes think that these people who puch for the "second system" really have no idea the problems they are bringing about. That is, it is innocent. Hate me for saying so, but there are just a lot of people working in software who lack a sense of wisdom. Folks like Fred Brooks who can see the madness are few and far between. Even rarer are those who both see the stupidit…
I think there's a "human factors" problem in action with second systems. The first system needs to be allowed to age before the second one becomes worthwhile - simply because more understanding will exist of both the problem domain, and how it was solved before. And if it's different people doing the second one, watch out.
The second generation is often fueled by things which were lacking or missing in the first version. At this point, the first generation is widely adopted, and now everybody and their brother wants their say in it.
Design by committee is bad. Design by brainstorm is good. Formality breaks everything.
Design by committee fails again. Maybe next time it'll work!
One major one is that, often, the participants come from different areas with different perspectives and visions of the outcome. Since participants rarely go to work with a firm set of agreed upon requirements or use cases, it leaves each member room to craft their own understandings of the goals. I've seen way too many working groups attempt to create a 'master' spec that takes into account all possibilities. Or, alternatively, clusters of people form from similar problem domains, and powerful clusters can take the work off course.
A second major problem is that there often is a lack of real user participants. Standards work is as close to the dullest engineering work one can get. Worse, it seems to attract certain types of engineers that love building specifications. Because of this, usually the real users flee immediately. This usually leaves a body of over-educated, overly-technical people to argue a lot over sometimes irrelevant details. Those types of people are definitely necessary for the standard to work in the end. But, because the real users flee, their influence is usually unchecked.
A third reason is that working groups rarely seem to use iterative and incremental life cycles. There's rarely any working code, often little V&V, and participants and users often can't experiment with their ideas. As we know, what's good in theory, sometimes doesn't work well in practice.
I think there are systematic reasons much standards work fails. The 'design-by-committee' outcomes arise from 1) lack of firm use cases to bound the work, 2) dissimilarity between participants, 3) lack of real user participants, 4) lack of iterative / incremental cycles.
We would be better far off it a single company/dictator (like, shudder, facebook) came up with a simple, competently designed one page authentication mechanism, provided some libraries in the popular languages and we all just went with that.
Yes, this is sad. And it happens all the time. Exactly the same thing happened to the whole Semantic Web effort at W3C. It basically got overtaken by enterprise and now it is of little interest or use to regular web developers.
I don't understand any of this. Microsoft develops and publishes 'protocols' (used lightly) and everyone hates them because they are pushing workable code out on everyone else... Bunch of people in a committee take three years trying to build the security token system to end all security token systems and have yet anything to show for it and we are sad? Why are people trying to do this anyway? oAuth is just an idea.…
Because OAuth is a protocol designed to enable systems developed independently and as such it's useless unless there's an high degree of standardization. It's like saying "why can't we all use our custom version of IP/TCP/HTTP/TLS". It simply wouldn't work.
Everyone has unique requirements.
Not really; the reality is more "Not everyone has the same requirements", which still leaves very large groups that do have the same or similar enough requirements; in fact, we've seen that with OAuth 1.0(a).