Re: [OAUTH-WG] Basic signature support in the core specification

[Justin Richer <[e-mail]>]

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:[e-mail]]
> > 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:[e-mail]]
> > > 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-mail]> wrote:
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Dick Hardt [mailto:[e-mail]]
> > > > 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
> > >         [e-mail]
> > >         https://www.ietf.org/mailman/listinfo/oauth
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > 
>