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 <[email protected]>: > > + Roman and Paul > > On Mon, Jul 18, 2022 at 12:25 PM Brian Campbell <[email protected] > <mailto:[email protected]>> 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 <[email protected] > <mailto:[email protected]>> 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 <[email protected] > <mailto:[email protected]>> > > 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 [email protected] https://www.ietf.org/mailman/listinfo/oauth
