Return-Path: 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 ; 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 ; 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 ; Thu, 9 Jan 2020 11:47:50 -0800 (PST) Received: by mail-wm1-x334.google.com with SMTP id d139so2787305wmd.0 for ; 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 Mime-Version: 1.0 (1.0) Date: Thu, 9 Jan 2020 20:47:47 +0100 Message-Id: References: Cc: oauth In-Reply-To: To: "Richard Backman, Annabelle" X-Mailer: iPad Mail (17C54) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 19:47:53 -0000 --Apple-Mail-FCC375DD-F111-4AC9-BF56-923327A9D137 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks for the text proposal. It works for me. > Am 09.01.2020 um 20:34 schrieb Richard Backman, Annabelle : >=20 > =EF=BB=BF > If we address this in PAR, I suggest something along the lines of the foll= owing: > =20 > As defined in [JAR], the request_uri parameter is required to reference a R= equest Object JWT. An AS MAY violate this requirement when it is generating r= equest URIs intended for its own consumption (e.g., URIs for pushed requests= ). This requirement exists to ensure interoperability in cases where the pro= vider of the request_uri is a separate entity from the consumer, such as whe= n a client provides a URI referencing an object stored on the client=E2=80=99= s backend service. When the AS is both provider and consumer, this interoper= ability concern does not apply. > =20 > =E2=80=93=20 > Annabelle Richard Backman > AWS Identity > =20 > =20 > From: OAuth on behalf of Torsten Lodderstedt > Date: Thursday, January 9, 2020 at 12:56 AM > To: "Richard Backman, Annabelle" > Cc: oauth > Subject: Re: [OAUTH-WG] PAR: pushed requests must become JWTs > =20 > I would assume given the status of JAR, we don=E2=80=99t want to change it= . And as I said, this difference does not impact interoperability from clien= t perspective. >=20 >=20 > Am 09.01.2020 um 00:58 schrieb Richard Backman, Annabelle : >=20 > It would be more appropriate to add the text to JAR rather than PAR. It do= esn't seem right for PAR to retcon rules in JAR. Moving the text to JAR also= highlights the weirdness of giving PAR special treatment. > =20 > 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. > =20 > 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. > =20 > This would allow for use cases such as an AS that provides pre-defined req= uest URIs, or vends request URIs via a client management console, or bakes t= hem into their client apps. > =20 > =E2=80=93 > Annabelle Richard Backman > AWS Identity > =20 > On 1/8/20, 2:50 PM, "Torsten Lodderstedt" wrote: > =20 > Hi, > =20 > 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. Tha= t why the draft states > =20 > "There is no need to make the > authorization request data available to other parties via this > URI.=E2=80=9D > =20 > This difference matters from an AS implementation perspective, it does= n't matter from a client's (interop) perspective. > =20 > We may add a statement to PAR saying that request_uris issued by the P= AR mechanism (MAY) deviate from the JAR definition. > =20 > best regards, > Torsten.=20 > =20 > > On 8. Jan 2020, at 23:42, Richard Backman, Annabelle wrote: > > > > Hi all, > >=20 > > The current drafts of PAR (-00) and JAR (-20) require that the AS tr= ansform all pushed requests into JWTs. This requirement arises from the foll= owing: > > =E2=80=A2 PAR uses the request_uri parameter defined in JAR t= o communicate the pushed request to the authorization endpoint. > > =E2=80=A2 According to JAR, the resource referenced by reque= st_uri MUST be a Request Object. (Section 5.2) > > =E2=80=A2 Request Object is defined to be a JWT containing a= ll the authorization request parameters. (Section 2.1) > >=20 > > There is no need for this requirement to support interoperability, a= s this is internal to the AS. It is also inconsistent with the rest of JAR, w= hich 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 endpoin= t, 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). > >=20 > > =E2=80=93 > > Annabelle Richard Backman > > AWS Identity > >=20 > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > =20 > =20 --Apple-Mail-FCC375DD-F111-4AC9-BF56-923327A9D137 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Thanks for the text propos= al. It works for me.

Am 0= 9.01.2020 um 20:34 schrieb Richard Backman, Annabelle <richanna=3D40amazo= n.com@dmarc.ietf.org>:

=EF=BB=BF

If we address this i= n PAR, I suggest something along the lines of the following:

 

As defined in [JAR], the request_uri parameter is required to referen= ce a Request Object JWT. An AS MAY violate this requirement when it is gener= ating request URIs intended for its own consumption (e.g., URIs for pushed requests). This requirement exists t= o 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 ref= erencing an object stored on the client=E2=80=99s backend service. When the AS is both provider and cons= umer, this interoperability concern does not apply.

 

=E2=80=93 

Annabelle Richard Backman

AWS Identity

 

 

From: OAuth <oauth-bounces@ietf.org> on behalf of Tor= sten Lodderstedt <torsten=3D40lodderstedt.net@dmarc.ietf.org>
Date: Thursday, January 9, 2020 at 12:56 AM
To: "Richard Backman, Annabelle" <richanna=3D40amazon.com@dmarc.ie= tf.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=E2=80=99= t want to change it. And as I said, this difference does not impact interope= rability from client perspective.



Am 09.01.2020 um 00:58= schrieb Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.o= rg>:

It would be more appropriate to add the text to JA= R rather than PAR. It doesn't seem right for PAR to retcon rules in JAR. Mov= ing the text to JAR also highlights the weirdness of giving PAR special trea= tment.

 

What if we changed this sentence in Section 5.2 of= JAR:

The contents of the resource referenced by the U= RI MUST be a Request

Object.

 

To:

The contents of the resource referenced by the U= RI MUST be a Request

Object, unless the URI was provided to the clie= nt by the Authorization

Server.

 

This would allow for use cases such as an AS that p= rovides pre-defined request URIs, or vends request URIs via a client managem= ent console, or bakes them into their client apps.

 

=E2=80=93

Annabelle Richard Backman

AWS Identity

 

On 1/8/20, 2:50 PM, "Torsten Lodderstedt" <tors= ten=3D40lodderstedt.net@dmarc.ietf.org> wrote:

 

    Hi,

    

    you are right, PAR does no= t 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 t= he

        &n= bsp; authorization request data available to other parties via this

        &n= bsp; URI.=E2=80=9D

   

    This difference matters fr= om an AS implementation perspective, it doesn't matter from a client's (inte= rop) perspective.

   

    We may add a statement to P= AR saying that request_uris issued by the PAR mechanism (MAY) deviate from t= he JAR definition.

    

    best regards,

    Torsten. 

    

    > On 8. Jan 2020, at 23= :42, Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org&g= t; wrote:

    >

    > Hi all,

    > 

    > The current drafts of= PAR (-00) and JAR (-20) require that the AS transform all pushed requests i= nto JWTs. This requirement arises from the following:

    >     &n= bsp;   =E2=80=A2 PAR uses the request_uri parameter defined in JAR= to communicate the pushed request to the authorization endpoint.=

    >     &n= bsp;   =E2=80=A2 According to JAR, the resource referenced by requ= est_uri MUST be a Request Object. (Section 5.2)

    >     &n= bsp;   =E2=80=A2 Request Object is defined to be a JWT containing a= ll the authorization request parameters. (Section 2.1)

    > 

    > There is no need for t= his requirement to support interoperability, as this is internal to the AS. I= t is also inconsistent with the rest of JAR, which avoids attempting to defi= ne the internal communications between the two AS endpoints. Worse, this restriction makes it harder for the authorization endpoint to l= everage validation and other work performed at the PAR endpoint, as the stat= e or outcome of that work must be forced into the JWT format (or retrieved v= ia a subsequent service call or database lookup).

    > 

    > =E2=80=93 =

    > Annabelle Richard Bac= kman

    > AWS Identity

    > 

    > _____________________= __________________________

    > OAuth mailing list

    > OAuth@ietf.org<= /p>

    > https://www.ietf.org/mailm= an/listinfo/oauth

   

    

= --Apple-Mail-FCC375DD-F111-4AC9-BF56-923327A9D137--