> -----Original Message----- > From: Tom Harrison <t...@apnic.net> > Sent: Thursday, January 20, 2022 5:26 PM > To: Hollenbeck, Scott <shollenb...@verisign.com> > Cc: mario.loffr...@iit.cnr.it; regext@ietf.org > Subject: [EXTERNAL] Re: Re: Re: [regext] id_token parameter usage in 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. > > On Thu, Jan 20, 2022 at 02:41:06PM +0000, Scott Hollenbeck wrote: > >> -----Original Message----- > >> From: Tom Harrison <t...@apnic.net> > >> Sent: Wednesday, January 19, 2022 9:09 PM > >> To: Hollenbeck, Scott <shollenb...@verisign.com> > >> Cc: mario.loffr...@iit.cnr.it; regext@ietf.org > >> Subject: [EXTERNAL] Re: Re: [regext] id_token parameter usage in > >> rdap- openid > > > > [SAH] [snip] > > > >>> [SAH] I wonder if the changes made in -09 are helpful or not in the > >>> context of this discussion. It's worth re-reading the draft to be > >>> sure. > >> > >> It looks like the key update is that the ID token is no longer passed > >> to the RDAP server by the RDAP client, with the user's identifier > >> taking the place of that token. However, if the RDAP server has only > >> an access token and a user identifier, it won't be able to determine > >> definitively the authorisation server that it needs to contact to > >> verify that token (I don't think the user's identifier is sufficient > >> for a 1:1 mapping to an authorisation server in this respect). > >> Possibly another option is to pass back the 'iss' claim from the ID > >> token to the RDAP client, and have the RDAP client provide that claim > >> on each request. > > > > [SAH] According to the OpenID Connect Discovery protocol, it *is* > > possible to determine the OpenID Provider based on the identifier > > alone and out-of-band means. See: > > > > https://secure-web.cisco.com/18PfVwBIpVxxYoyT6xsN-1- > IefbAjsVTLIbWTRUzM > > > 9B8GxvyvkjwdPUNBmxgDrU68dej6y85b2k_rE7tIVWHPm1nwOJIMXDC9n9F8 > NcdMqjOydL > > 3U8oBBrvfeCEvR_uMlK5H9AKeSO- > rl_ZPBPe6DoNG2K3yczOw3cF84mAhUY0DM-dOiqdzd > > s_laawBFj9OmBnWfbXMunQzGuVkBvu5nwZ1IZnZ6_cQhdVaQZ9bY- > _PkVdlMDJ_P6NQAMr > > Q1ePif/https%3A%2F%2Fopenid.net%2Fspecs%2Fopenid-connect- > discovery-1_0 > > .html%23IssuerDiscovery > > > > So, I think we have that covered. > > But it's not guaranteed that every user identifier will be associated with a > host that is implementing issuer discovery. For example, an RDAP server > might be configured to use multiple authorisation servers, each of which > permits the use of arbitrary email addresses as identifiers. Because each > permits arbitrary email addresses, it's not possible to use a simple mapping > from the domain of the email address to the authorisation server. The RDAP > server is then reliant on issuer discovery being implemented by the email > host, but there's no guarantee that it will be (Gmail doesn't implement it, > for > example). > If an RDAP server has some specific out-of-band means for mapping > identifiers to authorisation servers, then it could rely on that, but that may > not be possible in all situations. The RDAP server then has to fall back to > requesting that the user select an authorisation server during the login > process: this is fine, but it means that the RDAP server is receiving extra > information during the login process that it won't have available to it during > subsequent token-based requests.
[SAH] Hmm, Google used to support webfinger with Gmail. I can't find anything that says they've discontinued the service, but the resources I used in the past can't be found at their old locations. If we can't assume that discovery based on attributes of the identifier is reliable, what can we do? Out-of-band negotiation/configuration is one method, or we can ask the user/client to somehow identify the Identity Provider when they request tokens. That sounds more complicated than I'd prefer, but do we have any other options? Scott _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
