72/WAKU-RLN-KEYSTORE: add new RFC

content/docs/rfcs/72/README.md

@@ -86,37 +86,39 @@ There COULD be multiple credentials stored in a keystore, categorized by the `me
 Each contruct MUST include the keypair:
 > key: [`membershipHash`]: pair: [`WakuCredential`]
 
-### membershipHash 
+### membershipHash
 
-The `membershipHash` SHOULD be generated by user's participating in a membership group.
+The `membershipHash` SHOULD be generated by user's participating in a membership group, 
+as decribed in [32/RLN-V1](/spec/32/).
 Each user SHOULD register to the group with an `identity_commitment` stored in a Merkle tree.
-A cryptographic hash function that SHOULD be used to generate the `membershipHash` is [SHA256](https://www.rfc-editor.org/rfc/rfc4634.txt).
+A cryptographic hash function that SHOULD be used to generate the `membershipHash` is [SHA256](https://www.rfc-editor.org/rfc/rfc4634.txt),
+other hash functions MAY be used.
 The hash function that is used,
 SHOULD be mentioned in the `verison` attribute.
+
 To generate the `membershipHash`, 
-the `treeIndex`, `membershipContract`, `contractId` and `identityCredential` attributes SHOULD be used to create a hexadecimal string.
+the `treeIndex`, `membershipContract`, `chainId` and `identityCredential` attributes SHOULD be used to create a hexadecimal string.
 - it MUST NOT already exist in the keystore.
 
-#### treeIndex
+#### `treeIndex`
 
 After a user registers to a group, 
 a `treeIndex` value of the position in the Merkle tree SHOULD be returned.
 - it MUST be a Merkle tree data structure filled with `identity_commitment` from user registrations.
 - it MUST be a hexadecimal string
 
-#### membershipContract
+#### `membershipContract`
 
 For decentralized membership registrations, 
-the `membershipContract` SHOULD be derived from a public blockchain using smart contracts. 
-- it MUST be a hash of a `contractAddress`
-- `contractAddess` MUST be a string.
+the `membershipContract` SHOULD be a `contractAddress` from a public blockchain using smart contracts. 
+- it MUST be a string.
 
-#### contractId
+#### `chainId`
 
-The `contractId` SHOULD be the blockchain identifier used for `membershipcontract`.
+The `chainId` SHOULD be the blockchain identifier used for `membershipcontract`.
 - it MUST be a string
 
-#### identityCredential
+#### `identityCredential`
 
 The `identityCredential` MUST be derived after a succussful decryption of the keystore.
 
@@ -138,14 +140,17 @@ as a private input for zero-knowledge proof generation.
 - This secret hash SHOULD be kept private by the user.
 
 ##### `identity_commitment` 
-- it MUST be created with `identity_secret_hash` by using hashing function as described in [Poseidon Paper](https://eprint.iacr.org/2019/458.pdf). 
+- it SHOULD be created with `identity_secret_hash` by using the hash function Poseidon,
+as described in [Poseidon Paper](https://eprint.iacr.org/2019/458.pdf). 
 - it MUST be used by a user for group registering.
 
-### `WakuCredential`
+### WakuCredential
 
-The `WakuCredential` will store values used for encrytion and decrypting user's credentials.
+The `WakuCredential` will store values used for encryting and decrypting user's keystores.
 - it MUST be used for password verification.
-- it MUST follow [EIP-2335](https://eips.ethereum.org/EIPS/eip-2335) 
+- it MUST follow [EIP-2335](https://eips.ethereum.org/EIPS/eip-2335)
+- it MAY use [SHA256](https://www.rfc-editor.org/rfc/rfc4634.txt) as the hash function
+
 
 ### KDF
 
@@ -161,7 +166,7 @@ A `WakuCredential` object MUST include:
 | secret | key to be encrypted |
 | pubKey | public key |
 | path | HD, hardened derivation, path used to generate the secret |
-| checksum | hashing function | 
+| checksum | hash function | 
 | cipher | cipher function |
 
 ```js
@@ -187,29 +192,27 @@ crypto: {
 ```
 
 ### Decryption
-The keystore SHOULD decrypt a user's credentials using a password and 
-a Merkle proof, the `membershipHASh`, using PBKDF2 that returns the `decryptionKey` key.
+The keystore SHOULD decrypt a user's credentials using a password and the `membershipHash`, 
+using PBKDF2 that returns the `decryptionKey` key.
 The decryption key is used to verify the keystore is correct.
 - To generate the `decryptionKey`, it MUST be constructed from a password and KDF,
 as desrcibed in [ERC-2335: BLS12-381 Keystore](https://eips.ethereum.org/EIPS/eip-2335).
 - The `decryptionKey`, is derived from the cipher function and
 cipher parameters described in the KDF used in the keystore.
 
 ## Test Vectors
-### Input:
-Hashing function used: Poseidon Hash, as described in [Poseidon Paper](https://eprint.iacr.org/2019/458.pdf)
-
-`application`: "waku-rln-relay"
 
-`appIdentifier`: "01234567890abcdef"
-
-`version`: "0.2" 
-
-`hashFunction`: "poseidonHash"
-
-`password`: "sup3rsecure"
+RLN uses Poseidon hash algorithm to generate the `identityCredential`, 
+as described in [Poseidon Paper](https://eprint.iacr.org/2019/458.pdf).
+The keystore hash algorithm used is [SHA256](https://www.rfc-editor.org/rfc/rfc4634.txt).
 
+### Input:
 
+- `application`: "waku-rln-relay"
+- `appIdentifier`: "01234567890abcdef"
+- `version`: "0.2" 
+- `hashFunction`: "poseidonHash"
+- `password`: "sup3rsecure"
 
 ```js
 
@@ -269,7 +272,6 @@ version: "0.2",
       },
     }
 
-
 ```
 
 # Security Considerations