Re: [OAUTH-WG] Can a client send the Authorization Request?

Aaron Parecki <> Tue, 25 May 2021 23:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8EEFF3A138E for <>; Tue, 25 May 2021 16:43:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Yfg4sfqwTO63 for <>; Tue, 25 May 2021 16:43:28 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::12a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A144E3A1394 for <>; Tue, 25 May 2021 16:43:28 -0700 (PDT)
Received: by with SMTP id k4so26071521ili.4 for <>; Tue, 25 May 2021 16:43:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=E/3sS5FBCRSV5+URoclcVVEWm/UtfMeGt0vbCaDilCc=; b=Tf3BVZLhS531oaerLMU4q4gBs9PQa7l+OAjDYrTt51v+xmknQxmvj/NsBcOVZDH5gl Q9Cz8Z4WTzq9GelNYCd3e96X7/XK7hgIeylEZJ+6R2//HMCneycs+qicA+9/JBV3d0hk D3W+5P1pJv+GXmlS2AJgeSLslCqLQRsKyTykPhO34wycSLTLHe1IBTa7RA5swEMlWt62 fcPoRa1fpkHLxaqQx6AZBSqi7rhXy/2DVxLSt0AAdgSIOqkJa8gXbOlvX6FlIPU2/vDw LmdxjUj+F7VFhTupx/gdXrOwEx3x6ulv/uAFcF3rBS3A+aEAPRdKk3OOa3xr/PuQwWIC gxEw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=E/3sS5FBCRSV5+URoclcVVEWm/UtfMeGt0vbCaDilCc=; b=Yeh0S0kyWm9hrJttUMpCB2UArBg9HxprPGXVub4KLmARgbXvoCYK6K1qOmbrCuOEDd CmZGfu1HuUtpNY7hqjwE64lkvNiu+daeakcm0v9GzXNmIqCQ/NwW1qR+lfiJaPUXJt6N KBSRT28RA36UketEsrPNcAyo7BJw2K3v21/Ss2Mg+I4Rvpv3qWxDJAyZisbL04cvccsY i2PoJWUYmkKBvZKjxSFjrxK3jZRlizCnAeqY+S4iguHCK5ywPQ1qRXShgzRNS/44WZE6 btWgHfNA1vglw8GypBI6+ObvKNUWd6GUVjdT94jhapOk873EmGM9SQGwe1drSujyjOro Plqw==
X-Gm-Message-State: AOAM531VCLCrhS3z8IOtV6bK6ofrUvBWVWQBK8TkLq5RopRTcwZRsLy2 s4a9jNLJQjRHpO3IDZDxV0cYs9jC8ZDjkQ==
X-Google-Smtp-Source: ABdhPJxWAD3ytOFDtlHr0Ud/NNdtu80hbW2CZUhxX4XRJ9ID56igp4QHFsmQCp7+N3yT66ralENG5Q==
X-Received: by 2002:a05:6e02:927:: with SMTP id o7mr20938868ilt.35.1621986206743; Tue, 25 May 2021 16:43:26 -0700 (PDT)
Received: from ( []) by with ESMTPSA id e1sm5743833ilm.7.2021. for <> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 25 May 2021 16:43:26 -0700 (PDT)
Received: by with SMTP id o10so28807426ilm.13 for <>; Tue, 25 May 2021 16:43:26 -0700 (PDT)
X-Received: by 2002:a05:6e02:218f:: with SMTP id j15mr23853432ila.249.1621986205793; Tue, 25 May 2021 16:43:25 -0700 (PDT)
MIME-Version: 1.0
References: <952456782.01621954787444.JavaMail.root@shefa> <> <> <1223731896.51621974079788.JavaMail.root@shefa> <> <1879083589.81621983782745.JavaMail.root@shefa> <>
In-Reply-To: <>
From: Aaron Parecki <>
Date: Tue, 25 May 2021 16:43:14 -0700
X-Gmail-Original-Message-ID: <>
Message-ID: <>
To: Justin Richer <>
Cc: "A. Rothman" <>, Sascha Preibisch <>, IETF oauth WG <>
Content-Type: multipart/alternative; boundary="000000000000a085c505c3301730"
Archived-At: <>
Subject: Re: [OAUTH-WG] Can a client send the Authorization Request?
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: Tue, 25 May 2021 23:43:34 -0000

Honestly it didn't even occur to me that someone would try this, since the
entire point of the authorization endpoint is that it's the thing the
user's browser talks to. Adding MTLS just means you're going to have to
send the user to some other endpoint instead, which is then effectively
acting as the authorization endpoint anyway. So yeah I could see adding
some language around the authorization endpoint needing to be accessible by
the user agent without MTLS or other funny stuff.

PAR also fits in nicely in that case since the PAR endpoint could be
protected with MTLS since it *is* intended to only be accessible from the
OAuth client.


On Tue, May 25, 2021 at 4:38 PM Justin Richer <> wrote:

> I'm actually wondering if we should add discussion about not putting mtls
> on the authorisation endpoint into OAuth 2.1. Aaron et al, thoughts?
> -Justin
> ________________________________________
> From: A. Rothman []
> Sent: Tuesday, May 25, 2021 7:03 PM
> To: Justin Richer
> Cc: Sascha Preibisch; IETF oauth WG
> Subject: Re: [OAUTH-WG] Can a client send the Authorization Request?
> Justin,
> Thanks for this analysis. It pretty much sums up my own thoughts about
> this better than I could have :-)
> I just hope I wasn't 'leading the witness' too much... I'll have to
> double-check the details to make sure I didn't miss anything, but as I
> understand it, that's more or less it.
> btw it occurred to me that PAR wouldn't solve this specific problem either
> - if I understood correctly, it still ends with the user agent sending an
> Authorization Request to the AS, just with PAR-specific parameters instead
> of the usual ones... if so, and if the endpoint is still required to use
> mTLS, thus needs to be sent by the client... it would just be kicking the
> can down the road and violating the PAR spec instead.
> Thanks again for your time and explanations,
> Amichai