EOS Wallet Structure

Found this article online, might be helpful for ppl of the eos community to understand the EOS wallet structure.

Original source article written by VASA
Entrepreneur | Co-founder/Developer @TowardsBlockChain, an MIT CIC incubated startup

Original Source:

https://hackernoon.com/eos-101-getting-started-with-eos-part-2-2afbce4a8a05

Thanks to the original author for this explanation.

Wallets

Wallets are clients that store keys like we see in the above diagram. These keys may or may not be associated with the permissions of one or more accounts. For instance, each of the 3 keys above is associated with an account. key1 is associated with owner permission level whereas key2 and key3 are associated with active permission level of the account.

Ideally, a wallet has a locked (encrypted) and unlocked (decrypted) state that is protected by a high entropy password. The EOS repository comes bundled with a command line interface client called cleos which gives you an interface with which you can interact with a lite-client called keosd(EOSIO wallet daemon that loads wallet related plugins).

Accounts

An account is a human-readable name that is stored on the blockchain. It can be owned by an individual or group of individuals depending on permissions configuration. In the above case, the account is owned by an individual(person holding key1). An account is required to transfer or otherwise push a transaction to the blockchain.

Every account in EOS can be referenced by a unique human readable name of up to 12 characters in length, given by the account creator.
Now, to understand the significance of permission structure we have to understand actions and handlers.

Actions and handlers

Each account can send structured Actions(for eg. sending some steem to another account on Steemit) to other accounts and may define scripts to handle Actions(for eg. getting notified on receiving steem) when they are received.

The EOS.IO software gives each account its own private database which can only be accessed by its own action handlers. Action handling scripts can also send Actions to other accounts. The combination of Actions and automated action handlers is how EOS.IO defines smart contracts.

Authorities and Permissions

As we have seen above, there are many actions that can be performed. Also, multiple keys are associated with each account, for different actions. This can be a real mess to handle.

Fortunately, the permission structure is capable to handle this mess. Let’s see how.

Authorities determine whether or not any given action is properly authorized.

Every account has two native named permissions

owner authority symbolizes ownership of an account. There are only a few transactions that require this authority, but most notably, are actions that make any kind of change to the owner authority. Generally, it is suggested that owner is kept in cold storage and not shared with anyone. owner can be used to recover another permission that may have been compromised.

active authority is used for transferring funds, voting for producers and making other high-level account changes.

In addition to the native permissions, an account can possess custom named permissions that are available to further extend account management. Custom permissions are incredibly flexible and address numerous possible use cases when implemented. Much of this is up to the developer community in how they are employed, and what conventions if any, are adopted.
Permission for any given authority can be assigned to one or multiple public keys or a valid account name.