Found 3 records.

Status: Reported (3)

RFC 9126, "OAuth 2.0 Pushed Authorization Requests", September 2021

Errata ID: 6711
Status: Reported
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Brian Campbell
Date Reported: 2021-10-15

Section 3. says:

   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.

It should say:

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

Errata ID: 7254
Status: Reported
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Joseph Heenan
Date Reported: 2022-11-18

Section 1.1 says:

POST /as/par HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded

&response_type=code
&client_id=CLIENT1234&state=duk681S8n00GsJpe7n9boxdzen
<...>

It should say:

POST /as/par HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded

response_type=code
&client_id=CLIENT1234&state=duk681S8n00GsJpe7n9boxdzen
<...>

Notes:

In the 'Introductory Example', the POST body to the par endpoint contains an unnecessary '&' at the start. (It's perhaps technically valid, but could potentially confuse readers.)

Errata ID: 7410
Status: Reported
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Andrii Deinega
Date Reported: 2023-03-31

Section 1.1 says:

Uses "urn:example:bwc4JK-ESC0w8acc191e-Y1LTC2" in two examples.

It should say:

Use "urn:ietf:params:oauth:request_uri:bwc4JK-ESC0w8acc191e-Y1LTC2"
instead.

Notes:

Some may find the use of "urn:example:" a bit misleading.

Report New Errata