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://openid.net/specs/openid-connect-discovery-1_0.html#IssuerDiscovery > > 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. -Tom _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
