Are you going to write it? Still waiting for the best practices guide for 1.0 people suggested over three years ago.
EHL > -----Original Message----- > From: Justin Richer [mailto:jric...@mitre.org] > Sent: Monday, September 27, 2010 12:04 PM > To: Eran Hammer-Lahav > Cc: Dick Hardt; OAuth WG > Subject: Re: [OAUTH-WG] Basic signature support in the core specification > > 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
