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 _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
