The Zippie Vault is composed of an open source services layer in the Zippie platform, which uses an application interface layer (i.e. Vault API) to allow dApp developers to interact with the Vault for signature and encryption of arbitrary data. The Zippie OS also provides a Zippie Web3 provider object to the Zippie Vault via the API, allowing connection to the Zippie infrastructure and interaction with Web3 dApps through that ethereum node.

[Add diagram of Vault, web3 and vault API]

Options to get inspired from:

See: Link to Zippie Vault API Link to Zippie Web3 provider

How does it work?

The Zippie Vault stores and manages a users’ digital identity and access to it by 3rd party applications. A users’ digital identity from the vaults perspective is a master seed, which is used to derive a tree of encryption and message signing keys for various purposes. This feature also defines what devices are allowed to have access to this master seed by the user to perform authenticated operations.

Each of a users’ device has two keys, an authentication key and a local device key. The users’ master seed is split into two slices, one of which is stored remotely on a server but encrypted against the devices’ local key.

The other slice is stored locally, and encrypted against the same device key. When the vault is required to do an operation that requires the master seed, usually for private key derivation for a cryptographic operation like ethereum transaction signing, the encrypted remote slice is retrieved from the server, decrypted and combined with the local slice. It is then used and dereferenced as soon as the operation is complete in order to reduce the time that the master seed is stored in memory in its unencrypted form.

What is the Zippie Vault?

Zippie Vault is a web browser based key chain using IFrames allowing the creation of application specific asymmetric cryptographic keys based upon a master seed.

It is important to note that the master seed is only pulled when a new dapp is used or when a signature, encryption or decryption is required. It is never stored. Also, each dApp has a separate derivation key tree, generated from the hash of its URI. Therefore, each dApp has its own set of public keys.

The Zippie Vault also acts as a trusted intermediary for interacting between different vault enabled web applications, to allow limited and permissioned access to client side web APIs.

The Zippie vault is composed of a set of instantiated objects in the vault constructor and a series of plugin components. Additionally, a series of asynchronous functions allow the vault to create user identities, register and/or revoke devices (e.g. smartcard) associated with the identity, sign in applications to the vault, among other functions.

Additionally, an API and web3 provider are available to interact with the vault and access the ethereum network, respectively.

Using the Zippie Vault API

The Vault API is the main application interface to interact with the Zippie Vault.

Vault key management functions:

  • Sign: cryptographically signs a particular hash or piece of data for a particular purpose and vault derivation key path. See Key Paths and BIP32 derivation.
  • Encrypt: requests the vault to encrypt a message or piece of data, using an encoded hex of public key.
  • Decrypt: requests the vault to decrypt an encrypted message.
  • Get Key Info: get the public key and extended public key for a particular purpose and vault derivation key path. This is dApp specific pubkey information.

Using Zippie web3 provider

The Web3 provider object allows a developer to easily access the ethereum network using the Vault Keys, in a way similar to Metamask. This service will sign ethereum transactions locally and relay them to Zippie’s hosted ethereum node @zippie/vault-web3-provider.

This service connects to the Zippie infrastructure through websockets and allows keys in the dapp’s key tree to be used as just another Web3 account.

For more information on Zippie web3 provider see Developer Documentation