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

Thibault Normand <thibault.normand@gmail.com> Tue, 12 May 2020 07:28 UTC

Return-Path: <thibault.normand@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 B3F4D3A0C98 for <oauth@ietfa.amsl.com>; Tue, 12 May 2020 00:28:09 -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=ham 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 39ZsPJj7Pr-9 for <oauth@ietfa.amsl.com>; Tue, 12 May 2020 00:28:07 -0700 (PDT)
Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (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 7337C3A083C for <oauth@ietf.org>; Tue, 12 May 2020 00:28:07 -0700 (PDT)
Received: by mail-wr1-x42e.google.com with SMTP id y16so6836695wrs.3 for <oauth@ietf.org>; Tue, 12 May 2020 00:28:07 -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=3pmfZFRrha1LCNESYoWcWTBPFnxYfbvySo1wMQw52DA=; b=IT/csqdllg/kqFXbGORiwfAqG3c3b5je/3r9sdkzbXS9wo+kbWEpdOQhzh5IZbMV1B R/eleeNjWu/2OtiQDKaachsmTJgW2+nJI5uGZI9LIrxSYVChSJT7x8wVAJOiku/xFOro IcGySA3ld/3TBb5fOZ1MI+j5mGttXxfBDxlExhPgUwe3L+1aLGMOP0M0liF2RnRjLAm0 Vs2EVRMZCNKfGgCrGjh4qDcN5E21jM4t6+YvUz4OHmXS/TCpB2erTU+DEBH8TUCGoYDk OHRfFjGUIagtsS/IGde5yls/vVk7IdThCig/h+PJvg+ChnEPyDt+mBJrDbJ068f2FmhD p1gQ==
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=3pmfZFRrha1LCNESYoWcWTBPFnxYfbvySo1wMQw52DA=; b=gDZdSseGAFDYVMzy056rj9+WITX8TbJm8chNY1Rzt9/sxQpfn6Z3/9KrPhXm3HUaAq MqY13mBAMcscx0d1v06pi65y1eDaiscbrfbulBP+lalkUB83n++u4qFYJT604Yr4nUY5 BeUJJVk5/3Z4HNGY4fxZtgS+5Gus05OajrVt0rfFbA01XteaEp8N77HmbTu9cE71mu2b 6UiZKh/qwQf7do94vcA7xrcJl1nqG/b3W9JK3mg/B5hm5GsEUK1BPBMWiQDVzi6Yf8qm mshRHt4dlq2iLDAtJqbPNVhMPiJpN0Qj1URUXlqDPTejY8swoY744L/NOx5XmsWqUUaO V3qg==
X-Gm-Message-State: AOAM5316MhLj+dSOT/AAxyQDRxDbcz0G7O1T8Xaw6hIUv4vhjLONIAtO rGnDKOnzOg65KEGZe9hXMkct4m1W5mAWYbsenn0=
X-Google-Smtp-Source: ABdhPJwY5r9L8A2e+HbQGN4M9Qrt8jMPRoDavokzll5q2Bfv1L0l/8XK/tIdmA/5AECwlpsTEC25eAeftzOdkBFMclc=
X-Received: by 2002:a05:6000:ce:: with SMTP id q14mr1065244wrx.105.1589268485679; Tue, 12 May 2020 00:28:05 -0700 (PDT)
MIME-Version: 1.0
References: <DM6PR00MB0682FB5ABDAE909C7156564DF5AB0@DM6PR00MB0682.namprd00.prod.outlook.com> <A00DFA90-F7AB-4E54-AEE0-BCD98C45BF9D@lodderstedt.net> <CALAqi__J_j75mbFo_sU1o+ChreAaD0eBOYMC_EGExJHXXYq_+Q@mail.gmail.com>
In-Reply-To: <CALAqi__J_j75mbFo_sU1o+ChreAaD0eBOYMC_EGExJHXXYq_+Q@mail.gmail.com>
From: Thibault Normand <thibault.normand@gmail.com>
Date: Tue, 12 May 2020 09:27:54 +0200
Message-ID: <CADMp+sLGfPgdhn6BVvQxt=XG5pOoQ6VeDvz5jd7A3rUsigxaEQ@mail.gmail.com>
To: Filip Skokan <panva.ip@gmail.com>
Cc: Torsten Lodderstedt <torsten=40lodderstedt.net@dmarc.ietf.org>, oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000008aaf6b05a56e67e6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/C5vf3vj9pF7xBOFD3sKXh3Yfjl4>
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:28:10 -0000

Hello,

I'm currently implementing a new OIDC server (
https://github.com/Zenithar/go-solid) with restricted features such as PAR,
enforce PKCE, etc.
For other clients, that don't have the support of PAR it would be great to
be able to detect that PAR is enforced by default.

Also, I have a question about using JWT for initial request registration,
I'm enforcing default asymmetric authentication (private_key_jwt, and mTLS
(not implemented yet) with restricted encryption algorithms, if I use the
private key of the client to sign the JWT request registration, and use
client_assertion, it sounds for me like using the same key for multiple
purposes.

Regards,

Le mar. 12 mai 2020 à 09:02, Filip Skokan <panva.ip@gmail.com> a écrit :

> 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 mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>


-- 
Thibault Normand
"Il existe moins bien mais c'est plus cher !"
http://www.zenithar.org