> Am 19.07.2022 um 18:23 schrieb Brian Campbell <bcampb...@pingidentity.com>: > > 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 <tors...@lodderstedt.net > <mailto: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 >> <mailto:rifaat.s.i...@gmail.com>>: >> >> + Roman and Paul >> >> On Mon, Jul 18, 2022 at 12:25 PM Brian Campbell <bcampb...@pingidentity.com >> <mailto: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 >> <mailto: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 >> <https://www.rfc-editor.org/errata/eid6711> >> >> -------------------------------------- >> Type: Technical >> Reported by: Brian Campbell <bcampb...@pingidentity.com >> <mailto: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. > > > 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
