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

Torsten Lodderstedt <torsten@lodderstedt.net> Fri, 01 May 2020 09:51 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 98CF33A0DBF for <oauth@ietfa.amsl.com>; Fri, 1 May 2020 02:51:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, 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=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 6HWEC8pTZuuo for <oauth@ietfa.amsl.com>; Fri, 1 May 2020 02:51:34 -0700 (PDT)
Received: from mail-vk1-xa35.google.com (mail-vk1-xa35.google.com [IPv6:2607:f8b0:4864:20::a35]) (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 B79F73A0DA5 for <oauth@ietf.org>; Fri, 1 May 2020 02:51:34 -0700 (PDT)
Received: by mail-vk1-xa35.google.com with SMTP id 10so2577459vkr.7 for <oauth@ietf.org>; Fri, 01 May 2020 02:51:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=B0w6yoQObMyI4f+GeMw+DXT5m5SCvnQ4/wOuCX1+LRQ=; b=6BRdP2m5TiisnoiEUONMO0TT117jvLx6+kv3/tg+1104zXR0ZjPNXjRzNukJlN1fuV +DQRzme9hkUDQsluBA+ViJITL844PJmIm3ZAswnRjqj0mAdnURlagsvePilzWf0RM+88 wIOQCtrIXLGFSmQznRQwrO+Wll1M5qQa1JtAeKio3+268954VDsy1NLMSa1L4rQaGS3u xiqy3uQWlHoeZxy6BHjgkHe3fY1yOHkgJDmmJi/+7x/tyRLTYurII3FY0nWdUanbMagA 8/OWJ362QuqD/PKsvIZ/JGkbj4FFw94PhWSIyKLNvTJUPE52VOpxFqvmsXXHqE24bdG5 +dFQ==
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=B0w6yoQObMyI4f+GeMw+DXT5m5SCvnQ4/wOuCX1+LRQ=; b=nJYYog6nUmaJ380VC/whzScRVnwJCkw3zOJib7giKh2cWXvrR1xOiJsqcD9yE1c5IV q6NqRzi/KGbHTibiquvePenrgW0XsKnm6FRJrCRCdbI6XpajfyviyK/Wt6q6apIzZI03 CF32f71dZWS7JzN4wG/XYAfRJZkTpnjblFM2sGWVENFqLw+R7wVkN8tKoCIhekguHSqd UGkIAnH2/cDeHXpKnJSnPuaIOBPom2ATgQvLZ6bQl1tvfKTdRhJ1V9CK9mlHVN04T6wl 86lcuXAEkAwgNimyMpSaUfgv+IzN5jdopEd+kePqxM+fyvGec5uwpESh1b++BDMx6cd+ i9vQ==
X-Gm-Message-State: AGi0PuYyzmjyPsZ6fM+QwJhITWJ7LtpUmzI5xGXNy43kuR6FVZnCqyKN fkM67O+XpFp/alK0FKUO7m+GGUOvQlNjCX9Uo7ce8w==
X-Google-Smtp-Source: APiQypLYc6tfB5XTUiRuVqsDqK3YUkdG3s/3e/PtbbQPpH17cahWsVH1Y2k/1IvM96uhShlopCjYIsG6M+n7PGsrmQc=
X-Received: by 2002:a1f:5cd5:: with SMTP id q204mr2041840vkb.21.1588326693749; Fri, 01 May 2020 02:51:33 -0700 (PDT)
MIME-Version: 1.0
References: <7320379C-877F-4446-AB71-B4C70FEFA134@lodderstedt.net> <CALAqi_9eHXMT5iFKz256uK+tVZq+rU5cy3qwLMwMsm73CKK1Hw@mail.gmail.com> <CA+k3eCRyAu-VQ3JkeHW6nivqJ-RutLkEe7FnCCr8i8RZteDaCg@mail.gmail.com>
In-Reply-To: <CA+k3eCRyAu-VQ3JkeHW6nivqJ-RutLkEe7FnCCr8i8RZteDaCg@mail.gmail.com>
From: Torsten Lodderstedt <torsten@lodderstedt.net>
Date: Fri, 1 May 2020 11:51:22 +0200
Message-ID: <CAHOkhHE+Hthq19NBjFGEbtcMAXQ6oj5pfEfpKD9vBuHZUOqLLw@mail.gmail.com>
To: Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org>
Cc: Filip Skokan <panva.ip@gmail.com>, oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000005e60bc05a4932062"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/TDAPAS7aqTFnSZJYH-pgjk2_ma8>
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: Fri, 01 May 2020 09:51:44 -0000

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
>> <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
>>>
>> _______________________________________________
>> 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.*