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

[Torsten Lodderstedt <[e-mail]>]

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 <[e-mail]>:
> 
> + Roman and Paul
> 
> On Mon, Jul 18, 2022 at 12:25 PM Brian Campbell <[e-mail] <mailto:[e-mail]>> 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 <[e-mail] <mailto:[e-mail]>> 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 <https://www.rfc-editor.org/errata/eid6711>
> 
> --------------------------------------
> Type: Technical
> Reported by: Brian Campbell <[e-mail] <mailto:[e-mail]>>
> 
> 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.