field-manual icon indicating copy to clipboard operation
field-manual copied to clipboard

Device migration - Exporting/Importing identities

Open JustMaier opened this issue 5 years ago • 7 comments

I've created an app using OrbitDB and I'd like to give my users the ability to migrate an identity they started on one device to another. After reading the brief explanation in the README, I'm still not sure about what that process would be. Any help would be appreciated.

I was hoping to do something like this:

  1. Primary device opens a migration page that starts a unique pubsub channel.
  2. Primary device generates a QR code/link that secondary device can use to join the pubsub channel
  3. Secondary device joins and appears in a list for Primary device to select
  4. Primary device selects the secondary device and sends Identity for import via custom protocol
  5. Secondary device receives the identity offer and is given the option to import

So far all of that is pretty straight forward other than 4 and 5 that include exporting/importing OrbitDB identities.

JustMaier avatar Jul 02 '19 21:07 JustMaier

Hi @JustMaier, using the same identity on a different device could lead to consistency problems in OrbitDB since it assumes all public keys are unique per node.

What we're aiming for is to have the notion of a 'root' identity (eg Primary device identity) and generate new identities for each device which get linked with the root identity (by signing the respective public keys). In the case of orbit-db identities, there is currently no support for doing this without somehow copying the root identity keys over to the secondary device. In order to achieve this without copying keys we would need sth like the following:

  • Secondary device receives primary device public key (identity.id on primary device)
  • SD generates a new key-pair, signs PD public key and sends the signature (lets call it PDPublicKeySignature) and SD public key to PD
  • Primary device receives PDPublicKeySignature and SD public key and signs the concatenation (SDPublicKey + PDPublicKeySignature) and sends the signature to SD.

(identity.id would be the 'root identity pubkey', identity.publicKey is the device-specific public key,identity.signatures are the signatures proving ownership of both)

Now SD has the information is needs to create an identity which is linked to PD's identity and should be able to write to db's to which PD has write-access. Is this helpful?

shamb0t avatar Jul 03 '19 10:07 shamb0t

@shamb0t that's helpful, and the process is clear, however, since I'm not super familiar with OrbitDBs verification process I'm not completely sure what the modified verification process would be like. Is there an example of this anywhere?

JustMaier avatar Jul 03 '19 20:07 JustMaier

Sure thing, the two items that need to be checked are the signatures in identity.signatures. I believe the verification process wouldn't be modified in this case.

Verifying that identity.signatures.id is a valid signature of identity.id by identity.publicKey can be seen here (proving ownership of identity.publicKey)

The other check is to prove ownership of identity.id, you can see an example here which checks that the signature stored inidentity.signatures.publicKey is a valid signature of identity.publicKey + identity.signatures.id by identity.id.

shamb0t avatar Jul 04 '19 10:07 shamb0t

Thanks @shamb0t, that's helpful. I'll take that and see if I can implement the migration

JustMaier avatar Jul 08 '19 13:07 JustMaier

@JustMaier How'd it go? I'm going to move this over to the Field Manual so we can create a chapter or tutorial with more details.

aphelionz avatar Sep 27 '19 15:09 aphelionz

@aphelionz I started taking a stab at it, but sadly, the work needed to make it happen exceeded the time and energy I was willing to spend on the project. Sorry :(

JustMaier avatar Sep 30 '19 21:09 JustMaier

No problem, thanks for checking in again anyway :)

aphelionz avatar Sep 30 '19 22:09 aphelionz