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

[Brian Campbell <[e-mail]>]

Thanks Filip, and yes I agree that request and client_id parameter names should
be quoted in the corrected text. As should
"application/x-www-form-urlencoded". Corrected corrected text is below. I
believe someone with more authority would need to edit the errata while
verifying.


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.


On Tue, Jul 19, 2022 at 7:52 AM Filip Skokan <[e-mail]> wrote:

> 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.*
>>
>>
>>

-- 
_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._