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 <bcampb...@pingidentity.com> > > 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
