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

[Filip Skokan <[e-mail]>]

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 <[e-mail]>
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 <[e-mail]
> >:
>
> + Roman and Paul
>
> On Mon, Jul 18, 2022 at 12:25 PM Brian Campbell <
> [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]> 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 <[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.*
>
>
>