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 >>> >
- [OAUTH-WG] Can a client send the Authorization Re… A. Rothman
- Re: [OAUTH-WG] Can a client send the Authorizatio… Torsten Lodderstedt
- Re: [OAUTH-WG] Can a client send the Authorizatio… Sascha Preibisch
- Re: [OAUTH-WG] Can a client send the Authorizatio… A. Rothman
- Re: [OAUTH-WG] Can a client send the Authorizatio… Justin Richer
- Re: [OAUTH-WG] Can a client send the Authorizatio… A. Rothman
- Re: [OAUTH-WG] Can a client send the Authorizatio… A. Rothman
- Re: [OAUTH-WG] Can a client send the Authorizatio… Justin Richer
- Re: [OAUTH-WG] Can a client send the Authorizatio… A. Rothman
- Re: [OAUTH-WG] Can a client send the Authorizatio… Justin Richer
- Re: [OAUTH-WG] Can a client send the Authorizatio… Aaron Parecki
- Re: [OAUTH-WG] Can a client send the Authorizatio… Sascha Preibisch
- Re: [OAUTH-WG] Can a client send the Authorizatio… A. Rothman
- Re: [OAUTH-WG] Can a client send the Authorizatio… Sascha Preibisch
- Re: [OAUTH-WG] Can a client send the Authorizatio… A. Rothman
- Re: [OAUTH-WG] Can a client send the Authorizatio… Justin Richer
- Re: [OAUTH-WG] Can a client send the Authorizatio… A. Rothman