Privacy milestone discussion

[peersky]

This thread is for discussing privacy milestone: https://github.com/peeramid-labs/multipass/milestones/1/edit

Problem statement

Currently Multipass architecture assumes all user name handles are public.

There may be use cases when user may want to put this data in encrypted format.

For example:

vitalik.eth and vitalik.twitter may be public handles, yet vitalik.telegram may be token gated access feature, allowing only specific NFT holders to obtain information

Design considerations

1. Decentralized Identity and Data Storage

• Ceramic: Use Ceramic to store the private data associated with each user. Each user would have their own Ceramic stream, which can be controlled by their DID (Decentralized Identifier). This stream would store key-value pairs, where the key is the bytes32 identifier for a specific platform (e.g., bytes32("telegram")) and the value is the user's handle on that platform.
• Lit Protocol: Integrate Lit Protocol to encrypt the private data stored on Ceramic. Can create a Lit access control condition that requires the user to hold a specific NFT to decrypt and access the data.

2. Smart Contract Modifications

• Add a new field: Include a new bytes32 field in smart contract to store the Ceramic StreamID for each user. This StreamID will point to the user's private data on Ceramic.
• Modify existing functions: Update existing lookup functions to first check if the requested data is public or private.
  • If public, retrieve the data directly from the smart contract as before.
  • If private, retrieve the user's StreamID from the smart contract, then use this StreamID to fetch and decrypt the data from Ceramic using Lit Protocol.

3. User Experience

• Connect Wallet: Users connect their wallet to dApp, which allows to retrieve their DID.
• Grant Access: For private data, users need to prove they hold the required NFT to satisfy the Lit access control condition.
• Retrieve and Display Data: Once access is granted, the dApp fetches and decrypts the data from Ceramic and displays it to the user.

Registrar Workflow with Encrypted Data

• Data handling: The registrant encrypts the private data using Lit Protocol with the appropriate access control conditions (e.g., requiring an NFT).
• Registrar Decryption: Then he provides this encrypted data to the registrar, together with Lit Protocol access condition to decrypt data.
• Identity verification: The registrar performs their usual checks to verify the registrant's real-world identity.
• Signing: The registrar signs the hash using their private key as in public workflow. This creates a digital signature that is uniquely linked to both the registrar and the encrypted data. Returns it to user
• Registration on multipass: User submits signature from registrar along with DID & encrypted data
• Proofs of transmitting data: zkPoD or TLSNotary may be used to ensure that user pays for registrars efforts to decrypt via Lit Protocol as well as that Registrar acts honestly

Example Flow

1. Vitalik.eth registers his Twitter handle (vitalik.twitter) publicly in Multipass contract (receives a registrar signature on public data).
2. He also adds his Telegram handle (vitalik.telegram) privately, storing it encrypted on Ceramic with a Lit condition requiring a specific NFT for access.
3. Provides the encrypted data and his real domain identity information to the registrar.
4. The registrar verifies identity at specified domain, signs the encrypted data and returns his signature to Vitalik, who then submits it to the Multipass
5. Someone queries dApp for Vitalik's Twitter handle. The dApp retrieves it directly from the smart contract.
6. Another user queries for Vitalik's Telegram handle. The dApp retrieves Vitalik's StreamID from the smart contract, then attempts to decrypt the Telegram handle from Ceramic.
7. If the user holds the required NFT, Lit Protocol grants access, decrypts the data, and the dApp displays it. Otherwise, access is denied.

Advantages of this approach:

• Privacy: Sensitive information is encrypted and only accessible to authorized users.
• User Control: Users control which information is public and which is private.
• Flexibility: Can easily add more platforms and data types to the system.
• Decentralization: Leverages the decentralized nature of Ceramic and Lit Protocol.

Considerations:

• Gas Costs: Fetching data from Ceramic and decrypting it with Lit Protocol will incur gas costs. If Lit and Ceramic settle on same network, optimisation on payment may be done?
• Complexity: Integrating Ceramic and Lit Protocol adds complexity to project. Need to carefully consider the user experience and ensure the process is seamless.
• Security: Must properly implement access control and encryption to protect user data.

Open questions

1. Vendor selection

Is Lit protocol and Ceramic best combination? Will they work?

FHEnix is interesting alternative, yet not clear if that would be very gas efficient.

2. Can registrar sign based on ZK proof?

Assuming that registrar already knows real Vitalik ID, all he needs is to check that encrypted data indeed WOULD resolve to his id if decrypted.
Having ZK proof would allow save computation load on Lit Protocol as well as simplify the access control condition there.

3. Registrar <-> user communication proofs

is implementation of Registrar <-> user communication proofs via zkPoD or TLSNotary (i) doable, (ii) required from game theoretic standpoint, (iiI) what implications are to multipass smart contract requirements?

[peersky]

Based on user feedback, we have to prioritise this milestone before we can actually deploy to test network.

Users shall be able to maintain their privacy by selectively disclosing those eligible to receive their handle on network.

Such can be done as token gated access. For a simplest yet scalable implementation we can allow users to specify mint their identity tokens. as ERC1155.

Since Ethereum address space is actually less than ERC1155 token ID space we can use one ERC1155 token representing ID tokens, and use offset to represent token action type (depending on token action type users might be required to: hold / lock / burn / pay ).

Using this approach, we actually are able to create a

1. Unified ecosystem (single token, e.g. can be managed by DAO)
2. Tokenised Personal Identity disclosure rules