Relay updates: the cryptography, new deployment options, and new claim schemas

When we introduced Relay, our double-blind assurance product, we made the case for separating identity verification from the user’s context.
We offered a way for organizations to verify a claim about a user, such as their age, without knowing the user’s identity. And for us to verify the claim without knowing which website or app the user is on. We immediately got a positive response.
Adult content platforms in nearly every jurisdiction that requires age checks came to us first. The strongest pull has been from Italy and France, where organizations need to prioritize age checks via a double-blind implementation.
Creator platforms and dating apps in the UK, the Netherlands, France, and Germany followed. Each app has a version of the same age-claim requirement and offers a product where heavy identity flow can reduce signups. More recently, we’ve seen growing interest from organizations serving minors driven by the goal of minimizing PII liability and who want to rely instead on verified age bands.
These are different companies facing different regulators and requirements, but we hear the same underlying request to help verify users’ ages without handing over identity data.
This post takes a closer look at how Relay addresses this need, how organizations can deploy Relay, and how we’ve grown the claim type library.
Relay uses Privacy Pass to separate claims and identity
Privacy Pass is an architecture for privacy-preserving authorization. Your server redeems a token for a claim result, and that token can’t be linked back to the request that issued it. This lets Relay return an answer without Persona learning who asked for it. The Relay whitepaper (coming soon) has the full protocol details and threat model.
Privacy Pass is not something Persona invented. It is an open IETF standard, published as RFCs 9576, 9577, and 9578 in June 2024. Cloudflare and Apple also use it for proving something is legitimate without revealing who is making the request.
A blind signature underpins the process and helps separate the token issuance and redemption.

This is how Relay separates what each part can learn:
| Party | Knows | Doesn’t know |
|---|---|---|
| Your organization | The claim result | The end user’s name, birthdate, documents, or any underlying identity data |
| Persona | The identity data needed to derive the result | Which platform requested the verification or received the claim result |
To minimize risk, Persona deletes verification data once it produces the claim result. You can also encrypt the claim payload with your own key so only your server can decrypt it, and Oblivious HTTP keeps users’ IP addresses hidden from Persona.
If you use Persona’s Server SDKs or Relay Gateway Service, they handle blinding, signing, and unblinding automatically, so you don’t need to implement the cryptography yourself.
See it for yourself
Privacy claims are easy to make and harder to substantiate, so here is what you can inspect on your own:
The public demo is open to anyone, and the activity panel shows each step in real time. Switching to the technical view shows the same steps as Server SDK calls, Gateway Service requests, or raw API requests, so you can see how issuance and redemption remain separate.
The developer documentation, including the server SDK quickstart and our open-sourced repo for Relay, which walks through session creation, pass issuance, and redemption in code.
The Privacy Pass RFCs document the public standard behind Relay’s implementation.
New ways to deploy Relay
Regulatory demands for age assurance can apply regardless of a company’s engineering resources. A boutique storefront faces the same legal requirements as a global social platform, yet it often lacks the technical staff to build a complex identity system.
The core privacy benefits of Relay remain the same regardless of implementation. We are expanding how you can deploy it so that technical overhead doesn’t force an organization to collect more identity data than necessary.
Integrating Relay involves two choices: where the Privacy Pass exchange runs and how the verification flow appears to your users. The underlying cryptographic separation remains the same across all deployment paths.
Where the exchange runs
These options differ mainly in how much of your own infrastructure is involved.
Server SDK: The Server SDK handles Privacy Pass cryptography, retries, and idempotency for you.
Relay Gateway Service: The Relay Gateway Service provides a self-hosted HTTP service for teams that don’t want to add the Server SDK to their application code.
API: The API gives you direct control if you want to implement the Privacy Pass protocol in your runtime.
What the user sees
The verification process can live inside your product or be handed off entirely, depending on how much of the experience you want to own.
Embedded widget, a checkbox-style component in your interface
Hosted flow, if you would rather not embed anything
iOS and Android SDKs for native applications
Light, dark, and auto theming so the flow matches your product
Learn more: Integrating Relay
Claim types in Relay
As Relay adoption grows, we’ve become more convinced that claims can matter as much as identity verification results. The main difference between the two is that a verification check via Persona could return a record containing extracted data, images, confidence scores, and other information that your organization must protect. A claim returns an answer along with a public description of what was checked and the standard applied.
The claim’s structure ensures that regulators, issuing authorities, and verification platforms across the identity ecosystem can understand it regardless of their affiliation with Persona.
Verification → { name, dob, doc_number, doc_image, selfie, checks[], ... }
Claim → { claim_type: 'age_over_18_united_kingdom',
claim_result: 'passed',
methodology: [...] }
Persona configures different claim types in Relay to align with industry best practices, and each claim includes the information we confirm, the required assurance level, and the associated methods that can be used to check that claim.
We’ve grown our library of claims largely in response to regulatory changes across different markets. Today, you can use Relay for:
Market-specific Age 18+ claims for the United Kingdom, Germany, France, Italy, Brazil, and Australia. The threshold is the same across these claims, but the assurance level and methods behind each one align with local guidance.
Age 16+ for Australia for the social media provisions in the Australian codes.
Age 18+ Verified and Age 21+ Verified, which use a government ID matched to a live-bound selfie and are informed by ISO 27566-1. These are the general-purpose options for markets without dedicated guidance.
If you’re determining which requirements apply in each market, Persona Atlas tracks age assurance regulations.
In most cases, organizations only need a pass-or-fail claim result. But certain workflows require more granularity. We’re working on new claims in Relay that can return a verified value, such as a date of birth, using the same cryptographic separation between issuance and redemption.
Where we are headed
Relay supports our broader goal of making it technically and financially easier to preserve people’s privacy.
Part of this goal is to give organizations an easy way to minimize the data they need to collect, know, or store in order to comply with regulations. That’s what Relay does, and we’re eager to hear your feedback. Please let us know if you have requests for new claim types, more flexible ways to express claims, or server SDK support for additional languages.
While Relay minimizes data collection wherever possible, there will still be times when organizations have to collect and secure private data, as well as give people the ability to view, correct, and request deletion of their data. We’re developing a set of tools that will help address these requirements.
Relay is generally available. If you want to confirm age or eligibility without collecting full identity data, explore Relay, read the developer documentation, or try the live demo.
Age assurance requirements vary by jurisdiction and use case. While Persona’s claim types are informed by regulatory guidance, standards, and industry best practices, your organization is responsible for determining how to implement age verification in a way that meets applicable laws and requirements. The information provided is not intended to constitute legal advice.
The information provided is not intended to constitute legal advice; all information provided is for general informational purposes only and may not constitute the most up-to-date information. Any links to other third-party websites are only for the convenience of the reader.

