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
