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

Vladimir Dzhuvinov <vladimir@connect2id.com> Wed, 15 January 2020 20:43 UTC

Return-Path: <vladimir@connect2id.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 6CF65120935 for <oauth@ietfa.amsl.com>; Wed, 15 Jan 2020 12:43:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no
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 PKK8birFe0-E for <oauth@ietfa.amsl.com>; Wed, 15 Jan 2020 12:43:30 -0800 (PST)
Received: from p3plsmtpa07-04.prod.phx3.secureserver.net (p3plsmtpa07-04.prod.phx3.secureserver.net [173.201.192.233]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D84812089C for <oauth@ietf.org>; Wed, 15 Jan 2020 12:43:30 -0800 (PST)
Received: from [192.168.88.250] ([94.155.17.54]) by :SMTPAUTH: with ESMTPSA id rpVfir91sRMh6rpVgiTbeA; Wed, 15 Jan 2020 13:43:29 -0700
To: Benjamin Kaduk <kaduk@mit.edu>, Justin Richer <jricher@mit.edu>
Cc: oauth <oauth@ietf.org>, Nat Sakimura <nat@sakimura.org>, "Richard Backman, Annabelle" <richanna=40amazon.com@dmarc.ietf.org>
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> <CAANoGhJ+mffKvDSgHYuX+kYTCS_jyvQVYqia10LTRDg4Vw7jNw@mail.gmail.com> <CAC46A6B-229C-4B5A-AEE3-A2D8662A81DB@amazon.com> <1A5C82C9-383D-4C09-8233-3C9D0C85A1F6@mit.edu> <d689cba5-2453-60a1-7ec8-895e32eb1a1b@connect2id.com> <F42FBA3C-B549-4D93-94D6-C5B7583CC23B@mit.edu> <20200114044627.GM66991@kduck.mit.edu>
From: Vladimir Dzhuvinov <vladimir@connect2id.com>
Organization: Connect2id Ltd.
Message-ID: <7550b441-c598-c2a6-041f-417f7c2c18a3@connect2id.com>
Date: Wed, 15 Jan 2020 22:43:26 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2
MIME-Version: 1.0
In-Reply-To: <20200114044627.GM66991@kduck.mit.edu>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms090101020902050505020002"
X-CMAE-Envelope: MS4wfIc2o/ZHi7MN52HEdZOAy62xeCtWR8suhGIyLprlJOD3xE5ceLdhWdVNdRKLA1PLDTaSsMgVOVUFnJBo0tHDdpoq2LywrvcAKkWm2mshkKOkzVIgAKS+ dqsQU22wfekxmcaLba7BYM1nQqJcmblQeklUp1YiW8O587EoZdJSGpOukHlpURCW05TmSsueIbS7BZEI4hCZjHy7o4EeMm5ZCOwhFNhpVk6zNRjXLpmgaboo 6iY7JPXbKo12GP/P9hit/TR1yxicDU5SOCCTKrf19+iSUEbe6Edqt0oJcSZFcsyL
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/tVU_xD-h2UIlk13wNOP7IH4-tiM>
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: 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: Wed, 15 Jan 2020 20:43:32 -0000

On 14/01/2020 06:46, Benjamin Kaduk wrote:
> On Mon, Jan 13, 2020 at 12:32:41PM -0500, Justin Richer wrote:
>> To be clear, I’m not saying we suggest a particular form, and I agree that we shouldn’t specify that “it’s a JWT” or something of that nature. But if we call the result of PAR “thing X” and the target of request_uri “thing X” in JAR, then we’re compatible without saying what “thing X” needs to be in all cases. 
>>
> That seems fair.  What properties would a given "thing X" need to have in
> order to work, though -- uniqueness over a specific period of time?
> Unpredictability?  More?

 1. That the request_uri uniquely points to the submitted authZ request
    for the duration of the request_uri lifetime (defined by the
    expires_in response parameter).
 2. The request_uri cannot be reasonably guessed.

I think that's all we need Ben.

Vladimir