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 OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth