A practical guide to checking adult access while limiting what identity information reaches your platform.
Your platform needs to know whether a visitor is over 18. Why does its signup form leave you holding their passport?
Picture an adult subscription service with a familiar flow: create an account, confirm an email address, upload an ID, then wait for approval. The visitor wants access, and the business needs a reliable age check. But the document may reveal a name, photograph, date of birth, and document number. The access decision is narrower: does this person meet the age requirement?
That distinction matters for platforms using digital identity verification. Evidence used to establish age does not necessarily need to become part of the receiving platform’s records. Here, “without sharing ID documents” means without sending raw documents to that platform. Verification may still involve documents and personal-data processing elsewhere.
An age check has three stages. Evidence is assessed, using a document or another suitable source. A result communicates what that assessment establishes. Then the receiving platform decides whether the result meets its access requirements.
The World Wide Web Consortium’s Verifiable Credentials Data Model illustrates this distinction with an age-threshold claim instead of a date of birth. The recipient learns whether a relevant threshold is met, rather than receiving the exact birthday.
That example describes a design principle, not the technical process used by every provider. For a platform team, the practical lesson is to define the decision before defining the data request. “Confirm eligibility for this age-restricted service” is more precise than “send us everything available about the user.”
In our hypothetical subscription platform, a visitor needs access to adult-only content. The platform should establish what age threshold applies, what level of assurance is required, and what evidence it needs about the completed check.
That is a different task from onboarding a creator who will receive payments. The creator’s identity, business status, or other information may require separate assessment. A successful viewer age check should not silently become approval for a payout account.
Likewise, a result indicating that someone is over 18 does not establish that they are over 21, own a payment card, or may manage another person’s account. Those decisions may require additional checks, but the platform should name the purpose of each one.
ProperUser’s published partner agreement describes sharing verification status and age-confirmation status with integrating platforms. It excludes raw identity documents, biometric data, video recordings, facial templates, and uploaded files from transmission to those partners.
The agreement also makes user authorization part of sharing verification information through authenticated API communication. The receiving platform retains discretion over acceptance, rejection, and additional verification. ProperUser does not take over the partner’s regulatory obligations or represent that its verification satisfies every partner’s requirements.
Receiving a result rather than the underlying material still requires understanding what that result establishes.
Suppose the visitor confirms their email with a one-time code, but the age check has not finished. Should the platform open its adult-only content? An ordinary email or SMS code confirms something about access to that contact method; on its own, it does not establish an age threshold.
That distinction matters when evaluating OTP solutions for platforms. ProperUser describes one-time password confirmation for supported platform authentication. A platform using both age confirmation and OTP should know which question each result answers. It should also explain to users which result it requests, what will be shared, and what happens if the age check cannot be completed.
User authorization does not replace a lawful basis for processing, appropriate privacy information, or a retention policy. For example, the UK ICO requires organizations to identify a lawful basis before processing information for age assurance.
Our earlier article on secure identity verification without data exposure examines the wider onboarding question. Here, the focus is narrower: what must an age-restricted platform receive to make an access decision?
Withholding a passport image from a receiving platform does not establish that no organization collected it. Nor does it establish that the platform cannot identify the user through an existing account, email address, or other activity.
W3C’s guidance distinguishes minimizing disclosed information from preventing correlation. Persistent identifiers and other data can still link interactions, even when fewer identity attributes are shared.
Selective disclosure concerns what is revealed; unlinkability concerns whether separate interactions can be connected. A subscriber who signs into an existing account may still be identifiable to the platform even if their age check does not disclose a legal name. Limited document sharing does not automatically mean anonymous browsing.
For platform operators, the sensible next step is a data map: what does each organization collect, what reaches the platform, what is recorded, and who can access it? A reassuring statement about document sharing should not replace those answers.
The following are due-diligence questions, not a description of confirmed ProperUser features.
Confirm the threshold and the meaning of each response. Do not assume that a generic “verified” status establishes the particular age requirement for your service.
Ask how it establishes the response’s source, integrity, and connection to the intended request. A displayed success message is not, by itself, a trustworthy access-control signal.
Ask how the design addresses reused responses, shared devices, and adults helping minors complete checks. The EU age-verification blueprint’s threat model addresses replay and adult-assisted circumvention, showing why response security and the circumstances of use both matter.
A genuine result from one person should not become another person’s permission to enter. No single check eliminates every bypass.
Distinguish a negative age result from a technical failure or an incomplete process. Define how each affects access. A provider outage should not quietly become permission to bypass a required check; equally, an inconclusive result should not be described to the user as proof that they are underage.
Decide what evidence of the decision is necessary, who may access it, and how retention will be managed. Test the age gate alongside account recovery, support procedures, and other routes into restricted areas. A well-designed check can be undermined by an exception elsewhere.
A method can disclose little information and still be unsuitable for a particular age-assurance obligation.
In the UK, Ofcom lists digital identity services among methods capable of being highly effective at establishing whether someone is 18 or older. That is not automatic approval of an individual provider or implementation.
Its guidance evaluates technical accuracy, robustness, reliability, and fairness, alongside accessibility and interoperability. The relevant duties depend on the service and its content, and providers remain responsible for the effectiveness of their age-assurance process.
For a platform choosing a provider, that means asking for evidence appropriate to its use case—not relying solely on a privacy claim or a product category. The team should assess both the quality of the age determination and the way it controls access in practice.
The European Commission’s age-verification solution offers a separate example of this approach. Its published design allows a user to communicate that they meet an age threshold without providing their full identity details to the requesting website. Availability depends on deployment by Member States or other providers.
This is not a statement that ProperUser implements the EU solution. It illustrates a useful design direction: establish the attribute needed for a decision, rather than disclose an entire identity each time.
Before integrating an age check, write one sentence describing exactly what the platform must establish. Then document the acceptable result, the response to failure, the records required, and the circumstances that call for another check.
This exposes gaps that a generic “verified user” label can hide.
When discussing a result-based approach with ProperUser, start with the age decision your platform needs to make and the information it needs to receive.
The goal is a defensible access decision supported by appropriate evidence—not a larger collection of identity documents.
Yes, some approaches separate the evidence assessment from the result received by the platform. Whether a particular approach is sufficient depends on the method, implementation, and applicable requirements.
No. Meeting an age threshold answers a narrower question. KYC can involve identity and other checks appropriate to the relationship or regulated activity.
Not necessarily. Account information and other identifiers may still identify the person or connect their activity.
No. The platform must assess whether the verification and its surrounding controls meet the requirements applicable to its service.