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 <ace-boun...@ietf.org> On Behalf Of Carsten Bormann Sent: Monday, June 1, 2020 7:52 AM To: Seitz Ludwig <ludwig.se...@combitech.se> Cc: Benjamin Kaduk <ka...@mit.edu>; ace@ietf.org Subject: Re: [Ace] "default value" for authz-info endpoint On 2020-06-01, at 11:13, Seitz Ludwig <ludwig.se...@combitech.se> 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 <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
