Re: [OAUTH-WG] PAR: pushed requests must become JWTs

Brian Campbell <bcampbell@pingidentity.com> Fri, 10 January 2020 18:45 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 D888C120B09 for <oauth@ietfa.amsl.com>; Fri, 10 Jan 2020 10:45:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vXqk59IvTMRB for <oauth@ietfa.amsl.com>; Fri, 10 Jan 2020 10:45:38 -0800 (PST)
Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76F37120AE3 for <oauth@ietf.org>; Fri, 10 Jan 2020 10:45:37 -0800 (PST)
Received: by mail-lf1-x134.google.com with SMTP id y1so2228300lfb.6 for <oauth@ietf.org>; Fri, 10 Jan 2020 10:45:37 -0800 (PST)
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=b3Jivu8Lf4p5BG9y/MPULNjRwcb93oymoudr0xvKA4k=; b=LNfKCqABYGx0URc0D/ZTEJ861kKrghfA6z/y/iKPnLxnzR+raesifojLOtvFduN13C rOF531ds4GxhtCT2X6UXL4Jj/ivSIDHumB2tZUNa3yTb5sivMdmm4ISLP+Fmotq4WTZ1 RPdcY17uPjEuC+IKhNDhyBDPsua4ue9gvopKK2eeYBb/+8ivLNIB+OZqwKOxK+FlJqC2 ZlpUepkDR3nFBfADA0DjPsRorxA/azq87jOXhyHc72h5OoWpOEKdREmQhhyjBGKwSih9 Qt/ZSNKVDJxEqZs5p+TxXXq7LiY6Q7twERFp4uF9nTd3TdgP9SXOy2a5bl48AxvJrNp6 YwJQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=b3Jivu8Lf4p5BG9y/MPULNjRwcb93oymoudr0xvKA4k=; b=K92tEkjYS2+YBgTcZK45xwWSVNoxd2uzXZgi2ejWOsH+flcrBx/p0XgFF524b0kDze zebFCVtRUjpkl2d4KYtfaRYSJ8Vi31OMurx0fNoBRFD8c840I1mRK8Oy2A/B/7SzC9IU grwfjBXkITuBsxttIjrkbp1YAWImbaHWjQnFCtjXDmMQeGNdI6dtES0BQgg4IH7F0Fbl zi2QDG5yR0HlGxV45vkUChK41zQftxy0M0fmOab5TB8OrAB2V1dXBmOv+Y/fNOViiClX i9aA7hrJhjnhps0IFZIzc4SbhimYRceg6vnAQeW9XkemBjdswQ92jJ5TiPvC6r8oXe53 3aww==
X-Gm-Message-State: APjAAAVXza0hlswWyxoTmVcY/myGTsjo2RyDhnOPU5QNAcCaHmoupUzc feXAFfR/548cAuPeLwoiRm4Nvf2dUDQyh5TPPScnf44on5bBGpAfn6nvjZa5R+MUlAUHMSCwgHw drFCNYnj/Rho7DA==
X-Google-Smtp-Source: APXvYqwNyvXql7eY2IJA0PANy1HH+5cdh4ha41NKHtsasvGVkZoJgDJ5wZyHmm1f1v4SyxV1LsUbXXRapksTqcsj2+s=
X-Received: by 2002:ac2:4d04:: with SMTP id r4mr3264236lfi.77.1578681935222; Fri, 10 Jan 2020 10:45:35 -0800 (PST)
MIME-Version: 1.0
References: <8D1DD3BF-97B5-416A-B914-6867FD3553B0@amazon.com> <72A27E43-72C6-44D0-8D95-07FBF8CE332F@lodderstedt.net>
In-Reply-To: <72A27E43-72C6-44D0-8D95-07FBF8CE332F@lodderstedt.net>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Fri, 10 Jan 2020 11:45:08 -0700
Message-ID: <CA+k3eCSL5nS81uKbL3sPh9-SesPnaLsGgnO2=R4jjDy-fSVGKw@mail.gmail.com>
To: Torsten Lodderstedt <torsten=40lodderstedt.net@dmarc.ietf.org>, Nat Sakimura <nat@sakimura.org>, John Bradley <ve7jtb@ve7jtb.com>
Cc: "Richard Backman, Annabelle" <richanna=40amazon.com@dmarc.ietf.org>, oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000f66ed7059bcd8730"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/P3G2eeoLFokuEhFnByoWv1nVaxE>
Subject: Re: [OAUTH-WG] PAR: pushed requests must become JWTs
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 10 Jan 2020 18:45:42 -0000

Agree and agree. But given that the change suggested by Annabelle has no
impact on the client or interoperability, perhaps Nat or John could work
the change into the draft during the edits that happen during the final
stages of things?

On Thu, Jan 9, 2020 at 1:56 AM Torsten Lodderstedt <torsten=
40lodderstedt.net@dmarc.ietf.org> wrote:

> I would assume given the status of JAR, we don’t want to change it. And as
> I said, this difference does not impact interoperability from client
> perspective.
>
> Am 09.01.2020 um 00:58 schrieb Richard Backman, Annabelle <richanna=
> 40amazon.com@dmarc.ietf.org>:
>
> 
>
> It would be more appropriate to add the text to JAR rather than PAR. It
> doesn't seem right for PAR to retcon rules in JAR. Moving the text to JAR
> also highlights the weirdness of giving PAR special treatment.
>
>
>
> What if we changed this sentence in Section 5.2 of JAR:
>
> The contents of the resource referenced by the URI MUST be a Request
>
> Object.
>
>
>
> To:
>
> The contents of the resource referenced by the URI MUST be a Request
>
> Object, unless the URI was provided to the client by the Authorization
>
> Server.
>
>
>
> This would allow for use cases such as an AS that provides pre-defined
> request URIs, or vends request URIs via a client management console, or
> bakes them into their client apps.
>
>
>
> –
>
> Annabelle Richard Backman
>
> AWS Identity
>
>
>
> On 1/8/20, 2:50 PM, "Torsten Lodderstedt" <torsten=
> 40lodderstedt.net@dmarc.ietf.org> wrote:
>
>
>
>     Hi,
>
>
>
>     you are right, PAR does not require the AS to represent the request as
> a JWT-based request object. The URI is used as internal reference only.
> That why the draft states
>
>
>
>     "There is no need to make the
>
>           authorization request data available to other parties via this
>
>           URI.”
>
>
>
>     This difference matters from an AS implementation perspective, it
> doesn't matter from a client's (interop) perspective.
>
>
>
>     We may add a statement to PAR saying that request_uris issued by the
> PAR mechanism (MAY) deviate from the JAR definition.
>
>
>
>     best regards,
>
>     Torsten.
>
>
>
>     > On 8. Jan 2020, at 23:42, Richard Backman, Annabelle <richanna=
> 40amazon.com@dmarc.ietf.org> wrote:
>
>     >
>
>     > Hi all,
>
>     >
>
>     > The current drafts of PAR (-00) and JAR (-20) require that the AS
> transform all pushed requests into JWTs. This requirement arises from the
> following:
>
>     >         • PAR uses the request_uri parameter defined in JAR to
> communicate the pushed request to the authorization endpoint.
>
>     >         • According to JAR, the resource referenced by request_uri
> MUST be a Request Object. (Section 5.2)
>
>     >         • Request Object is defined to be a JWT containing all the
> authorization request parameters. (Section 2.1)
>
>     >
>
>     > There is no need for this requirement to support interoperability,
> as this is internal to the AS. It is also inconsistent with the rest of
> JAR, which avoids attempting to define the internal communications between
> the two AS endpoints. Worse, this restriction makes it harder for the
> authorization endpoint to leverage validation and other work performed at
> the PAR endpoint, as the state or outcome of that work must be forced into
> the JWT format (or retrieved via a subsequent service call or database
> lookup).
>
>     >
>
>     > –
>
>     > Annabelle Richard Backman
>
>     > AWS Identity
>
>     >
>
>     > _______________________________________________
>
>     > OAuth mailing list
>
>     > OAuth@ietf.org
>
>     > https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

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