Re: [OAUTH-WG] PAR - Can AS/client require request object?
Filip Skokan <panva.ip@gmail.com> Tue, 12 May 2020 07:01 UTC
Return-Path: <panva.ip@gmail.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 0E8463A0819
for <oauth@ietfa.amsl.com>; Tue, 12 May 2020 00:01:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001,
HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001,
URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key)
header.d=gmail.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 udpQcyZ9HPSo for <oauth@ietfa.amsl.com>;
Tue, 12 May 2020 00:01:48 -0700 (PDT)
Received: from mail-yb1-xb2c.google.com (mail-yb1-xb2c.google.com
[IPv6:2607:f8b0:4864:20::b2c])
(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 BD5973A0885
for <oauth@ietf.org>; Tue, 12 May 2020 00:01:47 -0700 (PDT)
Received: by mail-yb1-xb2c.google.com with SMTP id q206so6461476ybg.1
for <oauth@ietf.org>; Tue, 12 May 2020 00:01:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc; bh=5uk1xthSbqYc5MNJxk0xqkjnEd+zAjxGQb0uZLGXRCw=;
b=tT5zI30SGYiZhHkyi6lyQ9OKRYVqskDRwJzXnKjNG+k1Ksqcp64UMbUyz3K0Wu7zON
D+WEiLKZ2np5OF3THG1L1vpErG5tqfqPFAk7su1ES40Kjf/uJgiqQ/xNxjViVh9yhJ9J
hI0oiNnBTRyyjBHBCsv9Uj3rwah3dLABVxDTy9cX7t1RvobE0KRsJ/6pZV9YV3XkHuzd
7Q1SsjB6z9wyL8/d0n35c6MruRB9/CF8EB7pufhJwDW0RVTntDQP2uTH73HRxM0AM/xz
1WnyZXuRQs276roMCAtOYILbBBzYUV5snyemsSZDALQo25UbO0ITWbLGw02xZ2u+UU1n
u6cQ==
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=5uk1xthSbqYc5MNJxk0xqkjnEd+zAjxGQb0uZLGXRCw=;
b=JwX3o7npwNUHPD32uxIw//Ek38iqhAEHaYtM6QHEkp5zmzoLNgoz5yAzv9TYsdY/nj
hnu1RxDBx/5L1kJl7rER1ljbqerl36XVDYhtoTY+2l2zgefoOjI4nssVTJKPRvOXCSb0
+EXh0fw/vBNWHLXyzb9/6ig1BYAWy/OZLvKa/+SkecW5eCAqjHT8UU90jnXYWeqD6x8Z
0t8C5EoVhM4wBDHmZcz8tAWbIYdIPYkM5jWXT/K3qKYZQbJksnprOyqcWtRH6b4PUPq/
C4GV5g2uBmklgvMQQEjXvOcsxWeCkeIbquLtZO0B+fu3Z+C2OxT9jbO/CI8C74WYWsOU
uyDw==
X-Gm-Message-State: AGi0PubXZ5MxOH2KoKW3yd6MENYXlylLsdNIfuTA8iEYlHV1JisrOy2O
KD2ziyj92patpB1SghGkiWGxj3FJzLy3T471qQ==
X-Google-Smtp-Source: APiQypK9UwvKUoRQEx7Xuxz1foCccTYWjX/U2As5BokKEbmSPEHdzeD7/6vuClAQ4pFqHh3jegD8qhUzwrx2BNchQ8Q=
X-Received: by 2002:a5b:44b:: with SMTP id s11mr31695234ybp.399.1589266906029;
Tue, 12 May 2020 00:01:46 -0700 (PDT)
MIME-Version: 1.0
References: <DM6PR00MB0682FB5ABDAE909C7156564DF5AB0@DM6PR00MB0682.namprd00.prod.outlook.com>
<A00DFA90-F7AB-4E54-AEE0-BCD98C45BF9D@lodderstedt.net>
In-Reply-To: <A00DFA90-F7AB-4E54-AEE0-BCD98C45BF9D@lodderstedt.net>
From: Filip Skokan <panva.ip@gmail.com>
Date: Tue, 12 May 2020 09:01:10 +0200
Message-ID: <CALAqi__J_j75mbFo_sU1o+ChreAaD0eBOYMC_EGExJHXXYq_+Q@mail.gmail.com>
To: Torsten Lodderstedt <torsten=40lodderstedt.net@dmarc.ietf.org>
Cc: oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000006321cc05a56e0965"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/YoAAE4fTAfA-GAXL1z1aXtKd55M>
Subject: Re: [OAUTH-WG] PAR - Can AS/client require request object?
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: Tue, 12 May 2020 07:01:52 -0000
I think require_request_objects has its place, that place should be JAR, PAR as a backup. I believe doing only the "PAR-specific" name / meaning of it would be a missed opportunity. S pozdravem, *Filip Skokan* On Tue, 12 May 2020 at 08:27, Torsten Lodderstedt <torsten= 40lodderstedt.net@dmarc.ietf.org> wrote: > Hi all, > > I initially raised the question whether the AS should be able to require > request objects for all clients (in the same way as we decided to let the > AS required PAR for all clients) but this topic was never discussed later > on. > > I suggest to add a server metadata parameter “require_request_objects” so > the AS can indicate its policy to clients. > > I think the best place to define this parameter would be JAR, if that is > not possible any longer, we could use a different PAR-specific name and add > it to PAR. > > What do you think? > > best regards, > Torsten. > > > On 1. May 2020, at 17:56, Mike Jones <Michael.Jones= > 40microsoft.com@dmarc.ietf.org> wrote: > > > > Works for me. > > > > > > > > From: OAuth <oauth-bounces@ietf.org> On Behalf Of Torsten Lodderstedt > > Sent: Friday, May 1, 2020 2:51 AM > > To: Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org> > > Cc: oauth <oauth@ietf.org> > > Subject: Re: [OAUTH-WG] PAR - Can AS/client require request object? > > > > > > > > Filip´s proposal works for me. > > > > > > > > Are there any objections? > > > > > > > > Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org> schrieb am > Mo. 27. Apr. 2020 um 20:57: > > > > While there are certainly different permutations and contexts of use > that could be imagine, I tend to agree with Filip here in not seeing a > strong need to define new PAR specific metadata around signing/encryption > of the request object. > > > > > > > > On Mon, Apr 27, 2020 at 2:35 AM Filip Skokan <panva.ip@gmail.com> wrote: > > > > Considering there's going to be a setting that forces clients to use PAR > (other mailinglist thread), then we should rely on the existing > `request_object_signing_alg` presence to indicate a Request Object must be > used (as suggested by this upcoming OIDC Core errata), regardless of it > being PAR or JAR. I don't see the need for a PAR specific metadata, for one > - implementations wouldn't be easily able to re-use of existing pipelines, > two - yes the contexts differ but do you think clients will be using both > channels at the same time? And even if so, the Request Object is the same > therefore its applicable to both channels the same. > > > > > > Best, > > Filip Skokan > > > > > > > > > > > > On Sun, 26 Apr 2020 at 17:09, Torsten Lodderstedt <torsten= > 40lodderstedt.net@dmarc.ietf.org> wrote: > > > > Hi all, > > > > this is one of the topics we quickly flipped through in the virtual > meeting last week. > > > > I see the following open questions: > > - Can the client require its instances to use request objects only. > > - Are there further requirements on the properties of these objects? > Signed only, Signed and encrypted, algorithms? > > - Can an AS require ALL clients to use request objects only? > > - Further requirements here as well? > > - Is this tied to PAR or relevant for JAR as well? > > > > In my opinion, client as well as AS should be able to control enforced > use of request objects. > > > > I could imagine the setting for JAR request objects (“request" > parameter) and request objects in the PAR context differ, as the first case > goes through the user’s browser whereas the PAR case goes direct from > client to AS via a TLS protected channel. I therefore feel the settings > should be PAR specific. > > > > What do you think? > > > > best regards, > > Torsten. > > _______________________________________________ > > 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. > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >
- [OAUTH-WG] PAR - Can AS/client require request ob… Torsten Lodderstedt
- Re: [OAUTH-WG] PAR - Can AS/client require reques… Filip Skokan
- Re: [OAUTH-WG] PAR - Can AS/client require reques… Brian Campbell
- Re: [OAUTH-WG] PAR - Can AS/client require reques… Torsten Lodderstedt
- Re: [OAUTH-WG] PAR - Can AS/client require reques… Dave Tonge
- Re: [OAUTH-WG] PAR - Can AS/client require reques… Mike Jones
- Re: [OAUTH-WG] PAR - Can AS/client require reques… Torsten Lodderstedt
- Re: [OAUTH-WG] PAR - Can AS/client require reques… Filip Skokan
- Re: [OAUTH-WG] PAR - Can AS/client require reques… Thibault Normand
- Re: [OAUTH-WG] PAR - Can AS/client require reques… Vladimir Dzhuvinov