[regext] Federated Authentication for Machine-to-Machine Interactions in RDAP

"Hollenbeck, Scott" <shollenbeck@verisign.com> Wed, 27 July 2022 21:48 UTC

Return-Path: <shollenbeck@verisign.com>
X-Original-To: regext@ietfa.amsl.com
Delivered-To: regext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 624CEC13CCDF for <regext@ietfa.amsl.com>; Wed, 27 Jul 2022 14:48:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UkMhm4Ev-Ygh for <regext@ietfa.amsl.com>; Wed, 27 Jul 2022 14:48:27 -0700 (PDT)
Received: from mail3.verisign.com (mail3.verisign.com [72.13.63.32]) (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 97432C157B5E for <regext@ietf.org>; Wed, 27 Jul 2022 14:48:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=1017; q=dns/txt; s=VRSN; t=1658958509; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=qCmsXo6XTKcsUd1OXDXzcx8JMcfVGuV2Mv2EmbiYyGg=; b=aHhGKWMLaSXq9m/bRaZKnApq6Wd1gKDE0Zi8iBDd+0vTqHRuBeOEIsCN MHJLDB7VO+2ixqXfz6g7xCOOiUHEIGyx2MyY+Bx2g8dRxy9lcngZ8yuxo SmOMAYNFWQcxW06LAlLaHYHpejVPfxo2Jmo2HiSWMYR5axctqysOFHeFP rhSlFitJ3X52FVsoCnEC5AQHzyWZUe6sN84S+yJM0/dYYOyn6vcm6cl1C Ydv5cG5orQS/ki4sUBwOrSWi5IiIEQMU9MTrqBu+Liisl5v9ip1E97Jga kFBpr6UlDCRIhlzTpdYSzYzEYYtwWspNO1VwgH1/rHWG5M655sqgvTzYG g==;
IronPort-Data: A9a23:BEYKeqD56Wo5WhVW/5zhw5YqxClBgxIJ4kV8jS/XYbTApDwh1GdUz GtLUDyEMvneM2X9fIt0a4Xg8ElUsJDQzNRkTANkpHpgcSlH+JHPbTi7wuUcHAvJd5GeExg3h yk6QoOdRCzhZiaE/n9BClVlxJVF/fngqoDUUYYoAQgsA14/IMsdoUg7wbRh3dQ32YLR7z6l4 rseneWOYDdJ5BYpagr424rbwP+4lK2v0N+wlgVWicFj5DcypVFMZH4sDfjZw0/Df2VhNrXSq 9Drl+jlozyDr3/BPfv++lrzWhVirrf6Y1DS2iIOM0SoqkAqSicais7XOBeAAKv+Zvrgc91Zk b1wWZKMpQgBFZOTqMdAXStjKCx9LahipZH6IXa8rpnGp6HGWyOEL/RGJnsQZLI+19YvWCdQ/ vsCMHYEYladnfmwhrm8T4GAhOx6dI+yY9hZ4yw7i22JZRolacmrr6Hi/t9f2DM9gMpDFvX2e ccDaCFuYxKGaBpKUrsSIMtgwb7x1ySnG9FegFa8+as6znGU9xJSi4jODeuFat+SWsoAyy50o UqDpQwVGCoyLtGQxCqZ2nOhmuGJmjn0ML/+D5Wy7Pgzn1ue1jRKTQYITx2+oOL8gEn4UchZc goK4DEo66M18SRHU+XAYvFxm1bc1jZ0ZjaaO7dSBN2lokYM3zukOw==
IronPort-HdrOrdr: A9a23:1Ic166MUXHvw1cBcThyjsMiBIKoaSvp037BN7TEVdfU1SL37qy nAppQmPHPP5gr5O0tOpTnoAsDpfZq2z+8X3WB+B9afdTijlmeuIJpr8IfuhxbxcheTysdtkY NtabJ3BtG1L1Rr5PyR3CCIV/It2sOO/qztv/rZ1HsFd2xXQrtt9Bh0ETyWFUBKRA1LbKBTKK ah
X-IronPort-AV: E=Sophos;i="5.93,196,1654560000"; d="scan'208";a="16511950"
Received: from BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) by BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2375.28; Wed, 27 Jul 2022 17:48:25 -0400
Received: from BRN1WNEX02.vcorp.ad.vrsn.com ([10.173.153.49]) by BRN1WNEX02.vcorp.ad.vrsn.com ([10.173.153.49]) with mapi id 15.01.2375.028; Wed, 27 Jul 2022 17:48:25 -0400
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
To: "regext@ietf.org" <regext@ietf.org>
Thread-Topic: Federated Authentication for Machine-to-Machine Interactions in RDAP
Thread-Index: Adih5DMCEp6v43VfSnSxcjRQLNyVKQ==
Date: Wed, 27 Jul 2022 21:48:25 +0000
Message-ID: <5a9b171385c5492e8d64492aa8cf6092@verisign.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.170.148.18]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/mW1DJkQQtk69JtZCz8cPmWxk3-4>
Subject: [regext] Federated Authentication for Machine-to-Machine Interactions in RDAP
X-BeenThere: regext@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Registration Protocols Extensions <regext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/regext>, <mailto:regext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/regext/>
List-Post: <mailto:regext@ietf.org>
List-Help: <mailto:regext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/regext>, <mailto:regext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Jul 2022 21:48:31 -0000

OAuth 2.0 includes the ability to authorize a class of clients known as 
"confidential clients" in a machine-to-machine manner using the "Client 
Credentials Grant". The grant is described here:

https://datatracker.ietf.org/doc/html/rfc6749#section-4.4

A description of confidential and public clients can be found here:

https://datatracker.ietf.org/doc/html/rfc6749#section-2.1

Note that this requires some sort of prior arrangement between the client and, 
in our case, an RDAP server, such that the client can be authenticated by an 
Authorization Server without explicitly identifying, authenticating, and 
authorizing the specific human users who might be using the client. For 
example, the client might have a password that's been assigned by the RDAP 
server operator. The federated authentication draft doesn't currently include 
anything to support this type of grant. Should it? Is there an RDAP use case 
for which this would be useful?



Scott