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

Torsten Lodderstedt <torsten@lodderstedt.net> Thu, 09 January 2020 19:47 UTC

Return-Path: <torsten@lodderstedt.net>
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 B78A01207FB for <oauth@ietfa.amsl.com>; Thu, 9 Jan 2020 11:47:52 -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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lodderstedt.net
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 q1evJCuAi5Ho for <oauth@ietfa.amsl.com>; Thu, 9 Jan 2020 11:47:50 -0800 (PST)
Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (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 5271C120047 for <oauth@ietf.org>; Thu, 9 Jan 2020 11:47:50 -0800 (PST)
Received: by mail-wm1-x334.google.com with SMTP id d139so2787305wmd.0 for <oauth@ietf.org>; Thu, 09 Jan 2020 11:47:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=5GdRCTlzZ/aJxMmm6zlUn3ACPXxUfExOY+cXweVx7nk=; b=jX6SX57Z3RGcDco8gWlB96WsRnXb47AOJslw0GtrYo7UxaqiJTHF+A6cY3pXxsH02i ftmEDL4LuycU82t7AS9ZsfqODBiBY3jPHoeS+9eFMv/xkwMATvzKl2LYag6Z4v3IUhp6 J/6+7CKd4PymfLrlAyCYxPVDrdnn8AfibWSdZaYeS/EbN2cR+Ju2AZVMgtcbPbEpd3oi pR39LeUD5mX8rvRQ7ijSW8ERmMJFkbNiJHdxIkNbGWW+jKgaf+up8QDhwihsh0DdL8vZ YgawMteGcxh8t+vX1oLdIeKcmY6fSTxgY1e17kE//szYyBIcsDOgwdVOQJDrDgMEZqa6 FdvQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=5GdRCTlzZ/aJxMmm6zlUn3ACPXxUfExOY+cXweVx7nk=; b=IEPEcKWuhrsZ1P45HuIvVaLlxBANobSee2R58wj1CgnRZGxMTZGCcsXyYmYYjYtmjE TaDlsbQDi7y/SeGiKDw3jHslFDVdpcoKHNTiwBcNlpkvtggdZ0Ok57FEm+pefaVRQQOO RYtualXMJEWNz08GlY/AcqLXIe2A4N/C7IVmAfwIJSFkhTP/FP8q5xsYGETOfFIzjlid 7kwYbRAvcSBOLHEgNqbdk3RrRMju+/VwC//E47l3VhadosmTsA17SsNoEXxPqwzbnvDs hCRmHg6CLgIzUrNx/dOP3PL+fj8jiG9XtWzhSWv0wFTeJC7u0lts4mMiszvIvFSPfPf2 XHRQ==
X-Gm-Message-State: APjAAAVhkh7SyWy/UIaJfXcXJrEqQhs+gmZsFHlfmQwyvJTGivp72Zm1 SXOQ7jfgbeNn+Nn5AqvdJHROig==
X-Google-Smtp-Source: APXvYqyUd5CM6kQdzKPJdA+XrWCB64L/iWzjm03zqWe181QtX/dEnJInUj1+OrpXXL6v29saiBW09A==
X-Received: by 2002:a05:600c:24d1:: with SMTP id 17mr6511609wmu.136.1578599268837; Thu, 09 Jan 2020 11:47:48 -0800 (PST)
Received: from [10.30.1.34] ([213.151.95.78]) by smtp.gmail.com with ESMTPSA id n189sm4085854wme.33.2020.01.09.11.47.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 09 Jan 2020 11:47:48 -0800 (PST)
Content-Type: multipart/alternative; boundary=Apple-Mail-FCC375DD-F111-4AC9-BF56-923327A9D137
Content-Transfer-Encoding: 7bit
From: Torsten Lodderstedt <torsten@lodderstedt.net>
Mime-Version: 1.0 (1.0)
Date: Thu, 9 Jan 2020 20:47:47 +0100
Message-Id: <E2A2CBC0-39D1-4240-A163-A33711DF820F@lodderstedt.net>
References: <D37D8F06-3E07-4C89-B0B9-61AAF2CDAA2F@amazon.com>
Cc: oauth <oauth@ietf.org>
In-Reply-To: <D37D8F06-3E07-4C89-B0B9-61AAF2CDAA2F@amazon.com>
To: "Richard Backman, Annabelle" <richanna=40amazon.com@dmarc.ietf.org>
X-Mailer: iPad Mail (17C54)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/LFJew4EzUYh1qOLS3dKDDyxQSTk>
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: Thu, 09 Jan 2020 19:47:53 -0000

Thanks for the text proposal. It works for me.

> Am 09.01.2020 um 20:34 schrieb Richard Backman, Annabelle <richanna=40amazon.com@dmarc.ietf.org>rg>:
> 
> 
> If we address this in PAR, I suggest something along the lines of the following:
>  
> As defined in [JAR], the request_uri parameter is required to reference a Request Object JWT. An AS MAY violate this requirement when it is generating request URIs intended for its own consumption (e.g., URIs for pushed requests). This requirement exists to ensure interoperability in cases where the provider of the request_uri is a separate entity from the consumer, such as when a client provides a URI referencing an object stored on the client’s backend service. When the AS is both provider and consumer, this interoperability concern does not apply.
>  
> – 
> Annabelle Richard Backman
> AWS Identity
>  
>  
> From: OAuth <oauth-bounces@ietf.org> on behalf of Torsten Lodderstedt <torsten=40lodderstedt.net@dmarc.ietf.org>
> Date: Thursday, January 9, 2020 at 12:56 AM
> To: "Richard Backman, Annabelle" <richanna=40amazon.com@dmarc.ietf.org>
> Cc: oauth <oauth@ietf.org>
> Subject: Re: [OAUTH-WG] PAR: pushed requests must become JWTs
>  
> 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>rg>:
> 
> 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
>    
>