I spent 10 minutes searching for one in the article, in the RFC, in the wikipedia page, on google, to search for a .well-known example. Couldn't find one.
I did read one before while working with github oidc, and I did find it very useful.
What is it with technical documentations that go deep describing what it is in plenty words but refusing to give a single example? This far from the first case I've ran into either.
> I spent 10 minutes searching for one in the article, in the RFC, in the wikipedia page, on google, to search for a .well-known example. Couldn't find one.
I don't know how that can be, since you claim to have found the RFC; the RFC straight-forwardly states,
> 5. IANA Considerations
> This specification updates the registration procedures for the "Well-Known URI" registry, first defined in [RFC5785]; see Section 3.1.
& then of course directs IANA to establish a registry. We'd expect this section, given the very nature of the RFC is that it establishes a collection of things, so that there is an IANA considerations section should be wholly unsurprising…
And there's a link to a listing of every standardized .well-known URI there is.
> What is it with technical documentations that go deep describing what it is in plenty words but refusing to give a single example?
The RFC provides an example in the form of "example", but also in the form of "robots.txt" (as a "it could have used this, had this existed", but what else could it have done?).
I've been setting up some federated servers (Matrix, activitypub) and I ran into .well_known/ paths in many of them. Webfinger resolver for activitypub and a more custom matrix server-to-server federation endpoint.
well-known is for programmatic access, it either namespaces something you’re told to look for (e.g. various types of domain markers) or it lets you discover a feature / endpoint.
In the latter case you just probe, for instance if you’re a password manager and you have a password for site A you hit A/.well-known/change-password and if they returns something you can surface a change password link to your user.
The one you found is for OIDC provider discovery (https://openid.net/specs/openid-connect-discovery-1_0.html#P...) so someone tells you they want to log in via Google, you hit that endpoint, and it lets you setup Google as an oidc provider rather without needing to hard-code providers. Even if you just want to support Google as a provider, you hit that and you get the entire configuration rather than have to hunt down the same information in the docs.
Slightly less well-known than XDG directories among the developers of Linux-targeted software, it would seem.
Seriously, what an oxymoronic name. "/index.html" is a well known URL, literally: most of web-developers are aware of it. But inventing a bunch of URLs with predefined semantics and then slapping the "well-known" label on it... well, it won't magically make them actually well-known.
I spent 10 minutes searching for one in the article, in the RFC, in the wikipedia page, on google, to search for a .well-known example. Couldn't find one.
I did read one before while working with github oidc, and I did find it very useful.
What is it with technical documentations that go deep describing what it is in plenty words but refusing to give a single example? This far from the first case I've ran into either.
> I spent 10 minutes searching for one in the article, in the RFC, in the wikipedia page, on google, to search for a .well-known example. Couldn't find one.
I don't know how that can be, since you claim to have found the RFC; the RFC straight-forwardly states,
> 5. IANA Considerations
> This specification updates the registration procedures for the "Well-Known URI" registry, first defined in [RFC5785]; see Section 3.1.
& then of course directs IANA to establish a registry. We'd expect this section, given the very nature of the RFC is that it establishes a collection of things, so that there is an IANA considerations section should be wholly unsurprising…
If you see the linked section…
> The "Well-Known URIs" registry is located at <https://www.iana.org/assignments/well-known-uris/>.
And there's a link to a listing of every standardized .well-known URI there is.
> What is it with technical documentations that go deep describing what it is in plenty words but refusing to give a single example?
The RFC provides an example in the form of "example", but also in the form of "robots.txt" (as a "it could have used this, had this existed", but what else could it have done?).
I've been setting up some federated servers (Matrix, activitypub) and I ran into .well_known/ paths in many of them. Webfinger resolver for activitypub and a more custom matrix server-to-server federation endpoint.
They are collected at this registry: https://www.iana.org/assignments/well-known-uris/well-known-...
Are they actually, though?
If they adhere to the RFC, yes: https://www.rfc-editor.org/info/rfc8615/#section-3.1
And https://www.rfc-editor.org/info/rfc8615/#section-3
> Applications that wish to mint new well-known URIs MUST register. them, following the procedures in Section 5.1 […]
Of course this is all voluntary, but why would you risk a name collision with another project if the process is quite straightforward?
There's an interesting list on Wikipedia: https://en.wikipedia.org/wiki/Well-known_URI#List_of_well-kn...
Not one of them links to the actual well-known resource, only pdf specifications. And several I picked randomly leads to dead ends.
Here's one I could find: https://accounts.google.com/.well-known/openid-configuration
But how does one even find this?
well-known is for programmatic access, it either namespaces something you’re told to look for (e.g. various types of domain markers) or it lets you discover a feature / endpoint.
In the latter case you just probe, for instance if you’re a password manager and you have a password for site A you hit A/.well-known/change-password and if they returns something you can surface a change password link to your user.
The one you found is for OIDC provider discovery (https://openid.net/specs/openid-connect-discovery-1_0.html#P...) so someone tells you they want to log in via Google, you hit that endpoint, and it lets you setup Google as an oidc provider rather without needing to hard-code providers. Even if you just want to support Google as a provider, you hit that and you get the entire configuration rather than have to hunt down the same information in the docs.
3 replies →
I agree. I was hoping for a few positive examples, but didn't see any. The only one I know of is the OIDC discovery endpoint.
I would say acme-challenge is one of the most used ones. How else would one get SSL certificates today
DNS TXT challenge for example. Also better because you can get wildcard certs.
6 replies →
Another one that is emerging is the A2A agent card https://a2a-protocol.org/latest/topics/agent-discovery/#1-we...
Slightly less well-known than XDG directories among the developers of Linux-targeted software, it would seem.
Seriously, what an oxymoronic name. "/index.html" is a well known URL, literally: most of web-developers are aware of it. But inventing a bunch of URLs with predefined semantics and then slapping the "well-known" label on it... well, it won't magically make them actually well-known.