> -----Original Message----- > From: Tom Harrison <t...@apnic.net> > Sent: Sunday, January 23, 2022 5:11 PM > To: Hollenbeck, Scott <shollenb...@verisign.com> > Cc: mario.loffr...@iit.cnr.it; regext@ietf.org > Subject: [EXTERNAL] Re: 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 Fri, Jan 21, 2022 at 03:10:02PM +0000, Scott Hollenbeck wrote: > > On Fri, Jan 21, 2022 at 08:26:20AM +1000, Tom Harrison wrote: > >> 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? > > No, I don't think there are other options. But given that login is an > interactive > process anyway, asking them to select an identity provider at that point > doesn't sound like too much of a problem.
[SAH] The best thing we can do is to explain the situation in Section 3.1.3.1. What's there now needs to change: OLD: 3.1.3.1. Provider Discovery An RDAP server/RP needs to receive an identifier from an End-User that can be used to discover the End-User's OP. That process is required and is documented in the "OpenID Connect Discovery" protocol [OIDCD]. PROPOSED NEW: 3.1.3.1. Provider Discovery An RDAP server/RP needs to be able to map an End-User's identifier to an OP. This can be accomplished using the OPTIONAL "OpenID Connect Discovery" protocol [OIDCD], but that protocol is not widely implemented and can be unreliable. Out-of-band methods are also possible and can be more dependable. For example, an RP can support a limited number of OPs and maintain internal associations of those identifiers with the OPs that issued them. An RP can also ask an end-user to identify the OP that issued their identifier as part of an RDAP query workflow. An RP MAY use any provider discovery approach that is suitable for its operating environment. How does that sound? Scott _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
