Allow wallets to proceed with signed requests when the signature verification fails/can't be performed but the user wants to proceed anyway?

[jogu]

As per Martijn's comment #356 (comment) - namely:

Shouldn't we also extend this to scenarios where the wallet does not verify the signature but still decides to continue, e.g. because it cannot, because it doesn't want to or another reason.

[Sakurann]

I don't think the spec should make a decision on this. For example, under eIDAS 2.0, RP authentication is mandatory, so compliant wallets MUST NOT ignore the signature when it is present. we could add a note or something saying "the wallet must make a decision whether it can ignore the request signature based on the regulations, policy, etc." We need to discuss in the WG, but I think OpenID4VP has largely been written with the assumption is that if the request is signed and the wallet cannot validate it, it throws an error.

[David-Chadwick]

But consider TLS and web browsers. Sometimes when the browsers throw an error it's only because the web site's certificate has expired, so the user knows this and wants to proceed anyway. And most browsers will let them. "The user knows best". So I suggest that wallets should do the same thing. Warn the user but let them proceed if they want to. So I suggest "the wallet must make a decision whether it can ignore the request signature based on the regulations, policy, user choice etc."