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

Reply via email to