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

"Brock Allen" <> Mon, 29 February 2016 01:17 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2BA741AD0A6 for <>; Sun, 28 Feb 2016 17:17:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id W0yxR_zEuTvx for <>; Sun, 28 Feb 2016 17:17:51 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c00::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A43441AD0A4 for <>; Sun, 28 Feb 2016 17:17:51 -0800 (PST)
Received: by with SMTP id w128so37147574pfb.2 for <>; Sun, 28 Feb 2016 17:17:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=2p1FVcmw+R9qz7TmvqG9R7uUcEEANgxXRVmOmwz4Q5Q=; b=ROuvwNcAB76P6GlyEJhQ3bZIATT97vd0z7NMv+zJSZRGPwmYHhLKlRUpTf7Hwk+Rxc 4W2saX9Uw7x4KkV0kl7TITKCWCsmb6l5Dx78C+3zJWUmvlDHkYY18TwJKlIEb5DAH/hb k9R7KxUzPyoLQIHKKFsXxdXOSePTX62jpXrKIY6oWgv81myiHsGTsIaHaFlSQW7a8d/1 RR9mnAevBrSbAAhBmTw9ec1PP/GwynDV9/quI6GQn75G7U5sH/f7VN6vngNpOpx2JL60 Aw5fRXByGGMnf36+Iw19v9Ggj6UXhLPj/ebF2wTxhvD1lCpocjjtxSu8/LZdQ8lFUldo i/YA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=2p1FVcmw+R9qz7TmvqG9R7uUcEEANgxXRVmOmwz4Q5Q=; b=GDceTKfNQSIEuM0iAe3WYIghI6uPGQMrTypgtx9+FQ6gpDvvU9ZuLYlCFfETGOX6AY AvPeE4aSW/kLjV0d59wmwSkyh6i0OB8HgCZ2uSygJ5/RqK6Ju6fFKzZJtyYIrEP+yhw1 6MZMVF3zbE8+HhK4kJYYb5hMAc+3vLjsvnh1/UiI/QskIopZsIU98AwaZf4laGkpO2b5 k5kDD544rX86Wfeh+GGrtX2H21cXEjcbgzvvMmI5wzsEz5hL5MTh86bgPS9gGzSK0rjH JKotgr+pBNVXvqT7D3xCt1IlrpAS+HlSaSSQbHdiFnMkFayosBBMsrJ9zTsGLr5ZvO/s CBKQ==
X-Gm-Message-State: AD7BkJIziWClbvDVr3ybOR//3zGZMQJNThg171kZpZqSsQU1EaEwz4PP5eVgYy5CHNTPlg==
X-Received: by with SMTP id p19mr18657357pfi.165.1456708671076; Sun, 28 Feb 2016 17:17:51 -0800 (PST)
Received: from monk ( []) by with ESMTPSA id h85sm19386524pfj.52.2016. (version=TLSv1/SSLv3 cipher=OTHER); Sun, 28 Feb 2016 17:17:49 -0800 (PST)
From: "Brock Allen" <>
To: "'Justin Richer'" <>
References: <003b01d1726f$66036590$320a30b0$> <> <005401d17272$070325a0$150970e0$> <>
In-Reply-To: <>
Date: Sun, 28 Feb 2016 20:17:27 -0500
Message-ID: <006f01d1728e$f52af250$df80d6f0$>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0070_01D17265.0C56BF10"
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQFXkD4wUaeZYzbNhPIxfaFoz/BUGADRFDTHAaJuhE4B7FuyY6AS/gDA
Content-Language: en-us
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: Mon, 29 Feb 2016 01:17:54 -0000

Yea, I’m cool with just saying “duplicate keys won’t work” for my implementation, unless I do some implementation specific thing like sort them by value order or some such (but that would have to be on both sides).




From: Justin Richer [] 
Sent: Sunday, February 28, 2016 8:13 PM
To: Brock Allen <>
Cc: <> <>
Subject: Re: [OAUTH-WG] HTTP request signing and repeated query/header keys


Yeah, that’s the trick — you don’t want to end up replicating the entire HTTP message inside the JWS envelope, because then you end up with a SOAP kind of approach where you’re not really using the outside HTTP constructs to their fullest anymore. 


In the end, I don’t think this spec is ever going to be perfectly universal, but if it can hit a majority of use cases with a simple and robust solution, I think we’re in good shape.


 — Justin


On Feb 28, 2016, at 1:50 PM, Brock Allen < <> > wrote:


Now that I’m thinking about this, the only thing that comes to mind is a hash of the value included somehow (which I’m sure you’ve already thought of). That’s obviously more complexity and overhead for all scenarios to support this edge case. 




From: Brock Allen [] 
Sent: Sunday, February 28, 2016 4:40 PM
To: 'Justin Richer' < <> >
Cc: '< <> >' < <> >
Subject: RE: [OAUTH-WG] HTTP request signing and repeated query/header keys


Ok, missed that – thanks.


For now in my implementation I’m also ignoring this problem :)




From: Justin Richer [] 
Sent: Sunday, February 28, 2016 4:37 PM
To: Brock Allen < <> >
Cc: < <> > < <> >
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 < <> > 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.






OAuth mailing list <>