I'm aware of many production deployments of authorization server metadata that, for the issuer https://example.com/tenants/tenant123 use the OpenID Connect .well-known path formulation https://example.com/tenants/tenant123/.well-known/openid-configuration and none that use https://example.com/.well-known/oauth-authorization-server/tenants/tenant123.
It's not what RFC 8414 says to do, but it's what's done in practice. -- Mike From: Giuseppe De Marco <demarco...@gmail.com> Sent: Wednesday, July 3, 2024 10:09 AM To: Rafael Freitas <r.pereira.frei...@gmail.com> Cc: oauth <oauth@ietf.org> Subject: [OAUTH-WG] Re: Product Support for RFC8414 well-known URIs You made a very good point, see https://openid.net/specs/openid-federation-1_0.html#name-obtaining-federation-entity Il mer 3 lug 2024, 19:03 Rafael Freitas <r.pereira.frei...@gmail.com<mailto:r.pereira.frei...@gmail.com>> ha scritto: But does the OpenID implementation really go against RFC 5785? I'm re-reading it and I don't think it does, I'll elaborate, citing said RFC: > 1. When this happens, it is common to designate a "well-known location" for > such data, so that it can be easily located. However, this approach has the > drawback of risking collisions, both with other such designated "well-known > locations" and with pre-existing resources.(...) Here they clearly communicate a concern with avoiding collisions. > (...)To address this, this memo defines a path prefix in HTTP(S) URIs for > these "well-known locations", "/.well-known/". Future specifications that > need to define a resource for such site-wide metadata can register their use > to avoid collisions and minimise impingement upon sites' URI space.(...) Here they talk about site-wide metadata, which is not necessarily domain-wide metadata. Nowadays it is fairly common for a site to have a path prefix instead of a sub-domain. > 3. (...) A well-known URI is a URI [RFC3986] whose path component begins with > the characters "/.well-known/" (...) So, for example, for a well known URI of "oauth-authorization-server", the well-known URI would be "/.well-known/oauth-authorization-server". This does not specify that the path can not have any other components before this, it only says that any well known URLs must be prefixed with "/.well-known/". > (...)For example, if an application registers the name 'example', the > corresponding well-known URI on 'http://www.example.com/' would be > 'http://www.example.com/.well-known/example'. (...) I think this was a bad explanation because the word "example" appears in two places, generating some ambiguity. But note that they do not talk about a domain, but about an application. So I think it would follow that if the application registered the name (they don't talk about domains, but instead about names) 'http://www.myhoster.com/example' the corresponding well-known URI would be ''http://www.myhoster.com/example/.well-known/". > (...) Note that this specification defines neither how to determine the > authority to use for a particular context, nor the scope of the metadata > discovered by dereferencing the well-known URI; both should be defined by the > application itself.(...) To me this part nails the point home. They never intented to specify how URIs are dereferenced. If they meant for well known URIs to always be at the root of the domain, you would have already determined the authority for a given domain, and the scope for the metadata. But they leave it to each application. So I think it is possible to respect both RFC 5785 and the OpenID Specification. And regardless, requiring well-known not to be a sub-path of a domain is rather impractical, to the point where I think it's more likely for this RFC to not be adopted than for every OAuth server to obtain it's own domain / subdomain registry. _______________________________________________ OAuth mailing list -- oauth@ietf.org<mailto:oauth@ietf.org> To unsubscribe send an email to oauth-le...@ietf.org<mailto:oauth-le...@ietf.org>
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org