Arguments like this are why I have been advocating for separating the "developers guide" from the "protocol spec" for a while now. I believe that they support two different audiences.
A developers' guide then has the option of combining multiple specs, selecting profiles of those specs, and laying out exactly what's happening at each step for people to follow. -- Justin On Mon, 2010-09-27 at 11:35 -0400, Eran Hammer-Lahav wrote: > This is a stupid discussion. We have been talking past each other (the > working group) for over a year. We are not likely to convince either > side that bearer tokens are bad or good idea. > > > > All these experts reviewed WRAP in the strict context of their own > environment, with existing protocols and other weaknesses. Other and I > are reviewing it in the wider context of what is good for the web, and > am much less concerned about complexity. IOW, I don’t believe that in > this case WRAP made the right choice between developer ease and > security. > > > > This is also exactly the problem with the current specification. New > readers are more likely to assume that what is good for these big > companies is also good for them, without making their own threat model > analysis. How would they reach any other conclusion when the > specification doesn’t offer a complete alternative? > > > > We should focus on finding a compromise everyone can live with, since > clearly debating the two sides has produced nothing. I think > positioning bearer tokens as the primary mechanism, but including a > signature alternative in the same specification is a reasonable > compromise. Bearer token fans get the spotlight, while those looking > for a signature (providing the same protections as 1.0a HMAC-SHA-1) > get some algorithm included. > > > > We need to find a way to give each side something to live with. > > > > EHL > > > > > > From: Dick Hardt [mailto:dick.ha...@gmail.com] > Sent: Monday, September 27, 2010 6:31 AM > To: John Panzer; Eran Hammer-Lahav > Cc: OAuth WG; Ben Laurie > Subject: Re: [OAUTH-WG] Basic signature support in the core > specification > > > > > I'll echo John's comments and remind you that Micrsoft, Yahoo! and > Google security experts with plenty of real world experience worked on > WRAP which is OAuth bearer tokens. > > > > > Microsoft, Google, Salesforce, Facebook and others have deployed > bearer token OAuth in production after internal security reviews. I > don't think that is a personal opinion, that is fact. > > > > > wrt. another comment you had about security considerations, Brian > Eaton did write up a bunch of security considerations for WRAP. > > > > > On 2010-09-27, at 12:01 AM, John Panzer wrote: > > > > > On Sun, Sep 26, 2010 at 11:37 PM, Eran Hammer-Lahav > <e...@hueniverse.com> wrote: > > > > > -----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. > > > > > Actually in [1], Ben Laurie does not say that a simple reference to > TLS is a recipe for disaster. (Go read it.) In fact his first point > is that you need a well-define threat model before you can talk > sensibly about any of this; I would really like us to do that in this > case too. > > > > > > People tend to implement TLS incorrectly on the client side > which voids many of the important protections it is meant to > provide. > > > > > The bits they tend to implement incorrectly (specifically, things like > checking for certificate revocations) seem to me to be very general > and exactly the kinds of things one needs in order to implement _any_ > protection against the endpoint impersonation you are worried about. > Why would they be more likely to get it right for a new protocol than > for an existing one? > > > > > > > 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 > > > > > > > > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
