Age assurance and identity proofing
Checking whether someone is old enough or matches a real-world identity, while collecting only the evidence the decision actually needs.
What it is
Age assurance establishes whether someone falls above or below an age threshold. Identity proofing establishes that an online applicant maps to a real-world person and may check a document, selfie, address, or authoritative record. They overlap, but they are not the same: a service can prove 'over 18' without learning a name, and proving a name does not automatically prove the person presenting it owns the document.
Reach for the least intrusive one that answers the actual risk. An age-restricted feature may need only a reusable over-or-under result, while opening a regulated financial account can require stronger identity evidence. NIST SP 800-63A describes identity proofing assurance levels; products such as Yoti and Stripe Identity perform the evidence checks. The UK Online Safety Act turned this from a nice-to-have into a duty, with Ofcom requiring highly effective age checks on adult content from July 2025.
The gotcha is building a new breach target while trying to reduce risk. Birth dates, document images, and biometric templates are highly sensitive, and automated checks reject real people too. Keep a coarse verified result instead of raw evidence where possible, separate age from identity, set deletion deadlines, and provide an accessible retry and human review path.
Ask AI for it
Build two explicit verification paths. For an over-18 decision that does not need a legal identity, use Yoti Age Verification and retain only the signed threshold result, provider reference, method, and expiry. For a flow that genuinely needs identity proofing, create a Stripe Identity VerificationSession with document and matching-selfie checks, then grant access only from a verified webhook handled idempotently. Never place document images, selfies, exact birth dates, or provider secrets in the app database or analytics. Encrypt stored results, define a deletion schedule, prevent one result from being reused for a different purpose, and add retry, manual review, and accessible failure states.