Yes, I'm willing to write guides for the profiles that I use, once things settle down and we know what the protocol actually is. :) I'd argue that Facebook's developer docs are a start for "bearer tokens using the UX extension and web server/user agent profiles" already.
I think that the most sensible place to put things like this would be the oauth.net wiki. -- Justin On Tue, 2010-09-28 at 00:48 -0400, Eran Hammer-Lahav wrote: > 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
