(adding regext WG list)
Thanks for the note, Roland. I’m still working through Mario’s feedback, so it may be a while before I get to making any specific changes to the draft. If you see anything else in there, please let us know! The RDAP environment I’m familiar with probably won’t depend on dynamic discovery. The relying parties will probably have a relatively small set of identity providers that they’ll recognize and work with, and those relationships will be defined through some contractual process in order to provide access to any kind of sensitive data. I can see some value in adding some words to Section 3.1.3.1 to note that dynamic discovery is a MAY and that static configuration is also possible and acceptable. Scott From: Roland Hedberg <rol...@catalogix.se> Sent: Friday, November 12, 2021 3:30 AM To: draft-ietf-regext-rdap-ope...@ietf.org Cc: mario.loffr...@iit.cnr.it Subject: [EXTERNAL] Mail regarding draft-ietf-regext-rdap-openid 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 ! I’m new the regent and RDAP so let me introduce myself. May name is Roland Hedberg, I’m an software architect/implementer and I’ve been working with OIDC since 2009. For one thing I wrote and ran the OIDC certification test suite until 2 years ago when I decided to retire. I've done 2 OIDC library implementations in Python (pyoidc and JWTConnect-Python). I’ve also implemented SAML2 (pysaml2) and have been involved in running a SAML2 identity federation (SWAMID). Lately I’m the lead author of the OIDC federation specification: https://github.com/rohe/oidcfederation<https://secure-web.cisco.com/1Ioiqxc8cwyiMxcUnEp3dr7SfQeCZmfXFVZae9BVsbZXWLuFxUYV7Wb7JKMvUECKYHvVQ-A3DZDAMYY6guZ73-AIoUmaayg9Mp9xk93_RoAumdLiFJXvWVfIG0voN0Iif308eeYutAApL4cW2NMFfAQeon3yJfkSwFtyHjDNKxq3d_01oVloQqBCGQ0asEtR8x0HV-3rZw5Z8WPgByusf6RbF2n1hrgKDSwsOzUNhrsh3CS4q3Vksb0wdq7eeFz9f/https%3A%2F%2Fgithub.com%2Frohe%2Foidcfederation> I’ve read draft-ietf-regext-rdap-openid-08 and Mario’s comment "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://secure-web.cisco.com/1GhNnIGci4I69CY8EtumAUr8ghUDicngaUiJmgRxlfOh691KCQq_Hh08l18BN2AgDp7F9lUT5M8v4QCvKJ0wDEY198S5ErQxoi8x0rzuGWHBVd3iYh23AWIceUhVvaLDtpbKrvJHCmBcQTYB2i88Ytky60Mf0PMF2wGcDXINb7UlKQX90EUioOJehWvOmveYO3bQVL9n94xRYIfshGgTGeOxliMPaK0Np_ezlMUKcig2o4PwK8ZHcq0MbzzlMuyTn/https%3A%2F%2Fopenid.net%2Fspecs%2Fopenid-connect-federation-1_0.html> <https://openid.net/specs/openid-connect-federation-1_0.html<https://secure-web.cisco.com/1GhNnIGci4I69CY8EtumAUr8ghUDicngaUiJmgRxlfOh691KCQq_Hh08l18BN2AgDp7F9lUT5M8v4QCvKJ0wDEY198S5ErQxoi8x0rzuGWHBVd3iYh23AWIceUhVvaLDtpbKrvJHCmBcQTYB2i88Ytky60Mf0PMF2wGcDXINb7UlKQX90EUioOJehWvOmveYO3bQVL9n94xRYIfshGgTGeOxliMPaK0Np_ezlMUKcig2o4PwK8ZHcq0MbzzlMuyTn/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." To which I’d like to add my 2 c (sorry if I’m telling you things you already know, I have no idea how much you know about OIDC). OIDC is basically a peer to peer protocol. One RP communicating with one OP. Also everything starts with the RP. Before commencing the communication the entities needs to know about each other (endpoints, key material, ..). There are several ways this can happen the most common pattern right now is that the RP registers with an OP at some website provided by the OP is whatever way the OP wants it and then the RP can access the OPs metadata by using the process described in https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfig<https://secure-web.cisco.com/1coB_8oIt5_1UKO9OWKP-oQCap-Bgqb3MSGM1uSbZHKWHw5_EkcGKGZgkV1Cj48QINVpxC5uynVHrXqC-T799DbLOXIuEWpclYIiHEHz1fjNkbZ_fC--XvS_WrpWIwaujiISmG2A5AujIyuchTYYOWHg4bk12EknamZAPYp9uOkkC-HMmQ4sBXDlNzswYv5SIcbyMq4w6e3FJYEuvr-rfBOkKqEPf1x5NmUqOWfscr_NDxV9b9I41mtrbylcB6eOI/https%3A%2F%2Fopenid.net%2Fspecs%2Fopenid-connect-discovery-1_0.html%23ProviderConfig>. This is how Google does it. If I understand it correctly in draft-ietf-regext-rdap-openid-08 you argue for using what’s described in https://openid.net/specs/openid-connect-discovery-1_0.html#IssuerDiscovery<https://secure-web.cisco.com/1PFlpywPC4dq4ssm-cLe8nzKGtGJ-M_IE81Q2sklx-VDMhuJbaTdcFvyQZxVkCjA7vEZvoIvu4QAD_byFkgAahB_OK_yGwszroZw5Lfpjho-UdOjmPoeRdZWMTcb2kIuPyw-CutL_gdnlMKtpRKCmGfrlOSUpzG-I85TzX-k2CYp7kxrXgwqmh90YA-wayttFmmKVFAAw-8BMngVTZwF2uqmz9SGl9VbGqALI-vY62lWjH4KU1FDKrk5k04oOEZX7/https%3A%2F%2Fopenid.net%2Fspecs%2Fopenid-connect-discovery-1_0.html%23IssuerDiscovery> This works, sort of, but is rarely used. Basically because the user would need to know which identifier to use and they rarely do. You would like to have something that looks like and email address but isn’t. If the number of OPs are very small you could use something like the NASCAR pages with identity provider we have today. If the number is large (and I would say large is anything >10) you need something else. You need a federation. The most common type of multilateral federations right now is that you have a central authority where everyone has to register their metadata. The OIDC federation spec describes something different. Here you chose a trusted 3rd party who provides a trust anchor (a set of keys) for the federation. From my point of view you should not go the IssuerDiscovery way using web finger because of the problem with user identifier. You should not go the way of the central registry because it doesn’t scale and is not very dynamic. You should instead look at using OIDC federation as described in the specification. If you’re OK with it I’m prepared to spend some time discussing this with you on the regext mailing list. — Roland Scratch a pessimist and you find often a defender of privilege. -William Beveridge, economist and reformer (5 Mar 1879-1963)
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
