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> 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 > To unsubscribe send an email to oauth-le...@ietf.org >
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
