---
3ip: 3
title: 3ID HD path
author: oed@3box.io
discussions-to: https://chat.3box.io
status: Draft
created: 2019-04-09
---

## Simple Summary
This document specifies the HD path (see bip32) used in the upcoming 3ID system. It enables automatic generation of keys for *3Box Spaces*, reducing the amount of secret key material needed to be stored by the user.

## Abstract
Currently 3Box requires users to sign a new message for all spaces that an app wants to access. This is fine for a first version, but we'd like to make the user experience better. In order to achieve this we define a Hierarchical Deterministic path for deriving keys for spaces based on the space name.

## Specification

The binary representation of `3ID` is `051073068`, we remove the first zero to get our purpose number
```
m / 51073068' / persona' / app-path' / key-type
```

#### persona
To begin with we will just use 0 here. In the future we can add support for multiple personas by incrementing this number for each new persona.

#### app-path
The app path is based on the hash of the name of the space. Current spaces have only a string as their identifier. We will encode these spaces as: `<name>.3box`. All other spaces will be based on their ENS domain e.g. `a.space.eth`.

We take inspiration from EIP1775 to come up with a way to derive a path from the name.

For the applications's path we use sha256 of of the app name.

For example `a.space.eth` results in the hex string:
`6a86ff32df2e248c263c69f97eae66b0e75ee8059584fda579e84edf678c010d`

Below follows an exert from EIP1775 with instructions to decompose a hex string to a derivation path.

---
This requires to first convert the hex uid to 256 bits then decompose it as 8 * 31 bits + 8 bits

`x = x0 || x1 || x2 || x3 || x4 || x5 || x6 || x7 || x8`

where `x0` to `x7` are 31 bits and `x8` is 8 bits

then we convert the x_i to uints.

The derivation sub-path would be: `x0'/x1'/x2'/x3'/x4'/x5'/x6'/x7'/x8'`

---

For the root-store the derivation path is simply `0'/0'/0'/0'/0'/0'/0'/0'`

#### key-type
We have multiple different key types, all of them server different purposes. Below is a list of all the currently specified keys.

* `0` - signing key
* `1` - management key
* `2` - asymmetric encryption key
* `3` - symmetric encyprtion key
* `4` - db salt

`0` is the main authentication key and is used for signing things on behalf of the user. `1` is the key used to do key rotations for the DID. `4` is used as a salt for hasing the the *key* in all encrypted key-value store.

## Copyright
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
