Verifying Age and Guardian Consent Under DPDP

A checkbox that says "I confirm I am over 18" proves that someone clicked a checkbox. A text field asking for a parent's email proves that an email address exists. Neither establishes what the DPDP Act actually asks for: verifiable consent from a parent or lawful guardian before a child's personal data is processed. The gap between what most consent flows collect and what the law requires is exactly where this gets difficult. How do you confirm someone is a minor, and that the adult consenting on their behalf is a real guardian, without turning the platform into a repository of identity documents?

What the DPDP Act actually asks for

India's DPDP Act treats a child, defined as anyone under 18, as unable to consent to the processing of their own personal data. Before a data fiduciary can process that data, it must obtain verifiable consent from the child's parent or lawful guardian. The word doing the work is "verifiable." The Act does not ask platforms to collect a parent's say-so; it requires that verifiable consent be obtained "in such manner as may be prescribed." The prescribed manner set out in the DPDP Rules is what asks a platform to establish, in a way that would hold up to scrutiny, that a real guardian relationship exists and that the person exercising it is who they claim to be.

Establishing that means confirming two separate facts, and most consent flows only attempt one of them. First, that the data principal is in fact a minor, since most products don't want to apply age-verification friction to every adult user by default. Second, that the parent or guardian standing behind the consent is a real, identifiable adult with a genuine relationship to that minor, not a second account created by the same child.

Why the obvious fix creates a bigger liability

The straightforward way to verify both facts is to ask for proof: a birth certificate for the child, a government ID for the guardian, perhaps a document establishing the relationship between them. That does establish verifiability. It also means the platform now holds a scanned identity document for every child user and every guardian who consents on their behalf, which is itself sensitive personal data under DPDP. It now needs a retention policy, access controls, and a place in the platform's own breach response plan.

The verification requirement, solved this way, creates a second problem in the process of solving the first: the platform becomes a custodian of exactly the kind of document that does the most damage if it leaks.

How ConsentIQ verifies without holding the document

ConsentIQ verifies age and, where required, guardian identity through DigiLocker eKYC, run over a standard OAuth redirect flow, rather than by collecting a copy of any document itself.

The flow works the way any OAuth-based identity check does. The data principal, or where required, the parent or guardian, is redirected to DigiLocker and authenticates there directly, against documents already on file with the Indian government's own digital locker service. DigiLocker is the party that ever sees the underlying ID; ConsentIQ is not. What comes back over the OAuth exchange is a verified claim, confirming the fact the flow was checking for, such as date of birth. The exchange is designed to stay secure even on a shared or public device.

The result is that ConsentIQ can answer "was this consent given by a verified guardian" without ever opening, storing, or transmitting a scan of anyone's identity document.

What actually lands in the consent record

Verification is a one-time check; the consent record has to outlive it. Once DigiLocker confirms the relevant fact, ConsentIQ folds that confirmation into the same signed, data-blind artefact used for every other consent event on the platform. The identifier used to reach the guardian is hashed with the same keyed one-way hash that protects every other identifier in a ConsentIQ record. It is not stored in plaintext, and nothing from the DigiLocker document itself travels with it. What is retained is proof that the check happened and what it found, not the material that made the check possible.

Why this holds up later

A consent record that says "guardian consent obtained" is only as strong as what backs it up. A self-declared checkbox and a DigiLocker-verified claim can produce an identical-looking line in a database. Only one of them answers the question a regulator or auditor is likely to ask: how was this guardian relationship established? ConsentIQ ties that answer to the signed record at the point of capture.

DigiLocker eKYC verification is available in ConsentIQ today for child and guardian consent. See it in your own environment: book a ConsentIQ demo and proof of concept.