Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authorization Request (JAR) vs OIDC request object

Benjamin Kaduk <> Fri, 17 January 2020 03:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5716C1200C7 for <>; Thu, 16 Jan 2020 19:58:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id S2EDPjnD5BkX for <>; Thu, 16 Jan 2020 19:58:50 -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 94948120044 for <>; Thu, 16 Jan 2020 19:58:50 -0800 (PST)
Received: from ([]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by (8.14.7/8.12.4) with ESMTP id 00H3wj6b031433 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 16 Jan 2020 22:58:47 -0500
Date: Thu, 16 Jan 2020 19:58:44 -0800
From: Benjamin Kaduk <>
To: Neil Madden <>
Cc: Nat Sakimura <>, IETF oauth WG <>
Message-ID: <>
References: <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <>
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authorization Request (JAR) vs OIDC request object
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 17 Jan 2020 03:58:52 -0000

On Thu, Jan 16, 2020 at 04:31:30PM +0000, Neil Madden wrote:
> The mitigations of 10.4.1 are related, but the section heading is about (D)DoS attacks. I think this heading needs to be reworded to apply to SSRF attacks too or else add another section with similar mitigations. 
> Mitigation (a) is a bit vague as to what an "unexpected location" is. Perhaps specific wording that it should be a URI that has been pre-registered for the client (and validated at that time) or is otherwise known to be safe (e.g., is a URI scheme controlled by the AS itself as with PAR).

pedantic nit: "URI scheme" is probably not what we want, as the authority
component of the URI (per RFC 3986) seems more likely to match "controlled
by the AS itself"


> In addition for this to be effective the AS should not follow redirects when fetching the URI. It's not clear to me whether that is implied by "not perform recursive GET" so it may be worth explicitly spelling that out.