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

Justin Richer <jricher@mit.edu> Fri, 28 May 2021 18:21 UTC

Return-Path: <jricher@mit.edu>
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 1A94B3A30D8 for <oauth@ietfa.amsl.com>; Fri, 28 May 2021 11:21:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.196
X-Spam-Level:
X-Spam-Status: No, score=-4.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 zhGisxp-og18 for <oauth@ietfa.amsl.com>; Fri, 28 May 2021 11:21:24 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67A283A30D6 for <oauth@ietf.org>; Fri, 28 May 2021 11:21:24 -0700 (PDT)
Received: from [192.168.1.49] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 14SILIVN007066 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 28 May 2021 14:21:19 -0400
From: Justin Richer <jricher@mit.edu>
Message-Id: <ED67EEDD-2DF2-42A5-BB70-2C9FE7DD9ECA@mit.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_5C6A6D42-3363-430F-A6A2-07739E9837E6"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.6\))
Date: Fri, 28 May 2021 14:21:18 -0400
In-Reply-To: <359443702.361622099601973.JavaMail.root@shefa>
Cc: Aaron Parecki <aaron@parecki.com>, Sascha Preibisch <saschapreibisch@gmail.com>, IETF oauth WG <oauth@ietf.org>
To: "A. Rothman" <amichai2@amichais.net>
References: <952456782.01621954787444.JavaMail.root@shefa> <CAP=vD9sq72MKuw37voGE-0FAHpDXS-QsaRDHK04d3jFuNunyHA@mail.gmail.com> <357FECAE-9884-4A73-90FA-3F2FC44A0D1C@mit.edu> <1223731896.51621974079788.JavaMail.root@shefa> <2D8470ED-E192-464A-AE7C-7F69736BA66F@mit.edu> <1879083589.81621983782745.JavaMail.root@shefa> <ecb0b65ee3014b7baf2e7728a280f710@oc11expo18.exchange.mit.edu> <CAGBSGjr4zKh4AffHVTDriAiP-_o3K-aF4YYEZvJrULwV-Fmp+Q@mail.gmail.com> <359443702.361622099601973.JavaMail.root@shefa>
X-Mailer: Apple Mail (2.3608.120.23.2.6)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/5qekTa0g4rB-4lsuTOsyIgDGGX8>
Subject: Re: [OAUTH-WG] Can a client send the Authorization Request?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
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, 28 May 2021 18:21:29 -0000

So the text of RFC8705 is fixed, it could eventually be updated and obsoleted by another RFC, but that would take a new effort from the WG to consider it worthwhile. Not likely to happen for an implementation note like this, unfortunately. But OAuth 2.1 is meant to account for all of the different extensions and profiles of OAuth that are already out there, so it’s a really good place to discuss that kind of thing.

 — Justin

> On May 27, 2021, at 3:13 AM, A. Rothman <amichai2@amichais.net> wrote:
> 
> Maybe also worth mentioning something in RFC 8705, being the "OAuth MTLS" spec, along with the main OAuth 2.1 spec... I don't know how you'll arrange the RFCs next time around :-)
> 
> On 5/26/21 2:43 AM, Aaron Parecki wrote:
>> 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.
>> 
>> Aaron
>> 
>> On Tue, May 25, 2021 at 4:38 PM Justin Richer <jricher@mit.edu <mailto:jricher@mit.edu>> 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 [amichai2@amichais.net <mailto:amichai2@amichais.net>]
>> 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
>>