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
>