Add client_id_scheme based on .well-known

It would be beneficial to introduce a client_id_scheme that

• enables the client to sign Request Objects using a key indirectly trusted via TLS/browser PKI.
• allows the client to provide its metadata via a .well-known endpoint rather than in the request itself without prior registration or federation.

Currently, the only method for implementing request signing leveraging browser PKI is by using client_id_scheme=x509_san_dns, which can be quite cumbersome to implement. Clients would need to acquire another certificate from a browser CA for request signing. Additionally, on some platforms, accessing the list of trusted browser CAs outside of a user agent might involve more friction. Acquiring an extra certificate would also takes extra monetary and operational costs. Furthermore, certificates acquired from existing browser CAs typically include X509 extensions optimized for TLS, not for request signing.

Compared to client_id_scheme=redirect_uri, a new scheme based on well-known would allow the signing of requests which redirect_uri does not allow.

A new client ID scheme based on .well-known that includes the jwks/jwks_uri client metadata offers a more straightforward option for implementing the verification of the Request Object's signature.

Proposal:

• Introduce a new Client ID scheme value: well-known, e.g., client_id_scheme=well-known.
• Define it as follows:
  • client_id MUST be an HTTPS URI controlled by the client.
  • The wallet MUST fetch the client metadata from <client_id>/.well-known/client-metadata.
  • Client metadata from the client_metadata parameter take precedence over metadata found at the .well-known location except for the signing keys of the request objects.
  • Authorization requests can be signed or unsigned. If signed, then the verification keys MUST be provided in the .well-known client metadata.

No repository files or tests are identified in the issue. Start by reviewing the existing client_id_scheme behavior and the proposal's well-known metadata rules; done means the new scheme, HTTPS client_id requirements, metadata precedence, and request-signing key requirements are defined and covered by the project's relevant validation or protocol tests.