Proof of Humanity (PoH) User Journey

Step 1: Enrolling into HP

1. Raw palm signature captured through user’s device

   1. Phase 1: Palm print scan with visible light

   2. Phase 2: Palm print scan with visible light + Palm vein scan with IR light

2. Encrypted palm signature undergoes unique-ness check by Identity Validator (Issuer)

   1. If passed, proceed to the next step

   2. Phase 1: Issuer = HP Core Platform

   3. Phase 2: Issuers = Identity Validators, result based on consensus mechanism

3. Verifiable credential (VC) issued to User

   1. Phase 1:

      1. VC stored on HP Core Platform

      2. VC metadata encrypted with user-controlled key (key is stored on key-share network based on Lit Protocol)

      3. Encrypted VC transformed, enriched, atomized and stored on decentralized IPFS

      4. User can grant/revoke access to encrypted VC to 3rd parties

   2. Phase 2:

      1. VC stored on HP Core Platform

      2. VC metadata encrypted with user-controlled key (key is stored on key-share network based on Lit Protocol)

      3. Encrypted VC transformed, enriched, atomized and stored on decentralized IPFS

      4. User can grant/revoke access to encrypted VC to 3rd parties

4. VC issuance recorded on-chain

5. VC record added to VC database

   1. Phase 1: VC database = HP Core Platform Credential Store

   2. Phase 2: VC database = HP Core Platform Credential Store (for PII VCs) + HP Smart Contract (for non-PII VCs, in the form of Merkle Trees), cross-verifiable

6. Notes:

   1. VC database includes a list of revoked VCs

   2. VC may have built-in expiration dates

Step 2: Using VC to gain access to Third-Party DApp

1. Humanity Protocol User requests access to DApps that are connected to HP either directly or through a bridge

2. DApp requests User proof of eligibility via smart contract call

3. User shares zero-knowledge proof to decentralized zkProofer Nodes

   1. Direct sharing of non-PII VC

   2. Indirect sharing of PII VC

      1. User requests ZK verifiable presentation (VP) from HP Core Platform

      2. HP Core Platform consults VC database to produce VP

      3. HP Core Platform shares VP with zkProofer Nodes

4. zkProofer Nodes reach consensus and proceed to the next step if passed

5. Verification result recorded on-chain

6. DApp grant/reject access based on verification result

Step 3: Updating VC (for VC with Expiry Date)

1. Use notified of VC expiration when attempting to use VC to gain access to Third-Party DApp

2. User starts a new VC issuance process

3. Once new VC is issued, Identity Validator adds expired VC to the revoked VC list in VC database

4. VC revocation (reason: expiration) is recorded on-chain

Step 4: Deleting VC (for VCs that are stolen or lost)

1. User initiates a delete VC operation through dedicated smart contract on Humanity Protocol

   1. Note: Data is not deleted from IPFS, but reference to the deleted VC will be removed from VC database

2. Issuer adds deleted VC to the revoked VC list in VC database

3. VC revocation (reason: user deletion) is recorded on-chain

Step 5: Identity Validator Revoking VC (for Protocol Violations, etc)

1. Identity Validator adds VC in question to the revoked VC list in VC database

2. VC revocation (reason: issuer initiation) is recorded on-chain