Re: [OAUTH-WG] PAR - Can AS/client require request object?

Filip Skokan <panva.ip@gmail.com> Mon, 27 April 2020 08:35 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 BECB43A1267 for <oauth@ietfa.amsl.com>; Mon, 27 Apr 2020 01:35:21 -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 J-jof-mi8wHF for <oauth@ietfa.amsl.com>; Mon, 27 Apr 2020 01:35:17 -0700 (PDT)
Received: from mail-yb1-xb35.google.com (mail-yb1-xb35.google.com [IPv6:2607:f8b0:4864:20::b35]) (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 17C383A10B5 for <oauth@ietf.org>; Mon, 27 Apr 2020 01:35:17 -0700 (PDT)
Received: by mail-yb1-xb35.google.com with SMTP id l5so9055123ybf.5 for <oauth@ietf.org>; Mon, 27 Apr 2020 01:35:17 -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=LY4bLh/QT4GRjkyxazTp2XsI3V+1fiSyKwlh2qie+v8=; b=E1UKa4zTdplceqD8IyUcoWlqgXQnsWVq7UdJK4EEkf1qUcOuGQQ8XIjWgG4BywMlih 11ecv8hPekLn+vi5oZuQ6AEmxq9FA6oKsUecB65szzBWf4I02AzXRi8bMgg6IOnHY9T+ /h0sE5UpGxb9ubtiB1HAsy7GUlMs5ggkIhOziIbK7M9VCkoH2DxJkclaQpg2dgzBphU8 fFfsNLWAMyrY4IXI51//xt1UPGDHLzcfS1QAW0rOkNcN4HBvmvo66Gwnice+7m151PWy BwleXaMp7O14hXY2B7z9C01Z4Zm8vCK/63e6TzlSeH6AfJXjkD9nqG3gNnPRwjR0eytr U3WQ==
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=LY4bLh/QT4GRjkyxazTp2XsI3V+1fiSyKwlh2qie+v8=; b=YWE/vj7G94jQ0AZdUcbYUa62GvN+hA+Kms+BPC5/jb+u3r+H/QDO70It1Ym4jjCm3s 7eIMsOOan6F8RwMStphUgBmydM9m2P+b1xzXhCiRJ5NebBmbIAvrajTO9dEbRMRuSHuj zG9EL91AY52Jv0wDTqDPq1RnBiH/Txi0XzZChgl3BqQ/izP5ZM/RP+QgrKB8tNNXnS7w O7Z/LlGSmTGuzk7peptwlBhEC3rG4VVYNEuvAXst5DoEFNVOjOi/SzNSuOFC6URa3LCl 26jWUnT5CBlqOtT+PTG8aB8SIfkJpbOCETmPv+QleCY7Dh4L7o4q+9I3wkWJjzlpKL+0 TWgQ==
X-Gm-Message-State: AGi0Pubo1qYUGaX5Es/ElosmZHLtoKWFxah+DCRCXNl7cafu1KtWCC+B VcA6o+it9jVX0boIkYIll5ZlhcEQhQl00x8JzOZlOBU=
X-Google-Smtp-Source: APiQypJJ6vMtdezQX7o7J88S4y85FePkN6lxqc4LL11AOjJ0NFJCKxEmz2xl/BO/mFb8iukM38mdAk4N4dBcBhsWwbs=
X-Received: by 2002:a25:e907:: with SMTP id n7mr33168392ybd.85.1587976516037; Mon, 27 Apr 2020 01:35:16 -0700 (PDT)
MIME-Version: 1.0
References: <7320379C-877F-4446-AB71-B4C70FEFA134@lodderstedt.net>
In-Reply-To: <7320379C-877F-4446-AB71-B4C70FEFA134@lodderstedt.net>
From: Filip Skokan <panva.ip@gmail.com>
Date: Mon, 27 Apr 2020 10:34:37 +0200
Message-ID: <CALAqi_9eHXMT5iFKz256uK+tVZq+rU5cy3qwLMwMsm73CKK1Hw@mail.gmail.com>
To: Torsten Lodderstedt <torsten=40lodderstedt.net@dmarc.ietf.org>
Cc: oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000002670eb05a4419816"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/-blxUqjQ0g7pM5poN-rbfviiMcE>
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: Mon, 27 Apr 2020 08:35:22 -0000

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
<https://bitbucket.org/openid/connect/issues/1045/signalling-that-a-request-object-must>),
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
>