Mario, I've been thinking about this a bit and I have a slightly different proposal to suggest. 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 [SAH] I'd like to keep these values aligned to note the distinction between support for a local OP and eternal Ops. What about something like this? rdap_openidc_local_level_0 (or maybe "internal" instead of "local") rdap_openidc_remote_level_0 (or maybe "external" instead of "remote") A server could support one or both of these. If only one is supported, the client will need to send queries a certain way as described below. If both are supported, the client can send queries without the id parameter to use the local OP, and with the id parameter to use a remote OP. Note that this means that a server that supports rdap_openidc_local_level_0 can't distinguish between a query for which authentication is requested and a query without an authentication request. A query without the id parameter will look like a "standard" RDAP query. Is that a feature or a bug? > 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. [SAH] I think this can work. > 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
