It's a JSON array of public keys which you can use to validate a JWT which is what an OIDC token is.
Making it an array means you can rotate keys whenever but the validator is typically caching the public keys.
https://www.hanko.io/blog/understanding-jwks
Actually... found it https://datatracker.ietf.org/doc/html/rfc6749
And here's a PHP implementation that is perfect. https://github.com/thephpleague/oauth2-client
1. User enters hostname (or comes in from a QR code or TXT record or whatevs)
2. Client requests GET https://<hostname>/.well-known/<servicename>
3. This either redirects to the canonical base path of the service, which then can be queried itself for instances, or it directly returns a JSON/XML/whatever array of instances of the service on this server, and their respective base paths
This is a lot better than assuming the service must be the document root (forcing service discrimination into the hostname) or assuming it can always have /<servicename>/ as a base path.
That said, I still find it very bizzare that it's so hard to find a tangible example to see how it is in practice.
The rfc has none. Another spec including the use of it has none. In the end only completed service provider/implementers show it.
Before programmatic access happens, it needs to be written by a human. Yet the whole thing feels so human-unfriendly.
Perhaps I am biased robots.txt sets a high bar on how easy it is to find and work with?