Ok, missed that – thanks.
For now in my implementation I’m also ignoring this problem :) -Brock From: Justin Richer [mailto:[email protected]] Sent: Sunday, February 28, 2016 4:37 PM To: Brock Allen <[email protected]> Cc: <[email protected]> <[email protected]> Subject: Re: [OAUTH-WG] HTTP request signing and repeated query/header keys In §7.5 we currently have: The behavior of repeated query parameters or repeated HTTP headers is undefined by this specification. If a header or query parameter is repeated on either the outgoing request from the client or the incoming request to the protected resource, that query parameter or header name MUST NOT be covered by the hash and signature. [[ Note to the WG: is this something we need to cover? ]] Which is to say: Yeah, that’s a problem, probably. We either declare this behavior out of scope and say you can’t use this method with that kind of API (or at least those parameters/headers) or we define a mechanism for handling that. I’m in favor of the former, and removing the text from the generation sections that says repeated parameters are processed with no special handling, making them explicitly out of scope throughout. I would love to see more feedback from the group about this, especially if someone’s got a clever solution. — Justin On Feb 28, 2016, at 1:31 PM, Brock Allen <[email protected] <mailto:[email protected]> > wrote: Given that the client can iterate over the query/headers in any order to generate the concatenated value to hash, I think there’s an issue with query string or header values with repeated keys. I’ll stick with query params for simplicity in my sample. If a client signs this concatenated query: “a=1&a=2” then the “p” value in the signed JSON object could be this: "p": [["a", "a"], "blah"] On the resource server, how do you know which key/value pair to put in which order for verification? Also, given that different server implementations express these incoming parameters in different ways, it seems problematic to be consistent. Thanks. -Brock _______________________________________________ OAuth mailing list [email protected] <mailto:[email protected]> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
