OAuth terminology - mTLS and Private Key JWT

[elarlang]

#	Description	Level	#v5.0.be
10.4.16	Verify that the client is confidential and the authorization server requires the use of strong client authentication methods (based on public-key cryptography and resistant to replay attacks), i.e., 'mTLS' or 'private-key-jwt'.	3	v5.0.be-51.4.10

mTLS is not a parameter to be between apostrophes. Maybe to write them out full length to be clear?

ping @randomstuff

[randomstuff]

Yes, I agree.

[elarlang]

Ok, in a way this issue is a subset of #2894, but let's solve mTLS and private_key_jwt questions here.

#	Description	Level	#v5.0.be
10.4.5	Verify that the authorization server mitigates refresh token replay attacks for public clients, preferably using sender-constrained refresh tokens (i.e., Demonstrating Proof of Possession (DPoP) or Certificate-Bound Access Tokens (mTLS)). For L1 and L2 applications, refresh token rotation may be used. If refresh token rotation is used, the authorization server must invalidate the refresh token after usage, and revoke all refresh tokens for that authorization if an already used and invalidated refresh token is provided.	1	v5.0.be-51.4.4
10.4.14	Verify that the authorization server issues only sender-constrained (Proof-of-Possession) access tokens, either using mTLS certificate binding or Demonstration of Proof of Possession (DPoP).	3	v5.0.be-51.4.11
10.4.16	Verify that the client is confidential and the authorization server requires the use of strong client authentication methods (based on public-key cryptography and resistant to replay attacks), i.e., 'mTLS' or 'private-key-jwt'.	3	v5.0.be-51.4.10

The private-key-jwt seems anyway wrong, as technical parameter is private_key_jwt. Textual presentation is "Private Key JWT".

[randomstuff]

Shall we say:

private key JWT (private_key_jwt)

[elarlang]

I think those all requires some wording updates as well, @randomstuff can you propose updates for 10.4.5, 10.4.14 and 10.4.16?

[elarlang]

So how to write shortly "OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens" :)

[jmanico]

TLS Client Authetication +1 because it sends a better message than mTLS

[elarlang]

@randomstuff - is the naming update aligned with https://datatracker.ietf.org/doc/html/rfc8705#name-terminology ?

[randomstuff]

@elarlang, The OAuth speficiations use "Mutual-TLS (mTLS)" as a shorthand. In the PR, I've aligned the wording with the TLS 1.3 RFC.

Pros:

• it is the more official wording of the feature;
• it more clearly (and strictly) expresses what it does (TLS is always mutual anyway 😄, it's the TLS authentication which is mutual);
• we talk about mTLS in other places, not only for Oauth.

Cons:

• the "mTLS" shorthand is quite handy and quite widespread (but I have kept it for better clarity);
• Oauth specifications use "mTLS" all over the place.

[elarlang]

I don't have any alternative or better offer here, because I don't know that topic that deeply. My concern here is, that if we used terminology from OAuth-related RFCs for everything else, then it should be applied also to "mTLS" terms - if there is a difference between terminology in OAuth-related RFC and in TLS-related RFC, then for OAuth-related requirements we should use OAuth-related version and terminology.

[tghosth]

It does feel a little confusing to say mTLS and then client authentication. Can you maybe reword to be clear that client authentication is the goal and mtls is the mechanism that allows this?

[tghosth]

Or that mtls allows achieving that along with server authentication as well

[jmanico]

mTLS is a very confusing term and it's been discussed in some standards to change it.

“mutual” implies symmetrical verification, but in practice, mTLS usually means the client proves its identity to the server via a certificate, and that is not really mutual.

[jmanico]

It does feel a little confusing to say mTLS and then client authentication. Can you maybe reword to be clear that client authentication is the goal and mtls is the mechanism that allows this?

I like this move a lot, Josh.

[elarlang]

Mostly updated via #2931, some discussion continues in #2974