None

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: -- 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 at ietf.org https://www.ietf.org/mailman/listinfo/regext