If the issuer identifier value contains a path component, any terminating "/" MUST be removed before inserting "/.well-known/" and the well-known URI suffix between the host component and the path component.
Just as clarification then, this section does not require that path components not related to the issuer should be removed from the URI: ex: https://example.com/{application-identifier}/.wellknown/oauth-authorization-server/{issuer} Is that correct? The language in this section suggests that the url path should start in every case with /.well-known, which would not allow to have URIs like the one in the example above, ie: {application-identifier} and /.wellknown/oauth-authorization-server should always be at the root of the host ~AT On Tue, Jul 10, 2018 at 2:39 PM, David Waite <[email protected]> wrote: > > > On Jul 10, 2018, at 12:19 PM, Andres Torres <[email protected]> wrote: > > > In terms of API design the final result is confusing. The resource > /.well-known/oauth-authorization-server becomes a collection of resources > where issuer is a subresource.. However, > /.well-known/oauth-authorization-server should be a subresource of the > issuer/tenant. It is my understanding that .well-known is a prefix for > known resources in a given service. Multiple instances of a service (ie: > tenants) can be hosted using the same hostname in the form > {issuer|tenant-identifier}/.well-known/{known-resource}. This way a > proper resource hierarchy can be maintained in the URI namespace > and heterogeneous services can be deployed under the same hostname. > > > This is/was actually how it was done within OpenID Connect. However, the > only structured URL components allowed within IETF specifications are > underneath a /.well-known root. Since a multi-tenant application may have a > different issuer per tenant all within one origin, this transformation was > created such that each can have their own metadata. > > Another option would have been to have the issuer URL be the discovery > URL, but this would require an issuer of https://example.com to modify > the root of their service to respond to requests for metadata (such as in > response to the requirements of an Accepts header). > > A third option might be to define an ‘issuer’ parameter and behavior on > the metadata endpoint, such that servers which host only one issuer could > ignore it, but a server with multiple issuers could require and act on this > parameter. > > -DW >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
