> On Jul 10, 2018, at 12:19 PM, Andres Torres <jant...@gmail.com> 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 <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
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
