Aleternative authentication methods for account contract

[piniom]

The recent work in this repository focused on developing alternative authentication methods for the account contract. E.g. we have a prototype method "somewhat" compatible with the webautn specification. Next step would be to allow this to be used as a real way of authenticating. This rises two connected questions:

1. Should we keep the current method as is, ensuring that the client code compatible with the original account contract is also compatible with the new one?
   I assume the answer to this is YES.
2. In what way do we introduce the new methods. More specifically:
   1. How do we differentiate between different authentication methods?
   2. How do we ensure backward compatibility?

Currently the authentication is done by invoking the __validate__(...) method which calls theis_valid_signature(...) method. The is_valid_signature(...) checks the signature (an array of two felts) against the transaction hash. On the rust side we sign the (known) transaction hash with the private key (here) and this signature is then send to the network (here).

Ad. 2.1 I see two solutions:

1. We keep a flag in the state of the contract that stands for the current authentication method. We may change this flag only with the current authentication method. When we change the authentication method to the new one the old one becomes invalid (at least to the point when we change the flag back again). In case of webauthn (and possibly in other) this becomes problematic since we loose access to the account should our authenticator break (eg. we loose the phone with the fingerprint sensor). We may have more than one authenticator so this could be mitigated.
2. We dynamically differentiate between authentication methods based on the contents of the signature array.

Ad. 2.2 The solution depends on the way we differentiate

1. If we keep a flag, then nothing changes if the flag is set to the "old" method.
2. If we differentiate dynamically, we may assume that if the signature has 2 felts then the "old" method is used. Otherwise we treat the first felt as a flag, and treat the rest of the array accordingly.

With both solutions the idea is that we can serialize everything we need for some new method to the signature array, and deserialize it when vallidating. We would also obviously need to develop a compatible rust code extending the SingleOwnerAccount.

Is there anything I've missed regarding the possible solutions or architecture of the network and its implicit limitations?

[tarrencev]

We should do 2. We dynamically differentiate between authentication methods based on the contents of the signature array.. That is how the current implementation works, the first element can act as a selector for the authentication method.

I'm not sure what is referred to as the "old" method? Generally, we need a stateless approach since state is expensive