Re: [OAUTH-WG] [Technical Errata Reported] RFC9126 (6711)

[Torsten Lodderstedt]

> Am 19.07.2022 um 18:23 schrieb Brian Campbell :
> 
> The correction is attempting to remove some potential ambiguity that has been 
> interpreted as JAR's requirement for "client_id" not being applicable in the 
> context JAR over PAR. 

I unterstand.If it has caused confusion already, we should change the text.  

>  
> Maybe it should have been an editorial errata rather than technical.
> 
> On Tue, Jul 19, 2022 at 7:44 AM Torsten Lodderstedt  > wrote:
> I’m not sure this requires an update. It basically says „stick the uri you 
> get from step 1 into this parameter in step 2“. Does this really require use 
> to re-state any further requirements of a proper JAR?
> 
>> Am 19.07.2022 um 15:15 schrieb Rifaat Shekh-Yusef > >:
>> 
>> + Roman and Paul
>> 
>> On Mon, Jul 18, 2022 at 12:25 PM Brian Campbell > > wrote:
>> I believe this should be verified. I'm also the one that reported it though. 
>> But it's been sitting in reported status for a while now. 
>> 
>> On Fri, Oct 15, 2021 at 1:38 PM RFC Errata System > > wrote:
>> The following errata report has been submitted for RFC9126,
>> "OAuth 2.0 Pushed Authorization Requests".
>> 
>> --
>> You may review the report below and at:
>> https://www.rfc-editor.org/errata/eid6711 
>> 
>> 
>> --
>> Type: Technical
>> Reported by: Brian Campbell > >
>> 
>> Section: 3.
>> 
>> Original Text
>> -
>>Clients MAY use the "request" parameter as defined in JAR [RFC9101]
>>to push a Request Object JWT to the authorization server.  The rules
>>for processing, signing, and encryption of the Request Object as
>>defined in JAR [RFC9101] apply.  Request parameters required by a
>>given client authentication method are included in the "application/
>>x-www-form-urlencoded" request directly and are the only parameters
>>other than "request" in the form body (e.g., mutual TLS client
>>authentication [RFC8705] uses the "client_id" HTTP request parameter,
>>while JWT assertion-based client authentication [RFC7523] uses
>>"client_assertion" and "client_assertion_type").  All other request
>>parameters, i.e., those pertaining to the authorization request
>>itself, MUST appear as claims of the JWT representing the
>>authorization request.
>> 
>> Corrected Text
>> --
>>   Clients MAY use the request and client_id parameters as defined in 
>>   JAR [RFC9101] to push a Request Object JWT to the authorization 
>>   server. The rules for processing, signing, and encryption of the 
>>   Request Object as defined in JAR [RFC9101] apply. Request parameters
>>   required by a given client authentication method are included in the
>>   application/x-www-form-urlencoded request directly and are the only 
>>   parameters other than request and client_id in the form body (e.g.,
>>   JWT assertion-based client authentication [RFC7523] uses 
>>   "client_assertion" and "client_assertion_type") HTTP request
>>   parameters). All authorization request parameters, i.e., those 
>>   pertaining to the authorization request itself, MUST appear as
>>   claims of the JWT representing the authorization request.
>> 
>> Notes
>> -
>> That first paragraph of Sec 3 was not properly updated to come inline with 
>> JAR (now RFC9101) when it changed in draft -21 to require "client_id" in the 
>> authorization request in addition to in addition to "request" or 
>> "request_uri" - so is  somewhat ambiguous in maybe suggesting that 
>> "client_id" isn't required. But it is required based on how PAR works and 
>> RFC9101 requiring "client_id".
>> 
>> Instructions:
>> -
>> This erratum is currently posted as "Reported". If necessary, please
>> use "Reply All" to discuss whether it should be verified or
>> rejected. When a decision is reached, the verifying party  
>> can log in to change the status and edit the report, if necessary. 
>> 
>> --
>> RFC9126 (draft-ietf-oauth-par-10)
>> --
>> Title   : OAuth 2.0 Pushed Authorization Requests
>> Publication Date: September 2021
>> Author(s)   : T. Lodderstedt, B. Campbell, N. Sakimura, D. Tonge, F. 
>> Skokan
>> Category: PROPOSED STANDARD
>> Source  : Web Authorization Protocol
>> Area: Security
>> Stream  : IETF
>> Verifying Party : IESG
>> 
>> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
>> material for the sole use of the intended recipient(s). Any review, use, 
>> distribution or disclosure by others is strictly prohibited.  If you have 
>> received this communication in error, please notify the sender immediately 
>> by 

Re: [OAUTH-WG] [Technical Errata Reported] RFC9126 (6711)

[Brian Campbell]

The correction is attempting to remove some potential ambiguity that has
been interpreted as JAR's requirement for "client_id" not being applicable
in the context JAR over PAR.

Maybe it should have been an editorial errata rather than technical.

On Tue, Jul 19, 2022 at 7:44 AM Torsten Lodderstedt 
wrote:

> I’m not sure this requires an update. It basically says „stick the uri you
> get from step 1 into this parameter in step 2“. Does this really require
> use to re-state any further requirements of a proper JAR?
>
> Am 19.07.2022 um 15:15 schrieb Rifaat Shekh-Yusef  >:
>
> + Roman and Paul
>
> On Mon, Jul 18, 2022 at 12:25 PM Brian Campbell <
> bcampb...@pingidentity.com> wrote:
>
>> I believe this should be verified. I'm also the one that reported it
>> though. But it's been sitting in reported status for a while now.
>>
>> On Fri, Oct 15, 2021 at 1:38 PM RFC Errata System <
>> rfc-edi...@rfc-editor.org> wrote:
>>
>>> The following errata report has been submitted for RFC9126,
>>> "OAuth 2.0 Pushed Authorization Requests".
>>>
>>> --
>>> You may review the report below and at:
>>> https://www.rfc-editor.org/errata/eid6711
>>>
>>> --
>>> Type: Technical
>>> Reported by: Brian Campbell 
>>>
>>> Section: 3.
>>>
>>> Original Text
>>> -
>>>Clients MAY use the "request" parameter as defined in JAR [RFC9101]
>>>to push a Request Object JWT to the authorization server.  The rules
>>>for processing, signing, and encryption of the Request Object as
>>>defined in JAR [RFC9101] apply.  Request parameters required by a
>>>given client authentication method are included in the "application/
>>>x-www-form-urlencoded" request directly and are the only parameters
>>>other than "request" in the form body (e.g., mutual TLS client
>>>authentication [RFC8705] uses the "client_id" HTTP request parameter,
>>>while JWT assertion-based client authentication [RFC7523] uses
>>>"client_assertion" and "client_assertion_type").  All other request
>>>parameters, i.e., those pertaining to the authorization request
>>>itself, MUST appear as claims of the JWT representing the
>>>authorization request.
>>>
>>> Corrected Text
>>> --
>>>   Clients MAY use the request and client_id parameters as defined in
>>>   JAR [RFC9101] to push a Request Object JWT to the authorization
>>>   server. The rules for processing, signing, and encryption of the
>>>   Request Object as defined in JAR [RFC9101] apply. Request parameters
>>>   required by a given client authentication method are included in the
>>>   application/x-www-form-urlencoded request directly and are the only
>>>   parameters other than request and client_id in the form body (e.g.,
>>>   JWT assertion-based client authentication [RFC7523] uses
>>>   "client_assertion" and "client_assertion_type") HTTP request
>>>   parameters). All authorization request parameters, i.e., those
>>>   pertaining to the authorization request itself, MUST appear as
>>>   claims of the JWT representing the authorization request.
>>>
>>> Notes
>>> -
>>> That first paragraph of Sec 3 was not properly updated to come inline
>>> with JAR (now RFC9101) when it changed in draft -21 to require "client_id"
>>> in the authorization request in addition to in addition to "request" or
>>> "request_uri" - so is  somewhat ambiguous in maybe suggesting that
>>> "client_id" isn't required. But it is required based on how PAR works and
>>> RFC9101 requiring "client_id".
>>>
>>> Instructions:
>>> -
>>> This erratum is currently posted as "Reported". If necessary, please
>>> use "Reply All" to discuss whether it should be verified or
>>> rejected. When a decision is reached, the verifying party
>>> can log in to change the status and edit the report, if necessary.
>>>
>>> --
>>> RFC9126 (draft-ietf-oauth-par-10)
>>> --
>>> Title   : OAuth 2.0 Pushed Authorization Requests
>>> Publication Date: September 2021
>>> Author(s)   : T. Lodderstedt, B. Campbell, N. Sakimura, D.
>>> Tonge, F. Skokan
>>> Category: PROPOSED STANDARD
>>> Source  : Web Authorization Protocol
>>> Area: Security
>>> Stream  : IETF
>>> Verifying Party : IESG
>>>
>>
>> *CONFIDENTIALITY NOTICE: This email may contain confidential and
>> privileged material for the sole use of the intended recipient(s). Any
>> review, use, distribution or disclosure by others is strictly prohibited.
>> If you have received this communication in error, please notify the sender
>> immediately by e-mail and delete the message and any file attachments from
>> your computer. Thank you.*
>
>
>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure

Re: [OAUTH-WG] [Technical Errata Reported] RFC9126 (6711)

[Brian Campbell]

Thanks Filip, and yes I agree that request and client_id parameter names should
be quoted in the corrected text. As should
"application/x-www-form-urlencoded". Corrected corrected text is below. I
believe someone with more authority would need to edit the errata while
verifying.


Corrected Text
--
  Clients MAY use the "request" and "client_id" parameters as defined in
  JAR [RFC9101] to push a Request Object JWT to the authorization
  server. The rules for processing, signing, and encryption of the
  Request Object as defined in JAR [RFC9101] apply. Request parameters
  required by a given client authentication method are included in the
  "application/x-www-form-urlencoded" request directly and are the only
  parameters other than request and client_id in the form body (e.g.,
  JWT assertion-based client authentication [RFC7523] uses
  "client_assertion" and "client_assertion_type") HTTP request
  parameters). All authorization request parameters, i.e., those
  pertaining to the authorization request itself, MUST appear as
  claims of the JWT representing the authorization request.


On Tue, Jul 19, 2022 at 7:52 AM Filip Skokan  wrote:

> I too believe the Errata should be verified. (Although I think the
> parameter names request and client_id should be in quotes in the
> corrected text?).
>
> S pozdravem,
> *Filip Skokan*
>
>
> On Tue, 19 Jul 2022 at 15:44, Torsten Lodderstedt 
> wrote:
>
>> I’m not sure this requires an update. It basically says „stick the uri
>> you get from step 1 into this parameter in step 2“. Does this really
>> require use to re-state any further requirements of a proper JAR?
>>
>> Am 19.07.2022 um 15:15 schrieb Rifaat Shekh-Yusef <
>> rifaat.s.i...@gmail.com>:
>>
>> + Roman and Paul
>>
>> On Mon, Jul 18, 2022 at 12:25 PM Brian Campbell <
>> bcampb...@pingidentity.com> wrote:
>>
>>> I believe this should be verified. I'm also the one that reported it
>>> though. But it's been sitting in reported status for a while now.
>>>
>>> On Fri, Oct 15, 2021 at 1:38 PM RFC Errata System <
>>> rfc-edi...@rfc-editor.org> wrote:
>>>
 The following errata report has been submitted for RFC9126,
 "OAuth 2.0 Pushed Authorization Requests".

 --
 You may review the report below and at:
 https://www.rfc-editor.org/errata/eid6711

 --
 Type: Technical
 Reported by: Brian Campbell 

 Section: 3.

 Original Text
 -
Clients MAY use the "request" parameter as defined in JAR [RFC9101]
to push a Request Object JWT to the authorization server.  The rules
for processing, signing, and encryption of the Request Object as
defined in JAR [RFC9101] apply.  Request parameters required by a
given client authentication method are included in the "application/
x-www-form-urlencoded" request directly and are the only parameters
other than "request" in the form body (e.g., mutual TLS client
authentication [RFC8705] uses the "client_id" HTTP request parameter,
while JWT assertion-based client authentication [RFC7523] uses
"client_assertion" and "client_assertion_type").  All other request
parameters, i.e., those pertaining to the authorization request
itself, MUST appear as claims of the JWT representing the
authorization request.

 Corrected Text
 --
   Clients MAY use the request and client_id parameters as defined in
   JAR [RFC9101] to push a Request Object JWT to the authorization
   server. The rules for processing, signing, and encryption of the
   Request Object as defined in JAR [RFC9101] apply. Request parameters
   required by a given client authentication method are included in the
   application/x-www-form-urlencoded request directly and are the only
   parameters other than request and client_id in the form body (e.g.,
   JWT assertion-based client authentication [RFC7523] uses
   "client_assertion" and "client_assertion_type") HTTP request
   parameters). All authorization request parameters, i.e., those
   pertaining to the authorization request itself, MUST appear as
   claims of the JWT representing the authorization request.

 Notes
 -
 That first paragraph of Sec 3 was not properly updated to come inline
 with JAR (now RFC9101) when it changed in draft -21 to require "client_id"
 in the authorization request in addition to in addition to "request" or
 "request_uri" - so is  somewhat ambiguous in maybe suggesting that
 "client_id" isn't required. But it is required based on how PAR works and
 RFC9101 requiring "client_id".

 Instructions:
 -
 This erratum is currently posted as "Reported". If necessary, please
 use "Reply All" to discuss whether it should be verified or
 rejected. When a decision is 

Re: [OAUTH-WG] [Technical Errata Reported] RFC9126 (6711)

[Filip Skokan]

I too believe the Errata should be verified. (Although I think the
parameter names request and client_id should be in quotes in the corrected
text?).

S pozdravem,
*Filip Skokan*


On Tue, 19 Jul 2022 at 15:44, Torsten Lodderstedt 
wrote:

> I’m not sure this requires an update. It basically says „stick the uri you
> get from step 1 into this parameter in step 2“. Does this really require
> use to re-state any further requirements of a proper JAR?
>
> Am 19.07.2022 um 15:15 schrieb Rifaat Shekh-Yusef  >:
>
> + Roman and Paul
>
> On Mon, Jul 18, 2022 at 12:25 PM Brian Campbell <
> bcampb...@pingidentity.com> wrote:
>
>> I believe this should be verified. I'm also the one that reported it
>> though. But it's been sitting in reported status for a while now.
>>
>> On Fri, Oct 15, 2021 at 1:38 PM RFC Errata System <
>> rfc-edi...@rfc-editor.org> wrote:
>>
>>> The following errata report has been submitted for RFC9126,
>>> "OAuth 2.0 Pushed Authorization Requests".
>>>
>>> --
>>> You may review the report below and at:
>>> https://www.rfc-editor.org/errata/eid6711
>>>
>>> --
>>> Type: Technical
>>> Reported by: Brian Campbell 
>>>
>>> Section: 3.
>>>
>>> Original Text
>>> -
>>>Clients MAY use the "request" parameter as defined in JAR [RFC9101]
>>>to push a Request Object JWT to the authorization server.  The rules
>>>for processing, signing, and encryption of the Request Object as
>>>defined in JAR [RFC9101] apply.  Request parameters required by a
>>>given client authentication method are included in the "application/
>>>x-www-form-urlencoded" request directly and are the only parameters
>>>other than "request" in the form body (e.g., mutual TLS client
>>>authentication [RFC8705] uses the "client_id" HTTP request parameter,
>>>while JWT assertion-based client authentication [RFC7523] uses
>>>"client_assertion" and "client_assertion_type").  All other request
>>>parameters, i.e., those pertaining to the authorization request
>>>itself, MUST appear as claims of the JWT representing the
>>>authorization request.
>>>
>>> Corrected Text
>>> --
>>>   Clients MAY use the request and client_id parameters as defined in
>>>   JAR [RFC9101] to push a Request Object JWT to the authorization
>>>   server. The rules for processing, signing, and encryption of the
>>>   Request Object as defined in JAR [RFC9101] apply. Request parameters
>>>   required by a given client authentication method are included in the
>>>   application/x-www-form-urlencoded request directly and are the only
>>>   parameters other than request and client_id in the form body (e.g.,
>>>   JWT assertion-based client authentication [RFC7523] uses
>>>   "client_assertion" and "client_assertion_type") HTTP request
>>>   parameters). All authorization request parameters, i.e., those
>>>   pertaining to the authorization request itself, MUST appear as
>>>   claims of the JWT representing the authorization request.
>>>
>>> Notes
>>> -
>>> That first paragraph of Sec 3 was not properly updated to come inline
>>> with JAR (now RFC9101) when it changed in draft -21 to require "client_id"
>>> in the authorization request in addition to in addition to "request" or
>>> "request_uri" - so is  somewhat ambiguous in maybe suggesting that
>>> "client_id" isn't required. But it is required based on how PAR works and
>>> RFC9101 requiring "client_id".
>>>
>>> Instructions:
>>> -
>>> This erratum is currently posted as "Reported". If necessary, please
>>> use "Reply All" to discuss whether it should be verified or
>>> rejected. When a decision is reached, the verifying party
>>> can log in to change the status and edit the report, if necessary.
>>>
>>> --
>>> RFC9126 (draft-ietf-oauth-par-10)
>>> --
>>> Title   : OAuth 2.0 Pushed Authorization Requests
>>> Publication Date: September 2021
>>> Author(s)   : T. Lodderstedt, B. Campbell, N. Sakimura, D.
>>> Tonge, F. Skokan
>>> Category: PROPOSED STANDARD
>>> Source  : Web Authorization Protocol
>>> Area: Security
>>> Stream  : IETF
>>> Verifying Party : IESG
>>>
>>
>> *CONFIDENTIALITY NOTICE: This email may contain confidential and
>> privileged material for the sole use of the intended recipient(s). Any
>> review, use, distribution or disclosure by others is strictly prohibited.
>> If you have received this communication in error, please notify the sender
>> immediately by e-mail and delete the message and any file attachments from
>> your computer. Thank you.*
>
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] [Technical Errata Reported] RFC9126 (6711)

[Torsten Lodderstedt]

I’m not sure this requires an update. It basically says „stick the uri you get 
from step 1 into this parameter in step 2“. Does this really require use to 
re-state any further requirements of a proper JAR?

> Am 19.07.2022 um 15:15 schrieb Rifaat Shekh-Yusef :
> 
> + Roman and Paul
> 
> On Mon, Jul 18, 2022 at 12:25 PM Brian Campbell  > wrote:
> I believe this should be verified. I'm also the one that reported it though. 
> But it's been sitting in reported status for a while now. 
> 
> On Fri, Oct 15, 2021 at 1:38 PM RFC Errata System  > wrote:
> The following errata report has been submitted for RFC9126,
> "OAuth 2.0 Pushed Authorization Requests".
> 
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid6711 
> 
> 
> --
> Type: Technical
> Reported by: Brian Campbell  >
> 
> Section: 3.
> 
> Original Text
> -
>Clients MAY use the "request" parameter as defined in JAR [RFC9101]
>to push a Request Object JWT to the authorization server.  The rules
>for processing, signing, and encryption of the Request Object as
>defined in JAR [RFC9101] apply.  Request parameters required by a
>given client authentication method are included in the "application/
>x-www-form-urlencoded" request directly and are the only parameters
>other than "request" in the form body (e.g., mutual TLS client
>authentication [RFC8705] uses the "client_id" HTTP request parameter,
>while JWT assertion-based client authentication [RFC7523] uses
>"client_assertion" and "client_assertion_type").  All other request
>parameters, i.e., those pertaining to the authorization request
>itself, MUST appear as claims of the JWT representing the
>authorization request.
> 
> Corrected Text
> --
>   Clients MAY use the request and client_id parameters as defined in 
>   JAR [RFC9101] to push a Request Object JWT to the authorization 
>   server. The rules for processing, signing, and encryption of the 
>   Request Object as defined in JAR [RFC9101] apply. Request parameters
>   required by a given client authentication method are included in the
>   application/x-www-form-urlencoded request directly and are the only 
>   parameters other than request and client_id in the form body (e.g.,
>   JWT assertion-based client authentication [RFC7523] uses 
>   "client_assertion" and "client_assertion_type") HTTP request
>   parameters). All authorization request parameters, i.e., those 
>   pertaining to the authorization request itself, MUST appear as
>   claims of the JWT representing the authorization request.
> 
> Notes
> -
> That first paragraph of Sec 3 was not properly updated to come inline with 
> JAR (now RFC9101) when it changed in draft -21 to require "client_id" in the 
> authorization request in addition to in addition to "request" or 
> "request_uri" - so is  somewhat ambiguous in maybe suggesting that 
> "client_id" isn't required. But it is required based on how PAR works and 
> RFC9101 requiring "client_id".
> 
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party  
> can log in to change the status and edit the report, if necessary. 
> 
> --
> RFC9126 (draft-ietf-oauth-par-10)
> --
> Title   : OAuth 2.0 Pushed Authorization Requests
> Publication Date: September 2021
> Author(s)   : T. Lodderstedt, B. Campbell, N. Sakimura, D. Tonge, F. 
> Skokan
> Category: PROPOSED STANDARD
> Source  : Web Authorization Protocol
> Area: Security
> Stream  : IETF
> Verifying Party : IESG
> 
> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
> material for the sole use of the intended recipient(s). Any review, use, 
> distribution or disclosure by others is strictly prohibited.  If you have 
> received this communication in error, please notify the sender immediately by 
> e-mail and delete the message and any file attachments from your computer. 
> Thank you.

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

Re: [OAUTH-WG] [Technical Errata Reported] RFC9126 (6711)

[Rifaat Shekh-Yusef]

+ Roman and Paul

On Mon, Jul 18, 2022 at 12:25 PM Brian Campbell 
wrote:

> I believe this should be verified. I'm also the one that reported it
> though. But it's been sitting in reported status for a while now.
>
> On Fri, Oct 15, 2021 at 1:38 PM RFC Errata System <
> rfc-edi...@rfc-editor.org> wrote:
>
>> The following errata report has been submitted for RFC9126,
>> "OAuth 2.0 Pushed Authorization Requests".
>>
>> --
>> You may review the report below and at:
>> https://www.rfc-editor.org/errata/eid6711
>>
>> --
>> Type: Technical
>> Reported by: Brian Campbell 
>>
>> Section: 3.
>>
>> Original Text
>> -
>>Clients MAY use the "request" parameter as defined in JAR [RFC9101]
>>to push a Request Object JWT to the authorization server.  The rules
>>for processing, signing, and encryption of the Request Object as
>>defined in JAR [RFC9101] apply.  Request parameters required by a
>>given client authentication method are included in the "application/
>>x-www-form-urlencoded" request directly and are the only parameters
>>other than "request" in the form body (e.g., mutual TLS client
>>authentication [RFC8705] uses the "client_id" HTTP request parameter,
>>while JWT assertion-based client authentication [RFC7523] uses
>>"client_assertion" and "client_assertion_type").  All other request
>>parameters, i.e., those pertaining to the authorization request
>>itself, MUST appear as claims of the JWT representing the
>>authorization request.
>>
>> Corrected Text
>> --
>>   Clients MAY use the request and client_id parameters as defined in
>>   JAR [RFC9101] to push a Request Object JWT to the authorization
>>   server. The rules for processing, signing, and encryption of the
>>   Request Object as defined in JAR [RFC9101] apply. Request parameters
>>   required by a given client authentication method are included in the
>>   application/x-www-form-urlencoded request directly and are the only
>>   parameters other than request and client_id in the form body (e.g.,
>>   JWT assertion-based client authentication [RFC7523] uses
>>   "client_assertion" and "client_assertion_type") HTTP request
>>   parameters). All authorization request parameters, i.e., those
>>   pertaining to the authorization request itself, MUST appear as
>>   claims of the JWT representing the authorization request.
>>
>> Notes
>> -
>> That first paragraph of Sec 3 was not properly updated to come inline
>> with JAR (now RFC9101) when it changed in draft -21 to require "client_id"
>> in the authorization request in addition to in addition to "request" or
>> "request_uri" - so is  somewhat ambiguous in maybe suggesting that
>> "client_id" isn't required. But it is required based on how PAR works and
>> RFC9101 requiring "client_id".
>>
>> Instructions:
>> -
>> This erratum is currently posted as "Reported". If necessary, please
>> use "Reply All" to discuss whether it should be verified or
>> rejected. When a decision is reached, the verifying party
>> can log in to change the status and edit the report, if necessary.
>>
>> --
>> RFC9126 (draft-ietf-oauth-par-10)
>> --
>> Title   : OAuth 2.0 Pushed Authorization Requests
>> Publication Date: September 2021
>> Author(s)   : T. Lodderstedt, B. Campbell, N. Sakimura, D. Tonge,
>> F. Skokan
>> Category: PROPOSED STANDARD
>> Source  : Web Authorization Protocol
>> Area: Security
>> Stream  : IETF
>> Verifying Party : IESG
>>
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth