Age Verification With Business-Redacted Output
How an mDL threshold check can keep date of birth out of the relying party's result, what Alentra still processes and retains, and what counsel must decide.
“The business receives only a yes or no” and “nobody processes personal data” are not the same claim.
That distinction matters in every age-assurance design. The relying party may need only one decision—whether a threshold is satisfied—while the verification service still needs enough credential data to compute and prove it. A production review should map both sides of that boundary instead of advertising the whole flow as zero-PII.
This article explains Alentra's current boundary. It is product documentation, not a conclusion that the method satisfies every age-verification law. Requirements vary by state, industry, audience, method, recordkeeping duty, and pending litigation. Obtain counsel for the actual workflow.
What the business receives
Alentra's age_verify primitive accepts an arbitrary min_age. The wallet presentation includes the date of birth. Alentra verifies the presentation, computes whether the threshold is satisfied, and returns only these fields to the business:
{
"primitive": "age_verify",
"satisfied": true,
"min_age": 21,
"audit_id": "sess_example_0"
}
The business does not receive the name, address, DOB, license image, or other identity claims through age_verify. That makes the result business-redacted.
What Alentra still processes and retains
Alentra is not blind to the identity. It processes the wallet-provided DOB to calculate the threshold. The underlying signer and wallet evidence is sealed into the completed audit record using AES-256-GCM with a per-record data key wrapped by Google Cloud KMS.
Completed evidence is deliberately immutable. The customer, signer, administrator, self-service flow, and account-closure request cannot delete a completed result, its proof, audit row, or integrity links. The exact evidence period and any legal hold must be stated in the signed customer schedule.
That retention can support later evidence and legal claims, but it also creates a privacy obligation. A customer must confirm that the purpose, notice, instructions, retention period, and legal basis fit its use case.
Why Alentra does not use only a fixed wallet predicate
Some mDL credentials and wallet paths can expose fixed predicates such as “age over 18” or “age over 21.” They are not available uniformly for every threshold and supported presentation path.
Alentra computes from DOB so a customer can request an arbitrary threshold with one consistent contract. The tradeoff is explicit: the business sees only the verdict, while Alentra momentarily processes DOB and retains encrypted signer evidence.
What Alentra does not do
The primitive is intentionally narrow:
- It does not upload or store a photographed ID image.
- It does not send DOB or identity claims to the business.
- It does not issue a reusable Alentra credential that other platforms can replay.
- It does not decide whether a pass or fail should grant access.
- It does not replace a customer's legal analysis, notices, fallback, appeals, or broader KYC controls.
- The offline verifier can re-check issuer/device evidence only when the authorized disclosure includes that decrypted evidence and the verifier supplies trusted issuer/TSA roots; the normal business age-verification view remains identity-redacted.
Availability is part of the design
The Commission EUDI reference wallet is Alentra's current no-hardware private-beta test provider across the real EU country routes; Google Utopia remains available for Android testing. Google, Apple, and EUDI production routes stay coming soon until their provider/issuer approval, production trust and credentials, supported browser/device behavior, real acceptance, and Alentra release approval are complete.
A real product needs a fallback for users who do not have any available ledger credential. That fallback has its own data and legal model and should not silently weaken the privacy promise of the primary path.
A practical review checklist
Before shipping an age-verification flow, answer these questions in writing:
- Which law, product rule, or internal policy creates the threshold?
- Which data reaches the business, Alentra, the wallet provider, and any fallback vendor?
- What notice and consent are shown before the wallet presentation?
- What does a failed, unavailable, or unsupported presentation do?
- How long must completed evidence remain, and which legal holds can extend it?
- Who can decrypt full evidence, under what role, and with which audit trail?
- How are subject requests handled when completed evidence cannot be customer-deleted?
- How will webhooks be verified and deduplicated?
- How will the business reconcile a missing or delayed webhook?
- Has counsel approved both the credential route and every fallback?
age_verify is charged only when the step succeeds, at the configured rate shown in the dashboard. Pricing is the easy part. Defining the data boundary and evidence schedule is the work that makes the integration production-ready.
See the developer overview, privacy policy, and pricing before testing the EUDI reference sandbox.
Our field notes are checked against primary regulations, standards, and official provider documentation. Read the research standard.
