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

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:
>
> 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?

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

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.

Best,

Mario

>
>
>
> Scott
>
> _______________________________________________
> regext mailing list
> regext@ietf.org
> https://www.ietf.org/mailman/listinfo/regext

-- 
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
Web: http://www.iit.cnr.it/mario.loffredo