Re: [OAUTH-WG] JWT Secured Authorization Request: Inconsistencies with request_uri

Jim Manico <jim@manicode.com> Fri, 24 March 2017 17:14 UTC

Return-Path: <jim@manicode.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D3F31275AB for <oauth@ietfa.amsl.com>; Fri, 24 Mar 2017 10:14:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=manicode-com.20150623.gappssmtp.com
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 HHF6hwlHbwAT for <oauth@ietfa.amsl.com>; Fri, 24 Mar 2017 10:14:27 -0700 (PDT)
Received: from mail-pg0-x231.google.com (mail-pg0-x231.google.com [IPv6:2607:f8b0:400e:c05::231]) (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 62F5D1297C4 for <oauth@ietf.org>; Fri, 24 Mar 2017 10:14:22 -0700 (PDT)
Received: by mail-pg0-x231.google.com with SMTP id t143so4036131pgb.2 for <oauth@ietf.org>; Fri, 24 Mar 2017 10:14:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=manicode-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xtL0Iy0PUo326o8Y7w8Y30LZq5AxTS80cN+7Wu3DFFU=; b=HoGZ/cB22fDQiD6j8Z2lADiOTDqu6ocw5D976hRN0QgBIcgSCUVg0W5OcTqcCxkbN+ kv1VaSteZ26lCa/O1XzgMCp95X+yMrL1/Rt5l1kKXiGZVPB0YPK1GtQgdYeCbsI0fyE0 X4McFP21oEFSVKBW4Ji1z7dzNvzd9iA+jdJUjE+3HfHh6nHRQfUTQIcL0BdA1sP5RUW6 LGfTFx+hi/DZ+YIEppcl8AuWPCsKIPDU0mZt5oiTRivwxSCurFVwZnR8rOwM9ZgFAWYI XTCrzrShEFVHlkhcfQobN6Tx5kC6+FmGQ3mHyDFcUlKfE6+ZTBLqT5LBpoJLWaYdwO0X NpfQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xtL0Iy0PUo326o8Y7w8Y30LZq5AxTS80cN+7Wu3DFFU=; b=sq6lC51ZRu7kUhUcKStEgWWg8mcALj4me3qRbvO+GcSP1uSZf8f5dR8mON451kVa// TcQS0FgGbJisL3CXx7z7ZF5gCvCV8a/H4No6CWHeTffWN4XlQ8/ABVo5iSFcxw1xDdsI BYBxGiIsGePIjdoXJav4YRnM3fVqeOlZZzifFUOxVU3aSeTYLF59GfeHWx/1YJ7RV4o2 Vqm/auOoeT7gMkI6Jq4UPTXdlbo7cFhtBaKipmzrIIHeOo5LoyUjyh7ZzptliVdC7DWN Lp3OkRyfnJK2+JsvX/hJz/ej8P9/qaW7yuQZCXAd3A8DbQSxtwN7KFG3PnvKFkxuhCLH o/oA==
X-Gm-Message-State: AFeK/H37inIXAFbJUfn93BlQikGxFPPaTBGhXKt75TEsNwOnSqXycYsw6lsAAD6lBYNWgQPC
X-Received: by 10.99.60.12 with SMTP id j12mr7164694pga.233.1490375661768; Fri, 24 Mar 2017 10:14:21 -0700 (PDT)
Received: from [10.110.63.188] (mobile-166-176-187-98.mycingular.net. [166.176.187.98]) by smtp.gmail.com with ESMTPSA id n185sm5804852pga.9.2017.03.24.10.14.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Mar 2017 10:14:21 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail-C469E3F2-7BCD-4717-BA67-3A027445242C"
Mime-Version: 1.0 (1.0)
From: Jim Manico <jim@manicode.com>
X-Mailer: iPhone Mail (14D27)
In-Reply-To: <CAP-T6TSUm=-UQnp8XrjqUs71R7zHkO43ajuOFiJB20ovx_7Xkw@mail.gmail.com>
Date: Fri, 24 Mar 2017 10:14:19 -0700
Cc: oauth@ietf.org
Content-Transfer-Encoding: 7bit
Message-Id: <9CDF68D5-B041-4E58-BFFE-F1F8A48640E9@manicode.com>
References: <CAP-T6TSUm=-UQnp8XrjqUs71R7zHkO43ajuOFiJB20ovx_7Xkw@mail.gmail.com>
To: Dave Tonge <dave.tonge@momentumft.co.uk>
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/tzC9I1FICwbrFLW4eFTp1i6P-5A>
Subject: Re: [OAUTH-WG] JWT Secured Authorization Request: Inconsistencies with request_uri
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
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: Fri, 24 Mar 2017 17:14:30 -0000

From a security POV please force HTTPS as we see in 5.2.1. The only performance problem with HTTPS is that it's not used enough. There is no good reason for a security framework to support HTTP.

Aloha,
Jim

> On Mar 24, 2017, at 9:15 AM, Dave Tonge <dave.tonge@momentumft.co.uk> wrote:
> 
> Hi Nat and John
> 
> I have some questions re the JWT Secured Authorization Request spec
> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-12
> 
> 1. Does the request_uri always have to be an URL? 
> If the request object is hosted by the client then it makes sense, but if 10.3.d is followed and the AS provides an endpoint where the client can exchange a request object for a "Request Object URI" then it would seem acceptable for that uri to be an urn. Only the AS would need to be able to fetch the request object and therefore there would be no need for the request object to be made available via https.
> 
> 2. Should the mechanism described in 10.3.d be explained in 5.2?
> I think that 10.3.d could be widely used as it solves a number of problems - however it is currently not clearly defined in either OIDC Core or jwsreq. 
> 
> 3. The spec seems inconsistent on the use of HTTPS
> Subject to any discussion re request_uris always being urls, there seems to be an inconsistency between 5.2 and 5.2.1 
> 
> 5.2: 
>  The scheme used in the "request_uri" value MUST be "https",
>    unless the target Request Object is signed in a way that is
>    verifiable by the Authorization Server.
> 
> 5.2.1
> The Client stores the Request Object resource either locally or
>    remotely at a URL the Authorization Server can access.  The URL MUST
>    be HTTPS URL.  This URL is the Request Object URI, "request_uri".
> 
> 
> Thanks
> 
> -- 
> Dave Tonge
> CTO, Momentum Financial Technology
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth