Re: [OAUTH-WG] HTTP request signing and repeated query/header keys

Justin Richer <> Sun, 28 February 2016 21:37 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 718EC1A6F8C for <>; Sun, 28 Feb 2016 13:37:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.206
X-Spam-Status: No, score=-4.206 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TfPMh3c7xBFT for <>; Sun, 28 Feb 2016 13:37:21 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 356401A6F93 for <>; Sun, 28 Feb 2016 13:37:20 -0800 (PST)
X-AuditID: 1209190f-077ff7000000091f-44-56d3688f443f
Received: from ( []) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id F1.6A.02335.F8863D65; Sun, 28 Feb 2016 16:37:19 -0500 (EST)
Received: from ( []) by (8.13.8/8.9.2) with ESMTP id u1SLbJoo011543; Sun, 28 Feb 2016 16:37:19 -0500
Received: from [] ( []) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by (8.13.8/8.12.4) with ESMTP id u1SLbF2o028791 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 28 Feb 2016 16:37:18 -0500
Content-Type: multipart/alternative; boundary="Apple-Mail=_AC585A9F-94EA-4CEA-8EDC-DD148CB206B4"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Justin Richer <>
In-Reply-To: <003b01d1726f$66036590$320a30b0$>
Date: Sun, 28 Feb 2016 13:37:14 -0800
Message-Id: <>
References: <003b01d1726f$66036590$320a30b0$>
To: Brock Allen <>
X-Mailer: Apple Mail (2.2104)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpileLIzCtJLcpLzFFi42IR4hTV1u3PuBxmcPy0icWMH0fZLU6+fcXm wOSxc9Zddo8lS34yBTBFcdmkpOZklqUW6dslcGV8+DeRvWCmXcXfDW0sDYz7TLsYOTkkBEwk dl1tY+ti5OIQEmhjkpgxcxorhLORUWJh6yIo5xiTxLvJM1hAWpgFEiQ+Lj3JBGLzCuhJvLp1 mRXEFhbwlvh7qB/MZhNQlZi+pgWshlPAQuLzuSagOAcHC1D8zFUdEJNZQF1i7soIEJNXwEpi X5ccSLGQgLnEw7/LmUFsEQE1iYXT5zND3Ckrsfv3I6YJjPyzkNwwC8kNEHFtiWULXzND2JoS +7uXs2CKa0h0fpvIuoCRbRWjbEpulW5uYmZOcWqybnFyYl5eapGuiV5uZoleakrpJkZwUEvy 72D8dlDpEKMAB6MSD+8LzcthQqyJZcWVuYcYJTmYlER5+8QvhgnxJeWnVGYkFmfEF5XmpBYf YpTgYFYS4XW3BCrnTUmsrEotyodJSXOwKInzxtw8GiYkkJ5YkpqdmlqQWgSTleHgUJLgPZQO 1ChYlJqeWpGWmVOCkGbi4AQZzgM0nDkDZHhxQWJucWY6RP4Uo6KUOO9ukGYBkERGaR5cLyjp uGSUKbxiFAd6RZg3GaSKB5iw4LpfAQ1mAhossf4SyOCSRISUVANjV5sOE9Ot1/GiQQI3g9XT fn/7vN/i/b+t17e93Kn5MU39XExOS16S1MdlD6bxs09T+cm5+vo0jmzhyhdX1x448PblMW++ Q7d/7FXcJ9QZO8Ng6dzkGb0fmPwW750e+Mr+RkO8ad5+3qr/RXcTyiJ9Z/2aE77MwsHw3onH Vq23t55rZJC2F/t3TImlOCPRUIu5qDgRAL49mvYVAwAA
Archived-At: <>
Cc: "<>" <>
Subject: Re: [OAUTH-WG] HTTP request signing and repeated query/header keys
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 28 Feb 2016 21:37:23 -0000

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 <> 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