> -----Original Message----- > From: Dick Hardt [mailto:dick.ha...@gmail.com] > Sent: Sunday, September 26, 2010 11:21 PM
> > What I absolutely object to is presenting a specification that to a new > reader will read as if bearer tokens are the default way to go. OAuth 2.0 core > today reads like a complete protocol and that's my problem. > > It is a complete protocol for many existing use cases. That's clearly a matter of personal opinion :-) and why we have been arguing about this for over a year. > For those use cases > where it is not, you can call require signatures and point people to the > signature spec, just like the use of bearer tokens points people to the TLS > specs. According to Ben Laurie [1] and Ben Adida [2], a simple reference to TLS is a recipe for disaster. People tend to implement TLS incorrectly on the client side which voids many of the important protections it is meant to provide. As the editor, I am having a hard time consolidating your view which treats readers as security experts, capable of making educated decisions about the protocol, and the demands from others that the specification should be completely accessible to any developer (especially those with no security background) and read like a tutorial on OAuth. If we want to keep the full range, we need to clearly express it, including highlighting the significant shortcomings of bearer tokens, the known TLS deployment issues, and the value in whatever signature proposals we have ready to reference or include. Standards are meant to improve interoperability, but also security. This is why any IETF charter dealing with an existing technology states that the working group may break compatibility if it has interop or security reasons to do so. We are doing fine on interop, but doing pretty badly on security. EHL [1] http://www.links.org/?p=846 [2] http://benlog.com/articles/2009/12/22/its-a-wrap/ _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
