Proof of Humanity (PoH) User Journey
Step 1: Enrolling into HP
Raw palm signature captured through user’s device
Phase 1: Palm print scan with visible light
Phase 2: Palm print scan with visible light + Palm vein scan with IR light
Encrypted palm signature undergoes unique-ness check by Identity Validator (Issuer)
If passed, proceed to the next step
Phase 1: Issuer = HP Core Platform
Phase 2: Issuers = Identity Validators, result based on consensus mechanism
Verifiable credential (VC) issued to User
Phase 1:
VC minted as NFT
VC metadata encrypted with user-controlled key (key is stored on key-share network based on Lit Protocol)
Encrypted VC transformed, enriched, atomized and stored on decentralized IPFS
User can grant/revoke access to encrypted VC to 3rd parties
Phase 2:
VC minted as NFT
VC metadata encrypted with user-controlled key (key is stored on key-share network based on Lit Protocol)
Encrypted VC transformed, enriched, atomized and stored on decentralized IPFS
User can grant/revoke access to encrypted VC to 3rd parties
VC issuance recorded on-chain
VC record added to VC database
Phase 1: VC database = HP Core Platform Credential Store
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
Notes:
VC database includes a list of revoked VCs
VC may have built-in expiration dates
Step 2: Using VC to gain access to Third-Party DApp
Humanity Protocol User requests access to DApps that are connected to HP either directly or through a bridge
DApp requests User proof of eligibility via smart contract call
User shares zero-knowledge proof to decentralized Humanity zkProofers
Direct sharing of non-PII VC
Indirect sharing of PII VC
User requests ZK verifiable presentation (VP) from HP Core Platform
HP Core Platform consults VC database to produce VP
HP Core Platform shares VP with Humanity zkProofers
Humanity zkProofers reach consensus and proceed to the next step if passed
Verification result recorded on-chain
DApp grant/reject access based on verification result
Step 3: Updating VC (for VC with Expiry Date)
Use notified of VC expiration when attempting to use VC to gain access to Third-Party DApp
User starts a new VC issuance process
Once new VC is issued, Identity Validator adds expired VC to the revoked VC list in VC database
VC revocation (reason: expiration) is recorded on-chain
Step 4: Deleting VC (for VCs that are stolen or lost)
User initiates a delete VC operation through dedicated smart contract on Humanity Protocol
Note: Data is not deleted from IPFS, but reference to the deleted VC will be removed from VC database
Issuer adds deleted VC to the revoked VC list in VC database
VC revocation (reason: user deletion) is recorded on-chain
Step 5: Identity Validator Revoking VC (for Protocol Violations, etc)
Identity Validator adds VC in question to the revoked VC list in VC database
VC revocation (reason: issuer initiation) is recorded on-chain
Last updated