Prove “this is a verified minor in this age band” without turning the proof into a new child-tracking database.
UuLApp should separate the school’s authoritative student record from the minimal attributes a participating digital service needs for a child-safety decision.
The school knows the student. The service should know only what it needs.
School-held identity
Legal name, enrolment record and other school data remain under the school’s normal governance and should not be distributed merely because UuLApp is used.
UuLApp credential
Service-specific pseudonymous proofs should disclose only necessary status and validity attributes, avoiding a universal identifier that enables tracking across services.
Participating service
Receives the minimum result required to enforce age-appropriate access and interaction. It should not repurpose verification data for unrelated profiling or advertising.
Design rules for a lawful implementation.
- Purpose limitation: child-verification attributes are used for the defined safety/access purpose, not unrelated marketing.
- Data minimisation: if an age band is sufficient, do not disclose exact birth date.
- Pseudonymisation: services should not need the school’s full identity record to know the account is a verified minor.
- Retention control: age-verification and audit data should be retained only as long as justified for their specific purpose and legal obligations.
- Security: credential issuance, storage, transmission, authentication and revocation require appropriate technical and organisational safeguards.
- Transparency: children and parents should receive clear, age-appropriate explanations of what is processed and why.
- No behavioural profiling of minors as a protocol purpose: UuLApp verification data should not become an advertising profile.
Each participating organisation remains responsible for its own legal role, lawful basis, retention rules, security and any required impact assessment. UuLApp is designed around privacy-by-design principles, but adoption of the protocol is not by itself a legal-compliance certification.
Protect rights as well as identities.
A lawful basis for every purpose
Schools, credential providers and services must identify their controller or processor roles and a lawful basis for each operation. School enrolment records cannot automatically be reused for cross-service verification. Public-task processing needs an applicable legal basis; parental permission alone does not resolve this.
Consent depends on purpose and country
GDPR Article 8 applies when consent is the basis for an information society service offered directly to a child. The default threshold is 16; Member States may set it between 13 and 16. Below the applicable threshold, consent must be given or authorised by the holder of parental responsibility and reasonably verified. This is not a universal minimum age for internet access.
Minimum proof, no cross-service tracking
Use the least intrusive effective method. Disclose an age-threshold result when sufficient; avoid unnecessary birth dates, school identity and reusable identifiers. Verification must not create a means to track children across services or build advertising profiles.
Children need information and a remedy
Provide understandable notices, routes to exercise applicable data rights and human review of verification errors. Restrictions must be proportionate and account for disability, lack of documentation, evolving capacities and access to support.
Assess risk before launch
Assess whether a DPIA is required before processing; high-risk processing requires one. Define security, retention, incident response and international-transfer safeguards. Sensitive support information requires additional legal assessment and safeguards.
These are design requirements for the proposed protocol. This page does not certify a deployed system or replace its operational privacy notice.