Re: [Ace] "default value" for authz-info endpoint
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 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
Re: [Ace] "default value" for authz-info endpoint
On 2020-06-01, at 11:13, 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? It would probably not be an attribute but a link relation and/or a resource type. I would expect the authz-info resource would usually be the same for an entire server? This might argue for the “hosts” link relationship and an rt= registration. Registry: Resource Type (rt=) Link Target Attribute Values in Constrained RESTful Environments (CoRE) Parameters If the authz-info is often different for each resource, a link from the resource to the authz-info with an appropriate link relation would work best. Registry: Link Relations Grüße, Carsten > > /Ludwig > > > -Original Message- > From: Ace 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
Re: [Ace] "default value" for authz-info endpoint
We should make sure to keep draft-tiloca-core-oscore-directory in mind for this. It has a relation link defined for the Authorization server. Jim -Original Message- From: Ace On Behalf Of Carsten Bormann Sent: Monday, June 1, 2020 7:52 AM To: Seitz Ludwig Cc: Benjamin Kaduk ; ace@ietf.org Subject: Re: [Ace] "default value" for authz-info endpoint On 2020-06-01, at 11:13, 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? It would probably not be an attribute but a link relation and/or a resource type. I would expect the authz-info resource would usually be the same for an entire server? This might argue for the “hosts” link relationship and an rt= registration. Registry: Resource Type (rt=) Link Target Attribute Values in Constrained RESTful Environments (CoRE) Parameters If the authz-info is often different for each resource, a link from the resource to the authz-info with an appropriate link relation would work best. Registry: Link Relations Grüße, Carsten > > /Ludwig > > > -Original Message- > From: Ace 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
Re: [Ace] "default value" for authz-info endpoint
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 +, 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 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
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 +, 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 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
