When you store copies of IDs and selfies "for compliance," you become the custodian of the most sensitive data your users have. A breach does not just leak emails; it leaks documents that can be used for identity fraud and face images that can be used for impersonation. Regulators and plaintiffs treat that storage as a major risk and, increasingly, as a violation in itself. The alternative is an age token: keep the proof that a check happened, not the material that was checked.
Quick answer
- An age token is a signed statement from a verifier that a user cleared an age threshold at a given time.
- It contains the result (18+ / 21+), the threshold, a timestamp, an expiry, and an Audit ID.
- It does not contain the user's name, date of birth, ID image, selfie, or any field that identifies them.
- You store the token and the Audit ID. The verifier discards the document after issuing the result.
- Why it matters: Texas-style retention bans, GDPR data minimisation, and the UK and EU regulators' guidance all point the same way: hold the outcome, not the identity.
What an age token actually contains
A token is small on purpose. A typical payload carries:
- Result: passed or failed against the threshold requested.
- Threshold: the age the user was tested against, such as 16+, 18+, or 21+.
- Issued at / expires at: when the check happened and how long your platform should trust it.
- Audit ID: a reference the verifier can resolve if a regulator asks you to prove the check.
- Policy version: which verification method and rules were in force at the time.
- Subject reference: an opaque identifier bound to your session or account, not a personal identifier.
- Signature: proof the token came from the verifier and has not been altered.
What is deliberately absent is anything that would let a third party identify the person: no document number, no full date of birth, no image. The verifier processes those during the check and does not pass them on. For the data-handling detail, see what to collect and what to leave out.
Age token versus storing IDs and faces
The two models answer the same compliance question with very different risk profiles.
Storing IDs and faces gives you a full record of what was checked. It also gives you a database that is attractive to attackers, expensive to secure, hard to justify under data minimisation, and, in a growing number of US states, illegal to keep. Texas Civil Practice and Remedies Code 129B.002(b) says the site or its verifier "may not retain any identifying information of the individual," and most of the 27 state adult-content laws include the same clause.
Storing an age token gives you a record that the check happened, when, against which threshold, and under which policy. That is what an attorney general, Ofcom, or a DSA coordinator will ask for. It is also what a parent's lawyer in Louisiana or Utah cannot turn into a data-retention claim. Your database stops being a honeypot, and your privacy notice gets one paragraph shorter.
The verifier's retention policy is part of your compliance
Retention bans in Texas, North Carolina, and other states name the third-party verifier explicitly. A token-only architecture only works if the verifier also discards the document and selfie after issuing the result. Ask for that in writing before you integrate.
Token lifetime and returning users
A token is useful for exactly as long as you decide to trust it. Three patterns cover most platforms:
- Session-bound: the token expires when the session ends. Simplest, highest friction, suits one-off purchases.
- Account-bound with expiry: the token lives 30 to 90 days against an account. Returning users are not re-verified on every visit. Suits adult platforms, communities, and streaming.
- Device-bound: the token is tied to a device or browser and re-issued when that changes. Suits consumer apps where accounts are optional.
When a token expires, the user does not start from zero. A light reverification, such as a face match against the result of the earlier check, issues a fresh token with a fresh Audit ID. You keep a continuous audit trail without asking for the same passport twice.
How the token reaches your platform
The flow is the same whether you integrate through an API or a plugin:
- Your platform starts a verification and redirects the user to the verifier.
- The verifier checks the document and liveness, then issues a signed token.
- Your server exchanges the callback for the token and validates the signature.
- You store the token and Audit ID against the session or account and apply your access rule.
Developers can see the exact exchange in the AgeOnce token exchange reference. For how to present the resulting record to a regulator, see proving age verification with an audit trail.
What to store, in one list
- Age token (signed result, threshold, issued/expires, policy version).
- Audit ID.
- Account or session reference.
- Nothing else from the verification: no document image, no selfie, no date of birth, no document number.
Less data, less liability, better UX for returning users, and an architecture that fits GDPR, the DSA, the UK Online Safety Act, and the US retention bans at the same time. That is the whole case for the age token.
Frequently asked questions
An age token is a cryptographically signed statement from an age verification provider that a specific user cleared a specific threshold (for example 18+ or 21+) at a specific time. It carries the result, the threshold, a timestamp, an expiry, and an audit reference. It does not carry the user's name, date of birth, document image, or face.
No. An ID verification record stores what was checked: the document, the selfie, the extracted fields. An age token stores only the outcome of the check. The verifier may process the document to issue the token, but your platform never receives or retains it.
That is a policy decision, not a technical limit. Common choices are a single session, 30 to 90 days for returning users, or until the user's device or account changes. When the token expires, a light reverification issues a fresh one without a new document upload.
It fits them well. Texas and most of the 27 state adult-content laws require 18+ verification and forbid the site or its verifier from retaining identifying information. A signed result plus an Audit ID is exactly the record those statutes leave room for. Check the specific state for any additional record-keeping duties.
The Audit ID, the threshold applied, the policy version, the timestamp, and the account or session reference. That set proves the check happened and lets you answer a regulator without holding anything a breach could turn into identity fraud.
