A couple of thoughts to (hopefully) prompt discussion (see below)... > -----Original Message----- > From: Mario Loffredo <mario.loffr...@iit.cnr.it> > Sent: Monday, November 8, 2021 3:58 PM > To: Hollenbeck, Scott <shollenb...@verisign.com>; regext@ietf.org > Subject: [EXTERNAL] Re: [regext] 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. > > 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
[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. > - 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: [SAH] This is a new approach that uses some of the concepts that are in the current draft where the id parameter is used. > - 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://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. > > 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. [SAH] Agreed! What do others think? Scott _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
