Subject: [OAUTH-WG] HTTP signing and parameter validation

From: "Brock Allen" <[email-masked]>
Date: Sun, 28 Feb 2016 16:41:12 -0500

Another question related to HTTP signing.

It's not clear to me from the RFC if the resource server should be using the
incoming pop token JWS to know what to verify, or if the resource server
should have a preconceived notion of what should be sent in the pop token.
For example, the query params: should the resource server decode the pop
token to see what a client included, or should a resource server always know
query params "a, b and c" should always be expected. The same goes for any
of the params (method, path, body, etc).

Thanks.

-Brock

---

From: Justin Richer <[email-masked]>
Date: Sun, 28 Feb 2016 13:45:07 -0800

It’s a bit of both and it’s going to be highly specific to the API being protected. The RS should reject a signed request in which a critical parameter is unsigned — some implementations of OpenID 2.0 were susceptible to exactly this kind of attack a number of years ago. 

We could probably add more guidance text to describe what the API designers need to communicate to the client and the RS in terms of what’s expected to be covered by the signature. I’m open to suggested text on that point!

 — Justin

> On Feb 28, 2016, at 1:41 PM, Brock Allen <[email-masked]> wrote:
> 
> It’s not clear to me from the RFC if the resource server should be using the incoming pop token JWS to know what to verify, or if the resource server should have a preconceived notion of what should be sent in the pop token. For example, the query params: should the resource server decode the pop token to see what a client included, or should a resource server always know query params “a, b and c” should always be expected. The same goes for any of the params (method, path, body, etc).
>  
> Thanks.
>  
> -Brock
>  
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth