Identity and Access

Identity and Access

Primary identifier

• Email is the unique id for every adult account.
• One email = one adult account — no duplicate emails.
• Minors: subprofiles under linked guardians (Onboarding). Younger minors have no independent login; older teens may have their own credentials while still subject to parental oversight until adulthood (see Minor accounts and parental control).
• Shared family email: at signup, direct each adult to their own email; children are added as family profiles without email.

Authentication (v1)

Deferred profile/account work (OAuth, email verification, 2FA, avatar upload, field edit policy): Planning backlog — Profile and account.

Method	v1
Email + password	Yes
Google OAuth	Yes
Apple Sign In	Yes
Magic link	No
Church SSO (SAML/OIDC)	Later (sso_later)

Web tokens: HttpOnly cookies (Sanctum). Mobile uses token-based Sanctum flow.

Bot protection (v1)

• reCAPTCHA v3 on login and register when RECAPTCHA_SECRET_KEY is configured (optional in local dev when keys are unset).
• Client sends recaptchaToken on login and register GraphQL mutations; server validates score against a configurable threshold.
• reCAPTCHA is abuse friction, not identity proof. Operator smoke: Production smoke checklist.

Trust and identity verification (later)

Progressive trust: bot friction → account hygiene (email verification, 2FA) → humanity signals → identity proof (IDV) before high-trust social features for users without a church exemption. Personal study and onboarding are not blocked.

Church exemption paths: paying tenant member, ChMS-verified membership at link, or church admin vouch. Full spec: Identity verification.

Church association

• Optional always at signup.
• Required only when using church-specific features (later).
• Linking methods: invite code + ChMS OAuth (Planning Center / Breeze) when integrations ship.
• After link: Garrison Bible Study is authoritative for profile; ChMS used for membership verification and SSO only.
• If ChMS is unavailable: users with existing accounts can still log in (degrade_cached).

Permissions model

• ABAC (attribute-based): permissions derived from attributes (church, group, phase, relationship), not only fixed role names.
• Global admin roles (shipped): stored in user_role_assignments (role, scope_type = global, scope_id null). Capabilities are checked in UserAuthorization — not a single is_platform_admin boolean.
• Laravel authorization policies + capability checks on GraphQL resolvers; church-scoped roles remain deferred.

Global roles (v1)

Role	Capabilities	Admin UI
Platform administrator	All curriculum capabilities plus user management, audit log, feature flags, AI config/usage, plan assistant	/admin dashboard, users, audit, flags, AI
Curriculum designer	View/edit curriculum, submit and review changes, publish after approval	Curriculum map, tracks, plans, quizzes, outcomes, rubric, review queue

Platform administrators bypass the curriculum review gate on publish and merge. Designers cannot access platform-only routes.

Assignment: platform administrators call setUserGlobalRole (PlatformAdmin or CurriculumDesigner, enabled). At least one platform administrator must remain.

Church-scoped roles (mentor, church admin, moderator): deferred — same user_role_assignments table with scope_type = church when shipped.

Households (later feature, decided model)

• Linked accounts: each adult has their own login; guardians link child subprofiles.
• Multiple guardians: any guardian linked to a minor may impersonate, approve mentors/contacts, and view oversight data.
• Split households: for now, either linked guardian may act (approve, impersonate)—no requirement to pick a primary parent in product.
• Spiritual leadership / family tooling builds on this model (post–v1).

Minor accounts and parental control

Guardians have full authority over minors linked to them until the minor becomes an adult (age of majority; system-derived from date_of_birth). After adulthood, parental impersonation and oversight end; the account is a normal adult account.

Life stages

Stage	Independent login	Guardian oversight	How the API recognizes it
Young minor (e.g. under 13 / no email)	No — no credentials in the minor’s name	Full; child use is full impersonation only	is_minor = true, row in guardian_minor_links
Older teen (“old enough” for own credentials)	Yes — own email/credentials	Continues until adult: guardian may impersonate (full or partial) and see data	is_minor = false, row in guardian_minor_links, date_of_birth under age of majority
Adult	Yes	None — guardian link and impersonation removed or disabled	is_minor = false, no guardian_minor_links (or links removed at transition)

Exact age for “old enough” independent login: minors.independent_login_minimum_age in API config (default 13); must satisfy COPPA and regional rules. Age of majority: minors.age_of_majority (default 18).

Storage and derived status (API)

Do not use is_minor to mean “under 18.” Login blocking, teen accounts, and content/parental gates use different signals:

Mechanism	Meaning
is_minor	Blocks independent login for young dependents (subprofiles without their own credentials). Set when a guardian creates the subprofile—not derived from date_of_birth on self-serve adult signup. Login and registration reject these accounts until teen credentials are enabled.
guardian_minor_links	Pivot (guardian_user_id, minor_user_id) linking guardians to dependents. Any dependent under parental oversight has at least one row. Multiple guardians per minor are allowed.
date_of_birth + config	Derive under age of majority for content gates, parental oversight, and teen detection (is_minor false + guardian link + DOB before majority).

Teen account (product term): has a guardian link, is_minor is false, and DOB is before the configured age of majority—the user may sign in on their own while guardians retain oversight.

v1 self-serve signup requires 18+ (Onboarding); adults therefore register with is_minor false and no guardian links until household subprofile flows ship.

Account type and PII (guardian-controlled)

To minimize PII for minors, the guardian chooses the minor’s account type when creating or managing the subprofile—not the child during signup.

Principle	Detail
Guardian sets account type	Type defines which identifiers and profile fields are collected, required, shown, and shared (e.g. display label only vs legal name, no email vs teen email when eligible).
No self-serve PII from child	Minor-facing flows must not prompt for email, full name, photo, or other PII the guardian has not already authorized via account type and guardian entry.
Type may change over time	Guardian may upgrade type (e.g. when enabling teen login) after explicit guardian action; downgrades or removals follow deletion/anonymization rules.
Adult transition	On adulthood, the account becomes a normal adult account; the user then controls their own profile fields per standard onboarding.

Store minor_account_type (or equivalent) on the subprofile; enforce field requirements and APIs from that type. Exact type labels and field matrix: define at implementation (Architecture Questions).

Impersonation modes

Guardians may act on a minor’s account in two modes:

Mode	UI / identity	Purpose	Gamification & “login side effects”
Full	User appears as the minor	Hand device to child; child uses the app as themselves	Streaks, habits, and session activity accrue to the minor, not the guardian
Partial	User remains the guardian	Parent reviews or manages child data without “becoming” the child	Does not trigger the guardian’s own streaks, habits, or other per-login mechanics; read/manage child scope only

Full impersonation (child use):

• Server session: guardian_user_id + acting_as (minor) + impersonation_mode: full.
• Child-facing UI must not allow logout, account switch, or leaving impersonation without guardian authorization (re-auth, household PIN, or explicit end from the guardian’s own session).
• Guardian remains accountable in audit logs.

Partial impersonation (guardian oversight):

• Server session: guardian identity with viewing_minor_id (or equivalent)—not acting_as for writes that should attribute to the child.
• No locked “child exit” UX (guardian is already themselves).
• Use for dashboards, approvals, and read-only or guardian-scoped actions without conflating parent and child activity metrics.

Teens with their own login use their session normally; guardians use partial to monitor and full when the child should operate as themselves on a shared device.

Implementation note (when built): separate session claims for impersonation_mode (full | partial); reject clearing full impersonation without a guardian-authenticated step.

Social graph and mentorship

Rule	Detail
Guardian controls contacts	A minor may message or interact only with people a linked guardian has allowed.
Church-proposed mentors	Church assignment is pending until a linked guardian approves.
Revocation	Any linked guardian may revoke approval; server blocks new activity immediately.
Split households	Either linked guardian may approve or revoke (for now).

Cross-links: Messaging (mentor/mentee threads), Groups and Community (church-scoped assignments).

Spiritual phase and maturity (v1)

Profile field edit policy after development (locking spiritualPhase, read-only DOB): Planning backlog — Profile field edit policy.

Field	Store	Who sets	Used for
spiritual_phase (milk / transition / meat)	Yes	Self-assessment at onboarding	Fixed global curriculum
date_of_birth	Yes	User; guardian for minor subprofiles	Age of majority, teen vs adult, content/parental gates
gender	Yes (onboarding)	User	Mentorship pairing rules; editable in dev via profile
guardian_minor_links	Yes (pivot)	Guardian	Link guardians to dependents; identify teens and oversight scope
minor_account_type	Yes (minors)	Guardian	PII minimization; field requirements
is_minor	Yes	Guardian on subprofile create (young dependent)	Block independent login only—not “under 18”
adult_only on content	Yes	Platform	Hide from users under age of majority (DOB-derived)

• Phase curriculum definitions are fixed global (Domain Model).
• Mentor or church override of phase: when mentorship ships (store phase_source later).

Mentorship visibility

See Mentorship for pairing and study rules.

• Step discipleship lanes (mentee / mentor on mentored studies): visible to the active mentor–mentee pair.
• General study notes (not tied to a step lane): owner-private; mentors do not see them.
• Mentors may see mentee study progress (steps, titles, instructions) and mentee-lane content on those steps.
• Aggregates (streaks, time studied) remain the default mentor dashboard surface when built.
• Mentors may assign tasks (deferred); mentee sees completion status.
• Async chat uses Messaging (in-app, not SMS; deferred).

Account deletion

Data	On delete request
Private notes, profile PII	Deleted
Identity verification captures (ID/face media)	Deleted
Identity verification status log	Deleted or anonymized
Person record	Anonymized
Forum posts	Retained; author anonymized where required
Mentorship tasks / shared thread messages	Anonymized author (“Deleted user”); content kept for other party
Private mentorship-only drafts	Deleted

Document in privacy policy: shared discipleship records may remain in anonymized form. Legal review before mentorship launch is still recommended (not legal advice).

See Security and Privacy.