[OAUTH-WG] client authentication

Jaap Francke <jaap.francke@iwelcome.com> Tue, 17 September 2019 13:20 UTC

Return-Path: <jaap.francke@iwelcome.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 801FB12006B for <oauth@ietfa.amsl.com>; Tue, 17 Sep 2019 06:20:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iwelcome.com
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 RE0314JY_3_o for <oauth@ietfa.amsl.com>; Tue, 17 Sep 2019 06:20:43 -0700 (PDT)
Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-am5eur02on0621.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe07::621]) (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 364061200BA for <oauth@ietf.org>; Tue, 17 Sep 2019 06:20:42 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FMpIUlgmw0JzsYQTPum3Fr/0zSOZIbbqLuVh4dUWG6Jl2H5AYfeMIkEUOgHH82U2Mh1iFeVOLej9jUqu9yZs1ZaUX2blAv5/zEuSZtOaYChui6dQ1zArCesP3lZa+JwcTxUMXc7tt1EBZKWJJvKCFgI6WIKWBIJGUZguhBYf366nw7gtC4L0ubcZC0V2K8OhlHy2xkN4u0RD2vNcjK6FHSGCzMEgDRCRHN5pj0puQEcgf/FmH9WuyCUPbckV2i2t51I0CeA6das8KEuekTpHtXpr+7+M5o8JrCekcnvsmg0XaiSqssAXc5N4j1aPwFkQEnnAyogkw1XkvtqeuxaVuw==
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-SenderADCheck; bh=KHT83jszM5Jy8nllBpY6bsnN3sr4IJhKaRmPRhD5H90=; b=cEodSpXo1GGrgQJNy4KUbBzlxg1OaDvR2k9ooMCpyAlcRJhmbUG4VPNRpOVBU850kkyulHHMrQYYDnS6MU2N43jdlovxikU0jLgp2NlVJgZhOybHqA2XkAB6ODKCVvGTB01fX49RQpjJ8urTkwIy1EQ8QNarZ7zAoLLYGU9YXLoFqKSVOsA89/2QCM7Vln6rOFP8QTOdFlMEbCLK2X9z0jrhLLa956fUJsZojOJRIWFFfZS1jwx9Vts6WYtwzI7p21uhUHqFEjBD+L20QOhu5g4uBAsG91+WVPxNXXyZYrS4/8GAlBtLhC01N05kQRiTPpE/H2OEQSjCmMFZDGj9iw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=iwelcome.com; dmarc=pass action=none header.from=iwelcome.com; dkim=pass header.d=iwelcome.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iwelcome.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KHT83jszM5Jy8nllBpY6bsnN3sr4IJhKaRmPRhD5H90=; b=KXCZy4p42C9Mrcb5yhkgDektW+eWcndStUjOleW8pYZuv3Vj1FRUn8DaCPsA8rIEuqG7YCCw+PIFQMF7Xm4+Y2mkdGQlEi/pGcA1ffuHtvP8iNmIGEQCT+EdA1osO0FGtU7QgUEUnwlUazEGTwnJ+wpscCb0m+pKt3KegNpGJuY=
Received: from VI1P190MB0317.EURP190.PROD.OUTLOOK.COM (10.165.197.26) by VI1P190MB0559.EURP190.PROD.OUTLOOK.COM (10.165.191.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2263.21; Tue, 17 Sep 2019 13:20:39 +0000
Received: from VI1P190MB0317.EURP190.PROD.OUTLOOK.COM ([fe80::38b1:d48d:fc49:384f]) by VI1P190MB0317.EURP190.PROD.OUTLOOK.COM ([fe80::38b1:d48d:fc49:384f%4]) with mapi id 15.20.2263.023; Tue, 17 Sep 2019 13:20:39 +0000
From: Jaap Francke <jaap.francke@iwelcome.com>
To: "oauth@ietf.org" <oauth@ietf.org>
Thread-Topic: client authentication
Thread-Index: AQHVbVqyFCnAe6TcNUCWhiz8H2uvBQ==
Date: Tue, 17 Sep 2019 13:20:39 +0000
Message-ID: <2425F057-E2D8-46C3-A859-060245C309BB@iWelcome.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=jaap.francke@iwelcome.com;
x-originating-ip: [86.84.216.78]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: c2c988a1-a44a-451c-2471-08d73b71d589
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(5600167)(711020)(4605104)(1401327)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(2017052603328)(7193020); SRVR:VI1P190MB0559;
x-ms-traffictypediagnostic: VI1P190MB0559:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <VI1P190MB05590C176209D16DCE08EE73E48F0@VI1P190MB0559.EURP190.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 01630974C0
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(346002)(376002)(396003)(39830400003)(366004)(53754006)(189003)(199004)(51874003)(256004)(54896002)(6486002)(6306002)(5660300002)(71190400001)(6436002)(6512007)(25786009)(236005)(66476007)(64756008)(26005)(66446008)(102836004)(2351001)(66556008)(5640700003)(316002)(186003)(476003)(8936002)(81166006)(81156014)(2616005)(3846002)(2906002)(86362001)(6506007)(2501003)(91956017)(6916009)(6116002)(76116006)(221733001)(99286004)(7116003)(36756003)(7736002)(33656002)(8676002)(66066001)(1730700003)(66946007)(606006)(966005)(486006)(508600001)(14454004)(44832011)(14444005)(3480700005)(71200400001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1P190MB0559; H:VI1P190MB0317.EURP190.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: iwelcome.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: nr7pHQqvCOgitrpDCKy0oSgQe8k/Gw/7pwbfFVKRGB8ctoopG+pb+WB8W3n6zxMofKjbQULdlC6LHTJYU+WwO6KkAwVOQ602rpA5NX4zWj9p+Eg1pLWOLCksT9QrAUKiRDYV+CtenHx/wRyXS99OB+hTDseECy9I0qC3nsXVHyBBu1ft5uYGEDqz5VroW3M86GFcqOR/MO8it+kX6RUzeXtzpwsAnkpwGK2yVI44Z5Dy8HoTsCDPuqa73ZELcCMEiIZidiDsHBy6j45BVayB5OzSGNbZlA7H1neT6b3yXzUNMJfCm7XMRtwhYxjY1DtzY3hRqTZ96U/qQXjcX4550ypjcyszgT3hNcWFiqxtykGFv13+XVMX7ZaWGbhI5w/n6MX4fiBSPfntbYMDMlpnNCQCPfDrSAJHNirnDKNYHAY=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_2425F057E2D846C3A859060245C309BBiWelcomecom_"
MIME-Version: 1.0
X-OriginatorOrg: iwelcome.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c2c988a1-a44a-451c-2471-08d73b71d589
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Sep 2019 13:20:39.3447 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: d5d41fea-d7e6-42be-b3bb-05610e101f27
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: er7iye4Mkpp988kw5HMg59Uz0Nhe1W4N6oNPno2PcZzH74yVhlUAapK4jrhynasYoYieU5ixj4r+2AULcpIOpGmM/10t+CAJE6/GdKYetmM=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1P190MB0559
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/z-tAswbXSVN9DTZVh-uPkMIIIqc>
Subject: [OAUTH-WG] client authentication
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, 17 Sep 2019 13:20:47 -0000

Hi all,

I was exploring the topic of client authentication in various RFCs.
A few things are not 100% clear to me, I would be interested to get your feedback.

RFC7591 sets up the registry for client authentication methods on the token endpoint and adds:
- none
- client_secret_basic (RFC2617)
- client_secret_post (RFC6749)

I don’t understand why that registry seems limited to the token-endpoint. Client authentication also applies to other protected (OAuth) endpoints such as token introspect, so it makes sense to have a generic (OAuth) client authentication method registry.

OIDC specs indicate a few more:
- client_secret_jwt
- private_key_jwt
Is my understanding correct that client_secret_jwt refers to the same client authentication method as described in https://tools.ietf.org/html/rfc7523#section-2.2 ?

Furthermore there is RFC6750 which suggest 3 client authentication mechanisms which are not included in the registry:
- Bearer / authorisation request header
- bearer / URI query parameter
- bearer / form encoded body parameter
For example, the RFC7662 suggests to use the “bearer / authorisation request header” mechanism as client authentication/authorisation mechanism.
Any reason why this was not done?

Thanks in advance for any related feedback, regards,

Jaap Francke