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 <amich...@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 <jric...@mit.edu >> <mailto:jric...@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 [amich...@amichais.net <mailto:amich...@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 mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
