Allow the wallet to choose how to get the public key to authenticate the request and the client

[awoie]

The current specification imposes limitations on how the wallet must authenticate the client and where to retrieve the public key to verify the signature of a signed request. In scenarios where both the verifier and the wallet support multiple authentication methods, the wallet may not always have access to all the required options or trust points. This can lead to failed transactions and a suboptimal user experience.

To maintain security while improving user experience, we propose removing the client_id_scheme parameter and allowing the verifier to provide multiple authentication methods. The wallet would then be able to select from the supported and accepted options.

Proposal:

• Remove the client_id_scheme parameter.
• Allow the verifier to offer multiple authentication options for the wallet, specifically for retrieving the public verification key for signed request objects. It is up to the verifier to decide whether to provide multiple options, and the wallet can choose which options to accept.

PR #237 may address this need.

[jogu]

I'm not sure I understand the details of this proposal yet, but I can see two things that would need to happen in addition to removing client_id_scheme and allowing multiple authentication methods:

1. The verifier needs a way to be able to supply multiple x509 certificates, e.g. if it wants to authenticate using x509_san_dns and certificates from multiple countries/states (i.e. you can't specify multiple x5c headers, and although you can put multiple certs in a single x5c these must form a single chain)
2. The verifier needs a way to specify multiple client_ids as it may be trying to, for example, authenticate with both openid federation (requiring a client_id in the form https://example.com) and x509_san_dns (requiring a client_id in the form example.com) - or we need to redefine some of the client_id_schemes so a single client_id does work across all of them (but I'm not sure that's possible in practice)

[jogu]

#248 proposes what I think may be a more general solution.

[Sakurann]

resolved by #263 and #308