Identity verification

Identity verification

Ensure real people on high-trust surfaces (mentorship, messaging, groups) without blocking personal study for users who have not yet verified. Complements existing reCAPTCHA bot friction; does not replace it.

See also Identity and Access, Security and Privacy, Onboarding, Integrations, Mentorship.

Scope: Post–v1 platform feature. Applies to adult self-serve accounts without a church exemption. Minors remain guardian-controlled (Identity and Access — Minor accounts).

Open design choices: Architecture Questions.

Goals

• Reduce bots, synthetic accounts, and impersonation beyond reCAPTCHA scores.
• Gate cross-user, high-trust features—not signup or solo study.
• Preserve user privacy: verify once, retain minimum data, delete captures promptly.
• Let paying or vetted churches shoulder vetting for their members instead of duplicating platform ID checks.

Progressive trust ladder

Growth is not blocked at signup (Product Scope). Trust requirements increase with feature risk.

Tier	What	When
Bot friction	reCAPTCHA v3 on login/register when configured	Signup / login
Account hygiene	Email verification, optional 2FA (backlog)	Sensitive account changes
Humanity signals	Engagement heuristics, rate limits, abuse flags — not identity proof	Ongoing; may trigger step-up review
Identity proof (IDV)	Photo ID + face match + liveness + anti-spoof + coarse location	Before high-trust social features for users without a church exemption

v1: reCAPTCHA only. Planned: IDV gates mentorship initiation/acceptance, in-app Messaging, Groups and Community, and similar cross-user surfaces. Personal study and onboarding complete without IDV.

Humanity signals (non-IDV)

Platform activity (study streaks, note creation, normal usage patterns) can flag suspicious accounts and prioritize human review. These signals do not substitute for IDV on mentorship or messaging; they may delay or trigger step-up verification.

Church exemption

Users linked to a church the platform trusts may skip platform IDV. Exemption is per user + church link, with an auditable exemption_reason. Church admins do not receive ID scans or capture media by default (Security and Privacy).

Path	When it applies
Paying church tenant	User is a member of a church on a paid B2B2C plan when billing ships
ChMS-verified link	User linked via Planning Center / Breeze OAuth with active membership at link time (Integrations)
Church admin vouch	Church staff explicitly approves the member (manual path when ChMS is unavailable)

flowchart TD
  user[User requests high-trust feature]
  user --> exempt{Church exemption?}
  exempt -->|Paying tenant member| skip[Skip platform IDV]
  exempt -->|ChMS membership verified at link| skip
  exempt -->|Church admin vouched member| skip
  exempt -->|None of the above| idv[Platform ID + liveness flow]
  idv --> allow[Feature unlocked on pass]
  skip --> allow

If a user loses church membership or the church stops paying, exemption may lapse; re-verification policy is TBD (Architecture Questions).

Verification flow (proposed)

Mobile-first; web camera fallback.

1. Document capture — User shows a government-issued photo ID to the device camera.
2. Face + liveness — User shows their face; system requires challenge-response movement (head turn, blink, or similar) to defeat static photos and deepfakes.
3. Matching and anti-fraud — Automated checks that:
   • Face on camera matches the photo on the ID.
   • Captures are not AI-generated, replayed, or otherwise spoofed (presentation-attack detection).
   • Session integrity is maintained (single continuous capture where feasible).
4. Location corroboration — Coarse check only (e.g. IP country/region vs document issuing country, or opt-in device location with explicit consent). Not continuous tracking; not public geo on profile. Precision and consent: Architecture Questions.
5. Outcome — Store verification result metadata (status, method, timestamp, optional expiry). Do not treat raw ID images as profile data.

Failed attempts may route to human review; vendor vs in-house pipeline is TBD.

Privacy principles

User-facing promise (update public privacy policy before IDV ships):

Principle	Detail
Data minimization	Collect only what is needed for a pass/fail decision
Short retention	Delete ID and face capture media after verification; brief operational window for dispute/abuse review only (e.g. 24–72 hours — exact window TBD)
No church visibility of artifacts	Church admins see at most aggregate or consent-gated “verified member” status — never ID scans
Transparency	In-flow copy: what is checked, what is deleted, verification is for safety—not marketing or surveillance
Account deletion	Verification artifacts and derived PII from ID (document numbers, address) deleted or anonymized with the account (Identity and Access — Account deletion)
Legal review	Biometric and government-ID processing requires legal review (GDPR, BIPA, regional ID acceptance, COPPA-adjacent flows)

Relationship to profile fields

Field	Policy
Email	Remains primary login identifier
date_of_birth	ID may corroborate 18+; does not automatically replace self-reported DOB from Onboarding without an explicit future decision
gender	Mentorship pairing uses self-reported gender; do not auto-override from legal sex on ID unless decided otherwise (Architecture Questions)

Implementation notes (planning only)

• Likely third-party IDV API or hybrid (vendor liveness + in-house policy). Self-hosted AI is possible but carries high cost and compliance burden — vendor choice is open.
• AI for verification automation (face match, spoof detection) is distinct from end-user LLM features (AI Guidelines — Identity verification AI).
• GraphQL fields, storage, and UI are not specified here; implement when mentorship/messaging gates ship.