Subject: [regext] I-D Action: draft-ietf-regext-rdap-openid-08.txt

From: [email-masked]
Date: Mon, 08 Nov 2021 04:45:17 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Registration Protocols Extensions WG of the IETF.

        Title           : Federated Authentication for the Registration Data Access Protocol (RDAP) using OpenID Connect
        Author          : Scott Hollenbeck
	Filename        : draft-ietf-regext-rdap-openid-08.txt
	Pages           : 25
	Date            : 2021-11-08

Abstract:
   The Registration Data Access Protocol (RDAP) provides "RESTful" web
   services to retrieve registration metadata from domain name and
   regional internet registries.  RDAP allows a server to make access
   control decisions based on client identity, and as such it includes
   support for client identification features provided by the Hypertext
   Transfer Protocol (HTTP).  Identification methods that require
   clients to obtain and manage credentials from every RDAP server
   operator present management challenges for both clients and servers,
   whereas a federated authentication system would make it easier to
   operate and use RDAP without the need to maintain server-specific
   client credentials.  This document describes a federated
   authentication system for RDAP based on OpenID Connect.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-openid/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-openid-08

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-rdap-openid-08

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 8 Nov 2021 12:54:15 +0000

> -----Original Message-----
> From: I-D-Announce <[email-masked]> On Behalf Of
> [email-masked]
> Sent: Monday, November 8, 2021 7:45 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [EXTERNAL] I-D Action: draft-ietf-regext-rdap-openid-08.txt
> 
> Caution: This email originated from outside the organization. Do not click links
> or open attachments unless you recognize the sender and know the content
> is safe.
> 

[SAH] Folks, this update includes some significant changes that were designed to align the specification more closely with both OpenID Connect and the web services architecture. For example, the ID of the query requestor can now be sent to the server in an HTTP authorization header OR a query parameter. The token management bits were also changed to include a refresh token in the /tokens response. Thanks to Mario Loffredo for the suggestions included in this update.

Mario had some other suggestions that I haven't yet implemented. I encouraged him to share them with the list so we could have a broader discussion. Mario, please start that discussion at your convenience.

Direct link to diff:

Scott

---

From: Mario Loffredo <[email-masked]>
Date: Mon, 8 Nov 2021 21:58:01 +0100

Hi folks,

I think the first point we need to discuss is if we should introduce two 
conformance tags for this extension:

- "rdap_openidc_level_0" used by RDAP servers to signal that they 
implement SSO through the OIDC services provided by a local OP

- "rdap_federation_level_0" used by RDAP servers to signal that they 
implement SSO through the OIDC services provided by a set of trusted 
external OPs

To start a SSO session with a server that is rdap_openidc_level_0 
conformant, an end user operating through a web browser:

- sends a query to /tokens endpoint of the RDAP server without the id 
parameter

- is authenticated by the local OP (i.e. by filling out the login form)

- receives the access_token and uses it as either bearer or query 
parameter for submitting requests towards standard endpoints of the RDAP 
server

- requests for token refreshment and revoking without including the id 
parameter

In this scenario, the id parameter is ignored.

To start a SSO session with a server that is rdap_federation_level_0 
conformant, an end user operating through a web browser:

- sends a query to /tokens endpoint of the RDAP server including the id 
parameter

- is authenticated by the OP discovered through the OpenID Discovering 
process (i.e. by filling out the login form)

- receives the access_token and uses it as either bearer or query 
parameter for submitting requests towards standard endpoints of the RDAP 
server

- requests for token refreshment and revoking including the id parameter

In this scenario, the id parameter is required.

Some futher considerations support my proposal of splitting the 
conformance in two:

1) AFAIK, the available OPs provide built-in OIDC features supporting 
the implementation of the Authorization Code Flow. But this doesn't 
apply for the features required to implement federation such as OP 
discovery and dynamic client registration. Therefore, while SSO could be 
implemented without knowing OIDC in depth, RDAP developers on server 
side should tackle the implementation of a federation at a lower level.

2) Joining a federation doesn't only imply the implementation of such 
additional OIDC features but also an agreement between all the parties 
involved as it is described in 
https://openid.net/specs/openid-connect-federation-1_0.html 
<https://openid.net/specs/openid-connect-federation-1_0.html>. For this 
reason, it seems to me that a federation represents a layer upon the 
implementaion of OIDC to support authentication and SSO.

3) Currently, some OPs provide support external authentication through 
other mechanisms (e.g identity brokering, social login). Briefly, 
instead of discovering the OP from a user identifier, the user is 
directly requested to select in a list of trusted OPs the one which will 
be in charge of the authentication.

Hope it could be helpful to move the discussion forward.

Best,

Mario

Il 08/11/2021 13:54, Hollenbeck, Scott ha scritto:
> _______________________________________________
> regext mailing list
> [email-masked]
> 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

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 9 Nov 2021 14:22:46 +0000

A couple of thoughts to (hopefully) prompt discussion (see below)...

> From: Mario Loffredo <[email-masked]>
> Sent: Monday, November 8, 2021 3:58 PM
> To: Hollenbeck, Scott <[email-masked]>; [email-masked]
> Subject: [EXTERNAL] Re: [regext] I-D Action: draft-ietf-regext-rdap-openid-
> 08.txt
> 

[SAH] This redefines the current meaning of rdap_openidc_level_0, where the ID parameter is required. I'm not opposed to the idea of redefinition, but it would mean a change for anyone that 's implemented it the old way.

> - receives the access_token and uses it as either bearer or query parameter
> for submitting requests towards standard endpoints of the RDAP server
> 

[SAH] This is a new approach that uses some of the concepts that are in the current draft where the id parameter is used.

> - receives the access_token and uses it as either bearer or query parameter
> for submitting requests towards standard endpoints of the RDAP server
> 
> 1) AFAIK, the available OPs provide built-in OIDC features supporting the
> implementation of the Authorization Code Flow. But this doesn't apply for
> the features required to implement federation such as OP discovery and
> dynamic client registration. Therefore, while SSO could be implemented
> without knowing OIDC in depth, RDAP developers on server side should
> tackle the implementation of a federation at a lower level.
> 
> involved as it is described in https://secure-
> web.cisco.com/1AiNimHMRDqyGq6nNCI91cEqZf7PLMIrmUHbkI4btU0sRrip4
> AW1qNN_YMODP0CmNuliOoJ7fuyFIt-GQ1SZP7p1L-
> pqtnzM1xJYVW_aCjmgpkGv1-
> Dj85TSQZJMGwN5sC8HJlSeSS6oBGm2h8CrdP3bNwyJ9ZQKLJfyNRQctjUEcD7f
> RVjau74HIK0rYw1IiHgeEZKnkcxMjLbPfga7539mKjrKC9kja7iZ6Lbc4L0T65N_2y
> OHh_KEvyY-0y2KRNHM-VqtNhnJZGtu0c-WXTzHdQR5fZyIe-
> Av7LnwuHuk/https%3A%2F%2Fopenid.net%2Fspecs%2Fopenid-connect-
> federation-1_0.html
> <https://secure-
> web.cisco.com/1AiNimHMRDqyGq6nNCI91cEqZf7PLMIrmUHbkI4btU0sRrip4
> AW1qNN_YMODP0CmNuliOoJ7fuyFIt-GQ1SZP7p1L-
> pqtnzM1xJYVW_aCjmgpkGv1-
> Dj85TSQZJMGwN5sC8HJlSeSS6oBGm2h8CrdP3bNwyJ9ZQKLJfyNRQctjUEcD7f
> RVjau74HIK0rYw1IiHgeEZKnkcxMjLbPfga7539mKjrKC9kja7iZ6Lbc4L0T65N_2y
> OHh_KEvyY-0y2KRNHM-VqtNhnJZGtu0c-WXTzHdQR5fZyIe-
> Av7LnwuHuk/https%3A%2F%2Fopenid.net%2Fspecs%2Fopenid-connect-
> federation-1_0.html>. For this reason, it seems to me that a federation
> represents a layer upon the implementaion of OIDC to support
> authentication and SSO.
> 
> other mechanisms (e.g identity brokering, social login). Briefly, instead of
> discovering the OP from a user identifier, the user is directly requested to
> select in a list of trusted OPs the one which will be in charge of the
> authentication.
> 

[SAH] Agreed! What do others think?

Scott