How Human Pass keeps
who you are out of it.

1 What Human Pass is

Human Pass is an OpenID Connect provider. A site adds a "Continue with Human Pass" button and, when a person signs in, receives:

• verified_human: true: the person verified a government photo ID, with a live selfie and face match, and no other Human Pass exists for that document
• sub: an ID for that person on that site only, the same every time they sign in
• an assurance level (acr) and the standard protocol claims

Nothing else. No name, date of birth, address, document, photo or email.

Human Pass is built so that three things stay true together:

1. One person, one account per site. The same person always gets the same sub on a site, so a site can enforce one account per person and make bans stick.
2. No tracking across sites. The same person gets unrelated subs on different sites, so sites can't combine what they know.
3. No identity data where it isn't needed. Sites never receive identity data. Human Pass keeps only what uniqueness and account security require.

2 The parties and what each one sees

The provider never learns which site a person came from. Each verification starts a new session with the provider, and nothing identifying the site is sent.

3 Sign-in and verification flow

1. The site redirects the person to Human Pass using the standard authorization code flow, with PKCE required and exact-match redirect URIs.
2. First time: the person creates a sign-in (a passkey, or an email and password) and confirms an email address with a one-time code. Then they verify once with the provider: a photo of the document, and a live selfie with liveness detection and a face match.
3. Human Pass receives the provider's result, derives the document fingerprint (section 4.2), decides whether this is a new person or one it already knows, and has the provider delete the verification, including images.
4. The person agrees to share with the site, once per site. The site receives a signed, short-lived ID token with the claims above.
5. Every later sign-in is just a sign-in, with no new verification.

Without a document result, Human Pass doesn't issue verified_human at all.

4 How the guarantees are built

4.1 Per-site IDs

A site's ID for a person is derived with a keyed one-way function from two inputs: the person's internal random identifier, which never leaves Human Pass, and the site's identity.

• The key is held in a hardware-backed key service and can't be exported. Without it, two IDs can't be linked to each other or to a person.
• IDs are computed when needed, not stored. Human Pass keeps no table of people and the sites they use (see 4.4).
• One organization's web and mobile apps can share an ID space; test and live environments never do. A site may only use sign-in addresses on domains it has proven it owns, so one site can't pose as another to collect its IDs.
• IDs carry a version marker, so the key can be replaced without two IDs ever being equal (section 6).

4.2 Uniqueness: document fingerprints

From the provider's result, Human Pass takes the document's type, issuer and number, puts them into a standard form, and derives a fingerprint in two steps:

1. A keyed one-way function, using a separate non-exportable key. Document numbers come from fairly small ranges, so an ordinary hash could be reversed by trying every number. With a secret key, nothing can be tried without the key.
2. A deliberately slow, memory-hard step. This is defence in depth for the worst case: someone who could both use the key and had a copy of the database. Each guess then costs real time and memory, which makes trying every number very expensive. It raises the cost; protecting the key and the database is what matters most.

The document's details exist only in memory for that computation and are never written: not to the database, logs, queues or error reports. There is nowhere in the database to put them.

If the fingerprint matches an existing Human Pass, the person is that Human Pass, with the same sub on every site. That stops one document from creating a second account, and it's also how someone who has lost every sign-in gets back in (section 5).

4.3 Email and sign-in data

• Email is required, so security notices always arrive. It's stored encrypted, and found by a separate keyed fingerprint rather than by the address itself. Staff never see full addresses.
• Passwords are optional, stored with a modern memory-hard password hash, and rate-limited.
• Passkeys are supported and recommended.
• Password resets are single-use, expire quickly, and only go to confirmed addresses. The reset page never reveals whether an address has a Human Pass.

4.4 No record of who uses which site

Human Pass keeps no table linking a person to a site:

• a person's consent is recorded against the site's ID for them, not against the person
• when a person asks which sites they share with, the list is worked out on request and not stored
• audit records never contain a person together with a site
• the sign-in session, which necessarily involves both, is short-lived and deleted after at most 12 hours

Accepted trade-off. To tell sites about suspensions and deletions (section 7), Human Pass publishes the affected person's status to every site, not just the sites they use, so the list doesn't reveal where they had accounts. It's also stored so that entries can't be grouped by when they were written. In a database breach, the IDs of one suspended or deleted person could still be grouped together, but that wouldn't reveal which sites they actually used.

4.5 What's stored, in summary

No document images, selfies, names, dates of birth or addresses.

5 Account recovery, and stolen IDs

A person who has lost every sign-in can verify their document again: the fingerprint leads back to their Human Pass, with the same sub on every site. That's also exactly what someone with a stolen document would try, so recovery is deliberately slow and visible:

• Holds. A sign-in added by verifying again waits 72 hours before it works. Each person can choose anywhere from a day to two weeks, or "only with my approval". Their existing sign-in keeps working throughout.
• Notices go to the existing email when it's added and again shortly before it activates, each with a one-click "Not you? Stop it".
• Undo. If a recovery replaces the email, the previous address gets a link that works for 90 days. It removes the new sign-in, restores the old one, signs out every session, locks recovery, and opens a case with support automatically.
• Disputes ("someone set up a Human Pass with my ID"). Pending sign-ins are paused. Either side can be asked to verify the document again with the provider's strongest available checks. A senior staff member decides, and every step is audited. If the claim is upheld, the document moves to a fresh Human Pass for the rightful owner and the old one is revoked on every site.

A stolen document still has to pass the provider's liveness and face-match checks against the document photo.

6 Key management and compromise

• One key per purpose. Site IDs, document fingerprints, lookups, encryption and audit each use a separate key with its own permissions, held in a hardware-backed key service and never exported. Only the production service can use them, and every use is logged.
• Offline backup. The keys whose loss would break the guarantees are also kept as an encrypted offline copy under split control, so losing a cloud key can't erase anyone's identity.
• Deletion protection. Keys can't be deleted or disabled outside a controlled emergency path, and attempts raise alarms.
• Database copies are protected like keys, since a key together with a database copy is the worst case. Backups are encrypted separately, can't be shared outside the production environment, and are never copied into development.
• If a key is ever misused, each key has a planned response:
  • Site IDs can move to a new key version without breaking integrations. For 180 days, a person's tokens carry previous_sub alongside the new sub, and the status API reports old IDs as rotated, with replaced_by. Sites can rehearse this in the sandbox before they go live.
  • Fingerprints can move to a new key as people verify again, without letting anyone create a duplicate in the meantime.
  • Token signing keys rotate with overlap through the published key set, and can be replaced within minutes.

7 What sites can rely on, and what they must do

• sub is stable for a person on your site. That includes after they recover their account, change how they sign in, or delete it and come back within the retention period (section 8).
• Two exceptions: merged, when two Human Passes turn out to be one person, and rotated, after a key change (section 6).
• The status API reports both, with replaced_by, as well as suspended, revoked and deleted. It only answers for your own IDs. Unknown and active IDs look the same, so it can't be used to probe other sites' IDs.
• Sites should:
  • store sub as an opaque string
  • move an account to the new ID when a token carries previous_sub
  • call the status API regularly, for example daily; the developer dashboard shows when each client last did

8 Retention and deletion

When a person deletes their Human Pass, sites see the status deleted for their sub.

9 Known limitations

We'd rather you hear these from us.

• Several documents, several Human Passes. Uniqueness is per document. Someone with a passport and a driver's licence can currently create two Human Passes. Each one means passing liveness and face match as the document holder, which limits the risk, but it's the main gap in "one person, one account". We're evaluating ways to close it.
• Human Pass is a trusted party. With its keys, Human Pass could link a person's IDs across sites. Everything in section 4 exists to make that hard to do and hard to hide:
  • no stored mapping between people and sites
  • keys that can't be exported, and every key use logged
  • staff tools that can't search by person, email, document or site
  • only lawful requests, approved by two people, can trace an ID to a person
• ID verification isn't perfect. We rely on the provider's document and liveness checks. A high-quality forged document, or someone coerced into verifying, may pass.
• It needs a government photo ID. That excludes some people. We plan to add more ways to verify, such as government digital ID wallets.
• Not yet done:
  • production infrastructure: the offline key backup, deletion protection and database-copy protections in section 6 are designed but not yet in place
  • an independent penetration test
  • SOC 2
  • final legal review of retention periods and privacy notices

10 Contact

Partners and integration: the contact form.