.png)
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.
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.
The flow is deliberately familiar so you can focus on where verification happens:
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.
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_overage_in_yearsbirthdateThe verifier creates an authorisation request at:
/openid4/vp/v1_0/authorizationsThe wallet handoff is a QR code, and the verifier polls for status:
/openid4/vp/v1_0/authorizations/{authorizationId}/statusAfter authorisation, the demo retrieves:
/openid4/vp/v1_0/authorizations/{authorizationId}/policy-response/openid4/vp/v1_0/authorizations/{authorizationId}/credentialsFor protocol details, see the OID4VP specification.
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.
The scope is intentionally narrow:
These boundaries are important if you plan to use the demo as a starting point.
If you operate an age-gated service, this flow is a good template:
You can adapt the age logic or jurisdictional rules without changing the verifier pattern itself.
Try the demo and inspect how the policy and claim handling are implemented:
Have a question or want to chat about how Vidos can help? Reach out to our team of real-world practitioners today.
