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

[Rick Wilhelm <[e-mail]>]

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 <[e-mail]> on behalf of Hollenbeck, Scott <shollenbeck=[e-mail]>
Date: Wednesday, July 27, 2022 at 5:48 PM
To: [e-mail] <[e-mail]>
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
[e-mail]
https://www.ietf.org/mailman/listinfo/regext<https://protect-us.mimecast.com/s/IatlC0RPwLi20KLc3_feM?domain=ietf.org>