# DPKI - Distributed Public Keys
> ## Key Management // Identity and Identity Recovery
-----------
**First piece of three Holochain identity services.**
1. **DPKI** does key management for actually ensuring continuity of control of your keys and source chain.
2. **Personas** lets you control your identity data and provide profile mappings to allow selective and revokable access to your data
3. **Validation/Assertions/Trust Graph** enables collection of third party validation or assertions about identity and reputation.

--------

## User Seed and Key Generation
### Registration of User Seed and Master Keys on the DPKI (occurs during Holochain Installation):

## Types of Seeds:
>- Revocation Seed (RevSeed)
>- Generator Seed (GenSeed, Master ID Seed)

## Levels of Keys:
>- Revocation Keys : Directly created from the RevSeed

sequenceDiagram

Participant DHT
Participant User Local Chain
Participant HIP44
Participant DPKI
Participant User
    DPKI -->> User : Request Registration
    User -->> DPKI : genEntropy()
    DPKI -->> User : Request Password
    User -->> DPKI : genPassword() 
    DPKI -->> HIP44 : Provide Password
    HIP44 -->> HIP44 :genRevSeedMnemonic(entropy) (24 words)
    HIP44 -->> HIP44 :genRevSeed(password, mnemonic)

    HIP44 -->> DPKI :Returns RevSeed and RevSeedMnemonic
    HIP44 -->> HIP44 : makeHash(RevSeedMnemonic)
    HIP44 -->> HIP44 : pick word from RevSeedHash via modulo
    DPKI -->> User : Provides RevocationSeedMnemonic to User
    HIP44 -->> HIP44 :genIdMasterSeed(revocationSeed)
    HIP44 -->> User Local Chain : Returns IdMasterSeeds(revocationSeed)
    User Local Chain  -->> User Local Chain : Store IdMasterSeeds(revocationSeed)
        
    HIP44 -->> HIP44 : genIdKeys(app)
    HIP44 -->> DPKI : Returns Public Keys for app
        Note  over DPKI : Store Master Keys in the local chain
        
    DPKI -->> DHT : Publish Public Key and to DHT (Header)

## Registration of new dApp on the DPKI

**Decision to be made:**
- Where and when is the registration called ?
- [ ] During app installation
- Will need to work with core
- [ ] After app installation :
- Passing parameters

sequenceDiagram

Participant HIP44
Participant DPKI
Participant dApp
    dApp -->> DPKI : Request to register(APP.DNA.HASH,dApp.Agent.HASH)
    DPKI -->> HIP44 : registration(APP.DNA.HASH,dApp.Agent.HASH)
    HIP44 -->> HIP44 : registerApp()
    NOTE over HIP44 : if the dApp_Type is registered check if the APP_Account is registered too. if not create a new APP_Account. if the app is not registered create a new dApp_Type
    

--------
## Types of Package(s):

- HIP44: This is our cryptography tool package for generating RevSeeds and GenSeeds and their corresponding Priv/Pub. Key Pairs.

--------
## Gossip Identity Verification Process:

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.

## N(M) Process:
>- 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.

## Indentification Process
### Need :
To verify if the Agent is the same as the agen on the other app

- verifyAgents()
- valadateAgent()

sequenceDiagram

Participant DPKI
Participant App

    
    

## Other notes on Identity:

- ADR - Key/Identity Management (https://hackmd.io/VIVvRD9gQ5KnDy_C-y6leA)

## Revoking a Key

### Lost Key

### Compromised Key

### Getting a new Key

## Explained: Using a key in HoloChat

## DPKI Components
- Revocation/Acceptance of new keys
- Select Default Method:
- Rev Key / Rev Authority / M of N Sigs

sequenceDiagram

    Participant AppUI
    Participant AppDNA
    Participant DPKI_UI
    Participant DPKI_DNA

    
    AppUI->>AppDNA:d

- Override default method for a specific app

- Bridging from/to a holochain app
- Register a public DPKI key in ID string for an app
- Proof of control of private key:
- Run DPKI locally
- get(PubKeyHash) via DPKI API bridge to get the full key
- Encrypt(message, key)
- Bridge Call to DPKI with result=echo(encryptedMessage)
- check result =initial message before encryption

sequenceDiagram
    User -->> KeyMgtApp: ask for KeyMgtApp.App.Key.Hash 
    KeyMgtApp -->> User: KeyMgtApp.App.Key.Hash 
        Note over User: {"KeyMgtApp":"KeyMgtApp.App.DNA.Hash", "KeyRevocationAuth": KeyMgtApp.App.Key.Hash}
        Note over User: Stored as AgentId in chain and dht
    User ->> NewApp: Initialise
        Note over NewApp,KeyMgtApp: In Genesis code of NewApp call bridge to getGenesisPublicKey(). Uses KeyMgtApp App.Key.Hash
    NewApp-->>KeyMgtApp: Get Public Key
    KeyMgtApp-->>NewApp: Public Key
    Note over KeyMgtApp: Default Revocation method stored in KeyMgtApp
    NewApp -->> KeyMgtApp: Get default Revocation Method (linked from pubkey hash)
    Note over KeyMgtApp: Message is signed using private key
    KeyMgtApp -->> NewApp: Replies with Signed message or false if no default method
    NewApp->>NewApp: If false or if verifySignature(message,signature,pubkey) fails, throw error/return false in genesis
        Note over NewApp,KeyMgtApp: Error: "Invalid KeyMgtApp Key. Cannot confirm control of correlated private key."

- 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

--------
## Notes from the meeting (29/6)
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 the DPKI Experience More Friendly ?
**( How to make Key managemnet compatable with humans ? How to make the user experience Smooth ? )**

- Install Holochain
- Push an option to to convince the user to set up the revocation key and revocation method (Leave 1 i.e. self revocation method).
- Give the options of MofN when they have friends (Level 2)
- Use tools that are know to people Like (Creating Seeds) to make it seem relatable and easy to understand
- Use the **Revocation key Seed** to get the **Revocation method Seed** So that it has better security and less seed for the user to hold

### After the revocation (How can you change the Keys ?)
**NOTE : We don't send the private key over the wire.**
- Can't pass the keys over the wire ?
- Have the installer hcd get the new keys and Install the app

### How to Sync Two same apps are the same person
- ??
- KeyGen should be a System level function (So you dont have to generate and then pass it over the wire)

### Other random things I remember
- Membranes based on level of security/recover implemented
- M choose N would be a good way to incentivise users to get their peers to install Holochain
- Revocation private keys could be generated and stored in existing hardware wallets that follow the BIP39 standard
---------

## Notes from the meeting (3/7)

Had more clarification on the proposed ADR for Identity and Key Management

- https://hackmd.io/VIVvRD9gQ5KnDy_C-y6leA

-------