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

Reply via email to