Il 23/01/2022 23:11, Tom Harrison ha scritto:
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.
-Tom
Please note that except for authorization, token and userinfo endpoints,
all the other endpoints are optional so if we can't assume that a
webFinger server exists, the same should go for the other OP endpoints
recalled in this draft.
As opposed to the fact that the discovery metadata endpoint seems to be
provided by many OPs, dynamic client registration doesn't seem to me
largely implemented.
AFAIK, the google OP doesn't provide the client registration endpoint
(https://accounts.google.com/.well-known/openid-configuration).
As a consequence, the RDAP server should maintain the client credentials
resulting from an out-of-band registration.
IMHO, the pairs <OP, client credentials> should be maintained anyway to
avoid that the RDAP server starts the registration process at every RDAP
requests to the /tokens endpoint.
Mario
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
--
Dr. Mario Loffredo
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Web: http://www.iit.cnr.it/mario.loffredo
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
