Age Verification with the EUDI Wallet: The Wine Shop Demo

Age-gated commerce is a common first use case for the EUDI Wallet. The challenge is simple: verify eligibility without collecting more personal data than you need. The wine shop demo shows one practical pattern: request a single PID age attribute, apply a destination-specific legal age rule, and complete a simulated purchase.

This post walks through the flow, the verification details, and the scope so teams can reuse the pattern safely.

What is the wine shop demo?

The wine shop is an end-to-end demo that simulates a real purchase journey. The scope is a reference flow with simulated payment and simplified business logic. The value is that the full journey is inspectable and aligned to the EUDI Wallet verifier pattern.

• Live demo
• Source code

The user journey end-to-end

The flow is deliberately familiar so you can focus on where verification happens:

1. Browse and add items to the cart.
2. Select a shipping destination.
3. Verify identity with the wallet.
4. Evaluate the age check.
5. Complete a simulated payment and confirm the order.

The destination choice matters because legal drinking age is jurisdiction-specific. The demo uses the shipping destination to set the minimum age threshold used for eligibility.

What gets requested from the wallet?

The demo requests a single PID age attribute, chosen by user preference, rather than a full identity bundle. The PID credential format shown is SD-JWT (dc+sd-jwt) with VCT urn:eudi:pid:1.

The supported attributes are:

• age_equal_or_over
• age_in_years
• birthdate

The verifier creates an authorisation request at:

• /openid4/vp/v1_0/authorizations

The wallet handoff is a QR code, and the verifier polls for status:

• /openid4/vp/v1_0/authorizations/{authorizationId}/status

After authorisation, the demo retrieves:

• Policy response: /openid4/vp/v1_0/authorizations/{authorizationId}/policy-response
• Disclosed claims: /openid4/vp/v1_0/authorizations/{authorizationId}/credentials

For protocol details, see the OID4VP specification.

How the age check works

Eligibility is computed from the disclosed attribute and the destination’s legal age:

• age_equal_or_over.<minimumAge> uses a boolean attestation.
• age_in_years is compared directly to the required age.
• birthdate is used to compute age and compare to the required age.

This keeps disclosure minimal: the relying party only sees what it needs to decide eligibility, and the user explicitly consents to the attribute they share.

Scope boundaries and guardrails

The scope is intentionally narrow:

• The payment step is simulated.
• Issuer trust-chain validation runs through the authorizer flow, rather than the browser UI.
• The business logic is simplified to highlight the verification decision.

These boundaries are important if you plan to use the demo as a starting point.

How to reuse the pattern

If you operate an age-gated service, this flow is a good template:

• Use a single, minimal attribute to satisfy the policy.
• Tie the decision to jurisdictional rules you control.
• Keep the user journey short and transparent.

You can adapt the age logic or jurisdictional rules without changing the verifier pattern itself.

Next steps

Try the demo and inspect how the policy and claim handling are implemented:

• Live demo: https://eudi-usecase.demo.vidos.id/
• Repo: GitHub - vidos-id/usecase-demos: Collection of demos showcasing the use of Vidos in various use cases
• EUDI use case manuals: https://ec.europa.eu/digital-building-blocks/sites/spaces/EUDIGITALIDENTITYWALLET/pages/896827987/Use+case+manuals
• PID rulebook: European Digital Identity Wallet - European Digital Identity

Talk to our team

Have a question or want to chat about how Vidos can help? Reach out to our team of real-world practitioners today.