Most countries writing age-verification law in 2026 have done it in the same order: pass the mandate first, argue about the privacy fallout later. The UK shipped “highly effective age assurance” and then spent a year watching platforms hoard ID scans and get breached for it. Several US states wrote hard ID checks into statute and are now defending them in court. Canada did the opposite. Before Parliament has settled a single omnibus age-check law, the Office of the Privacy Commissioner (OPC) has published the rules for how an age check must be built if you run one at all.
On May 4, 2026, the OPC released two draft guidance documents — one for the platforms that rely on age assurance and one for the vendors that build it — and opened them for comment until August 4. The Computer & Communications Industry Association filed the day after the window closed, arguing for flexibility over a single prescribed method. The guidance is not law. But it is the clearest signal yet of how a G7 regulator that answers to a privacy statute, not an online-safety one, thinks age checks should work — and it lands the compliance question in a different place than London or Austin.
In Canada, the question a platform has to answer is not “did you check ID.” It is “can you prove the check was necessary and proportionate.” That reframing changes what you build.
What Canada actually published (and what it didn’t)
The two documents sit under Canada’s federal private-sector privacy law, the Personal Information Protection and Electronic Documents Act (PIPEDA). That matters, because it means the OPC is not inventing a new duty — it is reading age assurance through PIPEDA’s existing section 5(3): personal information may only be collected for purposes that “a reasonable person would consider appropriate in the circumstances.” An age check collects personal information. So the reasonable-person test already applies, and the guidance simply spells out how to pass it.
The relying-party document, Assessing whether and how to use age assurance, is the one most product and compliance teams need. It walks through when age assurance is even required, what form is proportionate, and how to run it without turning a safety measure into a surveillance one. The developer document, Designing age assurance to be privacy-protective, sets the technical floor for vendors, and the guidance is explicit that choosing a provider who meets it is part of a relying party’s own obligation. You cannot outsource the privacy duty to a vendor and look away.
What the OPC did not publish is a mandate. Canada still has no single federal statute that forces age checks the way the UK Online Safety Act does. The legislative picture is a set of moving parts: Bill S-210, which would have restricted young people’s access to sexually explicit material, stalled and was reintroduced as Bill S-209 with age estimation added as an accepted method and a narrower content definition; the Online Harms Act (Bill C-63) frames a design duty to reduce children’s exposure to harmful content; and Quebec’s Law 25 already imposes strong provincial privacy obligations. None of these has produced a UK-style “verify at the door” rule in force. So the honest status is: guidance now, mandate later, and the guidance is telling you what the mandate will expect.
That sequencing is the whole point. If you build to the OPC’s framework today, you are unlikely to be surprised by whatever Parliament passes next.
The three-question test every platform has to answer
The relying-party guidance is structured as a decision, not a checklist. Three questions, in order.
1. Do you even need age assurance?
The OPC’s starting position is blunt and worth quoting in spirit: age assurance should not be the default condition for accessing the internet. Before you gate anything, you have to establish a legitimate need to differentiate users by age. There are only two ways to do that.
One is a legal requirement — you host pornography, facilitate gambling, or sell an age-restricted product, and a law tells you to keep minors out. The other is harm: you have determined that a specific harm to children is likely if they access some or all of your service. The guidance’s own example is an online dating service where adult-to-child contact would be dangerous.
If you are leaning on the harm justification, two more conditions attach. You have to show the harm is real and specific to children, and you have to show a non-trivial number of children are likely to access the service. That second test is where a lot of general-audience platforms will try to escape and fail. The OPC is clear that an unenforced line in your privacy policy saying under-18s aren’t allowed counts for nothing. What counts is audience reality: research on your user base, whether advertisers place child-directed ads on you, whether your content or design appeals to children, whether kids are known to use similar services. Crucially, you assess this from high-level audience metrics — you do not get to collect everyone’s age to find out how many children you have. That would be the collection you were trying to justify, run in reverse.
This is the same scoping logic we unpacked in the one-third rule and in the broader US compliance patchwork: a clean majority of content does not buy you an exemption, and self-serving statements about your audience carry no weight.
There is also a second path the guidance treats separately: adjusting your practices to accommodate children rather than exclude them. If your data practices are the source of harm — behavioural profiling of minors, selling detailed profiles, pushing children to over-share — the OPC’s preference is that you fix the practice, not verify every user. Turn off behavioural advertising for anyone who signals they’re a child, make the protective setting the default, and you may remove the need for an age check entirely. Age assurance is the tool of last resort, after you’ve asked whether a less invasive fix would do.
2. What form of age assurance is proportionate?
Once a need is established, the method has to match the risk. The OPC’s rule is that you must not require more, or more sensitive, personal information than is necessary for the level of effectiveness the situation demands.
Where the stakes are high — a legal duty to keep minors out, or a serious harm — a strong method is warranted, and the OPC explicitly accepts that biometric age estimation or government-ID verification can be appropriate, provided they are implemented privately. Where the risk is more than trivial but not severe, you are expected to reach for the method that collects the least, even if it means slightly less certainty. Proportionality cuts both ways: it licenses a strong check when the harm is grave, and forbids one when it isn’t.
The guidance also nudges toward reuse over repetition. The OPC would rather you accept a credential from a digital wallet, or a signal from a browser or device, than force every user through a bespoke check — once those signals become trusted and common in Canada. It goes further: if a trusted digital credential does become widely adopted, refusing to accept it and forcing your own check on people may itself become inappropriate. That is a direct endorsement of the verify-once, prove-everywhere model and of OS- and device-level age signals as the destination, even if Canada isn’t there yet.
3. How do you run it without creating a new privacy problem?
This is where the OPC’s version of age assurance diverges most sharply from a blunt gate. A few of the rules have real teeth:
- Use the result only for the age decision. Neither the vendor nor the platform may retain, disclose, or repurpose what was collected. You can use the age signal to grant access or route someone to a younger-user experience. You cannot feed it into an ad profile. Anything beyond a yes/no should be destroyed as soon as possible.
- Don’t correlate visits. The system must not let you use age results to link a user’s sessions together. If the design doesn’t prevent correlation, you must not attempt it anyway.
- Prove you’re above the line, not below it. The OPC adopts the principle that age checks should confirm a user is authorised to access — over 18, over 16 — rather than flagging them as a minor. Segregate age-restricted content, use an off-by-default posture, and only trigger a check at the moment access must actually be differentiated. Everything not gated should stay reachable without a check.
- Give people options and an appeal. Where feasible, let users choose between more than one effective, privacy-protective method — some will prefer a credential over a face scan, others the reverse. And anyone denied access must have a privacy-protective way to appeal, which matters because age estimation produces false positives that lock out real adults.
- Minimise how often you re-check. Bind an age signal to an account or accept a reusable credential rather than re-running the flow on every visit, escalating to a re-confirmation only in higher-risk contexts.
Read together, these are not a checklist bolted onto a gate. They describe a privacy-first architecture: collect the minimum, decide, and delete.
Why the Canadian model isn’t the UK model
It’s tempting to file Canada under “another country doing age checks” and reuse your UK playbook. Don’t. The regulators start from different statutes and end in different places.
| United Kingdom (Ofcom / OSA) | Canada (OPC / PIPEDA) | |
|---|---|---|
| Governing frame | Online-safety duty | Privacy statute (PIPEDA s.5(3)) |
| Core question | Is your check “highly effective”? | Is the check necessary and proportionate? |
| Default posture | Verify to discharge the safety duty | Age assurance shouldn’t be the internet’s default |
| On strong methods | Required where content is in scope | Permitted where risk is high, discouraged where it isn’t |
| Enforcement lever today | Fines, live | Guidance under existing privacy law; mandate pending |
The practical difference: in the UK the failure mode is an ineffective check. In Canada the failure mode is a disproportionate one — a check you couldn’t justify, that collected too much, or that you ran on users you had no business gating. A platform that over-verifies in Canada is not being safe. It is creating a PIPEDA problem.
The two regimes agree on more than the framing suggests, though. The OPC leans on Ofcom’s and the Australian tech trial’s findings to accept that estimation and verification can be highly effective, and it echoes the UK position — the one the ICO priced at £14.5m against Reddit — that self-declaration alone won’t cut it where the data-protection risk is high. Where they diverge is default posture, and that difference is the one to design around.
The infrastructure gap Canada is honest about
The OPC is refreshingly candid that Canada lacks the plumbing for easy age checks. There is no broadly adopted way to prove your age online in Canada today. There is no national digital ID, only “voluntary, limited-scope provincial digital wallet initiatives,” and beyond basic “I am over 18” self-declarations, the regulator says Canadians don’t regularly encounter any age-assurance mechanism at all.
That gap is filling in slowly. The Digital Governance Standards Institute has published a Canadian standard for age verification and estimation, and it sits alongside the international ISO/IEC 27566 age-assurance standard we’ve covered as an emerging vendor benchmark. The OPC explicitly ties its guidance to both. It also flags an upcoming Children’s Code, which will read a lot like the age-appropriate design codes already live elsewhere.
Until a trusted credential is common, platforms have to bring their own assurance — which puts the burden back on picking a method and a vendor that clear the OPC’s bar now and can accept a wallet credential later without a re-architecture.
Trust is a design constraint, not a marketing line
The most quietly important part of the OPC’s material is a number. In its own polling, 71 percent of Canadians said they had little or no trust that Big Tech would protect their data, and 86 percent said the same of social media companies. The regulator’s conclusion is operational, not rhetorical: without a way to establish that an age check is trustworthy, many Canadians will simply refuse it and abandon the service rather than hand over their information.
That reframes trust as a conversion problem. Nobody wants to give their ID to a porn site, and by extension nobody wants to hand sensitive data to a platform they already distrust. The OPC’s implied answer is separation — an age-assurance layer that stands apart from the platform requesting it, collects the minimum, retains nothing, and can be seen to do so. That is exactly the case for a dedicated provider over a home-grown check, and it’s why “we delete the image after we return an age band” is a business argument in Canada, not just a compliance one.
What platforms operating in Canada should do now
Run the need test before the build. Document, honestly, whether you have a legal requirement or a specific child-harm justification and a non-trivial child audience. If you don’t, the OPC’s position is that you shouldn’t be verifying at all — and verifying anyway is its own liability.
Fix the practice before you gate the user. If your data practices are the harm, turn off behavioural profiling for likely-children and make protective settings default. It may remove the need for a check entirely.
Match method to risk, and reach for the least-collecting option that clears the bar. Estimate first, escalate to document verification only for the ambiguous cases — the estimate-then-verify waterfall is precisely the proportionality the OPC rewards.
Delete by default. Return an age band or a yes/no, discard everything else immediately, and never repurpose the result. The breach wave that punished data-hoarding verifiers is the cautionary tale the OPC is writing rules to prevent.
Build the escape hatches. Segregate restricted content so most users never hit a check, offer more than one method, and stand up a real appeal path for false rejections.
Pick a vendor you can hand a regulator. Choosing a provider that meets the developer guidance is your obligation, not theirs. Independent audits and conformity assessments are “shoulds” today and will be table stakes tomorrow — prove the check works, and prove it’s private.
How Xident fits
Canada’s framework rewards the exact posture Xident was built around: verify as little as the risk requires, keep nothing you don’t need, and prove it.
- Check is the low-friction, low-data first step — browser-based age estimation, liveness, and returning-user lookup — the proportionate default for most users, and roughly an order of magnitude cheaper than a document scan, so running estimation across the whole audience doesn’t wreck unit economics.
- Verification is the step-up — document capture with OCR, face match, and NFC chip reading — reserved for the high-risk or ambiguous cases where the OPC agrees a stronger method is warranted.
- Delete-after-decision by default returns an age result and discards the underlying image, matching the developer-guidance rule to collect the minimum and delete once the signal is generated.
- Client-side liveness runs on-device, blocking spoofing without shipping biometric images to a server — the on-device processing the OPC names as a privacy-protective design choice.
- Returning-user tokens bind an age signal to the account so users aren’t re-checked on every visit, and the architecture is built to accept a portable digital credential once Canada’s wallet layer matures — the reuse the guidance explicitly prefers.
- No cross-visit correlation and no secondary use are properties of the design, not promises in a policy, which is what a “reasonable person” and a PIPEDA-minded regulator want to see.
- One integration across the UK, EU, US states, and Canada means a global platform doesn’t run a different age-assurance stack per regime — see how the same approach meets Ofcom’s requirements in the UK.
The translation for a platform in Canada: estimate the whole audience cheaply, escalate only what the risk demands, retain nothing, and be able to show your working. That is proportionality as an architecture, not an afterthought.
The bottom line
Canada took the sequence everyone else got backwards. It wrote the privacy rules for age checks before it wrote the mandate, which means the compliance target is visible now, before the law that enforces it exists. The test isn’t whether you checked an ID. It’s whether you can justify the check as necessary, keep it proportionate to the actual risk, and run it without building a surveillance record as a side effect.
Platforms that treat Canadian age assurance as a UK-style gate will over-collect, over-verify, and create the privacy exposure the OPC is warning about. The ones that treat it as a proportionality exercise — verify the minimum, delete the rest, prove it — will be compliant when the mandate lands and, in a market where 86 percent of people don’t trust social media with their data, will convert the users everyone else scares off.
Rolling out age assurance for Canadian users? Talk to Xident’s team about proportionate, privacy-first flows that satisfy the OPC’s guidance, or explore the docs to see how Check and Verification keep collection minimal and deletion automatic.
