Re: [OAUTH-WG] third party applications

[Torsten Lodderstedt]

I agree. OAuth works for 3rd as well as 1st parties as well. 

> On 28. Aug 2020, at 05:26, Dima Postnikov  wrote:
> 
> Hi,
> 
> Can "third-party" term be removed from the specification?
> 
> The standard and associated best practices apply to other applications that 
> act on behalf of a resource owner, too (internal, "first-party" and etc).
> 
> Regards,
> 
> Dima
> 
> The OAuth 2.1 authorization framework enables a third-party
> 
>application to obtain limited access to an HTTP service, either on
>behalf of a resource owner by orchestrating an approval interaction
>between the resource owner and the HTTP service, or by allowing the
>third-party application to obtain access on its own behalf.  This
>specification replaces and obsoletes the OAuth 2.0 Authorization
>Framework described in 
> RFC 6749.
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] WGLC review of PAR

[Neil Madden]

Thanks for the response Brian, I agree with your comments. I’ve been scratching 
my head for a non-OIDC example for the URI swapping issue, but can’t think of 
one that isn’t very contrived at the moment.

— Neil

> On 26 Aug 2020, at 21:04, Brian Campbell  wrote:
> 
> Thanks Neil. Appreciate the review and feedback. My attempts at responses are 
> inline below. 
> 
> 
> On Thu, Aug 20, 2020 at 5:30 AM Neil Madden  > wrote:
> As promised in the last interim meeting, I’ve reviewed the current (03) 
> draft-ietf-oauth-par document. Overall it looks close to ready to me, with 
> mostly minor comments and one security-relevant comment on section 2.1 that 
> should be discussed further, and one additional proposed security 
> consideration:
> 
> Abstract:
> The wording here could be improved - “allows clients to push an authorization 
> request […] used as a reference to the data in a subsequent authorization 
> request.” Both the pushed data and the call to the authorization endpoint are 
> referred to as an “authorization request”. Maybe change the second usage to 
> “in a subsequent call to the authorization endpoint”.
> 
> Makes sense. 
>  
> 
> Section 1:
> The introductory part here is quite long. Maybe adding a new sub-heading 
> before the example would make it flow better.
> 
> Will look at breaking it up. 
>  
> 
> The end of the introduction uses the acronym “PAR” for the first time, but 
> never explicitly defines it.
> 
> Will fix. 
>  
> 
> I agree with Justin that ACR is not the best example to lead with. If it 
> stays there should be a reference to OIDC to explain what this means.
> 
> Yup. 
>  
> 
> The paragraph that begins “It also allows clients to push the form encoded …” 
> is confusing because the use of “also” suggests this is different from the 
> previous paragraph, but it seems to actually be saying the same thing?
> 
> Yeah, that is rather awkward because it is the same thing. Will fix. 
>  
> 
> “[…] but it also allows clients requiring
>an even higher security level, especially cryptographically confirmed
>non-repudiation, to explicitly adopt JWT-based request objects”
> 
> The “but” should be an “and” in this paragraph. It’s also not clear what is 
> being said here - isn’t JAR what provides JWT-based request objects? 
> 
> Yeah, JAR defines JWT-based request objects and PAR allows for their use by 
> sending the 'request' parameter to the PAR endpoint.  Will try and make that 
> more clear.
>  
> 
> The paragraph beginning “As a further benefit, …” is a little bit of a 
> Columbo moment (“Just one more thing…”) at the end of the introduction. Maybe 
> move this as another bullet point at the start of the section. The following 
> paragraph can then be rewritten as “The increased confidence in the identity 
> of the client during the authorization process allows confidential clients to 
> provide a different redirect_uri on every request. […]”
> 
>  Agree with the sentiment here and will endeavor to rework things along the 
> lines of the suggestion. 
> 
>  
> Section 2:
> The 3rd paragraph contains statements like 
> The endpoint also supports sending all authorization
>request parameters as request object according to
>[I-D.ietf-oauth-jwsreq 
> ].
> presumably this is not a normative requirement that any PAR implementation 
> has to also support JAR, or is it? Maybe change the wording to “MAY also 
> support …”.
> 
> Interesting question. PAR has a normative reference to JAR for the 
> request_uri parameter at the authz endpoint. But does that necessitate that 
> every PAR implementation also has to support all of JAR? I'm thinking 
> probably not. I mean, different but related, an AS PAR implementation might 
> legitimately support the request_uri parameter with URI values that it 
> creates but not support the more general retrieval of arbitrary URIs. In the 
> same vein, it seems legit and still useful to support PAR without also 
> supporting request object JWTs. So yeah, I think changing this to MAY or 
> something similar would be appropriate. 
>  
> 
> The first mention of “token_endpoint_auth_method” and client metadata should 
> have a reference to RFC 7591 - currently it’s only referenced later in 
> section 2.1.
> 
> Will fix. 
> 
> 2.1:
> I’m a little bit wary of the relaxing of the redirect_uri processing rules, 
> because this removes a layer of defence in depth. With the current 
> requirement for pre-registered URIs an attacker needs to compromise the 
> redirect endpoint *and* the client credentials in order to steal an 
> authorization code and use it. With this change, compromising the client 
> credentials alone would be enough. If the use-case is specifically in a PKI 
> environment, could the redirect_uri be baked into the cert? Maybe this 
> use-case could be better addressed in a separate draft.
> 
>  I agree that the specifics

Re: [OAUTH-WG] third party applications

[Dick Hardt]

The driver in my opinion for first-party use of OAuth is to separate the
trust domains so that the application is scoped in what it can do vs an
application that has full access to all resources. I agree that third-party
can indicate that internal use does not apply. How about the following?

   The OAuth 2.1 authorization framework enables an *independent*
   application to obtain limited access to an HTTP service, either on
   behalf of a resource owner by orchestrating an approval interaction
   between the resource owner and the HTTP service, or by allowing the
   application to obtain access on its own behalf.  This
   specification replaces and obsoletes the OAuth 2.0 Authorization
   Framework described in RFC 6749.
ᐧ

On Fri, Aug 28, 2020 at 3:02 AM Torsten Lodderstedt  wrote:

> I agree. OAuth works for 3rd as well as 1st parties as well.
>
> > On 28. Aug 2020, at 05:26, Dima Postnikov  wrote:
> >
> > Hi,
> >
> > Can "third-party" term be removed from the specification?
> >
> > The standard and associated best practices apply to other applications
> that act on behalf of a resource owner, too (internal, "first-party" and
> etc).
> >
> > Regards,
> >
> > Dima
> >
> > The OAuth 2.1 authorization framework enables a third-party
> >
> >application to obtain limited access to an HTTP service, either on
> >behalf of a resource owner by orchestrating an approval interaction
> >between the resource owner and the HTTP service, or by allowing the
> >third-party application to obtain access on its own behalf.  This
> >specification replaces and obsoletes the OAuth 2.0 Authorization
> >Framework described in
> > RFC 6749.
> > ___
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] third party applications

[Torsten Lodderstedt]

In my experience OAuth is used in 1st party scenarios as means to separate 
functions (e.g. central user management vs. different products) within the same 
trust domain thus enabling architectural flexibility. 

I would just remove any constraint on the kind of applications OAuth can be 
used for. I don’t see how this governs the protocol design.  

> On 28. Aug 2020, at 15:29, Dick Hardt  wrote:
> 
> The driver in my opinion for first-party use of OAuth is to separate the 
> trust domains so that the application is scoped in what it can do vs an 
> application that has full access to all resources. I agree that third-party 
> can indicate that internal use does not apply. How about the following?
> 
>The OAuth 2.1 authorization framework enables an independent
>application to obtain limited access to an HTTP service, either on
>behalf of a resource owner by orchestrating an approval interaction
>between the resource owner and the HTTP service, or by allowing the
>application to obtain access on its own behalf.  This
>specification replaces and obsoletes the OAuth 2.0 Authorization
>Framework described in RFC 6749.
> ᐧ
> 
> On Fri, Aug 28, 2020 at 3:02 AM Torsten Lodderstedt 
>  wrote:
> I agree. OAuth works for 3rd as well as 1st parties as well. 
> 
> > On 28. Aug 2020, at 05:26, Dima Postnikov  wrote:
> > 
> > Hi,
> > 
> > Can "third-party" term be removed from the specification?
> > 
> > The standard and associated best practices apply to other applications that 
> > act on behalf of a resource owner, too (internal, "first-party" and etc).
> > 
> > Regards,
> > 
> > Dima
> > 
> > The OAuth 2.1 authorization framework enables a third-party
> > 
> >application to obtain limited access to an HTTP service, either on
> >behalf of a resource owner by orchestrating an approval interaction
> >between the resource owner and the HTTP service, or by allowing the
> >third-party application to obtain access on its own behalf.  This
> >specification replaces and obsoletes the OAuth 2.0 Authorization
> >Framework described in 
> > RFC 6749.
> > ___
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] third party applications

[Dick Hardt]

Well, OAuth is not very useful in a monolithic application. No need for an
interoperable protocol for that kind of application.

And in separating functions, you are creating separate trust domains. Yes,
it is still all internal, but it enables a separation of concerns.
ᐧ

On Fri, Aug 28, 2020 at 7:49 AM Torsten Lodderstedt 
wrote:

> In my experience OAuth is used in 1st party scenarios as means to separate
> functions (e.g. central user management vs. different products) within the
> same trust domain thus enabling architectural flexibility.
>
> I would just remove any constraint on the kind of applications OAuth can
> be used for. I don’t see how this governs the protocol design.
>
> > On 28. Aug 2020, at 15:29, Dick Hardt  wrote:
> >
> > The driver in my opinion for first-party use of OAuth is to separate the
> trust domains so that the application is scoped in what it can do vs an
> application that has full access to all resources. I agree that third-party
> can indicate that internal use does not apply. How about the following?
> >
> >The OAuth 2.1 authorization framework enables an independent
> >application to obtain limited access to an HTTP service, either on
> >behalf of a resource owner by orchestrating an approval interaction
> >between the resource owner and the HTTP service, or by allowing the
> >application to obtain access on its own behalf.  This
> >specification replaces and obsoletes the OAuth 2.0 Authorization
> >Framework described in RFC 6749.
> > ᐧ
> >
> > On Fri, Aug 28, 2020 at 3:02 AM Torsten Lodderstedt  40lodderstedt@dmarc.ietf.org> wrote:
> > I agree. OAuth works for 3rd as well as 1st parties as well.
> >
> > > On 28. Aug 2020, at 05:26, Dima Postnikov  wrote:
> > >
> > > Hi,
> > >
> > > Can "third-party" term be removed from the specification?
> > >
> > > The standard and associated best practices apply to other applications
> that act on behalf of a resource owner, too (internal, "first-party" and
> etc).
> > >
> > > Regards,
> > >
> > > Dima
> > >
> > > The OAuth 2.1 authorization framework enables a third-party
> > >
> > >application to obtain limited access to an HTTP service, either on
> > >behalf of a resource owner by orchestrating an approval interaction
> > >between the resource owner and the HTTP service, or by allowing the
> > >third-party application to obtain access on its own behalf.  This
> > >specification replaces and obsoletes the OAuth 2.0 Authorization
> > >Framework described in
> > > RFC 6749.
> > > ___
> > > OAuth mailing list
> > > OAuth@ietf.org
> > > https://www.ietf.org/mailman/listinfo/oauth
> >
> > ___
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] third party applications

[Torsten Lodderstedt]

> On 28. Aug 2020, at 16:56, Dick Hardt  wrote:
> 
> Well, OAuth is not very useful in a monolithic application. No need for an 
> interoperable protocol for that kind of application.

I don’t know why we need to make any assumptions about the application that 
uses OAuth. A lot of assumptions might turn out to be wrong. So if me make 
assumptions they must be relevant for the protocol design. 

So again, why is “independent” or “third-party” relevant for the protocol 
design? 

> 
> And in separating functions, you are creating separate trust domains. Yes, it 
> is still all internal, but it enables a separation of concerns.
> ᐧ
> 
> On Fri, Aug 28, 2020 at 7:49 AM Torsten Lodderstedt  
> wrote:
> In my experience OAuth is used in 1st party scenarios as means to separate 
> functions (e.g. central user management vs. different products) within the 
> same trust domain thus enabling architectural flexibility. 
> 
> I would just remove any constraint on the kind of applications OAuth can be 
> used for. I don’t see how this governs the protocol design.  
> 
> > On 28. Aug 2020, at 15:29, Dick Hardt  wrote:
> > 
> > The driver in my opinion for first-party use of OAuth is to separate the 
> > trust domains so that the application is scoped in what it can do vs an 
> > application that has full access to all resources. I agree that third-party 
> > can indicate that internal use does not apply. How about the following?
> > 
> >The OAuth 2.1 authorization framework enables an independent
> >application to obtain limited access to an HTTP service, either on
> >behalf of a resource owner by orchestrating an approval interaction
> >between the resource owner and the HTTP service, or by allowing the
> >application to obtain access on its own behalf.  This
> >specification replaces and obsoletes the OAuth 2.0 Authorization
> >Framework described in RFC 6749.
> > ᐧ
> > 
> > On Fri, Aug 28, 2020 at 3:02 AM Torsten Lodderstedt 
> >  wrote:
> > I agree. OAuth works for 3rd as well as 1st parties as well. 
> > 
> > > On 28. Aug 2020, at 05:26, Dima Postnikov  wrote:
> > > 
> > > Hi,
> > > 
> > > Can "third-party" term be removed from the specification?
> > > 
> > > The standard and associated best practices apply to other applications 
> > > that act on behalf of a resource owner, too (internal, "first-party" and 
> > > etc).
> > > 
> > > Regards,
> > > 
> > > Dima
> > > 
> > > The OAuth 2.1 authorization framework enables a third-party
> > > 
> > >application to obtain limited access to an HTTP service, either on
> > >behalf of a resource owner by orchestrating an approval interaction
> > >between the resource owner and the HTTP service, or by allowing the
> > >third-party application to obtain access on its own behalf.  This
> > >specification replaces and obsoletes the OAuth 2.0 Authorization
> > >Framework described in 
> > > RFC 6749.
> > > ___
> > > OAuth mailing list
> > > OAuth@ietf.org
> > > https://www.ietf.org/mailman/listinfo/oauth
> > 
> > ___
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> 

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] third party applications

[Jim Manico]

It does not make sense to use OAuth in most single party situations. These 
single-party OAuth use cases are frequently a complete misuse of the framework. 
I +1 the language “3rd party” in an effort to steer implementors in the right 
direction.

--
Jim Manico
@Manicode


> On Aug 28, 2020, at 5:07 AM, Torsten Lodderstedt 
>  wrote:
> 
> 
>> On 28. Aug 2020, at 16:56, Dick Hardt  wrote:
>> 
>> Well, OAuth is not very useful in a monolithic application. No need for an 
>> interoperable protocol for that kind of application.
> 
> I don’t know why we need to make any assumptions about the application that 
> uses OAuth. A lot of assumptions might turn out to be wrong. So if me make 
> assumptions they must be relevant for the protocol design. 
> 
> So again, why is “independent” or “third-party” relevant for the protocol 
> design? 
> 
>> 
>> And in separating functions, you are creating separate trust domains. Yes, 
>> it is still all internal, but it enables a separation of concerns.
>> ᐧ
>> 
>> On Fri, Aug 28, 2020 at 7:49 AM Torsten Lodderstedt 
>>  wrote:
>> In my experience OAuth is used in 1st party scenarios as means to separate 
>> functions (e.g. central user management vs. different products) within the 
>> same trust domain thus enabling architectural flexibility. 
>> 
>> I would just remove any constraint on the kind of applications OAuth can be 
>> used for. I don’t see how this governs the protocol design.  
>> 
 On 28. Aug 2020, at 15:29, Dick Hardt  wrote:
>>> 
>>> The driver in my opinion for first-party use of OAuth is to separate the 
>>> trust domains so that the application is scoped in what it can do vs an 
>>> application that has full access to all resources. I agree that third-party 
>>> can indicate that internal use does not apply. How about the following?
>>> 
>>>   The OAuth 2.1 authorization framework enables an independent
>>>   application to obtain limited access to an HTTP service, either on
>>>   behalf of a resource owner by orchestrating an approval interaction
>>>   between the resource owner and the HTTP service, or by allowing the
>>>   application to obtain access on its own behalf.  This
>>>   specification replaces and obsoletes the OAuth 2.0 Authorization
>>>   Framework described in RFC 6749.
>>> ᐧ
>>> 
 On Fri, Aug 28, 2020 at 3:02 AM Torsten Lodderstedt 
  wrote:
>>> I agree. OAuth works for 3rd as well as 1st parties as well. 
>>> 
 On 28. Aug 2020, at 05:26, Dima Postnikov  wrote:
 
 Hi,
 
 Can "third-party" term be removed from the specification?
 
 The standard and associated best practices apply to other applications 
 that act on behalf of a resource owner, too (internal, "first-party" and 
 etc).
 
 Regards,
 
 Dima
 
 The OAuth 2.1 authorization framework enables a third-party
 
   application to obtain limited access to an HTTP service, either on
   behalf of a resource owner by orchestrating an approval interaction
   between the resource owner and the HTTP service, or by allowing the
   third-party application to obtain access on its own behalf.  This
   specification replaces and obsoletes the OAuth 2.0 Authorization
   Framework described in 
 RFC 6749.
 ___
 OAuth mailing list
 OAuth@ietf.org
 https://www.ietf.org/mailman/listinfo/oauth
>>> 
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>> 
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] third party applications

[Aaron Parecki]

I agree. While the original motivations for OAuth were to support
third-party apps, it's proven to be useful in many other kinds of
situations as well, even when it's a "first-party" app but the OAuth server
is operated by a different organization than the APIs. I don't think the
abstract needs any qualification on this and would only confuse people
further. Any clarifications of which situations are appropriate for using
OAuth could be explored in a different section in the spec.

Aaron Parecki

On Fri, Aug 28, 2020 at 3:02 AM Torsten Lodderstedt  wrote:

> I agree. OAuth works for 3rd as well as 1st parties as well.
>
> > On 28. Aug 2020, at 05:26, Dima Postnikov  wrote:
> >
> > Hi,
> >
> > Can "third-party" term be removed from the specification?
> >
> > The standard and associated best practices apply to other applications
> that act on behalf of a resource owner, too (internal, "first-party" and
> etc).
> >
> > Regards,
> >
> > Dima
> >
> > The OAuth 2.1 authorization framework enables a third-party
> >
> >application to obtain limited access to an HTTP service, either on
> >behalf of a resource owner by orchestrating an approval interaction
> >between the resource owner and the HTTP service, or by allowing the
> >third-party application to obtain access on its own behalf.  This
> >specification replaces and obsoletes the OAuth 2.0 Authorization
> >Framework described in
> > RFC 6749.
> > ___
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] WGLC Review of PAR

[Mike Jones]

I agree with Dick that it would be a mistake to make the URL one-time use.  
It’s unenforceable and unnecessarily gets in the way of valuable deployment 
patterns.

From: OAuth  On Behalf Of Dick Hardt
Sent: Thursday, August 27, 2020 9:12 AM
To: Justin Richer 
Cc: Brian Campbell ; oauth 

Subject: Re: [OAUTH-WG] WGLC Review of PAR

That is not correct.

The authorization code one-time-use is directly between the client and the AS. 
The client has a number of mechanisms to ensure it only presents the 
authorization code to the AS once, such as a session that was set when the user 
started at the client.

In contrast, in a redirect from the client to the AS, the client loses control 
on how many times the user-agent loads the URL at the AS. Additionally, there 
is unlikely to be an active browser session at the AS, so the AS can not easily 
differentiate between a URL load from the same user, or different users. If 
one-time-use, one of them MUST fail. If the two requests happen to be from the 
same user (because of a reload, which the user did because the AS was slow to 
respond), there is no way for the AS to know which of the requests is the one 
that is current in front of the user. While the AS can internally ensure 
processing of the request once, one-time-use would dictate that it provides a 
failure message to one of the requests.

/Dick


ᐧ

On Thu, Aug 27, 2020 at 7:17 AM Justin Richer 
mailto:jric...@mit.edu>> wrote:
We already have this same property with authorization codes, and it’s managed 
today reasonably well (in my opinion). If you submit the same request URI twice 
in the same browser (the refresh you’re talking about), it shouldn’t start two 
separate authorization requests, but it would be reasonable to detect that the 
same session attached to the same request URI value showed up twice and 
continue the session as appropriate.

None of this is in conflict with “one time use”, in my view, since you’re 
actively detecting the session and source of the value.

 — Justin


On Aug 26, 2020, at 6:16 PM, Dick Hardt 
mailto:dick.ha...@gmail.com>> wrote:

I think one-time use may be overly restrictive, and I don't think it is the 
property that we actually want.

Give the request URI is in a redirect from the browser, there is a good chance 
of a race condition where the same browser request is made more than once, for 
example, while the browser is loading the authorization URL at the AS, the user 
could refresh the page causing the authorization URL to be reloaded. Would the 
reload count as a second use? One could argue it either way.

What I think we want from what I understand, is the request URI MUST be unique 
so that there is no confusion on which request is being referenced.

I did not see anything about the expiry time of the request URI (but I did not 
look super hard). If that is not there, then I think the request URI MUST 
expire in a "short" period of time.



ᐧ

On Wed, Aug 26, 2020 at 1:45 PM Brian Campbell 
mailto:40pingidentity@dmarc.ietf.org>>
 wrote:
Thanks Justin. Just a couple more responses to responses inline below (but with 
lots of content that needs no further discussion removed).

A TL;DR for the WG is that I'd like to get some wider feedback on the question 
of changing the one-time-use condition on the request_uri from a SHOULD to a 
MUST.

On Tue, Aug 25, 2020 at 4:57 PM Justin Richer 
mailto:jric...@mit.edu>> wrote:
Hi Brian, just a couple responses inline where it seemed fitting. Thanks for 
going through everything!
 — Justin


On Aug 25, 2020, at 6:01 PM, Brian Campbell 
mailto:bcampb...@pingidentity.com>> wrote:

Thanks for the review and comments Justin. Replies (or attempts thereat) are 
inline below.


On Wed, Aug 19, 2020 at 2:06 PM Justin Richer 
mailto:jric...@mit.edu>> wrote:
I’ve done a full read through of the PAR specification, and here are my notes 
on it.


¶2: Of necessity, this spec mixes parameters in the authorization endpoint 
and token endpoint registries into a single request. Is there any danger of 
conflict between them? The registry holds them in one list but they could 
possibly have different semantics in both places..

I think that technically such danger does exist but that it's highly unlikely 
in practice. Especially because the only token endpoint parameters that are 
relevant to PAR are those that deal with client authentication (currently 
client_secret, client_assertion, and client_assertion_type). I'm also not sure 
what can reasonably be done about it given the way the registries are. I guess 
PAR could update the registration for those three (client_secret, 
client_assertion, and client_assertion_type) to also indicate authorization 
request as a usage location with some commentary that it's only for avoiding 
name collisions. And offer some guidance about doing the same for any future 
client auth methods being defined. But honestly I'm not sure what, if anything, 
to do here?

And yes it is super unfortunate that