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

Mario Loffredo <> Fri, 29 July 2022 11:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 153B2C16ED1C for <>; Fri, 29 Jul 2022 04:59:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.907
X-Spam-Status: No, score=-6.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_HI=-5, 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
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jP-ffhAkFJli for <>; Fri, 29 Jul 2022 04:59:45 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 34155C15A72F for <>; Fri, 29 Jul 2022 04:59:44 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5A4A5B80513; Fri, 29 Jul 2022 13:59:42 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2KF-oZZ1KMAa; Fri, 29 Jul 2022 13:59:39 +0200 (CEST)
Received: from [] ( []) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 6EAF3B803F3; Fri, 29 Jul 2022 13:59:39 +0200 (CEST)
Message-ID: <>
Date: Fri, 29 Jul 2022 13:57:04 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0
To: "Hollenbeck, Scott" <>, "" <>
References: <>
From: Mario Loffredo <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [regext] Federated Authentication for Machine-to-Machine Interactions in RDAP
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Registration Protocols Extensions <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 29 Jul 2022 11:59:49 -0000

Hi Scott,

please find my comments below.

Il 27/07/2022 23:48, Hollenbeck, Scott ha scritto:
> 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:
> A description of confidential and public clients can be found here:
> 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?

Think it should be addressed, though I'm not sure this is the right 

The authentication flows explored so far fit well the use cases where a 
human occasionally submits a request. The case of authenticated software 
agents submitting a lot of requests routinely doesn't find a practical 
solution in this draft. I would like to remind everyone that EU 
Parliament and EU Council has recently reached an agreement on core 
elements of the e-Evidence proposal. Therefore, I guess that soon we 
will have to figure out how to provide regular authenticated access to 
registration data to categories of users legitimated for their purposes 
such as authorities and cybercrime agencies.

That being said, I see two big drawbacks in using the Client Credential 
flow, at least as is:

- Client Credential flow is for trusted clients. Clients need to be 
registered by the OP before submitting a request for an access token. 
But, RDAP clients are generally untrusted and I don't consider scalable 
a solution where several RDAP clients are required to register by many 
OPs including the local ones. In the approach described in this draft, 
the trusted client is the RDAP server.

- Roles and access grants are generally assigned to users not to 
clients. In addition, think there would be a potential risk of providing 
access to illegitimate users via legitimate clients.

The Resource Owner Password Credential Flow would have fiited better but 
it has been rightly deprecated by OAuth. I'm afraid that a usage of CC 
Flow in a manner similar to the ROPC flow wouldn't be welcome by 
security experts.

I would suggest to explore another approach where a third-party 
authority interconnects clients and servers that are mutually authenticated.



> Scott
> _______________________________________________
> regext mailing list

Dr. Mario Loffredo
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497