.. _keycards-vs-user-wallets: ======================== KeyCards vs User Wallets ======================== We introduce a seperate KeyPair for the :term:`Store` system, called a :term:`KeyCard`, which is only used to create `eth_typedData_v4 `_ signatures for the :term:`Store` system. This is to avoid the need to sign with the User :term:`Wallet`, which is a more convoluted and risky operation since it involves prompting the Wallet Software for verification. The *KeyCard* can be used without any direct user interaction since they are just used for signature creation, not writing to contracts/spending ETH. Musing on Storage ----------------- We are assuming **KeyCards** are generated locally and saved separately from the :term:`wallet`, accessible by our software, which is running in the browser. While the **KCs** are bound in access to the :term:`Store` and don't need to hold any ETH themselves, there still is a security risk of impersonation and malicious access to the :term:`Store` system if they leak. The following presentation gives a good overview of the different schemes to protect such data, namely localStorage and Web Crypto API: `Storing Cryptographic Keys in Persistent Browser Storage 2017.pdf `_ `This Article `_ is also good. It leads down a similar way, using a password in tandem with WebCryptoAPI to lock away JSON data in a pretty comprehensive way (stored at rest and not accessible from xss/injection attacks). Now, introducing another password would defeat the purpose of the **KeyCard**, which is blessed via the **Users** Wallet to begin with. Ideally we would find a way to retrieve the **KeyCard** key from the WebCryptoAPI with help of the Wallet maybe, like storing a symmetric key, or the **keycard** secret material itself at that point. For the time being and first proof-of-concepts we will use plain localStorage.