Re: [OAUTH-WG] DPoP JWT claims

Brian Campbell <bcampbell@pingidentity.com> Thu, 16 June 2022 22:19 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 273B4C15AACA for <oauth@ietfa.amsl.com>; Thu, 16 Jun 2022 15:19:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.104
X-Spam-Level:
X-Spam-Status: No, score=-2.104 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, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pingidentity.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cP8ifejLkvLh for <oauth@ietfa.amsl.com>; Thu, 16 Jun 2022 15:19:23 -0700 (PDT)
Received: from mail-oa1-x29.google.com (mail-oa1-x29.google.com [IPv6:2001:4860:4864:20::29]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E234AC15AE2D for <oauth@ietf.org>; Thu, 16 Jun 2022 15:19:23 -0700 (PDT)
Received: by mail-oa1-x29.google.com with SMTP id 586e51a60fabf-f2a4c51c45so3521615fac.9 for <oauth@ietf.org>; Thu, 16 Jun 2022 15:19:23 -0700 (PDT)
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=9OpE8wSQo/kA+VaN6HGVCI2cwm1nO81zyUmpG6dNXXI=; b=Mp6kn7uIeNkbrLr8Do3BVwJMDNyKMdA+dZiGxFECGAzmOEk/+qmcnKv9KVHaXNYBvZ hVbmWtKmZ7WSOEniAOKO8iy+HdHajmNnzWFoShtfIGgfZrm/UAGj9O9/K1O3hZBvSV9f Qe30i/l4n7PADblbFrVAHCoUUsiw/0f8DVDNOJYu9wUi/xis2W/xSKnHMzZ5G25Uh2fX ug9n4KaM2an1miGH6cstpSnfX9rHfSeCb9/Z/mUimQfFdxUQVGwbz4aU5yZvqoqtLcVs F0Lzs2QNFEWykzf9JpEtK2oXxGw1oB/M5NVRuMwU8Wm70H+zt0zeGueZrW+hoJZfJHD0 7Cjg==
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=9OpE8wSQo/kA+VaN6HGVCI2cwm1nO81zyUmpG6dNXXI=; b=1OXaQGj9sQXmW5MFYBauvSZohbtzFO1lK/6b61YzsUvnumoouB/xPq4X+fVm8fmhci 49hUhXuMF5ePA00wVGD91sQhjmoUv562Xi5Ok6pOuarjQ/dMaqm8ZgbjqRoEv121YVmC secKzlMnWQisFU/9FTtOIGhkz6xZYIN9ld9SCehEL7dNlNgPcrzCSkbUlN3sSQqTfYbv qAWBiH4QuIzDXONUdzVhNjLllzk/uQmua5XuCF971fik9QDxXvQoCk9fK5lEvhOqBnO3 0O7agKh3YSFUg1kfKUg5LbE3AD2tUTiBslJ+ZqIEjLXYhqBrC1mnXNWCxZV5Ly4naqxC QCWA==
X-Gm-Message-State: AJIora9P4K45MXypVxLfNPBfsuL7d+ZFG97SQS9I9juJM3bqsh8nWrM0 DhHYdUb/Jnj1dsSl69WjmEpc6ZMlMXgCa4NQFOmZ4SSpTwyrnncEA2ChJcvgEn7g7SiWtZ3KaSS LHi7nKfpMtELlJA==
X-Google-Smtp-Source: AGRyM1sxBTJ1DwnHO0Ez3QcmOTdm21GPMmyLGS03u2RbE1Yy4XJMQn+/qpgB5Z+oY1fyBEmkKie4drW4FTsIAfXPm3M=
X-Received: by 2002:a05:6870:891f:b0:f3:3811:3e30 with SMTP id i31-20020a056870891f00b000f338113e30mr9895603oao.269.1655417962420; Thu, 16 Jun 2022 15:19:22 -0700 (PDT)
MIME-Version: 1.0
References: <CAD9ie-siSJZ-8OUFhHKdWY=ZT7r=6GaBAu8LWBs3J4BoqTCtqQ@mail.gmail.com> <86DAF05C-BB10-49AA-8B1B-E19E8A410624@forgerock.com>
In-Reply-To: <86DAF05C-BB10-49AA-8B1B-E19E8A410624@forgerock.com>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Thu, 16 Jun 2022 16:18:49 -0600
Message-ID: <CA+k3eCQnizWdFZgEhT8yO2eb0PSBDP+-d3Wp7p9EnYxF=HuZYQ@mail.gmail.com>
To: Neil Madden <neil.madden@forgerock.com>
Cc: Dick.Hardt@gmail.com, Warren Parad <wparad=40rhosys.ch@dmarc.ietf.org>, oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000009af05305e198072f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/CEEpbCzMwVusn3OTphC7CxnYcBg>
Subject: Re: [OAUTH-WG] DPoP JWT claims
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.39
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: Thu, 16 Jun 2022 22:19:28 -0000

I'm not sure the JWT claims registry has turned out to be exactly what was
envisioned. And, to your point, the utility of some of the registrations is
questionable. The issue of name conflicts vs reuse is more subtle than it
seems. And practically speaking the registry is kind of the only way to
legitimately get/use a short claim name (so called private claim names
aren't ideal and arguably not appropriate for a prospective spec).

There was some sort of related discussion with an AD a while back
https://mailarchive.ietf.org/arch/msg/jwt-reg-review/O4rmJbMOZZFbi6mlVk6VHp-xUs8/
that basically resulted in "just go ahead and register stuff". At least
that was my takeaway.

FWIW there was also some discussion around those very questions with
respect to "nonce" (see
https://github.com/danielfett/draft-dpop/pull/81#discussion_r713354503 and
maybe a few comments back) with some push-back on using it. But the outcome
was to go ahead with nonce but also update the registry via a OIDC errata.
Though I suspect that action got lost in the shuffle. Maybe DPoP should do
it?

On Thu, Jun 16, 2022 at 3:33 PM Neil Madden <neil.madden@forgerock.com>
wrote:

> Is that actually true? The DPoP spec itself is a case in point: it reuses
> the existing OIDC “nonce” claim but explicitly says that DPoP nonces are
> not like OIDC nonces (section 9):
>
> “ Developers should also take care to not
>
>    confuse DPoP nonces with the OpenID Connect [OpenID.Core <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop#ref-OpenID.Core>] ID Token
>    nonce.”
>
>
> The official IANA registration of “nonce” says:
>
>
> Value used to associate a Client session with an ID Token
>
>
> Does this matter? If not, does it matter if some other spec defines a “htm” claim with different meaning?
>
>
> On 16 Jun 2022, at 20:50, Dick Hardt <dick.hardt@gmail.com> wrote:
>
> 
> Registering the names provides clarity on use and avoids confusion on the
> meaning of a claim — ie two specs won’t have conflicting definitions of
> “htm”
>
> On Thu, Jun 16, 2022 at 10:20 AM Warren Parad <wparad=
> 40rhosys.ch@dmarc.ietf.org> wrote:
>
>> I think the registration really helps with discovery, especially as an
>> implementer. When you see or observe these claims in a JWT, you can google
>> them potentially returning no results. If you know about the IANA registry
>> you can find them, even if you don't know that the tokens have anything to
>> do with DPoP.
>>
>> On Thu, Jun 16, 2022 at 6:21 PM Neil Madden <neil.madden@forgerock.com>
>> wrote:
>>
>>> The DPoP spec registers the “htm”, “htu”, and “ath” claims [1]. But do
>>> these claims actually make sense outside of a DPoP proof? Presumably the
>>> risk of naming collision within a DPoP proof is pretty small, so is there
>>> any benefit to registering them rather than just using them as private
>>> claims?
>>>
>>> (I guess I could ask the same question about lots of other entries in
>>> the current registry at IANA, many of which look completely app-specific to
>>> me).
>>>
>>> [1]:
>>> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop#section-12.7
>>>
>>>
>>> — Neil
>>> _______________________________________________
>>> 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
>>
> _______________________________________________
> 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._