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

Neil Madden <> Sat, 18 January 2020 10:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C832E1200C5 for <>; Sat, 18 Jan 2020 02:21:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OIhGrWi2JCP2 for <>; Sat, 18 Jan 2020 02:21:08 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::343]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E1D57120058 for <>; Sat, 18 Jan 2020 02:21:07 -0800 (PST)
Received: by with SMTP id p17so10027604wmb.0 for <>; Sat, 18 Jan 2020 02:21:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Yi2g3LxV9VKDMkDq1ZI77LWT7EQUYJqu+0AoI+VIZnc=; b=MHAgMdorQySDqvhieQu0uO205F/MTlchEiq2uHz8KBKSZwZbP17qdnLko9MRCUerJw xX46/oDK4j/sRj+yCMY1MyVW17SF0tQrcdALYACHQEVGQw1I8Gyu7jGv8kcIiJYH43a7 srreFOHXsw38QnVIRUPremKXViSvnA4TZ4rbs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Yi2g3LxV9VKDMkDq1ZI77LWT7EQUYJqu+0AoI+VIZnc=; b=iODVniktet7XlacOmekleU45tPPJk3WFO2EboWy//LeiRwq5E+ZkeMZFeYvKkuMKmk R6ptDvGap3ePKcz905MLGMDBz0rnNzHJx0GO+LuZuMsZBgh//45Qr5NfkSUqGg7CplUZ toZ/cqK3eqiCaJX4qNzjtb6SkfrFH09Q3EDvIlPC6W+MlNRFwZwAf19kLL3+funXy73G YIlMMRKXSCvB9OgSEDR6X9BSEuLy9dBHOGqQudpDi6Yho+K4reWmGIeDUTDNJv19cr7d wq8apzF0dCEoT4/dyBuC6pugyZvnzlSw7aKVtg8U0KuAZ6trZoLwTViXtopp0RFctpYO Ei0Q==
X-Gm-Message-State: APjAAAWiVCVMuXMNp7RqlOUYqckYM99L1rYqAj0EcAS0KVkGfMOpatB1 v6XcGyPsY2tNa7hE7JsquYRGjUJd3nMAOOj5
X-Google-Smtp-Source: APXvYqyrN0UyT7hSwTrEyUIeSCmuGhcEx7oyhsPfOAnp0ELSfMqpmhGFTJF8Nw3QmA1R4PcNeT65xQ==
X-Received: by 2002:a05:600c:251:: with SMTP id 17mr9061945wmj.88.1579342866337; Sat, 18 Jan 2020 02:21:06 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id g18sm13068281wmh.48.2020. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 18 Jan 2020 02:21:05 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\))
From: Neil Madden <>
In-Reply-To: <>
Date: Sat, 18 Jan 2020 10:21:04 +0000
Cc: Nat Sakimura <>, IETF oauth WG <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <>
To: Benjamin Kaduk <>
X-Mailer: Apple Mail (2.3601.0.10)
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: Sat, 18 Jan 2020 10:21:11 -0000

On 17 Jan 2020, at 03:58, Benjamin Kaduk <> wrote:
> 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"

Well that's what actually I wanted to prevent. The authority component may refer to services *owned by* the AS (e.g. related microservices) but the authority component of a URI is not under the control of the AS - anybody can put whatever they like in there either from guessing likely hostnames or looking them up in things like certificate transparency logs. Compare that to something like x-request-id:<random-uuid> where the AS has complete control over the address space.

As Nat requested, I'll try and come up with some wording in a pull request that captures the issue in a more general way.

-- Neil