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
