Re: [OAUTH-WG] Proposed changes to RFC 8705 (oauth-mtls)

Benjamin Kaduk <> Sun, 12 December 2021 01:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EDADE3A00E5; Sat, 11 Dec 2021 17:29:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.499
X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 67S-IkLcTcav; Sat, 11 Dec 2021 17:29:22 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4A80B3A00D3; Sat, 11 Dec 2021 17:29:21 -0800 (PST)
Received: from ([]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by (8.14.7/8.12.4) with ESMTP id 1BC1TDwe028904 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 11 Dec 2021 20:29:19 -0500
Date: Sat, 11 Dec 2021 17:29:12 -0800
From: Benjamin Kaduk <>
To: Warren Parad <>
Cc: Justin Richer <>, oauth <>, Dmitry Telegin <>
Message-ID: <>
References: <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
Archived-At: <>
Subject: Re: [OAUTH-WG] Proposed changes to RFC 8705 (oauth-mtls)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 12 Dec 2021 01:29:26 -0000

<soapbox warning>

On Thu, Dec 09, 2021 at 09:59:58PM +0100, Warren Parad wrote:
> If we want to signal that the token should be used with mTLS and not
> without, that to me says "claim" as "*mtls: true"*. Further, Bearer says
> "use this as is, it doesn't need to be modified", the token doesn't need to
> be modified to use it with mTLS so Bearer is correct.

I can see how you might read Section 7.1 of RFC 6749 as saying that
"bearer" refers soley to "simply including the access token string in the
request".  But if you go follow the reference to RFC 6750, it's right there
in the abstract that:

   [...] Any party in
   possession of a bearer token (a "bearer") can use it to get access to
   the associated resources (without demonstrating possession of a
   cryptographic key).

I.e., if a token requires proof of possession of a cryptographic key in
order to use the token, it's not a bearer token.
So I really don't see any evidence to support a claim that the original
intent was for Bearer to be used even for PoP tokens.
That said...

> I really wish we would stop trying to create different token values for the
> part of the Authorization header string that comes before the token. Having
> DPoP token type is bothering me as well, do we need it there, probably not,
> but that's not this discussion. At this point we should consider the
> *token_type* functionality fundamentally broken, and realistically a
> vestigial piece of OAuth that neither offers value nor should be reasonably
> used for any purpose. If so desired, then let's put the mTLS signaling flag
> as a claim where anyone and everyone can see it without having to magically
> know what protocol was used to convey the HTTP message to the RS.

... this part may still be true, in practice, given the current deployed