Re: [OAUTH-WG] Google's view on signatures in the core OAuth2 spec

[Justin Richer <[e-mail]>]

> > I think that any signature method that we end up using needs to rely
> > less on magic and anecdote and more on explicit declaration.
> 
> This is certainly correct ...
> 
> 
> > I think
> > that Brian Eaton's approach of sending the bare string that was  
> > signed,
> > which was also a JSON element that could be parsed and validated,  
> > was an
> > essential simplification.
> 
> ... but this does not follow.  The signer can specify what was signed  
> without sending the data...
> 
> > Even OpenID states which of the parameters on
> > the request were signed, which makes it easier to validate.
> 
> ... as in this pattern.  There are some other examples of elements of  
> the signed object being conditionally included:
> 1. HTTP Digest authentication [1]
> 2. The IKEv2 key exchange messages [2]

And I'm marginally OK with either pattern, though I think that the
former is a much cleaner way to do it. I believe either case to be
worlds better than the OAuth 1.0 method, which has caused countless
problems. I actually had to help someone debug between sending that
first email and this one, so I can attest that the problem has not gone
away! :)

> As has been pointed out before, there is a security risk in sending  
> the signed request data itself (as opposed to metadata that allows the  
> recipient to reconstruct the data), because the recipient can choose  
> not to verify the binding between the signed data and the request.

Yes, there is certainly a risk if someone just checks the signature and
does not verify the content of the message. This is a bad implementation
of an authorization system, to be sure, and it's an issue that people
need to be aware of. But simply signing metadata doesn't completely
solve the problem, either. In both cases there can be parameters that
are outside of the signed request that need to be checked and treated
appropriately. 

 -- Justin