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

[Benjamin Kaduk <[e-mail]>]

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

-Ben