Authentication abstraction for improved security of users' private keys

[paulperegud]

We do not really want to solve the problem of security of users' private keys ourselves. So, lets enable usage of existing solutions with our chain.

1. hardware tokens - abstracted away by Metamask and likes
2. multisig wallets - ?
3. Universal login - ?

To address both multisig and UL, I propose authentication abstraction. Everywhere where we use addresses of owners, we use type address today. It uses 20 bytes out of 32 bytes (smallest storage accounting unit).

1. Use bytes32 instead of address to indicate owner of tokens
2. Pack 20 bytes of owner's address into 20 least significant bytes of bytes32 field
3. Use 21. byte as a ID of AuthenticationScheme contract, with value zero reserved for plain addresses.
4. AuthenticationScheme implements only one view call - it takes the hash of the signed transaction, the address and the part of the witness which contains the signature(s) and verifies them against contract at address.

Every AuthenticationScheme contract handles particular type/version of multisig/UL. Since we can't expect multisigs to implement an API where you provide a hash of signed message and signatures, we implement them just as Vaults for particular token standards. In case of gnosis multisig - read owners of the contract, read required and check the correctness of the signatures provided.

EDIT: On Ethereum side we treat calls where msg.sender == owner as authenticated. This allows multisigs and UL to initiate exits and play exit games.

@boolafish @pgebal @pik694

[boolafish]

We would need to know where to exit to though. IDK, AuthenticationScheme would be able to provide where to exit? Previously this info would either be owner or outputGuard.

[paulperegud]

We would need to know where to exit to though. IDK, AuthenticationScheme would be able to provide where to exit? Previously this info would either be owner or outputGuard.

Good point! In case of multisigs that would be the address of the multisig contract itself. Not sure about UL. In worst case we can have a second callback for that.

[Pongch]

This might be a good place to explore some ERC implementation for these Auth schemes. UL is EIP 1028 http://eips.ethereum.org/EIPS/eip-1078.

Also keeping in mind that it is using the adopted proxy/ identity standard-725 and meta-transaction-1077 under the hood

http://eips.ethereum.org/EIPS/eip-725 http://eips.ethereum.org/EIPS/eip-1077

[boolafish]

Instead of introducing new "id" I would probably stick with outputGuard to hold the AuthenticationScheme ID + Authentication contract address. (so using hash instead of reserving bytes for ID)

The output predicate would knows how which authentication api interface to call by getting AuthenticationScheme ID from output guard pre-image. Or, we can even make each output predicate handles only one authentication api. So the output type would act as AuthenticationScheme ID.

[paulperegud]

Or, we can even make each output predicate handles only one authentication api. So the output type would act as AuthenticationScheme ID.

This is the exact scenario I want to prevent. Having separate predicates for settlement/signature, settlement/gnosis_multisig, settlement/parity_multisig, settlement/openzeppelin_multisig, etc.

Instead of introducing new "id" I would probably stick with outputGuard to hold the AuthenticationScheme ID + Authentication contract address. (so using hash instead of reserving bytes for ID)

That's definitely a possibility.