If your product has users under 18 — edtech, gaming, social, anything with a young audience — India's DPDP rules hand you a hard requirement most teams haven't built for: before you process a child's personal data, you need verifiable consent from their parent or guardian. Not a checkbox that says "I am over 18." Verifiable: you have to actually confirm an identifiable adult gave that consent.

The good news is that the mechanism the rules point to — a government-backed identity token, in practice DigiLocker — is something you already know how to integrate, because it's an OIDC flow. This post walks the requirement, then the build: how a DigiLocker-based parental-consent flow works end to end, the consent record you need to keep, and the age-gating that has to follow.

What DPDP actually requires

Two things from the DPDP Act and its 2025 Rules set the bar:

A child is anyone under 18. This is stricter than the GDPR's 16 (or lower in some EU states). More of your users are "children" under Indian law than under European law.
Verifiable parental consent before processing. Rule 10 requires the data fiduciary to adopt technical measures to ensure that consent for a child's data comes from an adult who is identifiable — verified either against reliable identity details the fiduciary already holds, or via a virtual token mapped to verified identity issued by an entitled provider. That second path is the DigiLocker-shaped one.

And once a user is known to be a child, the Act adds standing prohibitions: no behavioral tracking or targeted advertising directed at children, and no processing likely to harm their well-being. So "verify the parent" is step one; "treat the child's account differently forever after" is step two.

The substantive obligations land in 2027, but the design work is now — retrofitting age-gating into a live product is painful, and building it in from the start is cheap.

Why DigiLocker fits

DigiLocker is an Aadhaar-linked government identity wallet, and critically for developers, it speaks OAuth 2.0 / OIDC. That means "verify the parent is a real, identifiable adult" reduces to a flow you've implemented a dozen times for social login: redirect the user to an authorization server, they authenticate, you get back a verified identity assertion. The difference is what the assertion is for — not logging the parent in, but producing a verifiable record that a specific adult consented for a specific child.

Because it's a government-issued, Aadhaar-backed credential, a DigiLocker assertion is exactly the "virtual token mapped to verified identity" Rule 10 describes — far stronger than a self-declared birth date or an uploaded document you can't validate.

The flow, end to end

Here's the parental-consent flow as an OIDC integration:

1. Child signs up → your app detects/declares age < 18 → blocks data
   processing, starts the parental-consent flow instead.
2. App asks for the parent and redirects the PARENT to DigiLocker
   (OIDC authorization request).
3. Parent authenticates with DigiLocker (Aadhaar-backed).
4. DigiLocker returns a verified identity assertion → your app confirms
   the consenter is an identifiable adult (18+).
5. App records a consent artefact: which adult, for which child account,
   what data/purpose, timestamp, IP — written to an immutable log.
6. Child's account is unlocked, but flagged "child" → tracking and
   targeted ads disabled for that segment from here on.

Steps 2–4 are a standard OIDC round-trip — the same shape as "Sign in with X". Steps 5–6 are where the compliance value lives, and they're the parts teams skip.

"Verifiable" means you can prove it later. A regulator, or a parent disputing it, can ask: who consented, when, for which child, and for what? So the consent record has to be a first-class, immutable artefact — not a boolean column you might overwrite. Capture at minimum:

The verified parent identity reference (from the DigiLocker assertion — store the verification result, not raw Aadhaar).
The child account it authorizes.
The purpose and scope of processing consented to.
A timestamp and the actor/IP.
The verification method (DigiLocker / Aadhaar-backed), so the strength of consent is on record.

Crucially, follow the Aadhaar-masking discipline: you need the fact of verification and a minimal reference, not the parent's full Aadhaar number sitting in your database. Store the assertion outcome and the audit metadata; don't hoard the underlying identifier.

This pairs naturally with how a consent-manager-style model records every grant — and with an append-only audit trail, which is what turns "we got consent" into "here is the immutable record that we got consent."

The mistake is treating parental consent as a one-time gate that, once passed, returns the child to a normal account. The Act's prohibitions on tracking and targeted advertising are ongoing. So the "child" flag has to propagate:

Disable behavioral tracking and targeted ads for child-flagged accounts — at the analytics and ad-serving layer, not just the UI.
Scope down data collection to what the service actually needs.
Honor consent withdrawal — a parent can revoke, and your systems have to act on it.
Re-evaluate at 18 — the account graduates out of child status on a known date.

If your architecture can't carry a durable "this is a child" attribute into every downstream system, that's the gap to fix before the consent flow is worth building.

How NamoID models it

NamoID's data model is built for this: an organization can require a DigiLocker-verified parent before a sub-18 user is allowed to complete signup, and that verification — like every consent in the system — is written to an append-only event store with its timestamp, scope, and verification method. The child attribute lives on the user record so downstream systems can honor the tracking and targeting prohibitions, and the consent event is exactly the artefact you produce when someone asks you to prove the parent agreed. You get the Rule 10 flow as a configuration of the identity layer rather than a bespoke build per product.

FAQ

Is "I confirm I'm over 18" enough? No. That's self-declared, not verifiable. Rule 10 wants the consenter confirmed as an identifiable adult — which a DigiLocker/Aadhaar-backed assertion provides and a checkbox doesn't.

Do I have to store the parent's Aadhaar number? No — and you shouldn't. Store the verification result and a minimal reference, following Aadhaar-masking norms. You need proof an adult was verified, not their full identifier.

Is a child 16 or 18 in India? 18. India's DPDP threshold is higher than the GDPR's 16, so more of your users count as children under Indian law.

Do I need this today? The obligations are enforced from 2027, but build it now — adding durable age-gating to a mature product later is far harder than designing it in.

Build the gate once, prove it forever

Verifiable parental consent sounds like a legal problem; it's really an identity-and-audit problem you already have the tools for. A DigiLocker OIDC flow confirms an identifiable adult, an immutable consent record makes it provable, and a durable child flag carries the tracking-and-targeting prohibitions downstream.

NamoID gives you the DigiLocker-verified-parent flow and the append-only consent record as part of the identity layer. If you're building for an under-18 audience in India, that's the Rule 10 requirement turned into a configuration instead of a project — talk to us about the children's-consent path.