Le mar. 10 juil. 2018 21:55, Andres Torres <jant...@gmail.com> a écrit :
> 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 > This is how it is defined in https://tools.ietf.org/html/rfc5785 > > ~AT > > On Tue, Jul 10, 2018 at 2:39 PM, David Waite <da...@alkaline-solutions.com > > wrote: > >> >> >> 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 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 >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
