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

"A. Rothman" <amichai2@amichais.net> Sat, 29 May 2021 08:32 UTC

Return-Path: <amichai2@amichais.net>
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 AD6BB3A0ECC for <oauth@ietfa.amsl.com>; Sat, 29 May 2021 01:32:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.393
X-Spam-Level: *
X-Spam-Status: No, score=1.393 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FORGED_MUA_MOZILLA=2.309, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RDNS_DYNAMIC=0.982, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 L1_FapDxPo4h for <oauth@ietfa.amsl.com>; Sat, 29 May 2021 01:32:28 -0700 (PDT)
Received: from mail.freeutils.net (line134-103.adsl.actcom.co.il [192.115.134.103]) by ietfa.amsl.com (Postfix) with ESMTP id 9C0993A0EC4 for <oauth@ietf.org>; Sat, 29 May 2021 01:32:27 -0700 (PDT)
Message-ID: <802860253.681622277141675.JavaMail.root@shefa>
MIME-Version: 1.0
X-UserIsAuth: true
Received: from router.asus.com ([192.168.80.1]) by mail.freeutils.net (JAMES SMTP Server 2.3.1) with SMTP ID 801; Sat, 29 May 2021 11:32:21 +0300 (IDT)
To: Justin Richer <jricher@mit.edu>
Cc: Aaron Parecki <aaron@parecki.com>, Sascha Preibisch <saschapreibisch@gmail.com>, IETF oauth WG <oauth@ietf.org>
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> <ED67EEDD-2DF2-42A5-BB70-2C9FE7DD9ECA@mit.edu>
From: "A. Rothman" <amichai2@amichais.net>
Date: Sat, 29 May 2021 11:32:21 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1
In-Reply-To: <ED67EEDD-2DF2-42A5-BB70-2C9FE7DD9ECA@mit.edu>
Content-Type: multipart/alternative; boundary="------------56A8020B576CAD09D8934C3B"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/ca7IGGBH-nMXiseY6AwJrzyk9NQ>
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: Sat, 29 May 2021 08:32:33 -0000

Yeah, I just meant it could naturally fit also in the next iteration of 
RFC8705, if/when it is superseded. In the main spec would obviously be 
great :-)

Thanks!

Amichai

On 5/28/21 9:21 PM, Justin Richer wrote:
> 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 
>> <mailto: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
>>>
>