Use a detached proofing flow that returns only the eligibility result the site needs, such as over 18, while keeping the relying party hidden from the verifier. The proof should travel through a wallet or credential layer, not through a login path that exposes identity or context.
Why hidden-site age assurance has to separate proof from presentation
The core design choice is to treat age assurance as a detached verification step, not as a login or account-opening flow. If the verifier learns which site requested the check, the system leaks context that can be tied back to the person being checked. The safer pattern is to disclose only the eligibility result the relying party needs, such as “over 18”.
That separation matters because the verifier’s role is to attest to an attribute, not to learn the transaction context. A wallet or credential layer can carry the proof between the verifier and the site without exposing the relying party to the verifier. That preserves privacy and keeps the age check reusable across services without turning it into a tracking or profiling event.
When the verifier does not know the site, the architecture must also avoid building hidden side channels into the proof request. Request metadata, redirect patterns, session identifiers, and response timing can all reveal the relying party indirectly if the flow is not deliberately minimised.
What the proof path should and should not reveal
A hidden-site design should be built around selective disclosure and purpose limitation. The verifier should confirm the age attribute, then return only the minimum assertion needed by the service. The site can enforce its own policy based on that assertion, but it should not need the verifier to know why the check was requested or which property is being accessed.
In practice, this means the verifier should not sit inside the site’s sign-in flow, because login paths usually expose identity context, tenant context, or application identifiers. A detached proofing flow is better when the goal is to prove eligibility without binding the check to the user’s account history or the site’s internal identity model.
That also changes how you think about trust boundaries. The site must trust the age assertion, not the verifier’s knowledge of the site. If the proof is portable, the relying party can remain anonymous to the verifier while still receiving a high-confidence answer about eligibility.
How to design the hidden-site model in practice
The most robust pattern is to issue or verify an age credential once, then let a wallet present only a narrow claim to the site. This works best when the credential is privacy-preserving by design, so the verifier can attest to age without reconstructing the user’s full identity or browsing intent.
Strong implementations also minimise correlation risk by separating issuance, verification, and presentation contexts. That means different identifiers, limited logging, and no unnecessary reuse of the same browser session or app context across steps. If the system cannot avoid correlation, the design has not really hidden the site, it has only concealed it cosmetically.
For organisations evaluating an assurance stack, NHIMG’s Age Verification and Age Assurance Guide is the most direct reference for accuracy, privacy, and circumvention trade-offs in age checks. For the identity and authenticator side of the design, NIST SP 800-63 Digital Identity Guidelines helps frame assurance level, authentication strength, and the distinction between proving an attribute and running a login.
Risk and Threat Considerations
When the verifier learns the site, the privacy risk is no longer limited to the age claim itself. The request context can reveal sensitive interests, protected characteristics, or usage patterns, and it can create a correlation trail across services that users would not expect.
Failure mechanism: The flow leaks relying-party context through login redirection, shared telemetry, reusable identifiers, or verbose proof metadata, allowing the verifier or intermediaries to reconstruct where the user was trying to go.
Impact: Users can be profiled or re-identified across visits, the assurance service can become a cross-site tracking point, and the age-check control may create more exposure than the policy it was meant to enforce.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63, OWASP ASVS and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 and GDPR define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | IA-2 — Identification and Authentication (Organizational Users) | Hidden-site age assurance often must avoid turning into a login path. |
| Recommendation — Separate age assertion from account authentication and keep the verifier blind to the relying party. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The site should consume only the minimum eligibility assertion needed. |
| Recommendation — Limit the assurance flow to the attribute required for access decisions. | ||
| OWASP ASVS | V10 — OAuth and OIDC | Detached proofing flows often depend on privacy-sensitive token and federation handling. |
| Recommendation — Design token and federation flows to avoid leaking relying-party context. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication, and Access Control | Age assurance is an identity-gated access decision that must preserve least disclosure. |
| Recommendation — Apply least-disclosure controls so the relying party receives only the needed eligibility result. | ||
| GDPR | Art.5 — Principles relating to processing of personal data | Hidden-site assurance should minimise personal-data disclosure and correlation. |
| Recommendation — Minimise data collected and ensure the verifier does not learn unnecessary context. | ||
Practitioner Guidance
What to prioritise: Design the system so the verifier only emits a bounded assertion, not a session that can be repurposed for identity discovery. If the verification step can be correlated back to the site from logs, redirects, or tokens, the hidden-site requirement has not been met.
What to verify: Test the full path from browser or wallet to site and confirm that the verifier cannot observe the relying party in network metadata, UI prompts, error handling, or token contents. Also check that the site can reject or accept the assertion without asking for additional identity context.
Practitioner takeaway: Hidden-site age assurance works when the proof is portable and context-poor, so the verifier can confirm eligibility without ever becoming a proxy for the user’s destination.
Related resources from NHI Mgmt Group
- How should organisations design age assurance systems so biometric data is never exposed to unnecessary access paths?
- How should organisations design age assurance so it is hard to spoof without forcing unnecessary ID collection?
- How should organisations assess facial age estimation when they need to meet age assurance duties under the Age Appropriate Design Code?
- How do you know if age assurance is actually working?