Summary: Human ID is best understood as privacy-preserving identity-verification infrastructure that lets issuers verify a person once, then lets the user prove narrow facts about themselves without revealing the full underlying identity. Its core mechanism is a three-party credential flow — issuer, user, consumer — combined with zero-knowledge proofs and app-readable SBT/API surfaces for things like uniqueness, residency, sanctions status, age, or accredited-investor checks. That makes Human ID a useful comparison class for Ethereum Attestation Service, Sign Protocol, Verax, ONCHAINID, and Semaphore because the key control surfaces are not only schema design, but also issuer trust, KYC-provider visibility, proof policy, per-action uniqueness rules, and the way compliance facts are exposed to apps without publishing raw identity data.
What it does:
Lets issuers issue credentials after identity verification and lets users later prove selected facts from those credentials without disclosing full identity details
Supports developer integrations around government-ID/KYC, sanctions or clean-hands checks, phone credentials, biometrics, and ePassport-based verification
Offers a user flow where developers direct users to Human ID issuance pages or embed the Human ID SDK to request an SBT / credential flow from within their app
Exposes verification to applications through an API and, in older flows, directly through onchain contracts that check whether a user is unique or satisfies a given property
Uses per-action uniqueness logic to support Sybil-resistant airdrops, voting, grant distribution, and similar one-person-one-action use cases
Sits inside the broader human.tech framework, where Human Passport and Human Network extend the surrounding personhood, recovery, and cryptographic-key infrastructure
Key claims:
The Human ID docs describe it as a privacy-preserving identity protocol that uses zero-knowledge proofs so users can prove facts about themselves without revealing the whole identity, which is the clearest reason to classify it as compliance-proof middleware rather than as a generic KYC service
The architecture overview defines three explicit actors — user, issuer, and consumer — and centers the system on issuance plus selective proving, which makes the trust model much clearer than projects that present identity as a vague attestation layer
The integration docs show that the common implementation pattern is credential issuance plus an app-readable SBT/API check, which means Human ID is designed to be consumed as application middleware rather than as a standalone identity wallet
The docs say proofs can cover residency, non-US status, accredited-investor status, over-18 checks, sanctions-related clean hands, uniqueness, and one-time governance or airdrop participation, so the mechanism is not just login but programmable compliance and admission control
The developer docs recommend a default action ID and note that proofs are once-per-ID by default to reduce Sybil attacks and bribery, which is analytically important because identity uniqueness is scoped and policy-shaped rather than universally portable in one undifferentiated credential
The documentation-generated answer on trust surfaces says issuers and identity providers remain trust anchors, KYC providers may still see the user during verification, and consumers verify proofs or SBTs without needing the raw credential, which helps separate privacy-at-proof-time from the upstream trust concentrated in verification and issuance
The broader human.tech site frames Human ID alongside Human Passport and Human Network, while the Human Network repo describes threshold cryptography and OPRF-based key/identity primitives; taken together, this suggests the long-run strategic surface is broader identity, personhood, and key-management infrastructure rather than one narrow proof API
Whitepaper: No standalone Human ID whitepaper was located during this pass. The main primary-source packet is saved at ../whitepapers/human-id-primary-sources-2026-05-09.md.