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

Brian Campbell <bcampbell@pingidentity.com> Mon, 18 July 2022 16:25 UTC

Return-Path: <bcampbell@pingidentity.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61016C13C522 for <oauth@ietfa.amsl.com>; Mon, 18 Jul 2022 09:25:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pingidentity.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qMrrVcgTBzQQ for <oauth@ietfa.amsl.com>; Mon, 18 Jul 2022 09:25:53 -0700 (PDT)
Received: from mail-yw1-x112d.google.com (mail-yw1-x112d.google.com [IPv6:2607:f8b0:4864:20::112d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74E25C13C528 for <oauth@ietf.org>; Mon, 18 Jul 2022 09:25:53 -0700 (PDT)
Received: by mail-yw1-x112d.google.com with SMTP id 00721157ae682-31caffa4a45so113161957b3.3 for <oauth@ietf.org>; Mon, 18 Jul 2022 09:25:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1hRqeukbXXMCk/E6bm0BRvfzkBVJJTkl3ZGnnren6oo=; b=ID0zGK3dkXObbqSm14Ij6thEfizqb2aBztRMXOJzOBX3ZofIpQ3P8S/d2d+Ed2j8Aa wm4Z59q0nMYzisBPyftn+7LRUIL36DqAKpmPuKbi1Xxh7s+JLc346chOfrkhcLusqFvm 13KuXckZi30D1wz9jx+991IqfvLhwLu5gxp7WYMbjzUXCi6eAt0yyBv2xmkSCJjNVJUh b+PUCyLPm59Dse/KWrVRbvMwc3XGNWML3401qmvDpwfKkWVMuz+Kd1nQn78NL/nxL58u ynVjwJll6hVd4/XHNL4zSiQlM+ShvfiSKe77XpJcHbzBk2sEfrfRGb/UbbHpNOlHmexJ RyQQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1hRqeukbXXMCk/E6bm0BRvfzkBVJJTkl3ZGnnren6oo=; b=V0ix6ZzRnKRM1c33RtT9SPvNSPYWDqYQ3RP+HeQLUq+BtQOb3mQT65jaGx+Hrc7FCI Pt9JwKXn2rbZJmN1M7WvCJAgBsB+LoMtLFOn+UbDTmMUEMyEInhYv+HTTAvgVtlR9NNE x+aS1MgsM1HqJJUgb1JWjC/IL9zeHvgO0LtpJimo/tj/rqMszekBo8mkT/ywJJC7McCL QFpgqtlSFEs72OX7nTi8suqzreedx94jOamTWuEoIOvPZsFHfzSlkf6NWUsEW4qXcrnH lNOazySoahXUkwv8IZirFZ++K887MXIs+XxCKRzRmjPSRQailVShx5DvcrmkR1kBLHnX z26g==
X-Gm-Message-State: AJIora80NIruiu1nrj07bjxe+fDUqh2xonvxkD2+9lwY86ccVCePPpD8 Wwi4tYnE3f5GA9EFrF3M8PO/rLVg/Ia/Ea96cVmoi9gGRHHBsA988vLG6ftg946bzN5DF6rvQ/X c8WeibQaVth+4mw==
X-Google-Smtp-Source: AGRyM1u9GP7zimJZwFna+TT1Get/z0rXzdRIgJS7x2CqaVm92Q7ME28VUgWGhOlZXHTgEJfVJMWIzXjGCNYJUaKOw+E=
X-Received: by 2002:a81:990:0:b0:31c:f77a:22dd with SMTP id 138-20020a810990000000b0031cf77a22ddmr30577476ywj.361.1658161552148; Mon, 18 Jul 2022 09:25:52 -0700 (PDT)
MIME-Version: 1.0
References: <20211015193847.E6C9E20EBD5@rfc-editor.org>
In-Reply-To: <20211015193847.E6C9E20EBD5@rfc-editor.org>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Mon, 18 Jul 2022 10:25:17 -0600
Message-ID: <CA+k3eCTmZHQ9yrokOQLd98t9JWvQB39Qf1Xz2rq=Dm8=JZ_nBw@mail.gmail.com>
To: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: torsten@lodderstedt.net, nat@sakimura.org, dave@tonge.org, panva.ip@gmail.com, rdd@cert.org, kaduk@mit.edu, Hannes.Tschofenig@gmx.net, rifaat.s.ietf@gmail.com, oauth@ietf.org
Content-Type: multipart/alternative; boundary="0000000000004be84c05e416d289"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/kCIdU2LmYUv234xJT-srBfGmYsE>
Subject: Re: [OAUTH-WG] [Technical Errata Reported] RFC9126 (6711)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Jul 2022 16:25:57 -0000

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-editor@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
>
> --------------------------------------
> Type: Technical
> Reported by: Brian Campbell <bcampbell@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._