وَلَا تَجَسَّسُوا
wa lā tajassasū — “and do not spy on one another.”
Security architecture
Even our admins can’t see what you’re using the passport for.
Most SSO providers’ promises live in their privacy policies. Ours live in the data model. The infrastructure is built so that the questions admins would be tempted (or compelled) to answer about individual users do not have answers in our databases. We see aggregates. We do not see you.
Zero-admin-visibility architecture
Five properties, each verifiable in the open-source code.
- 01
Pairwise pseudonymous subject identifiers + user-chosen handles
Every relying party (app you sign into) receives a different opaque user ID for the same user. The ID Ihsan Standard sees for you is different from the ID a Muslim mental-health app sees for you, even though both are signed in as the same UmmahPassport account. Cross-app correlation requires a court order plus knowledge of the salt we generate per-user; the salt itself is encrypted at rest with a key only the user's session can derive. On top of this, you can set a per-app display handle on first sign-in — the app sees only the handle you chose plus the per-app hashed identifier, never your real name or your UmmahPassport-wide identity. You can be "abu-yusuf" on Ihsan Standard and "reader-2718" on a different app, and the apps cannot link the two.
- 02
Encrypted activity logs
Auth events ("user signed into app X at time T") are encrypted at rest with a per-user key derived from a password / passkey. Admins running database queries see ciphertext, not your activity. Decryption happens only inside your authenticated session and the audit log you can view on your own dashboard. There is no admin tool that shows "give me all of user U's auth events."
- 03
Aggregate-only telemetry
What admins can see: "X auth events to client_id=ihsan this week," "Y users with active sessions globally," "Z token-introspection failures." What admins cannot see: which user signed into which app at which time. Aggregate stats are computed via differential-privacy techniques (Laplace noise on small bucket counts) so a single user is never derivable from the aggregate.
- 04
Sealed admin endpoints
Admin actions that involve user-specific data (a user requests their data export, a court order is served) require a two-key ceremony: one key held by the technical council, one by the user's recovery passphrase. Neither party alone can decrypt without the other's cooperation. This is the same shape as a Shamir-secret-sharing two-of-two scheme — it eliminates the single-admin compromise risk.
- 05
Open-source verifiability
Per Charter §VI, the cryptographic primitives, the encryption-at-rest implementation, and the SSO server itself are open source. Any cryptographer can read the actual code and verify that the properties above are not just claimed but implemented. This is the difference between "we promise" and "check for yourself."
What this means in practice
Government subpoenas UmmahPassport for “all users who signed into client_id=advocacy-app in March 2026”? UmmahPassport can produce an aggregate count. Producing individual identities requires (a) the per-user salt, which is not stored in our database in plaintext, and (b) the user’s active session, which expires within hours. Lawful compulsion against the company cannot produce information the company architecturally does not hold.
Anti-abuse · proof of personhood
Privacy and Sybil-resistance, both at once.
A privacy-first SSO is meaningless if a single attacker can spin up a million accounts. We use a tiered model: anyone can create a basic identity; higher-trust operations require higher tiers of verification; each tier’s verification leaks the minimum possible information to UmmahPassport. The tiers below balance friction against abuse-resistance.
Tier 1 · Basic identity
Every account, including free.Requirements
- •Verified email address (a unique email = one account; bouncing addresses block sign-up).
- •Per-IP and per-email rate limiting on account creation.
- •Standard CAPTCHA on signup (hCaptcha / Cloudflare Turnstile, both privacy-respecting).
- •Sliding-window abuse detection — bursts of signups from the same IP block, ASN, or device-fingerprint trigger review.
What it unlocks
Basic UmmahPassport identity. Sign in to apps in the network. View public Ihsan Standard org pages.
Tier 2 · Verified human
Required for community-trust features.Requirements
- •Phone number verification (one phone = one Tier-2 verification; phone number is stored salted-hashed, not in cleartext).
- •WebAuthn / passkey set up (eliminates the password-reuse attack vector entirely).
- •Account in good standing for ≥ 30 days.
What it unlocks
Vouching, ability to submit org-page suggestions on Ihsan Standard, posting in community-moderated forums (when shipped), participating in mutual-aid pools.
Tier 3 · Vouched member
Web of trust — vouched for by N existing Tier-2 members.Requirements
- •Three Tier-2-or-higher members vouch for you within a 90-day window. Vouchers stake their own trust score on your behavior.
- •Alternative: in-person verification at a registered masjid that operates the NoorMap Tier-3 verification ceremony (Phase 2 roll-out).
What it unlocks
Eligibility for community-leadership roles in network projects, higher-trust operations like cross-org coordinator volunteers in Crisis Response.
Tier 4 · Notable Verified
Identity-verified for accountability-bearing roles only.Requirements
- •Government ID + selfie verification via an Ihsan-Standard-vetted third-party identity-verification provider. The provider sees the ID; we receive only a yes/no "verified, here's a hash of the name as one-way fingerprint" — never the ID document itself.
- •Limited to scholars on advisory boards, named org-rep claimants, members of the technical or scholar councils.
What it unlocks
Authoritative attestation on org-rep claims (you can publicly attest on behalf of an org); eligibility for council roles; ability to publicly vouch for Tier-3 candidates.
The masjid-attestation pathway
For users without a passable government ID, or who do not want to share one even with a verification vendor, the alternative path is in-person attestation at a registered masjid running the NoorMap verification ceremony. A masjid representative signs a vouching credential with the masjid’s registered key after seeing the user in person. The credential becomes Tier-3 equivalent without any document ever leaving the masjid. This pathway is being built jointly with the NoorMap project.
Security program
Operational rigor matching the architectural rigor.
Open-source code
SSO server + RP SDK + security-sensitive code published under MIT. Continuous public Git history. Security researchers can read every line.
Annual third-party penetration test
Independent security firm engaged annually; report published in summary form. Critical findings remediated before report publication.
Bug bounty
Standing program with payouts scaled to severity. Coordinated disclosure standard; researchers credited.
Cryptographic key management
Production keys held in cloud HSM (AWS CloudHSM-equivalent on a non-Google-non-AWS host; or on-prem HSM). Rotation quarterly; previous key retained for in-flight token verification.
Incident-response protocol
Charter-published incident playbook. User-affecting incidents disclosed within 72 hours per GDPR-equivalent standard regardless of jurisdiction.
Per-jurisdiction data residency
EU users opt into EU-hosted identity. North American users on North-American-hosted (non-US-cloud-provider option available). Other regions added as the network grows.
Where we deliberately do NOT host
Infrastructure choices that follow from the threat model.
- ✕Not on Google Cloud Platform. Project Nimbus, Project Maven, the announced Palantir AIP partnership.
- ✕Not on Microsoft Azure. JWCC, HoloLens IVAS, the announced Palantir Foundry partnership.
- ✕Not on AWS GovCloud.The CIA C2S / C2E platform and Palantir Federal’s primary deployment surface.
- ✕No third-party tracking SDKs. No Google Analytics, Meta Pixel, TikTok Pixel, Hotjar, or session-replay vendors on UmmahPassport pages.
- ✓Hosted on independent infrastructure. Options include Hetzner, OVHcloud, and DigitalOcean for North American / European hosting; comparable independent providers per region. None of these vendors hold the contracts above.