Re: [OAUTH-WG] RFC 8705 (oauth-mtls): RS error code for missing client certificate
乗松隆志 / NORIMATSU,TAKASHI <takashi.norimatsu.ws@hitachi.com> Tue, 16 November 2021 23:05 UTC
Return-Path: <takashi.norimatsu.ws@hitachi.com>
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 255D93A0A6A for <oauth@ietfa.amsl.com>; Tue, 16 Nov 2021 15:05:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.537
X-Spam-Level:
X-Spam-Status: No, score=-1.537 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dRD--jZlQdxm for <oauth@ietfa.amsl.com>; Tue, 16 Nov 2021 15:05:15 -0800 (PST)
Received: from esa.hc514-86.ap.iphmx.com (esa.hc514-86.ap.iphmx.com [139.138.45.249]) (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 464DF3A0A60 for <oauth@ietf.org>; Tue, 16 Nov 2021 15:05:14 -0800 (PST)
IronPort-SDR: +eY70LqWb7pUL0bLKwqdIDryrQ6UtdVCrb9xV2P+qafiVhfwEV9mPTjqkJ3tkIUEmskr13uot0 TgE16PYqtsmLjxXh07rc7BcZrOY4apUO0Y5kRVV5i6cwHLk3hZXNdfGfQT3eYFKdcm5mMaly26 Cf8O3xY7LyxXhRHlYn0cXN7UtMgnf5s+jSmw5aOOIADcbN1q85yNT6VZO3KJClpDcYOfWdvxeC 9m1ZqZKKlPM3LQfsYq6BOOGp4jv+0yDTcdcWh02Ncrv2INjKGfeLDSPt20D4dolFS9cXzX8i+F f6A=
X-IronPort-AV: E=Sophos; i="5.87,239,1631577600"; d="scan'208,217"; a="61452898"
Received: from mail11.maildeliv.hitachi.co.jp (HELO mail11.hitachi.co.jp) ([133.145.228.58]) by ob1.hc514-86.ap.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Nov 2021 23:05:11 +0000
Received: from mlsv7.hitachi.co.jp (unknown [133.145.228.43]) by mail11.hitachi.co.jp (Postfix) with ESMTP id E9C2FC002E; Wed, 17 Nov 2021 08:05:11 +0900 (JST)
Received: from mfgw12.hitachi.co.jp by mlsv7.hitachi.co.jp (8.14.4/8.14.4) id 1AGN5BGZ008154; Wed, 17 Nov 2021 08:05:11 +0900
Received: from GUjpTKHDCemcs06.global.hitachi.net ([158.213.210.115]) by mfgw12.hitachi.co.jp with ESMTP id n7VnmuPQBN1lmn7Vnmk6sd; Wed, 17 Nov 2021 08:05:11 +0900
Received: from GUjpTKHDCemcs07.global.hitachi.net (2002:9ed5:d274::9ed5:d274) by GUjpTKHDCemcs06.global.hitachi.net (2002:9ed5:d273::9ed5:d273) with Microsoft SMTP Server (TLS) id 15.0.1497.26; Wed, 17 Nov 2021 08:05:11 +0900
Received: from JPN01-OS0-obe.outbound.protection.outlook.com (74.107.156.4) by GUjpTKHDCemcs07.global.hitachi.net (158.213.210.116) with Microsoft SMTP Server (TLS) id 15.0.1497.26 via Frontend Transport; Wed, 17 Nov 2021 08:05:11 +0900
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PWfv0HMFk2WAHw21EZhJcOLI+y6aCisaxN9O6IF6gEMD68elktoxMPsvpNUTDMNkRMmpWVqMqDf+wacJ3MY0rslab5RX+OyUO8y9Pfc9pgkadag3DHlH2MkVmy8KwSpXpdEJWKE+1v3ucBpyBOrz86Abk4KHtCaoHsT+4560VXFOArEHA0LnyBlYe0PJJWP1h98whNibzM+EjluT4ZR4aZzRk+7MLzBQ1arBi1alks986/1UzOcsPDdAIYDYYrnrzLC47vX0KYUFAjJuOale2Pp3aoNxlPRWlv88SwEcjI49u18sEt2+ZrfJQciibZQbB0d++8dXCo/kGDIgTjFrgw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=NcCgHlg4qkg84EcX6MJ/rZgm1ULrvEXWY6S2UVhtx4o=; b=S+AoW8YH4hxhNtT9CCfEUNO07e4vcaiRKFgDwfUyILKcOD16jATRtajzpAhGgqvugl16ZOP2toQS2L71faNVsfKWvH9/e5I0aUUfuoK0hnUW/nXdvftMeAqEJ3xDvcql5dV9tnzB2S4RuKRQGgrDRDOJCRNz0iWkorKa+fFqLfjmfv1wBuSpTKGxH7A1EICxAsYEu6wHXSElFWsreescj6AYmFtp526tSPHJ9GnzEBz9SoPyl9q+Lha7ZQjQHF6YVeF+hYaZbqD5TxkRSQr6csEIqJOlOWcFUozuk8oJhwMLXIOCfOF2QJFXs6O06il4NKyQDtT6P1Lqg3LikyFkBQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=hitachi.com; dmarc=pass action=none header.from=hitachi.com; dkim=pass header.d=hitachi.com; arc=none
Received: from TYWPR01MB7282.jpnprd01.prod.outlook.com (2603:1096:400:c7::7) by TYCPR01MB8128.jpnprd01.prod.outlook.com (2603:1096:400:102::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4690.27; Tue, 16 Nov 2021 23:05:05 +0000
Received: from TYWPR01MB7282.jpnprd01.prod.outlook.com ([fe80::ac7c:afc6:1d4e:5bbd]) by TYWPR01MB7282.jpnprd01.prod.outlook.com ([fe80::ac7c:afc6:1d4e:5bbd%6]) with mapi id 15.20.4690.027; Tue, 16 Nov 2021 23:05:05 +0000
From: 乗松隆志 / NORIMATSU,TAKASHI <takashi.norimatsu.ws@hitachi.com>
To: Justin Richer <jricher@mit.edu>, Dmitry Telegin <dmitryt@backbase.com>
CC: oauth <oauth@ietf.org>
Thread-Topic: [!]Re: [OAUTH-WG] RFC 8705 (oauth-mtls): RS error code for missing client certificate
Thread-Index: AQHX18mLfiN0PpgYKkWKMQfQ9C3ABawEySyAgACCiaA=
Date: Tue, 16 Nov 2021 23:05:05 +0000
Message-ID: <TYWPR01MB7282464DEC94611BFA28760BCE999@TYWPR01MB7282.jpnprd01.prod.outlook.com>
References: <CAOtx8Dk5f9dLT=mF4_G3ytTm4BzjYxohHVbc27R0nikiQxsdsA@mail.gmail.com> <CAOtx8D=6yEjTEVkx7LnaWk_FYrW80+KxhskGjreQs8X0dnVsnA@mail.gmail.com> <F15CE2F2-1B9A-4201-900E-7BD06AFF3E41@mit.edu> <CAOtx8Dka=FowfTD+ApviDq2-dHaE9offkUKFQqssU7spJWLaLg@mail.gmail.com> <05885557846748b085d67aabd360b04f@oc11expo18.exchange.mit.edu> <CAOtx8DmMiczRTsoQ52YvJZa+j07uRzb-EXu_UO_TYEzZHSe+Tw@mail.gmail.com> <6266B16D-1FCD-4747-B2E6-9893A967B248@mit.edu>
In-Reply-To: <6266B16D-1FCD-4747-B2E6-9893A967B248@mit.edu>
Accept-Language: ja-JP, en-US
Content-Language: ja-JP
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=hitachi.com;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 13d4e511-67b0-4cd7-8378-08d9a9558758
x-ms-traffictypediagnostic: TYCPR01MB8128:
x-microsoft-antispam-prvs: <TYCPR01MB812899B795F9A6C2B42B0812CE999@TYCPR01MB8128.jpnprd01.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: UbNVASt7Wo3Gzfgz76eJdZ/JbAqB20EwwUt4C3bSSNwDDMHdvVT2f787O2BIA8nEC4PbSiym02p4b4wQuuSs1GwElfuKgRTOnbn7X3GS1lSsbO26eQA6DHGgeQS24WALyGfyI5LxpGLD68CFfQOfUjjl4Qy4ctZ2p3i/N9DYMlZ7Urdw+h4gnNeI9UrQFsZJr+CKzsn6vu3//Le8YN3lENMAwcYKo4qSiwZUR5i4ogMmnYRYnWZQbeKf8tB7cojHEfpwZP5KirIYmSdBq7rrpKsWKH+pAe1QNPw3XoXMEB68nqZO+KYCU7c7x+FXsHBLywJyGD5iR1T38uxLNiOJMzBeyYhBM3Z5OtMOr12vJ2ZVHrlNqDqvbqULLK6+Mr9yQ1UxvU41cIEOL1/cwkF88FoWYmQPnwIi/Z1G3qJ4UzK/bF1a5xEXNG0ZjYvODsoK6PtCT2H8jTU8kwE+DBdGJ6Zn+ZePiUCnn5PQORSNp5vIxWK6R3c8CQagJPMWizXFZA4meYU2ukW8mAeNcDTc5PPhOretdfIYOx/0ug1FPgiWjn8wgpQgRYc+b3YxIUq6oZFROC4xcrw0w7n6/+YDCB7IERfzg0vgvKpOBrQUBdH5GQKk5faYYnY7nKiP6YrO3dfgv9+Ns1JiT7978HQnZdO74Do7r4lm9wWuu7ViBMJBz0U2cnwHU+8IN+y+IN21rgLiAANLjl4fR2eNhCiCv0b6imSiy/Yvq1LKvOgfFvQuSknO5XuMQsLBQJp+sA+kQIom1hsrUzryME4juCIe0a+QPGgLo6ut6eIkCQLtj3k=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:TYWPR01MB7282.jpnprd01.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(166002)(66476007)(55016002)(38070700005)(9686003)(66556008)(64756008)(66446008)(83380400001)(8676002)(66946007)(8936002)(71200400001)(316002)(86362001)(82960400001)(76116006)(33656002)(5660300002)(122000001)(38100700002)(966005)(110136005)(508600001)(26005)(186003)(6506007)(7696005)(4326008)(53546011)(52536014)(85182001)(2906002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: 1/reC3zYbimXYr2a8Q9wUfm1Cmul8ITV/ELHkEF5RS00zto0qZhgpy3AE5DnfM5fKtFKkHIIS9tUaP2rCrbe7x21ynzHG2WQBD6QTRBVMKOGz1nv+nOVcFBhrsvIzPfHW8uCjB8OjwbPIa0PJZnr+hLjsP7sXl+frSeM8+456COkdk+VjyAbQ03qDM8rG7Ud6c6uDCdo2c+T5R59rZbAIhU7aETCUKQ3+VjelUNRhpe4MIxqqf6773JZpTIoSYo9bYrSzkO6StJPQWig/kLf3+o7+Obp3rD/y9rzuNKAGbQDLEDhyWCWr/vDXUM8qdaUNuOXX+AqvreGdmTsGoYfwG+PMcn9X4tWcDAj3ApbXZHh86uRrvlD5glpQTEzs4T+ashIkBnqWP/aq1G9fZvwcMwF0dFvDmSCK+DeHc1Z332ndhqwhsk2dqsSP3/bPCzT3DdTnOvFkPXV6r5ckBZqgq+K2GsNry+haCnO2x8IrjBbjUb3H+MNBorbwgKiIOXjxa41qayagn0dNAW4S2fcG4TriMVZ/mc95ehk5G/tPKTaouns5u5YbUPv2WrfGkPpyK2OSeGXrJInbP1FZ0VkfFHXnL4eTS1KVVpFahW2KdWkqGRJTfhr6GhmvVY+yE+HYMu4WpyXQFkNFhvoRMon8u7ml4t6WHh728Pf+iLkmVbyndVDWc1dr+/gEuTRAAi/8f3HIC+yH/0hHT/qKO0p3lxWgP5PL3Wv9WrWc9VuYyba1JaZEPViVX1KrK1GRIFb6gEpVgjPBTyHjKMm8OdMJtVG+BnnHAWcjK8h7QYxfPAHq/8DCjpKIb9eIwFtsQDqMhuqURhSvR0TwtoTqMi50dXZUUSMW0fI/0+hE/oDTs4Ehxb5swyjBk3IlY234daJZj1rmEsahvX9sANkNN35xEZmoT7p/4jPJvDT1/yYm30c8Ip1vtjnVH4lymlN3XLESElXk6MKCXeVwrj+2Tv3k+OHLrrsOtaBJ6x/r2yY1XtlrcmqoCpPdFSlhn/5PthBYzsZA3NvYtY9Bd1FzS3IWAj4Z5MLoMtn0lATU1rTpnrqBcIdb1v29diY9w76rRxn2x+G1tK3D9WpnqHhsDvh/8qk5P6Sslf3H0XSiPLh2xaSi7EBSQkCq3CVLeGj7vSIhgj+5X1fQ00ItUbgoECvTka4TND2Mvs+EwrXhOcEV8Vd3g8PEokEYMDhcGVwh7LV5Qe8IN5irfermixvQVeOIwh2buz2d22yrNQ7w5QdbQEyzS70yX7XEcmv7scAmpN20yqmdhNFA4ZaH7d3b8l8f4K4xptnuT5bsEyryCEAsvwYxgGPC0aBe4vpS/VqCDmasEUoe16ZvqR8FYtWxZKYhzN44RhHVOGk2rWrRPLqBvQLdTqy0QB7sVFjT7Z+fqy3PSRvvDO/B/Yqyux7IyqW+eePubppIp/8FiwcCllAcLdYNI6RaIckAu5WNSs2EyXibs7DN3w1C4MquPUrcFbzEBKDJ30TnnzuZeBHFTq7HqaZB/JsQlZzl2T0tt8hOmSWF9LfkQuamanapvku5tkvkzI8R+iHJUgSPHSwjRkq/NRUT+kMNAlsWlWwZXQmjd99/ej7Mofj1R7mlhoDZuq7rpLPrGLWlKAWiREx+wr+BYlXs9LqkA3Wb5Asn5CtRsAootzdHbhvT3F5FTVeFOAavtZN7kfde1u2nW3FL2yZR4KMGHMI+tF/LxgLxTH4izes
Content-Type: multipart/alternative; boundary="_000_TYWPR01MB7282464DEC94611BFA28760BCE999TYWPR01MB7282jpnp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: TYWPR01MB7282.jpnprd01.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 13d4e511-67b0-4cd7-8378-08d9a9558758
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Nov 2021 23:05:05.6261 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: f54277c9-dafe-44aa-85a4-73d5c7c52450
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: Sq3C4WgmzI0tQyL3gT6pMlkS1BjRsAwTS0ZsQETNelLIa/iZZuHcI5n40B9IVksiED3nUDUOStakIt6LEyVF5q0L7X6gldzLzPtnRfJ0tqD20gZQ3akcoPtNbxbLV2ou
X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYCPR01MB8128
X-OriginatorOrg: hitachi.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/PQP1bnnzMTYwfd4wyz_yFnWP_AY>
Subject: Re: [OAUTH-WG] RFC 8705 (oauth-mtls): RS error code for missing client certificate
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 16 Nov 2021 23:05:20 -0000
Hello, Considering that several technologies has emerged for realizing sender constrained tokens (e.g. holder-of-key bound : certificate bound by MTLS, DPoP, etc ... in the future), it might be good to show which kind of technology is used for sender constraint token explicitly with Authentication header value if there is a chance that RS allows several technologies for sender constrained access token. Regards, Takashi Norimatsu Hitachi, Ltd. From: Justin Richer <jricher@mit.edu> Sent: Tuesday, November 16, 2021 1:18 AM To: Dmitry Telegin <dmitryt@backbase.com> Cc: oauth <oauth@ietf.org>; 乗松隆志 / NORIMATSU,TAKASHI <takashi.norimatsu.ws@hitachi.com> Subject: [!]Re: [OAUTH-WG] RFC 8705 (oauth-mtls): RS error code for missing client certificate On Nov 12, 2021, at 8:30 AM, Dmitry Telegin <dmitryt@backbase.com<mailto:dmitryt@backbase.com>> wrote: Just to make sure I understand the process, is it going to be something like draft-XXXXXX-oauth-mtls-rfc8705-bis -> draft-ietf-oauth-mtls-rfc8705-bis -> new RFC that will obsolete the current one? CCing my colleague Takashi Norimatsu who worked on MTLS holder-of-key for Keycloak, perhaps he has more ideas for improvements. That’s the most likely path if it happens, yes. And that’s if the WG wants to make that change, which would break things. As for this stance: The MTLS draft also re-uses “Bearer” as a token header, which is also a mistake in my opinion. Did you mean the re-use of the "Bearer" scheme for the Authorization header and WWW-Authenticate challenge? If so, and if we decide to introduce a new scheme, I think this would imply a new value for the "token_type" token response attribute as well. I actually meant the use in the “Authorization: Bearer <token>” header, as well as the token type. In my opinion both of those should be something other than “bearer” because it’s not a bearer token, it’s TLS bound. The argument in the WG at the time was that it would allow easier upgrades from existing implementations. I personally hold that this decision allows for more dangerous downgrades instead. 🤷♀️ — Justin Of particular interest to me is the question whether different binding mechanisms (DPoP, MTLS) could co-exist, or should they be mutually exclusive; this deserves a separate thread though. - Dmitry On Thu, Nov 11, 2021 at 10:22 AM Justin Richer <jricher@mit.edu<mailto:jricher@mit.edu>> wrote: 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. -Justin ________________________________________ From: Dmitry Telegin [dmitryt@backbase.com<mailto:dmitryt@backbase.com>] 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 <jricher@mit.edu<mailto:jricher@mit.edu><mailto:jricher@mit.edu<mailto:jricher@mit.edu>>> 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 <dmitryt=40backbase.com@dmarc.ietf.org<mailto:40backbase.com@dmarc.ietf.org><mailto:dmitryt<mailto:dmitryt>=40backbase.com@dmarc.ietf.org<mailto:40backbase.com@dmarc.ietf.org>>> wrote: Any updates on this one? The missing certificate case looks more like "invalid_request" to me: invalid_request 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 <dmitryt@backbase.com<mailto:dmitryt@backbase.com><mailto:dmitryt@backbase.com<mailto:dmitryt@backbase.com>>> 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<https://datatracker.ietf.org/doc/html/rfc6750<https://secure-web.cisco.com/1o_2s-Gspt8sfupLKDuTsMUX0mq2oJBpOmhZGA15-xGMgZFiTepx6JeXQohQQs-Glnj09iZyh6bzIPoQDrizWlLZBsH-6nxwkLrjVuMHBrgVmb0xqFr2O9pc9oRLu2KFZ2VqpLc7Pkf_IxyVbW0CW5OI_dBUr_LFaRcZPhnfQbeXcYZHRMzwtikk1ositkwgcSYqfKsn8uZWaYQipspFXiyB4xgg891fgojvsQuvMi5ZWKELavcBAjh8KQzxhSIHLk0q4XdaUWI325xXswKFR8DW2eFWf2G_LHg2fVEbDayTFBmjpLpm_nuhESWkdHuDH/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc6750>>] 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. Thanks, Dmitry _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org><mailto:OAuth@ietf.org<mailto:OAuth@ietf.org>> https://www.ietf.org/mailman/listinfo/oauth<https://secure-web.cisco.com/1DcCIzbtbXNIKMHxsgjNGi4azyXC-apZRqf390H1ZxBHQkpGwvQjJIVhO420OXxNCSzpXIvFNgkcV93HKWRmsyNWztAipkXMP4u3UXu4pmv0uXcaK-fyPec9nZTunr_08LsLBX76KocDJk5Wc5DBrwq5yArl6n3HqqsfaLRsSER5VsPcjBjGexgiccHaFhG6NTErbU7WRvY-X8xULLdpL7A-TvykYVndXf73heLo0JZ_fymjUvmMIC3_Seqq34Ta2b5LZRSjClmtcKSi75m2lpaEGrX5C1vGENl7mIH0PaelRR2cqxh7E3HNTwBxxYSe0/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth>
- [OAUTH-WG] RFC 8705 (oauth-mtls): RS error code f… Dmitry Telegin
- Re: [OAUTH-WG] RFC 8705 (oauth-mtls): RS error co… Dmitry Telegin
- Re: [OAUTH-WG] RFC 8705 (oauth-mtls): RS error co… Justin Richer
- Re: [OAUTH-WG] RFC 8705 (oauth-mtls): RS error co… Dmitry Telegin
- Re: [OAUTH-WG] RFC 8705 (oauth-mtls): RS error co… Justin Richer
- Re: [OAUTH-WG] RFC 8705 (oauth-mtls): RS error co… Dmitry Telegin
- Re: [OAUTH-WG] RFC 8705 (oauth-mtls): RS error co… Justin Richer
- Re: [OAUTH-WG] RFC 8705 (oauth-mtls): RS error co… 乗松隆志 / NORIMATSU,TAKASHI
- Re: [OAUTH-WG] RFC 8705 (oauth-mtls): RS error co… 乗松隆志 / NORIMATSU,TAKASHI
- Re: [OAUTH-WG] RFC 8705 (oauth-mtls): RS error co… Justin Richer