IETF Logo Mail Archive

Re: [OAUTH-WG] DPoP and client registration metadata

Brian Campbell <bcampbell@pingidentity.com> Mon, 14 February 2022 22:52 UTC

Return-Path: <bcampbell@pingidentity.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 9A52B3A12EB for <oauth@ietfa.amsl.com>; Mon, 14 Feb 2022 14:52:27 -0800 (PST)
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=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pingidentity.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 qnHFdFQWm3zu for <oauth@ietfa.amsl.com>; Mon, 14 Feb 2022 14:52:23 -0800 (PST)
Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (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 4076B3A12E8 for <oauth@ietf.org>; Mon, 14 Feb 2022 14:52:23 -0800 (PST)
Received: by mail-lj1-x233.google.com with SMTP id o9so19446932ljq.4 for <oauth@ietf.org>; Mon, 14 Feb 2022 14:52:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NeYMqytK/iYbCDvpE5sTBNIhVdTiFWMHeLOOQtdvtXU=; b=RHPKdAfOp0vnmr/Av3/WPjQTqUHd7BFffZbSZqCdDPnj4VX8pmS4Ls4MH1YoA1mcj/ HFgDN7xzylFD5dC8NYkL+YmML9C+6b9hkAxG35KM3V3j+Ub2JAXaho/prt5wZ23xjRc+ Uj7DAC+5uaoA5AK/dSoPWmm+Sz3v5YGJyJMPqOYQuucXqnHcgLZVu/FHs2l7u7HI7dif GZjFLIseIrzENYZPC/072zOyXoA/U2LbFzZvejCRJBSQzyi2ctBMTEcG4SCmiWfLrMp0 ZEbzemRHAPvZcbqAWJIxgwOQXGCvDKaraHhZRWmGMe2B7aWp6OhreT3MZVOKYmTHKahq W/YQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NeYMqytK/iYbCDvpE5sTBNIhVdTiFWMHeLOOQtdvtXU=; b=gxhAshv8yPQdZRCuUS38b1hCHSBypB2yx53SlRuy6hO6e56Nl+Ydo1ImPXdES+oIe8 wPUyrhGUxRhCAAcxrSjWai6xxVaWDDXVkzAK1RUQF1XhBS7bLCoFQhYejET1kuqnWeO1 /+kbT9AE8xnrBBlAc0kzilMcWhqmCEXkOdWtxRyI8zrPc/+xnkSaNzZr580ANJGP/FQS phtAK2kklA1FkSbK3XV6Yc5vbs1QuTsuZFdd2UaCysnl8Cs2W/VBpeVfOems33l9+piF PHQrnE/nDT1PzpkRvVcN0Mp8k9Fpj5An5D5YoZmu6LDBzA/ox2bfsaMaApWwsYJ34i5i w3RA==
X-Gm-Message-State: AOAM531+wdLRSxnIDNezpSI3CQB7jmK9wIkeLdL6gY0zaDvecms1EiNt 4x9r9SJxRBYglA4kcTjDvrZQkmFIexk0Hzi4O2Y7O9D1VmaYL8o0AUQKjcoUAVii4+nFRcqwCGh sqw03lzu0RKL1xH2i0jo=
X-Google-Smtp-Source: ABdhPJwkmro4vcfGaUDxQoaXUsVnJr+uua26+IUxTq8/uFgraV6pq1eIem/8cVZL1bNL01XDl3uV45thK7BDtaRiDtE=
X-Received: by 2002:a2e:2e03:: with SMTP id u3mr618964lju.249.1644879140836; Mon, 14 Feb 2022 14:52:20 -0800 (PST)
MIME-Version: 1.0
References: <CAOtx8DkFrDBk==_4Yr8JFiNmPSQkhMnVDk09RGhz_Kb52gMMtA@mail.gmail.com> <CA+k3eCSG0-bjJRsVrgAtVocvRBpwY+7fBxr=WPAYdUBd25g=pQ@mail.gmail.com>
In-Reply-To: <CA+k3eCSG0-bjJRsVrgAtVocvRBpwY+7fBxr=WPAYdUBd25g=pQ@mail.gmail.com>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Mon, 14 Feb 2022 15:51:54 -0700
Message-ID: <CA+k3eCTCjawQx7g8Q+tUwtC7oRCkpev0r-kCuo3n3Xy18XvgVA@mail.gmail.com>
To: Dmitry Telegin <dmitryt=40backbase.com@dmarc.ietf.org>
Cc: oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e37dfa05d80244a4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/sXBTLowQfKYN_9VKErxl1e3ys3c>
Subject: Re: [OAUTH-WG] DPoP and client registration metadata
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, 14 Feb 2022 22:52:28 -0000

This (more or less) has come up again in the from of a github issue:
https://github.com/danielfett/draft-dpop/issues/105 and it has me sort of
maybe reconsidering the idea of introducing some kind of client metadata
that indicates that the client will always do DPoP. So I wanted to bring it
up again here on the list to try and see what folks had opinions on it.

On Tue, Oct 26, 2021 at 4:08 PM Brian Campbell <bcampbell@pingidentity.com>
wrote:

> There are no plans to introduce client registration metadata for DPoP -
> the requirement to use DPoP is more of a property of a resource so I don't
> think registration metadata for a client fits very well.
>
>
> On Tue, Oct 26, 2021 at 8:53 AM Dmitry Telegin <dmitryt=
> 40backbase.com@dmarc.ietf.org> wrote:
>
>> For dynamically registered clients, there is currently no way to indicate
>> the intention to use DPoP. Hence, it's completely up to the AS whether to
>> enforce DPoP or not on such clients (for example, using client registration
>> policies).
>>
>> Seems like there is no common approach here; for example, RFC 8705 (OAuth
>> 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens)
>> does define client registration metadata (see section 9.5), whilst RFC 7636
>> (PKCE) does not. I guess this is due to PKCE being initially conceived as a
>> feature that would become mandatory in OAuth 2.1.
>>
>> Are there any plans to introduce client registration metadata for DPoP?
>>
>> Regards,
>> Dmitry
>> Backbase
>>
>> _______________________________________________
>> 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._

v2.23.0 | Report a Bug | By Email