Re: [OAUTH-WG] DPoP JWT claims

Benjamin Kaduk <kaduk@mit.edu> Wed, 22 June 2022 02:59 UTC

Return-Path: <kaduk@mit.edu>
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 9D612C14CF1A for <oauth@ietfa.amsl.com>; Tue, 21 Jun 2022 19:59:09 -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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=mit.edu
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 bPDJrQLokOPG for <oauth@ietfa.amsl.com>; Tue, 21 Jun 2022 19:59:04 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3D92C14F74B for <oauth@ietf.org>; Tue, 21 Jun 2022 19:59:04 -0700 (PDT)
Received: from kduck.mit.edu (c-73-169-244-254.hsd1.wa.comcast.net [73.169.244.254]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 25M2wqhM023858 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 21 Jun 2022 22:58:59 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=outgoing; t=1655866741; bh=seGcmbikQlbYeFUBpG7Hjr/LTTPHt6qxQE+5cH+0ZNs=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=UjqLKaBD3u2pZ1e9lysTYk/ZJBz6NqZ7ZvIwrhRDuPtv7WAv68i4OoGlcXWrVe3N3 z/D5qfYyv9QY4ktbrtXb926+2P89vHXx2StFx8p5eHXmMA2wCaYbY4k4rxkEyZf+wL DMVqOnD2Hd90kay/ScrPRJ5gFavRl2srgiy8d06ja30QkYGxoV8+cPLlk8x3RYr2Ot eFbKOa7gaNwrQ7e2enixCItRv51jN8CVhDG6Ee0EE8wbQy6PwSZg1ps0xA2OExlU8k tv5iQvgxyihoh+O9QoczJ1TDfoUNYJonIX3RHc5YtLnvTq2VQMwfeCSVEjdLjwrwPG TmucenLIwuunw==
Date: Tue, 21 Jun 2022 19:58:51 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org>
Cc: Neil Madden <neil.madden@forgerock.com>, Warren Parad <wparad=40rhosys.ch@dmarc.ietf.org>, oauth <oauth@ietf.org>
Message-ID: <20220622025851.GF26442@kduck.mit.edu>
References: <CAD9ie-siSJZ-8OUFhHKdWY=ZT7r=6GaBAu8LWBs3J4BoqTCtqQ@mail.gmail.com> <86DAF05C-BB10-49AA-8B1B-E19E8A410624@forgerock.com> <CA+k3eCQnizWdFZgEhT8yO2eb0PSBDP+-d3Wp7p9EnYxF=HuZYQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CA+k3eCQnizWdFZgEhT8yO2eb0PSBDP+-d3Wp7p9EnYxF=HuZYQ@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/l-eJ2C9tXg5oXz4mySQkSlJgAFg>
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: Wed, 22 Jun 2022 02:59:09 -0000

On Thu, Jun 16, 2022 at 04:18:49PM -0600, Brian Campbell wrote:
> 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).

This is probably the main reason I'm still in favor of registering short
claim names -- people are going to want to use them and it's better to have
most things in the registry than to have completely independent siloed
usage.

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

I think we both (at the time) thought that it's better to have (registered)
claim names that reflect the specificity of expected usage.  We can't
always have nice things, though (case in point: all the existing
registrations), and we're not going to "keep the registry pure" in whatever
sense by pushing back hard on new registrations.  So that's how we end up
in practice with "go ahead and register stuff", though we can certainly ask
people if they want a more-specific name.

> 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?

I do have some general unease about reusing the claim (name) for a
different meaning/usage without updating the registry in some manner.
Consult a current AD for an authoritative reference, but I expect that OIDC
has some form of "change control" over the existing registration and would
need to be involved in some form if this change is made.

As another data point, over in draft-ietf-ace-oauth-authz I made people
create a new "cnonce" claim instead of reusing the existing "nonce" (also
as claimed by OIDC).

-Ben

> 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._

> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth