[OAUTH-WG] HTTP signing and parameter validation

"Brock Allen" <brockallen@gmail.com> Sun, 28 February 2016 21:41 UTC

Return-Path: <brockallen@gmail.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 414B11A702E for <oauth@ietfa.amsl.com>; Sun, 28 Feb 2016 13:41:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DWg7e1Hdoyig for <oauth@ietfa.amsl.com>; Sun, 28 Feb 2016 13:41:44 -0800 (PST)
Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95A571A700F for <OAuth@ietf.org>; Sun, 28 Feb 2016 13:41:44 -0800 (PST)
Received: by mail-pf0-x229.google.com with SMTP id 4so2095228pfd.1 for <OAuth@ietf.org>; Sun, 28 Feb 2016 13:41:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version:thread-index :content-language; bh=6/V4o7STht1sxdD/VQ1G9JI/XRchl+OpHQyiAv1zH98=; b=S1fNdWPKOpvXT5fruTFH7qHXziFVDUf8vu00KWKVsA9AWBFqxNQ564ToUdUJ3y0ITu 2IBROb1iG1UCQ+cnCOQucQ+6bj6HMKdb0loLQpB1hzDPH+S53rCYLArMlRSmyB0lcGNA SjpGhecEy3Ib9SD3ZJX+ibakwEOxLhaQWT3G6/mIkPZ2+8MjVf7WQixaH2SbG97Ih+ty yIzmJdalsb6hdqUyhNGQpXr5zzXccYRs4UKPgk1YREYchhVfScTY0o1vJUnLMkkGE09q 6+wzUl9s2xKDCWiBtgt8dxfq+i2R/svzbE0l5ERcq0/5FTFB4h0q4YhAxkpPElX/CzC3 45OQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :thread-index:content-language; bh=6/V4o7STht1sxdD/VQ1G9JI/XRchl+OpHQyiAv1zH98=; b=FBrT57GTpsR3TNuSNLa0LEI95owuhtMm/TYK9IYxL5xtQPOvY7yhg4g6Ju0OrCcW9Y Nnwkpui4sS5gU7espowqFGUV2krvNRbThNQ2jX/XlKN7rf7W8+yHpX0D+36hMCem/ip2 Nmj3pqt4WZACTk7BAs77h9xeOMI6VXrV4EXDeSfbXzxdmM6nBv4DLX0+b2X4Wxdkica2 jTeZG/leBbD6KaSoBVg8dGLkuv70aWFQ5RCSuwJiAMWPhwmR6vHl6df9q5IComY9u450 Oqdl4ycVOV6BiK7pu0ZtpQWb0rhSiACAwHdoRzVpqiuPRZuTYoolprruYlYbOm+WsR/Q j9hA==
X-Gm-Message-State: AD7BkJJwUl3CfjEAx720BkU2JYo4HKILBjTeOP4rCKaWyraeyqBUC010Jwln0ETWVpZpng==
X-Received: by 10.98.68.220 with SMTP id m89mr17878084pfi.65.1456695704291; Sun, 28 Feb 2016 13:41:44 -0800 (PST)
Received: from monk (ip68-9-116-135.ri.ri.cox.net. [68.9.116.135]) by smtp.gmail.com with ESMTPSA id ll7sm33089178pab.6.2016.02.28.13.41.43 for <OAuth@ietf.org> (version=TLSv1/SSLv3 cipher=OTHER); Sun, 28 Feb 2016 13:41:43 -0800 (PST)
From: Brock Allen <brockallen@gmail.com>
To: OAuth@ietf.org
Date: Sun, 28 Feb 2016 16:41:12 -0500
Message-ID: <004901d17270$c49dbaf0$4dd930d0$@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_004A_01D17246.DBC8EB70"
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AdFyb3Cta2A+egHyQ++Wc8zo3PDaMw==
Content-Language: en-us
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/hBv01abq_b7lVoz4EDyKzPDokDM>
Subject: [OAUTH-WG] HTTP signing and parameter validation
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 28 Feb 2016 21:41:46 -0000

Another question related to HTTP signing.

 

It's not clear to me from the RFC if the resource server should be using the
incoming pop token JWS to know what to verify, or if the resource server
should have a preconceived notion of what should be sent in the pop token.
For example, the query params: should the resource server decode the pop
token to see what a client included, or should a resource server always know
query params "a, b and c" should always be expected. The same goes for any
of the params (method, path, body, etc).

 

Thanks.

 

-Brock