Key Management // Identity and Identity Recovery
First piece of three Holochain identity services.
- Revocation Seed (RevSeed)
- Generator Seed (GenSeed, Master ID Seed)
- Revocation Keys : Directly created from the RevSeed
Decision to be made:
Primary Revocation Key (48 words) >> generate 1.) Master Revocation Key and 2.) Master Identity Seeds ("GenSeeds", of 12 words each)
Set a Revocation Method for each particular key.
Updating Key Revocation method.
- For any change in the revocation
Instructions on how to choose ppl.
- Email,
- Call,
- Skype, etc.
- M friends are asked to sign the user's identity (their agent key)
- At the time of the revocation, user contacts the M friends to request the revocation
- At least N(M) friends then need to create revocation request to the user's DPKI
- Once N(M) friend hashs/agent keys have been received (that match the M number who originally signed the agreement to be the M users and attest to the user's identity at the time of the N(M) request) then new keys generated and pointed assigned.
To verify if the Agent is the same as the agen on the other app
Override default method for a specific app
Bridging from/to a holochain app
Unify identities across devices
Bind to HC identity services
"Proof" of key control across HC apps
Hold/reveal Assertions/Claims/Fields
Seed & HD keys
"Proof" of legacy identity services (email, FB, Twitter, github, google, phone, etc.)
OAuth provider for legacy web
We discussed the importance of user experience and how a well designed process can ensure the majority of users has good security and recovery protocols set up be default.
(node damaged or destroyed)
To do this we imagined using a key generation algorithm (BIP39?). This would allow a user to securely record and store a key phrase which can be used to regenerate their public/private key pairs. This would allow a user who lost their private key to recover it and resume using their apps.
(node stolen by bad agent)
It was discussed that this same key phrase could be used to generate revocation key pairs stored inside DPKI. This would allow a user posessing the key phrase to not only recover their app private keys but also revoke them to prevent a bad agent in possession of their device from permanently taking controll.
Finally we considered how to structure the communications between DPKI and a users apps. The main concern was that if a bad agent were to temporally take control of a users node they could use DPKI to discover all the apps which they are a part of. (Art explained why this is a bad scenario).
If the bridging calls go from DPKI to the peripheral dApps this makes it much easier to revoke all keys in the case of a compromise. It has the downside of revealing all apps that are bridged.
The alternative is that apps bridge TO DPKI. In this case a user must activate revokation from within all their apps, potentially 100s, but means their existance would not be revealed if DPKI was exposed.
Another option we partially explored is using multiple instances of DPKI (with different keys generated from the seed phrase) to bridge to different apps thus limiting the potential information a hacker could gain.
( How to make Key managemnet compatable with humans ? How to make the user experience Smooth ? )
NOTE : We don't send the private key over the wire.
Had more clarification on the proposed ADR for Identity and Key Management