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

Torsten Lodderstedt <torsten@lodderstedt.net> Fri, 24 July 2020 07:12 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 BD7723A0A7B for <oauth@ietfa.amsl.com>; Fri, 24 Jul 2020 00:12:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=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 v2IzHu6ysrvz for <oauth@ietfa.amsl.com>; Fri, 24 Jul 2020 00:12:24 -0700 (PDT)
Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [IPv6:2a00:1450:4864:20::62a]) (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 CC4E93A0A8F for <oauth@ietf.org>; Fri, 24 Jul 2020 00:12:23 -0700 (PDT)
Received: by mail-ej1-x62a.google.com with SMTP id l4so8875852ejd.13 for <oauth@ietf.org>; Fri, 24 Jul 2020 00:12:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=nmFJvOc7RzefeBtB8/mCFSbt5ElbKojHxw2CNn8VdgI=; b=F70XvB0LMYfHha4nFKd6NbipSetTOaC5r+AMIPFOsSFAU1m/LXgc2Kbze38Bx6jcSo +pMIrK+zP3gkQB4Nj5dovDnepD0RYoRKhw8Q2U5+bD8ZaqN8G0/YAq2vJZN75qszzCD8 +5a4L0SvpjF1sittkK6AFm47ONaqEE0oEgjFUT6DWIhqXDfOhoO9gVhCDNll3+doMwF5 QvOAUyTXPGf7E+vMOLt1A07q8kw+rpatgcxhPBMheMN1+ZE3W5C1LmERb74dTDlmI5B7 o4oibskrJrCrYPz8VmqJg1QiMcGajRpE5K9Zj3LUGjVenoihIDNXL4CIj6J9WI6uKeTj JoPQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=nmFJvOc7RzefeBtB8/mCFSbt5ElbKojHxw2CNn8VdgI=; b=fSk7w4+BlT/33YGDGQKBIDcWfDxBk3Zy0Uf8QNH2mQwYjZdMvZKt9KgX0NzfezUyEY Vxs1y9txqfKVt6TnOhK7gWX1G6JxrrvmcA8LRSnI1dYHy8memtQEbrrJvLqtBiQDVEjT JJCRmtQyPS12yW8yW++LHWI3CPiXLinRnZprb5MMwIy/ivCoY0n5ik3992PctBwXKh5o EoGrbr5tZNYeLNGrigZ2Z6s1eLTGdReSshoa0pnxrQryonX0Br9HahZjV8DoAG/d7nfn 4Zlb1o91tuB+cOfi7WLwgLz+9y+xnjIOZ9wqA2rF8u6PMUkEEHjIi+ztRxARYjlDQOBN phuw==
X-Gm-Message-State: AOAM532+40I9ssR6E2yKCT48qXBrpu2L5x+XlvFCHgUVGaIA7RGbk54S 4jOfhLkhNrohpVosiplTx21ScN6Yb+M=
X-Google-Smtp-Source: ABdhPJxFI3Nw+W299sSQfaF4Z0OU7/2Y89+XwgU2D22OX5K0r2tZzPNdekRGjFvkeiJYiHez8Xik/g==
X-Received: by 2002:a17:906:7fc8:: with SMTP id r8mr8298919ejs.412.1595574741914; Fri, 24 Jul 2020 00:12:21 -0700 (PDT)
Received: from p200300eb8f0138d07919e861a29aecbb.dip0.t-ipconnect.de (p200300eb8f0138d07919e861a29aecbb.dip0.t-ipconnect.de. [2003:eb:8f01:38d0:7919:e861:a29a:ecbb]) by smtp.gmail.com with ESMTPSA id d23sm85536ejj.74.2020.07.24.00.12.20 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Jul 2020 00:12:21 -0700 (PDT)
From: Torsten Lodderstedt <torsten@lodderstedt.net>
Message-Id: <3C919E79-C162-4B5D-A2BE-95825981CF3A@lodderstedt.net>
Content-Type: multipart/signed; boundary="Apple-Mail=_5D8239C1-8711-4F80-A131-40B27EC3F22E"; protocol="application/pkcs7-signature"; micalg=sha-256
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Fri, 24 Jul 2020 09:12:19 +0200
In-Reply-To: <CAGBSGjp+gudsyu9EsyEZ8-JsUKQQDHL+T15G7=PDa=f7hvBZhQ@mail.gmail.com>
Cc: oauth <oauth@ietf.org>
To: Aaron Parecki <aaron@parecki.com>
References: <869491B5-9AA5-4593-A307-46FAAF7E990D@mit.edu> <7B488048-896B-4F88-976C-909D0BFA16D3@lodderstedt.net> <CAGBSGjp+gudsyu9EsyEZ8-JsUKQQDHL+T15G7=PDa=f7hvBZhQ@mail.gmail.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/x4-EQtosODRrNPa0UGLqT4ezzCU>
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: Fri, 24 Jul 2020 07:12:26 -0000

Hi Aaron, 

that’s a very good point. I was also in favour of just providing the client with the URL it needs to send the user to (like XYZ and OAuth do). 

In the end, we decided to stay with the current approach since it fits with the rest of the existing ecosystem, namely JAR and authorization endpoint discovery. 

best regards,
Torsten. 

> On 24. Jul 2020, at 00:49, Aaron Parecki <aaron@parecki.com> wrote:
> 
> I know this is a bit of an old thread to dig up, but as I'm working through this draft again, something is sticking out to me about this.
> 
> In every other instance of "*_uri" in OAuth and extensions, the value is a URI (usually https) which will be visited by the user's browser or be sent a POST request from a client. In the case of PAR, this "request_uri" is actually just an identifier that is *added* to an existing URL, the authorization endpoint, not a URL that will be visited itself. This discrepancy is bothering me.
> 
> I would have expected that either:
> 
> * The PAR response includes a "request_uri" which is the full URL that the client would redirect the user's browser to, OR
> * The PAR response includes a "request_id" which it adds in the query string to the authorization endpoint and then redirects the browser to
> 
> For example:
> 
> POST /as/par HTTP/1.1
> ...
> response:
> {
>       "request_uri": "https://as.example.com/auth?request=bwc4JK-ESC0w8acc191e-Y1LTC2",
>       "expires_in": 60
> }
> 
> then the user's browser is sent to whatever the value of "request_uri" is
> 
> OR
> 
> POST /as/par HTTP/1..1
> ...
> response:
> {
>       "request_id": "urn:ietf:params:oauth:request_uri:bwc4JK-ESC0w8acc191e-Y1LTC2",
>       "expires_in": 60
> }
> 
> then the "request_id" is added to the authorization endpoint (as currently described by PAR)
> 
> https://as.example.com/auth?client_id=s6BhdRkqt3&request_uri=urn%3Aietf%3Aparams%3Aoauth%3Arequest_uri%3Abwc4JK-ESC0w8acc191e-Y1LTC2
> 
> My personal preference is the first option, keeping the term "request_uri" but having it actually be the full URI, to simplify the job of the client. In that model, the client doesn't have to mess with building URLs, and actually provides additional flexibility for the AS as well since that endpoint no longer needs to be the exact same URL as the authorization endpoint.. 
> 
> ---
> Aaron Parecki
> https://aaronparecki.com
> 
> 
> On Thu, Jan 16, 2020 at 8:25 AM Torsten Lodderstedt <torsten=40lodderstedt.net@dmarc.ietf.org> wrote:
> I just thought about another option. What if we change PAR to not use the request_uri parameter but a new parameter, e.g. request_id?
> 
> That would decouple both specs. The reason why we use request_uri was to make the life of clients easier since they can use the standard library function for request objects to pass the PAR reference to the AS. Is this worth the trouble?
> 
>> Am 16.01.2020 um 16:48 schrieb Justin Richer <jricher@mit.edu>du>:
>> 
>> +1 to this approach, and it sounds like JAR might need to come back to go through another round anyway thanks to the breaking changes the IESG pushed into it after it left WGLC.
>> 
>> I’d rather see us get this right than publish something many of us think is broken. 
>> 
>> Maybe PAR and JAR (and JARM?) end up going out as a bundle of specs.
>> 
>>  — Justin
>> 
>>> 
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth