Re: [OAUTH-WG] Mail regarding draft-ietf-oauth-discovery

[David Waite <[e-mail]>]

> On Jul 10, 2018, at 12:19 PM, Andres Torres <[e-mail]> 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