[OAUTH-WG] DPoP and client registration metadata

Dmitry Telegin <dmitryt@backbase.com> Tue, 26 October 2021 14:52 UTC

Return-Path: <dmitryt@backbase.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 B23913A1238 for <oauth@ietfa.amsl.com>; Tue, 26 Oct 2021 07:52:31 -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=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=backbase.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 0zNooaEWbwTh for <oauth@ietfa.amsl.com>; Tue, 26 Oct 2021 07:52:27 -0700 (PDT)
Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (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 1CB553A123E for <oauth@ietf.org>; Tue, 26 Oct 2021 07:52:27 -0700 (PDT)
Received: by mail-lf1-x136.google.com with SMTP id l13so21615294lfg.6 for <oauth@ietf.org>; Tue, 26 Oct 2021 07:52:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=backbase.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=PA+p4rx/IIZtk89JFA7fGs4nUgoZbtWlMq83fpcK4gA=; b=A/TvHYirTuBWtEMPDP7C/Kmo+tXjBj+1x6FIo26k1SivOOoicosD4QX/Evz1JSQ/fb UoZi5YSvouw9UHvgBTlUiLrteGklt66BCfJ7diI8Heu5HT7Lk36tpv/ZJiG4eBNpP0Dp eeS7jTQrKQ+EUBzwQ97mmeeM5s3j5WPPoVOv/6kfS3zhH1IhK06I/JqcB7GWDmkBYmYr /cNT+ayj/j5AvuwGOGbhIwUa85/6Ow01mUYRBIsXafqnUT0jOsl8y4E57YHkX9VvE1X9 MGl6yNYKdghRLnbd4DAAAnSsJTH4WBLkoGlB93NbvJQTDvSwz9bj9yjxuUObGDxzAfAU WyMg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=PA+p4rx/IIZtk89JFA7fGs4nUgoZbtWlMq83fpcK4gA=; b=pSUIHthfRJLdlGrDXWr6dKDZ7eRrhCKCXsEwBH0AmBzuu0aLUV+IQ+g3V6iAVISV2n sf80kHUuatDzX1STh3hyZrg1dyalFd+TAvl+TBarDNwbzzYvDSm+3fq9SbKLqb1a3o11 tD3OHStvOcGeCd157j8I7qmrU7ht1iuOnzjKn0jlC4hO7sscjEpHtK8NLiQ6HkOofTRH phn2PbXXm/Fy3m34kBV3ZSkcqgWwM8oXbW/sS012HTmi4OFflDb9hRL/7ZRzHaFRWp/4 rMp2X63iwdtMr75xBfODQAx6N2NMWkaethlH+3G48kFUU82HWmCNIfvwDdMAkt8+Folc q3pw==
X-Gm-Message-State: AOAM531lmdqYAOJsrw742rXumOkhWkYftkPfVBh9rFR+Zjx1lJeJ5L1A fu4qs5Hi3UBMQ+omo1QJ1C6wdszBZ/qXglDPvXBsuBiUKiApBw==
X-Google-Smtp-Source: ABdhPJy56WR7I0uOqA+pST7LmywMhd+Kj6RcF7S1kLDSOJWmDsftozhI/5O8HtTCYuyAl31UMduMiYQdxtgJ72wkWvM=
X-Received: by 2002:a19:7609:: with SMTP id c9mr10556593lff.317.1635259940212; Tue, 26 Oct 2021 07:52:20 -0700 (PDT)
MIME-Version: 1.0
From: Dmitry Telegin <dmitryt@backbase.com>
Date: Tue, 26 Oct 2021 17:52:09 +0300
Message-ID: <CAOtx8DkFrDBk==_4Yr8JFiNmPSQkhMnVDk09RGhz_Kb52gMMtA@mail.gmail.com>
To: oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000da368c05cf429f63"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/ReCiilADT4jwVaj7e9bCFerOhuk>
Subject: [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: Tue, 26 Oct 2021 14:52:37 -0000

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