Hi Tomas, Thank you for your comment. Some observations and questions: I have a hard time seeing a reasonable use case where a resource server (RS) would need several authz-info endpoints, one could however imagine a use case with a powerful server hosting several virtual resource servers (RS) under the same IP address and thus several different authz-info endpoints (one for each RS), but this does not sound like the typical Constrained Environment scenario to me. In order to better understand what this is about: If you have such a multi-tenant situation with a .well-known for a default configuration, how would clients discover the non-default configurations? Also if a RS were to use the default URI (which is <hostname>/authz-info), why would it need to announce this in a .well-known? I would assume that this is only necessary if a non-default URI is used.
@ACE: This is far away from my area of expertise and at this point I cannot devote the necessary time to "read up" on this. Can someone help us find a good solution that that we can move draft-ietf-oauth-authz forward? /Ludwig -----Original Message----- From: Ace <ace-boun...@ietf.org> On Behalf Of Tomas Gustavsson Sent: den 2 juni 2020 07:19 To: ace@ietf.org Subject: Re: [Ace] "default value" for authz-info endpoint Hi, In most cases where I've been involved with implementing a single RFC defined .well-known URL for actually servicing all end points, it ends up being one .well-known for default configuration, and multiple other (not .well-known) URLs in order to handle other configurations in multi-tennant scenarios. I hope whatever .well-known scheme is selected will handle multi-tennancy, where thare can be differently configured service end points servicing from the same host/ip. I.e. can one host server multiple authz-info? (does that make sense?) Regards, Tomas On 2020-06-02 01:58, Benjamin Kaduk wrote: > Hi Ludwig, > > I'm confident that a well-known URI (or link relation) for discovery > of RS configuration/parameters would address the BCP 190 concerns. > What we need is an obvious path to not stomp on the server owner's > namespace, and whether we do that by letting the server tell us what > what path to use or by constraining ourself to a well-specified > cordoned-off corner reserved for our use is up to us. > > Thanks for all the ideas and follow-up discussion! > > -Ben > > On Mon, Jun 01, 2020 at 09:13:13AM +0000, Seitz Ludwig wrote: >> Hi Ben, >> >> I had a look at the well-known URI list at IANA and it seems that for >> vanilla OAuth 2.0 endpoints (authorization, token, introspect) there are no >> well-known URI:s either. What exists is an URI used by the authorization >> server to self-describe (including attributes giving the values of the >> endpoint's URIs). >> >> So my interpretation would be that instead of defining a well-known URI for >> authz-info, we need to define an attribute that a Resource Server can >> include in its well-known information to identify the authz-info endpoint >> URI it is exposing. >> >> @Carsten (or other core experts): Would it make sense to define a new >> attribute in the /.well-known/core format for Resource Servers using coap? >> >> /Ludwig >> >> >> -----Original Message----- >> From: Ace <ace-boun...@ietf.org> On Behalf Of Benjamin Kaduk >> Sent: den 31 maj 2020 00:36 >> To: ace@ietf.org >> Subject: [Ace] "default value" for authz-info endpoint >> >> Hi all, >> >> I was prompted by the discussion at the interim to look more closely >> at what we say about the "default name" for endpoint URIs, e.g., the >> authz-info endpoint. The last paragraph of >> https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-33#section-5.8 >> .1 >> says: >> >> The default name of this endpoint in an url-path is '/authz-info', >> however implementations are not required to use this name and can >> define their own instead. >> >> I've gotten advice from some URI experts that this doesn't give an >> easy/discoverable path (pun intended) to using a non-default value, which is >> problematic from the perspective of BCP 190 (and we should expect to get >> discussed at IESG evaluation time). This sort of issue goes away if we >> allocate a well-known URI for authz-info from >> https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml and >> have that be the default. In particular, that wouldn't actually stop any >> deployments from using /authz-info, but it does mean they'd have to >> knowingly "opt in" to doing so. >> >> What do people think? >> >> Thanks, >> >> Ben >> >> _______________________________________________ >> Ace mailing list >> Ace@ietf.org >> https://www.ietf.org/mailman/listinfo/ace > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
