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 <tors...@lodderstedt.net> 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 <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
