Trust is Math, Not Policy
How HUMΛN Passport ensures identity integrity through cryptographic enforcement — even when the code is open source and self-hosted.
How It Works
A HUMΛN Passport is valid only if it can prove four things:
1. Private Key Possession
Every Passport operation requires an Ed25519 signature from the device's Secure Enclave. The private key never leaves the device hardware. Not even HUMΛN can access it.
WebAuthn/FIDO2 ensures the key is bound to a physical authenticator (Face ID, fingerprint, security key). Software-only keys are flagged as lower attestation quality.
2. Device Attestation
The WebAuthn ceremony includes attestation metadata from the device. This proves the credential was created on a real device with hardware key storage — not fabricated by a server.
Attestation formats (packed, tpm, apple) are classified by quality: self (none), device (hardware-backed), and platform (App Attest / Play Integrity).
3. Ledger Anchoring
When a Passport is minted, the DID + public key + attestation hash are anchored to the ledger. Any deployment verifying a Passport checks this anchor.
A self-hosted deployment that fabricates a Passport fails here — the DID was never anchored by a legitimate device ceremony.
4. Delegation Chain Integrity
Every API credential traces back to a Passport through a cryptographic delegation chain. Breaking any link in the chain invalidates the entire authorization.
Delegation tokens are signed JWTs with explicit scopes, expiry, and the issuing Passport's DID. Tampered tokens fail signature verification.
Self-Hosted Deployments
What Deployments CAN Do
- Register Passport via device ceremony (WebAuthn)
- Store public records (DIDs, public keys)
- Issue delegation tokens from existing Passports
- Verify incoming delegation tokens
- Enforce tier policies on their endpoints
- Serve the compliance endpoint for transparency
What Deployments CANNOT Do
- Access private keys (hardware-bound, never exported)
- Mint Human Passports server-side (requires device ceremony)
- Forge attestation data (signed by device, not server)
- Create credentials that pass ledger verification
- Override delegation chain cryptography
- Impersonate another deployment's Passports
"Can't Someone Just Modify the Code?"
Yes, they can — and that's by design. Here's why it doesn't matter:
The Attack Scenario
A malicious operator forks the code, removes WebAuthn requirements, and creates "Passports" with server-generated keys. What happens?
No device attestation
The forged credentials have no hardware attestation data. Any verifier can detect this.
No ledger anchor
The DIDs were never registered through a legitimate ceremony. Ledger verification fails.
Walled garden only
The fake Passports work ONLY within the modified deployment. They cannot interoperate with any other HUMΛN deployment. This is equivalent to running a private server with made-up accounts — it affects nobody else.
Breach Blast Radius
Traditional Identity System
Server breach = all accounts compromised. Centralized database with passwords/tokens. Blast radius: entire user base.
HUMΛN Passport
Server breach = public records only. Private keys are hardware-bound and never on servers. Blast radius: local deployment only, no key compromise.
Why Open Source Makes This More Secure
Counterintuitively, open-sourcing the code strengthens security:
Auditable by Anyone
Security researchers, enterprises, and the community can verify that the protocol does what it claims. No black boxes.
Trust is in the Math
Cryptographic enforcement doesn't rely on code secrecy. The same Ed25519, WebAuthn, and hash functions are used by billions of devices daily.
Compliance is Verifiable
Every deployment exposes a signed compliance endpoint. Other nodes can verify a deployment's behavior without trusting it.
Verify for Yourself
The code is open. The math is public. The compliance endpoint is live.