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 <amich...@amichais.net
<mailto: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
