Managing Devices

server stuff
{:port 3001}start-serverport?
200pingport:port => 3001status?

Create Some Profiles

1false{:id1 96a76174-b9d7-454d-9978-dab6111b2b6f}noneno
2true{:id2 dadcbe01-6672-44a5-aacf-861bc80be50e}{:passphrase2 sadness marshy viper corral crabbing identify smartness escapade graves discolor garter compare eternal upright kinship crystal sibling stinging result}yes

Able to Invalidate First Device

The first device to register should be able to be invalidated without rendering the core identity unusable. This means that the first device to register must in fact create two sets of keys: one for the core identity of the person, and one for the device. This way we can invalidate the first device without losing the core identity information.

What this means practically is that we can only store core identity information in the device secure enclave. If a secure enclave isn't available, that device cannot be used to add other devices except using the passphrase approach.

Add Device

Using Account Passphrase

Upon registering my primary device (or anytime thereafter), I can cause my complete identity information to be sent to the server, encrypted with a generated passphrase. I protect that identity information by sending the passphrase, hashed, to the server along with the encrypted identity information and a unique username to help the server find my account.

If a device asks the server to register itself with an existing identity, all it need do is download the encrypted identity information. The new device can then decrypt the identity information and save it in secure storage for later use. The server won't allow us to download that information if we don't send the correct hash of our original passphrase with the request.

3:id2 -> dadcbe01-6672-44a5-aacf-861bc80be50e:passphrase2 -> sadness marshy viper corral crabbing identify smartness escapade graves discolor garter compare eternal upright kinship crystal sibling stinging resultExpected 'dadcbe01-6672-44a5-aacf-861bc80be50e' but got 'invalid-request/400/Profile already exists'
4:id2 -> dadcbe01-6672-44a5-aacf-861bc80be50ebad passphraseExpected 'Identity Unavailable' but got 'invalid-request/400/Profile already exists'

Using Random String

This approach is necessary if the user has not chosen to save their identity information to the server.

I should be able to register another device. This is how it should work behind-the-scenes:

  1. New device generates identity and encryption keys as normal
  2. Existing device generates human-readable random string that authorizes new device to register its keys with user profile, submitting said string to server (which must not ever leak the string to the outside world) with an expiration timestamp
  3. New device receives user ID and auth string from existing device without using the internet (like QR code, etc)
  4. New device submits add_device request to the server with user ID and auth string, signed with device private signing key
  5. Existing device polls server for device registrations, and, when the registration for new device arrives, uses that device's public encryption key to encrypt core identity information and send it to server
  6. New device waits for core identity information to be available and then downloads it from the server, which promptly deletes said info once successful

This creates a hub-and-spoke architecture of profile information.

5:id1 -> 96a76174-b9d7-454d-9978-dab6111b2b6ffalseExpected '96a76174-b9d7-454d-9978-dab6111b2b6f' but got 'db9ff05d-50e4-43f8-ac65-01d8c1ea69b2'
6:id1 -> 96a76174-b9d7-454d-9978-dab6111b2b6ftrueExpected 'Token expired' but got '0cddf6b8-8d8d-4a97-88b2-e3b858fad961'

Manage Profile from Any Device

Manage Dream from Any Device

Others Validating Messages from My Device

Others Encrypting Messages to My Device

Invalidate a Device

Messages from Invalid Device Before Invalidation

Messages from Invalid Device After Invalidation

server stuff
stoppedstop-serverport:port => 3001result?