Re: [OAUTH-WG] RFC 8705 (oauth-mtls): RS error code for missing client certificate

Justin Richer <> Thu, 11 November 2021 07:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 550D83A0CE0 for <>; Wed, 10 Nov 2021 23:22:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LDoV_vHsD8BN for <>; Wed, 10 Nov 2021 23:22:29 -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 8A7E63A0CEE for <>; Wed, 10 Nov 2021 23:22:29 -0800 (PST)
Received: from (W92EXEDGE3.EXCHANGE.MIT.EDU []) by (8.14.7/8.12.4) with ESMTP id 1AB7MOhA021733; Thu, 11 Nov 2021 02:22:25 -0500
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1497.26; Thu, 11 Nov 2021 02:22:21 -0500
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1497.23; Thu, 11 Nov 2021 02:22:24 -0500
Received: from ([]) by ([]) with mapi id 15.00.1497.023; Thu, 11 Nov 2021 02:22:24 -0500
From: Justin Richer <>
To: Dmitry Telegin <>
CC: oauth <>
Thread-Topic: [OAUTH-WG] RFC 8705 (oauth-mtls): RS error code for missing client certificate
Thread-Index: AQHXsNIOipjTaE3tXUKJVibEnI97z6v9fl4A//+t8ICAAIkRAIAAglBx
Date: Thu, 11 Nov 2021 07:22:24 +0000
Message-ID: <>
References: <> <> <>, <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [OAUTH-WG] RFC 8705 (oauth-mtls): RS error code for missing client certificate
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: Thu, 11 Nov 2021 07:22:34 -0000

Only if this working group wanted to take up the work of making a new revision of the standard, but I haven't seen any indication of desire to do that here. One possibility is for you to propose an update as an individual draft to the group here. 

From: Dmitry Telegin []
Sent: Wednesday, November 10, 2021 1:34 PM
To: Justin Richer
Cc: oauth
Subject: Re: [OAUTH-WG] RFC 8705 (oauth-mtls): RS error code for missing client certificate

Thanks for the reply. That makes sense.

Given that MTLS is not a draft but rather a proposed standard (RFC 8705), do you think there is a chance the changes you proposed could land in MTLS one day?

On Wed, Nov 10, 2021 at 6:24 PM Justin Richer <<>> wrote:
This is just my interpretation, but this feels more like invalid token, because you’re not presenting all of the material required for the token itself. The DPoP draft has added “invalid_dpop_proof” as an error code, which I think is even better, but the MTLS draft is missing such an element and that is arguably a mistake in the document. The MTLS draft also re-uses “Bearer” as a token header, which is also a mistake in my opinion.

But given the codes available, “invalid_token” seems to fit better because you aren’t messing up the request _to the resource_ itself, you’re messing up the token presentation.

 — Justin

On Nov 10, 2021, at 10:17 AM, Dmitry Telegin <<>> wrote:

Any updates on this one? The missing certificate case looks more like "invalid_request" to me:

         The request is missing a required parameter, includes an
         unsupported parameter or parameter value, repeats the same
         parameter, uses more than one method for including an access
         token, or is otherwise malformed.  The resource server SHOULD
         respond with the HTTP 400 (Bad Request) status code.

On Fri, Sep 24, 2021 at 2:23 AM Dmitry Telegin <<>> wrote:
>From the document:

   The protected resource MUST obtain, from its TLS implementation
   layer, the client certificate used for mutual TLS and MUST verify
   that the certificate matches the certificate associated with the
   access token.  If they do not match, the resource access attempt MUST
   be rejected with an error, per [RFC6750<>], using an HTTP 401 status
   code and the "invalid_token" error code.

Should the same error code be used in the case when the resource failed to obtain a certificate from the TLS layer? This could happen, for example, if the TLS stack has been misconfigured (e.g. verify-client="REQUESTED" instead of "REQUIRED" for Undertow), and the user agent provided no certificate.


OAuth mailing list<>