Thnkrr: Parental Consent at Onboarding

Research and decision record, 2026-09-15. Nothing in this doc is built yet. Scope: getting and verifying a guardian's consent when a student under 18 signs up. Parental monitoring, supervision and parental controls are out of scope by design. Where this doc and docs/05 §A5 differ, this doc is the newer decision; the older docs have not been edited yet (§10 lists every conflict). Not legal advice — §12 lists what counsel must confirm.

Tags: [Primary] = statute, regulator, court, or the company's own docs; [Reported] = credible press, law-firm or tracker summary; [Analysis] = our reasoning; [Unverified] = could not be confirmed as of 2026-09-15.

0. Summary

One flow for every country. A student under 18 names a guardian. The school checks that guardian against its own records before anything is sent. Only then does the guardian get an email, read a plain notice, and sign (tick + typed name) to confirm or decline. Indian schools add one step from 13 May 2027: the guardian proves they are an adult through DigiLocker. No card, ID, SSN or face checks. No Clever or ClassLink in the pilot.

Why this shape. Consent has to prove two things: the person is an adult, and the person is this student's guardian. An email to an address the student typed proves neither. Card, ID and face checks prove only adulthood. Only the school's records prove the relationship — which is why every school-partnered product researched anchors on them (§7) — and outside India, a parent or legal guardian on a school's records for a 13–17-year-old is an adult in practice [Analysis].

Why school first. If the email went out before the school checked, a typo or a made-up address would send a child's name to a stranger, and the consent request would become a harassment tool [Analysis].

What must change in the build. The current consent step is a stub with several flaws — most seriously, the guardian page confirms consent the moment it is opened (§9.2). The flow also exposes bypasses that exist today regardless of consent method: lying about date of birth, choosing an unlisted school, and self-verifying as an educator (§5).

1. Decisions (2026-09-15)

1.1 The one country switch

India, from 13 May 2027: the guardian proves they are an adult via DigiLocker on the consent page (§6.4). Keyed off schools.country, which already exists (default US). The start date is a config value, because a proposal to shorten the timeline exists though it was never notified.

Everything else in this doc applies to every school.

2. What valid consent needs — first principles

Every step in §3 exists to satisfy one of these. If a future change breaks one, the consent stops holding up.

3. The flow

3.1 Before any student at a school signs up

1. Pilot agreement signed. For US schools it includes a FERPA "school official" clause covering guardian verification (§6.3). Required, because the school confirms guardian details before the guardian signs anything — so a release inside the guardian's form cannot cover that disclosure.
2. Verifiers designated by Thnkrr. One or two named people per school (counsellor or administrator), granted by Thnkrr ops — never self-service (§5, bypass 3).
3. The school tells parents first, through its own newsletter or messaging, that a Thnkrr email will arrive. Otherwise the email reads like phishing.
4. Terms of Use and Privacy Notice published, translated into the school's main languages. Neither exists in the app today (§9.3).
5. Sending domain authenticated (SPF, DKIM, DMARC) so consent emails don't land in spam.
6. Indian schools, from 13 May 2027: DigiLocker integration live (§6.4).

3.2 Step by step

Step 1 — The student signs up.

• Role → date of birth → email and password → school (A2–A4, as today).
• The student agrees to the Terms and Privacy Notice themselves (R7).
• Then:
  • Under 18, partner school → Step 2.
  • 18 or over, partner school → the verifier confirms the age band (Step 3, no guardian).
  • Under 18, school not listed or not a partner → waitlist (§10, conflicts with docs/05 §7 and D-14).

Step 2 — The student enters their guardian.

• Guardian's name, relationship (parent, legal guardian, other) and email — or "my guardian doesn't use email", which routes to the paper form.
• Rejected on entry: the student's own email, any email that already has a Thnkrr account, the school's email domain, disposable-email domains.
• Nothing is sent to the guardian.
• The waiting screen shows two lines: School check — waiting · Guardian — not contacted yet.

Step 3 — The school verifies. The verifier sees one card per student:

• student name and grade;
• the age band the student claimed — under 18 or 18+ — not the date of birth (docs/04 §5.1: birthdate is never displayed);
• guardian name, relationship and email as entered.

They check the school's own records and choose:

The verifier screen says in plain words: confirm only what matches your school's records — not the student's word. Every verifier action is logged with who did it.

Step 4 — Thnkrr emails the verified guardian.

• Names the school ("Westfield High uses Thnkrr") and the student, says what Thnkrr is, and links to the consent page.
• The link is single-use, expires in 7 days, and belongs to this one request.

Step 5 — The guardian decides.

• The page opens with: You are [guardian name], [student name]'s [relationship].
• The notice, in plain words:
  • what Thnkrr is and that it is school-scoped;
  • what we collect about the student, and who sees what — classmates, educators (roster information only), adult college mentors;
  • that mentors never contact students first; students request them, and threads are moderated;
  • that everything written is screened by AI moderation run by a third-party provider;
  • that messages are kept and cannot be deleted (docs/10);
  • no ads, no sale of data;
  • how moderation and reporting work (Ohio asks for a moderation-features list [Reported]);
  • how to withdraw, and how to contact us.
• The guardian ticks "I am this student's parent or legal guardian", types their full name, and chooses Confirm, Decline or This isn't me.
• Opening the page does nothing. Only the buttons act.
• If the browser is logged in as the student, the page refuses: "This link is for your parent or guardian."
• Indian schools, from 13 May 2027: the DigiLocker adult check happens here, before Confirm counts.

Step 5P — Paper route (no email, limited English, no internet, or the school prefers it).

• Same notice on paper, in the guardian's language. The guardian signs.
• The verifier checks the signer against school records and marks Paper form received with a form reference. This counts as Steps 3–5 together.
• The school keeps the paper; Thnkrr keeps only the reference. File uploads are ruled out anyway (docs/13 §10 rule 4).
• India after 13 May 2027: counsel must confirm the paper route (§12).

Step 6 — Confirmation.

• The guardian gets a confirmation email with a withdraw link.
• The student is told their guardian confirmed.
• The account opens once email verification is also done (D-11).

3.3 When something goes wrong

N and M are product choices still to be set (§10).

3.4 Students with no guardian who can consent

• Emancipated minor: the verifier records the basis; the student consents for themselves.
• Foster care, kinship care, unaccompanied youth: the verifier records who holds authority under local law, and that person consents by email or paper. Counsel provides the short list of acceptable people per jurisdiction (§12).
• Custody disputes and protective orders: handled by the verifier's Doesn't match. Guardian details are visible only to the verifier, and one guardian never sees another's details.

3.5 After onboarding

• Turning 18: the guardian requirement ends automatically (D-11); the student confirms the Terms themselves once.
• Material change to what Thnkrr collects or who sees it: consent is tied to a notice version, so re-consent can be requested. Not needed for the pilot beyond storing the version.
• Stub-confirmed accounts are not consented. Any account confirmed by CONSENT_DEMO_AUTOCONFIRM must be re-consented or deleted before real students join.

3.6 What we keep, never keep, and delete

Keep (the consent record):

• student id;
• guardian name, relationship and contact (encryption: §9.4);
• source of the details — student-entered or paper;
• verifier id, time and outcome;
• notice version and language;
• decision (confirmed, declined, not me), time and typed name;
• Indian schools: that the adult check passed, plus the DigiLocker transaction reference;
• IP address and browser for the request and the decision, as keyed hashes (plain SHA-256 of an IPv4 address is brute-forceable);
• when each email was sent.

Never keep: ID images, card numbers, SSNs, Aadhaar numbers, the DigiLocker identity record (§6.4), or any school's guardian list.

Delete: pending, expired and declined sign-up data after N days (except the decline marker). How long the consent record outlives account deletion is counsel's number (§12).

4. Why school-first, and what it costs

Counsellor load [Analysis]: one review per minor. At roughly 30 seconds per student with the school's records open alongside, 1,000 students ≈ 8 hours. So roll out in waves or in supervised sign-up sessions, and expect no progress during school holidays.

5. Ways around consent, and what closes each

6. What the law requires

6.1 US federal — COPPA as the benchmark

COPPA covers only under-13s, and Thnkrr blocks them. It still sets the vocabulary every state borrows.

• Amended rule: published 22 Apr 2025, effective 23 Jun 2025, compliance by 22 Apr 2026 [Primary] (Federal Register).
• Standard (§312.5(b)(1)): a method must be "reasonably calculated, in light of available technology, to ensure that the person providing consent is the child's parent" [Primary] (16 CFR 312.5).
• Approved methods: signed form (mail, fax, electronic scan); card or online-payment transaction; staffed toll-free call; video call; government ID checked then deleted; knowledge-based questions; photo ID matched to a live selfie; "email plus" and "text plus" [Primary].
• Email plus and text plus are only for services that don't disclose children's data. "Disclose" includes public posting, message boards and chat, so a network with profiles and messaging can't use them [Primary] (§312.2) [Analysis].
• The FTC has long rejected email alone: "e-mail alone does not satisfy the COPPA because it is easily subject to circumvention by children" [Primary] (64 FR 59888, 1999).
• Facial age estimation as a consent method was denied without prejudice on 29 Mar 2024 [Primary] (FTC).
• Age checks at sign-up: a 25 Feb 2026 policy statement says the FTC won't pursue data collected solely to determine age, if it is deleted promptly and used for nothing else [Primary] (FTC).
• Schools consenting for parents: only for under-13s, only for the school's use and no other commercial purpose. The 2025 rule did not codify it; the FTC FAQ still governs [Primary] (COPPA FAQ §M).

6.2 US states — account-opening consent (status as of 2026-09-15)

No federal appeals court has ruled on the merits in Mississippi, Florida, Georgia or Utah; the Supreme Court has granted no merits review of these laws [Reported].

What the one flow does against these [Analysis]: it gives a parent's signed attestation after the school confirms the relationship, a written confirmation and a withdrawal path, and keeps no ID data. That meets the "unspecified" and "commercially reasonable" laws on a strong argument and covers Florida's relationship prong. Whether a typed-name web form counts as a "signed form" for Ohio and Nebraska is for counsel; the paper route always counts.

6.3 FERPA — the school's disclosure to Thnkrr

• A parent's name is personally identifiable information in education records [Primary] (34 CFR 99.3).
• A school may disclose it to a vendor acting as a "school official" performing an institutional function, under the school's direct control, used only for the authorized purpose [Primary] (34 CFR 99.31(a)(1)(i)(B); PTAC guidance).
• Both parents keep FERPA rights unless a court order or binding document revokes them [Primary] (34 CFR 99.4). The verifier's Doesn't match is how restricted parents are handled.
• Consequence: because the school checks before the guardian signs, the pilot agreement must carry the school-official clause (§3.1).

6.4 India — DPDP Act 2023 and DPDP Rules 2025

• Child = under 18 (s.2(f)). Parental consent must be "verifiable" (s.9(1)). No tracking, behavioural monitoring or targeted ads to children (s.9(3)). Penalty up to ₹200 crore [Primary] (s.9).
• Rule 10(1) requires "due diligence, for checking that the individual identifying herself as the parent is an adult who is identifiable", by reference to "(a) reliable details of identity and age of the individual available with the Data Fiduciary; or (b) details of identity and age, voluntarily provided — (i) by the individual; or (ii) through a virtual token… issued by an authorised entity", which includes DigiLocker [Primary] (Gazette G.S.R. 846(E)).
• Thnkrr's situation matches the Rule's Case 2: the child starts sign-up and the parent is not a user, so the parent is checked against government-issued identity or age details, or a token [Primary].
• The rule requires adulthood, not proof of relationship. The relationship rests on the declaration [Primary]. The school check adds it anyway.
• When: s.9 and Rules 10–12 commence 13 May 2027 (some trackers say 14 May). A Jan 2026 proposal to shorten the timeline, reported as mainly for large platforms, was never notified as of 6 Sep 2026 [Reported] (dpdprules.org timeline).
• School records or a school's attestation don't count as far as anyone has said: no MeitY or Board guidance addresses it [Unverified — none found], and commentary says school-level permissions are "unlikely to meet statutory standards" [Analysis] (KS&K). So the verifier check stays, but it is not the Rule 10 check.
• Exemptions don't help: the Fourth Schedule's educational-institution exemption covers only an institution's own tracking and behavioural monitoring; Part B item 6 exempts only the age check and the Rule 10 due diligence itself [Primary] (Schedule 4).
• DigiLocker in practice [Reported]:
  • No age-only "token" product has launched; Andhra Pradesh was only evaluating one in Apr 2026.
  • A company registers as a "Requester" on API Setu, which checks its GST number. A firm outside India also needs an Indian mobile number and India-hosted server.
  • The web flow is a redirect: parent enters an OTP, consents, returns.
  • It returns the full Aadhaar record (name, date of birth, address, masked number) — so Thnkrr must compute "18+" on the server and discard the rest immediately. (Setu DigiLocker docs)
  • UIDAI's Aadhaar app supports age-only sharing via "web portal, kiosk, or QR"; whether it works for a remote parent on a web page is [Unverified].
• Contracts: a minor's agreement is void under the Indian Contract Act s.11, so the guardian accepts the Terms on the student's behalf [Analysis].

6.5 EU — GDPR

• Art. 8: parental consent below the member state's digital age of consent (13–16), when consent is the legal basis; "reasonable efforts to verify… taking into consideration available technology" [Primary] (Art. 8).
• EDPB Guidelines 05/2020: "In low-risk cases, verification of parental responsibility via email may be sufficient… in high-risk cases, it may be appropriate to ask for more proof". When the child reaches the age of consent, they can confirm or withdraw, and must be told so [Primary] (guidelines). Adult mentors make Thnkrr higher risk; the school check is the "more proof" [Analysis].
• DSA Art. 28 minors guidelines don't apply to micro and small enterprises [Primary] (Commission).
• EU Kids Act: the Commission's minimum-age proposal is expected around the 16 Sep 2026 State of the Union. The reported draft requires "express permission" of parents for ages 13–15 [Reported] (Euronews). Re-check once published.
• The one flow covers it: guardian consent to 18 plus the student's own agreement satisfies both the under-age and at-age cases [Analysis].

6.6 UK

• Age of consent is 13, so no parental consent is legally required for 13–17 [Primary] (ICO). The flow keeps it as policy.
• Under-16 social media restrictions announced 15 Jun 2026: regulations not yet laid, due by end-2026, in force spring 2027, no parental-consent route; the government is "not looking to bring dedicated educational platforms" into scope [Primary] (GOV.UK fact sheet). Whether a LinkedIn-style network with social features counts is open [Unverified].

6.7 Australia

Under-16 social media minimum age since 10 Dec 2025; parental consent cannot override it. Services whose sole or primary purpose is "professional networking or professional development" or "supporting the education of end-users" are excluded [Primary] (Rules 2025, r.5(1)).

6.8 Accessibility (US public schools)

DOJ's ADA Title II web rule, as extended by an interim final rule on 20 Apr 2026: compliance by 26 Apr 2027 (population ≥50,000) or 26 Apr 2028 (smaller entities). Vendor content used under contract is covered and "would usually need to meet WCAG 2.1, Level AA" [Primary] (ADA.gov). The consent email, consent page and paper form must be accessible.

6.9 How the one flow meets each requirement

7. How the industry does it

7.1 School-partnered products take the guardian from the school

• Naviance (PowerSchool): imports only SIS contacts marked "Lives With" or "Has Custody"; parents register with a single-use code [Primary] (docs).
• MaiaLearning: parent accounts created from the SIS; activation link expires after 7 days [Reported].
• Scoir — closest to Thnkrr's flow: a parent the student enters stays "Pending" until a counsellor links them, because "only the school can make this connection" [Primary] (help).
• Clever Family Portal, Seesaw: invitations go to SIS contacts only [Primary].
• Google Workspace for Education: since Mar 2025, admins re-confirm parental consent for under-18 additional services every year [Primary] (Workspace Updates).

7.2 Everyone else

7.3 Enforcement lessons that shaped §3 and §5

8. Verification tools and rostering

8.1 Identity and adulthood checks

None of these prove the adult is this student's guardian.

8.2 Clever and ClassLink

• What they give: school rosters synced nightly, sign-in with school accounts, and guardian contacts. Clever contacts carry relationship (Parent, Grandparent, Self…) and type (Parent/Guardian, Emergency…), which are often missing [Primary] (Clever API). OneRoster links guardians as users with role parent, guardian or relative [Primary].
• They don't get around a school's refusal: the district controls per app whether contact fields are shared [Primary].
• Cost: Clever is free for schools; apps pay a custom quote, reportedly $12–$18 per school per month with a 50-school minimum [Reported] (Edlink). ClassLink charges vendors nothing [Primary] (ClassLink).
• Fit: single sign-on through them would break docs/04's "auth stays 100% internal"; rostering alone wouldn't. US only.
• Where they'd fit later: Step 2 becomes "pick your parent from the school's list", and Step 3 becomes automatic for matches, leaving counsellors only mismatches and hard cases. Step 5 does not change. For 5 schools, a spreadsheet in OneRoster format does the same job.

9. The current build against this flow

Paths are relative to thnkrr-api/ unless marked web/ (= thnkrr-web/).

9.1 What already fits

• Async flow with a holding screen: src/lib/authorize.ts:95-97, web/src/components/ConsentGate.tsx.
• Activation derived from state: activateIfReady, src/modules/identity/service.ts:123-139.
• Guardian page needs no account (consentPublicRoutes), so no guardian accounts are needed.
• Changing guardian details creates a new record: src/modules/onboarding/service.ts:118-139.
• parental_consents.method is text, so new methods need no enum change.
• audit_log takes free-text actions: src/db/schema/moderation.ts:87-101.
• Scheduled jobs for expiry sweeps and reminders: src/jobs/boss.ts:78-81.
• The roster confirm action is the model for the verifier review: src/modules/school/service.ts:215-259.
• schools.country and schools.region exist for the India switch.

9.2 Bugs in the current stub

1. Consent confirms on page load. web/src/pages/ConsentConfirmPage.tsx:13-24 POSTs as soon as the page opens — email scanners can confirm it, and there is no notice, no Decline, no student name.
2. Stale links report success. A superseded link returns ok (src/modules/onboarding/service.ts:190) and the page says the account is active.
3. The token's bind: "awaiting" is never checked; single use relies on the status check.
4. A consented student can re-lock their account: submitConsent doesn't check existing status (src/modules/onboarding/service.ts:113-116).
5. Nothing stops the student's own email being used as the guardian's.
6. Relationship always sent as "parent" when the email is changed: web/src/pages/OnboardingPage.tsx:266.
7. Requests never expire: nothing writes expired; resend mints fresh 7-day links indefinitely (src/modules/onboarding/service.ts:170-176), writes no audit entry, and only the global 300/min rate limit applies — a student can email any address repeatedly.
8. The guardian email names neither the student nor what is being consented to (src/modules/onboarding/service.ts:156-168).
9. Consent proof is deleted with the account: parental_consents.user_id is ON DELETE CASCADE.
10. A held student who turns 18 stays stuck until next login; sessions don't recompute status (src/modules/identity/service.ts:245-268).
11. The page promises withdrawal "any time" (web/src/pages/ConsentConfirmPage.tsx:31-32), which isn't built.
12. Guardian email is stored in plain text; docs/04 §5.1 planned it encrypted.

9.3 Missing for this flow

• Verifier role and queue. school_admin exists but is never granted; the roster shows no consent state (packages/contracts/src/educator.ts:40-48).
• Terms of Use, Privacy Notice, and the student's acceptance — none exist in web/src.
• Consent page and translated notice.
• Email. The mailer is plain text with no templates, translations or bounce detection (src/lib/mailer.ts:9-27), and verifier email reminders aren't wired (docs/13 §9).
• Withdrawal.
• Age-band confirmation for students claiming 18+.
• Waitlist for under-18s at unlisted schools.
• India: DigiLocker adapter (behind an interface, like storage/mailer/imageScreen).
• Encryption at rest and keyed hashing (src/lib/crypto.ts has neither).

9.4 Schema cost

Additive (safe after pilot data exists, D-12):

• nullable columns on parental_consents: source, verified_by, verified_at, verification_outcome, policy_version, notice_language, attested_name, decided_at, expires_at, ip_hmac, ua_hmac, form_reference, adult_check_ref;
• consent_status gains declined — its own migration, unused in the same run (D-12);
• a new consent-evidence table with no foreign key, if proof must outlive account deletion;
• a new encrypted guardian-contact column, written alongside the old one.

Structural — decide before touching:

• Changing the user_id FK from CASCADE (drop and re-add the constraint).
• Encrypting guardian_email in place (type change plus backfill).
• Guardian login accounts (would relax NOT NULL on users.password_hash/birthdate) — avoid; the token page is enough.

10. Open decisions

11. Re-check triggers

12. For counsel

1. Does a typed-name web attestation satisfy "signed form" methods (Ohio, Nebraska)?
2. Tennessee: exact method, retention wording, and whether the career-development exclusion covers Thnkrr. Mississippi: methods and exclusions. Florida: coverage, and whether school records satisfy "verifies the age and identity of that parent".
3. Minnesota, South Carolina, Indiana, Idaho and Illinois 2026 laws.
4. FERPA school-official clause wording for guardian verification.
5. India: is Thnkrr or the school the Data Fiduciary; can school records ever satisfy Rule 10(1)(a); handling the full Aadhaar record from DigiLocker; Indian entity and GST registration; whether the paper route works after 13 May 2027.
6. EU: legal basis per country; national ages of consent; the EU Kids Act once published.
7. UK: whether Thnkrr falls under the under-16 regulations.
8. Who may consent for foster, kinship, unaccompanied and emancipated students, per jurisdiction.
9. How long consent records are kept, including after account deletion.
10. Terms of Use and Privacy Notice, including disclosure of processors (AI moderation provider, hosting, email).