Scott, et al, Great question. One use case that comes to mind is working with law enforcement. In certain situations, authenticated access to RDAP data is required to override the default restrictions on disclosure. However, for operational security reasons, the law enforcement agency (LEA) doesn’t want individual query sources to be revealed. And so the LEA sends all if it’s internal queries through an internal source, like an internal web page that then sends the queries on to the RDAP server. (In certain situations, there may also be restrictions on the RDAP server logging those queries, but that’s a different issue.)
I think that right now, this sort of arrangement could be handled by an IP passlist. A rather blunt instrument to be sure, which can be challenging to implement in certain operational situations. There may be other solutions that I either don’t know or am not recalling. Offering this as a possible use-case. Not sure if it’s worth adding to the draft. Thanks Rick From: regext <[email protected]> on behalf of Hollenbeck, Scott <[email protected]> Date: Wednesday, July 27, 2022 at 5:48 PM To: [email protected] <[email protected]> Subject: [EXTERNAL] [regext] Federated Authentication for Machine-to-Machine Interactions in RDAP CAUTION: This email came from outside your organization. Don?t trust emails, links, or attachments from senders that seem suspicious or you are not expecting. 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<https://protect-us.mimecast.com/s/4pxXC820GEtj8lKTMnlTD?domain=datatracker.ietf.org> A description of confidential and public clients can be found here: https://datatracker.ietf.org/doc/html/rfc6749#section-2.1<https://protect-us.mimecast.com/s/1DB0C9rPJgHmVvpsPN3QF?domain=datatracker.ietf.org> 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 _______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext<https://protect-us.mimecast.com/s/IatlC0RPwLi20KLc3_feM?domain=ietf.org>
_______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
