Exactly WebAuthn Owner Plugin security record

The ERC-4337 states the following for signature validation: > If the account does not support signature aggregation, it MUST validate the signature is a valid signature of the `userOpHash`, and SHOULD return SIG_VALIDATION_FAILED (and not revert) on signature mismatch. Any other error MUST revert. This requirement states that `SIG_VALIDATION_FAILED` should only be returned on a failing signature, i.e. one that does not match the expected value and all the other cases should revert, which is when the signature is malformed or invalid. Due to the unknown nature of ERC1271 signatures, to return `SIG_VALIDATION_FAILED` for all failing signature validation is a valid approach that was also taken by the Alchemy team. However, the behaviour can be aligned for ECDSA and P256 signature validations. The following errors should revert instead of returning `SIG_VALIDATION_FAILED`: 1. `ECDSA` 1. Invalid Signature Length 2. Invalid Signature `S` value 2. `WebAuthnAuth` 1. Invalid Signature `S` value 2. Invalid `r` value

One of the options for signatures for the owner is an ECDSA signature. In the current setup, it is possible to have 2 valid signatures for the same data/`userOpHash`. In the context of Ethereum signatures, the `s` value represents a critical part of the signature along with the `r` value. These values are calculated during the signing process using the private key of the sender and are meant to be unique for each signature. However, due to the mathematics of elliptic curve cryptography, it's possible to have two `s` values that are valid for the same `r` and message. This arises from the fact that elliptic curves operate in a cyclic group modulo `n`, where `n` is the order of the curve. Both `s` and `-s mod n` can be valid for the same `r` and message, even though they are numerically different. The value `v` is used to determine if the expected value is `s` or `-s mod n`. This functionality of the signature means that there could be 2 valid signatures for the same data. This causes issues in most systems, so it is a common practice to limit the `s` value to the upper quadrant of the elliptic curve so that only one `s` value can be accepted. This is currently not the case with the signature verification logic.