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

John Bradley <ve7jtb@ve7jtb.com> Fri, 10 January 2020 20:28 UTC

Return-Path: <ve7jtb@ve7jtb.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 50EDE120100 for <oauth@ietfa.amsl.com>; Fri, 10 Jan 2020 12:28:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.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 4n0oEJeX84PO for <oauth@ietfa.amsl.com>; Fri, 10 Jan 2020 12:28:41 -0800 (PST)
Received: from mail-wr1-x443.google.com (mail-wr1-x443.google.com [IPv6:2a00:1450:4864:20::443]) (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 A73B21200FF for <oauth@ietf.org>; Fri, 10 Jan 2020 12:28:40 -0800 (PST)
Received: by mail-wr1-x443.google.com with SMTP id b6so3037674wrq.0 for <oauth@ietf.org>; Fri, 10 Jan 2020 12:28:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=r69CKG402OJKJhfFCILYX5vf5AVNnGtYrWYhHJk7L/8=; b=tpUrXg6EkRn+E1s6up7hBtdlCRG144p3seH/82blb3LrgENzTGtLbTDyAlApk7B1gu KJ2CO+nGEKtuxA8nxkaDfaJ/dQEQ7fyUq+HH48yFrEyiVnMo9+PWQQBfSX8RbZM8LNzb HsY/3Wl23DI/ZE/2cBLLw63dH4Xs/m/CvIAC77qGt50ikbQfzgyzZJgwy/mM+WjzfpYH tK2eeRsQSvUDKjEkuOw2urqwAqaKPswDBUu+it3aWF9eJGKmPLur7DvnjvwWYr2INvNv Wpvcsa+NTG7FO4/lX8mVuurhO8lW9ZMmZtmLVOonbF2rfq8pdDb/I4LAj8y7pRSuFvVU TflQ==
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=r69CKG402OJKJhfFCILYX5vf5AVNnGtYrWYhHJk7L/8=; b=eyNZp5qCbBOgCc9isIQH8unVirzFHTljoQiTkFxMYmdSGrRLF34RQZQ3sQr2nd/zFn 0Ntw/4v1DS3fLV47Q6yp/eNO2+HGnyoV5ntokM903IuQ+cYSHjx5uAMfKHqR4qUDzCce YetkEC7eCSAOuEfTrrUzmzoCakI4OBRb0i0dGKfUg8pzt6UU+VNqTSGOAT8EQoLeLLAb kvFNy7aJhhn5O9gLTMI/Pk9R9QeR6MHzUZhezETQRIyB9CKUj2YVrNJBar5SsSoTexa6 6lBgLvOn0Djieq00I7qMfyDfo1wiP0MKPW7Z8Qf0GGlc+RblJvIegzqz4vpZi2lrB8J0 xHJg==
X-Gm-Message-State: APjAAAUqXqyHaZDN5lqR4nrmj8ZBB+JwAZjlOGEKlsywQXXlMDQkxRFK vE0BtXKhr/U6eaW0gMoGUUuziAp4crtGXbUaoxZK6g==
X-Google-Smtp-Source: APXvYqyI/S8VrZOZ78GxQtiySQytRvDMkoe2gqFhLlScNDmH016uYCMuFOT3ExQnX3DdjNHCBb6HHWW+fVEgrtSq3Fc=
X-Received: by 2002:adf:f382:: with SMTP id m2mr5222434wro.163.1578688118831; Fri, 10 Jan 2020 12:28:38 -0800 (PST)
MIME-Version: 1.0
References: <8D1DD3BF-97B5-416A-B914-6867FD3553B0@amazon.com> <72A27E43-72C6-44D0-8D95-07FBF8CE332F@lodderstedt.net> <CA+k3eCSL5nS81uKbL3sPh9-SesPnaLsGgnO2=R4jjDy-fSVGKw@mail.gmail.com> <CAANoGh+9+g=2kzh5k-n5eOVHNX=F6kxWbwrP-u=yG-F_C02i8g@mail.gmail.com> <CA+k3eCSSSnX2oCoSvtGpbZZCQ+xydaE0g1SseikAs19M8VBLpw@mail.gmail.com>
In-Reply-To: <CA+k3eCSSSnX2oCoSvtGpbZZCQ+xydaE0g1SseikAs19M8VBLpw@mail.gmail.com>
From: John Bradley <ve7jtb@ve7jtb.com>
Date: Fri, 10 Jan 2020 17:28:29 -0300
Message-ID: <CAANoGhJ+mffKvDSgHYuX+kYTCS_jyvQVYqia10LTRDg4Vw7jNw@mail.gmail.com>
To: Brian Campbell <bcampbell@pingidentity.com>
Cc: Torsten Lodderstedt <torsten=40lodderstedt.net@dmarc.ietf.org>, Nat Sakimura <nat@sakimura.org>, "Richard Backman, Annabelle" <richanna=40amazon.com@dmarc.ietf.org>, oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000088d2c6059bcef875"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/-ku28V5LcKUiGRubND3grNsw2Yc>
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 20:28:46 -0000

If we assume the client posts a JAR and gets back a reference.  Then the
reference is to a JAR.

I think I see the problem.  If the server providing the reference is
associated with the AS then the server dosen't need to dereference the
object via HTTP, so it could be a URN as an example.

So yes it is not a interoperability issue for the client.

I will think about how I can finesse that.

I agree it is not a change in intent.

I will see if I can get our AD to accept that.

John B.




On Fri, Jan 10, 2020, 4:57 PM Brian Campbell <bcampbell@pingidentity.com>
wrote:

> Sure but the text proposed (or something like it) qualifies it such that
> there aren't interoperability questions because it's only an implementation
> detail to the AS who both produces the URI and consumes its content.
>
> On Fri, Jan 10, 2020 at 12:48 PM John Bradley <ve7jtb@ve7jtb.com> wrote:
>
>> It may be a challenge to change text saying that the contents of the
>> resource could be something other than a request object.
>>
>> If not a request object then what and how is that interoperable are
>> likely AD questions.
>>
>> I could perhaps see changing it to must be a request object, or other
>> format defined by a profile.
>>
>> John B.
>>
>>
>> On Fri, Jan 10, 2020, 3:45 PM Brian Campbell <bcampbell@pingidentity.com>
>> wrote:
>>
>>> 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.*
>>
>>
> *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.*