Regarding RFC 8414 (Proposed Standard) Section 3.1. Authorization Server Metadata Request:
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. The client would make the following request when the issuer identifier is "https://example.com/issuer1"; and the well-known URI suffix is "oauth-authorization-server" to obtain the metadata, since the issuer identifier contains a path component: GET /.well-known/oauth-authorization-server/issuer1 HTTP/1.1 Host: example.com 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. Thanks in advance for you time. Cheers, Andres Torres
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
