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.
OAuth 2.0 and the Road to Hell
11–20 of 73 posts
Re: OAuth 2.0 and the Road to Hell
#12It 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…
Re: OAuth 2.0 and the Road to Hell
#13Firstly, 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 it did in OAuth 1. The same is true for self-encoding: clients don't have to issue self-encoded tokens and can instead issue unique id-style tokens with long expiry times. As for refresh, that's unfortunate but issuers could easily work around it if the OAuth 1 way was preferable.
In short, OAuth 2 is simpler to implement for the client in exchange for being slightly harder on the issuer, whilst also being more flexible. Yes, it relies on SSL for security. So does your bank.
Re: OAuth 2.0 and the Road to Hell
#14It 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…
Re: OAuth 2.0 and the Road to Hell
#15somewhat, shocking. i guess i'll be moving away from Oauth, feels like a relief and scary at the same time. what are some good alternatives?
Re: OAuth 2.0 and the Road to Hell
#16Hang 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…
Re: OAuth 2.0 and the Road to Hell
#17Hang 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?
Re: OAuth 2.0 and the Road to Hell
#18Re: OAuth 2.0 and the Road to Hell
#19What does WS-* mean?
Re: OAuth 2.0 and the Road to Hell
#20What does WS-* mean?
In short, it's collective name for many Web Services specifications that are still heavily in use in "enterprise" world. It's a mess.