Clarify that signed requests for DC API should be rejected if the signature can't be verfied

[GarethCOliver]

It'd be good to call out that, if the wallet can not verify the signature for the signed version (A.3.2), then they must reject the request. As we were implementing this, initially we assumed that falling back to how we handle the unsigned case would make sense. However, because the origin is not included for signed cases, it would be vulnerable to replay attacks in ways that unsigned is not.

At least to me, this wasn't clear from reading A.3.

It'd be nice (IMO) if an unsigned request, and a signed request that can't be verified by a wallet had the same security properties and would be a motivation for including the origin in all cases.

[c2bo]

If that kind of downgrade is wanted, couldn't you in theory just change the client_id to web-origin: in the response? That way you would still include the platform-provided origin in the response and keep the same security assumptions as a standard unsigned flow.

That would also clearly signal to the RP that the wallet was not able to verify the trust framework it provided and it downgraded to the unsigned flow.

Somewhat relevant issue: #362