This is split out from openid/OpenID4VC-HAIP#133 :

For item 3 "what if verifier wants to pass multiple trust models, hoping one is supported by the wallet?"

This is implicitly mentioned in the WG10 ask since the 18013-5 request structure supports multiple RP authentication signatures.

Not having the ability to support multiple RP authentication signatures would mean that it's not possible to request documents that use different trust models, or request documents from issuers (e.g. regions) that have different trust models. Not having those abilities would be a significant limitation of the protocol.

Most of the consequences and possible solutions are similar to the ones mentioned in item 1, since having multiple RP authentication signatures seems to not be supported by the JAR specification.

The proposal addresses this by defining an array of verifier_authentication elements, each of which can contain a signature for a trust model. As the elements that are signed by these structures is dynamic (see item 1), this mechanism supports both the scenario of signing the encryption information, as well as also signing the vp_query.

This doesn't seem to be an mdl specific thing, there is a general problem that a verifier must submit a request to the wallet without knowing anything about the wallet, and, for example, obtaining an mdl regardless of where the mdl was issued/what wallet it is in means:

1. The verifier may support more than one client_id_scheme and cannot know which one(s) the wallet(s) installed on the user's device support (e.g. for mdl USA states likely require x509_san_dns, some parts of the EU may well use OID Federation instead, and for non-mdl cases there may be even more deviation - this may also mean that the client_ids differ as, for example, there isn't a client_id that is valid for both x509_san_dns and openid federation)
2. For each client_id_scheme, the verifier may have more than one way to authenticate, e.g. for x509_san_dns they may have a x509 certificate suitable for use in California and a second one suitable for use in the EU.