Linaltec

EUDI Wallet Access Control
Security Check Demo

An interactive demonstration of how the Wallet Access Control Engine (WACE) evaluates security checks and informs users about risks before sharing personal data — based on CEN/TS 18297 and the eIDAS 2.0 regulatory framework.

CEN/TS 18297 eIDAS 2.0 IA 2024/2982 ETSI TS 119 472-3 ISO/IEC TS 27560 GDPR Art. 9

Purpose of This Demo

The EU Digital Identity Wallet places the citizen at the centre of every data-sharing transaction. But the citizen is also the weakest link in the security chain — they must make informed decisions about sharing sensitive personal data with relying parties, often under time pressure and without technical expertise.

CEN/TS 18297 defines the Wallet Access Control Engine (WACE) — a set of security controls that evaluate every relying party request before the user sees it. The WACE checks certificates, role types, trust list registrations, embedded disclosure policies, processing information notices, and user preferences. Based on these checks, it produces a recommendation: grant, advise caution, recommend against sharing, or deny outright.

This demo illustrates how those security checks work and how the wallet user could be informed of the results. It covers the full notification inventory (N-01 through N-16) across all lifecycle phases defined in the CEN/TC 224 WG20 working document on wallet user notifications.

This demo is not intended to dictate how the user experience should look. It does not prescribe a specific UX design or visual style. Its sole purpose is to demonstrate the security checks performed by the WACE, the warnings and notifications generated, and how different severity levels could be communicated to help users make informed decisions. Wallet implementers are free to design their own user interfaces while ensuring the underlying security checks and notifications defined in the standard are properly conveyed.

What the Demo Covers

The interactive demo below simulates a wallet phone screen with a control panel for selecting different scenarios. Each scenario triggers a different combination of WACE security checks and produces a specific outcome. The demo covers: certificate validation against ETSI EN 319 411-1 policies, relying party role type matching via access control metadata, RP identity verification against EU Trusted Lists (ETSI TS 119 612), embedded disclosure policy evaluation per TS 119 472-3, ISO/IEC TS 27560 processing information notice validation, user preference conflict detection, Level of Assurance authentication requirements including multi-factor authentication simulation, user override with informed consent per REQ-10.2 and REQ-10.3, cross-border trust gaps for non-EU jurisdictions, and transaction log retention policies.

The demo also illustrates the issuer governance problem: wallet providers lack domain expertise to craft meaningful warning messages. A toggle between "Wallet Provider" and "Issuer Context" text demonstrates how issuer-authored notifications can significantly improve user understanding of risks.

How to Test the Scenarios

Select a scenario from the control panel in the demo below. The phone screen will display the WACE assessment. Each scenario shows a description and testing steps when selected. Use the Details button to drill into checks, and toggle between Wallet Provider and Issuer Context text to see the governance difference.

Key Scenarios to Try

These four scenarios cover the main paths a wallet user will encounter: a clean pass, override warnings at different severity levels, a multi-factor authentication flow, and a hard denial.

💊
1. Clean Pass
Pharmacy ePrescription — all WACE checks pass, user approves, transaction completes. Shows the baseline "everything works" flow.
🏪
2. Override Warning
Scenarios where the WACE recommends caution. Not Recommended triggers an override confirmation popup (e.g. Unknown Retailer, Cross-Border). Advisory allows approval with a warning (e.g. Insurance Retention Conflict).
🇪🇺
3. LoA High & MFA
eGov Portal — all checks pass but LoA High triggers multi-factor authentication. Simulate PIN + biometric success/failure paths.
🚨
4. Denied
Cascade Denial — an unverifiable entity failing every trust check. Also: Log Deletion Restricted where a legal retention period blocks the action.

Outcome Levels

🛡️ Granted All checks pass — safe to approve
⚠️ Advisory Minor conflicts — approval with warning
⛔ Not Recommended Trust or policy failures — override required
🚫 Denied Multiple critical failures — access blocked

Interactive Demo

Access Control Flow — CEN/TS 18297 Clause 6.2.2

The diagram below illustrates the three-step access control flow for relying party operations over Wallet Held Attestations: wallet unit processing (automated security checks), wallet user decision (human approval with override option), and wallet response (final decision returned to the relying party with transaction logging).

Figure 5 — Access Control Flow for RP Operations over WHAs CEN/TS 18297 — Clause 6.2.2 RP Request Received (see 5.3) Step 1 — Wallet Unit Processing (6.2.2.3) 1a) RP Authentication Check [Ctrl-5, Ctrl-6] 1b) RP Authorization Check [Ctrl-2, Ctrl-5, Ctrl-6] 1c) WHA Validity Check [Ctrl-0] 1d) Policy Evaluation [Ctrl-1, Ctrl-4, Ctrl-13, Ctrl-14] WACE Output (6.2.2.3.5) access_granted_ recommended access_not_granted_ recommended access_denied (bypass Step 2) Step 2 — Wallet User Decision (6.2.2.4) 2a) WACE Decision Presentation [Ctrl-7] 2b) User Override Option [Ctrl-10] 2c) User Approval & WHA Selection [Ctrl-8] 2d) User Authentication [Ctrl-3, Ctrl-9] User Decision Output (6.2.2.4.4) access_granted access_not_granted Step 3 — Wallet Response (6.2.2.5) 3a) Return Final Decision to RP [Ctrl-11] 3b) Transaction Log Management [Ctrl-12] Response Returned to RP Wallet Held Access Control Metadata (5.2.2) Policies Instructions RP Registration Certs Pricing Policies Consumed by 1a–1d Relying Party Request (5.3) Operation type WHA list RP attestation/cert Processing Info Notice Legend Step 1: Wallet Unit Processing Step 2: Wallet User Decision Step 3: Wallet Response Decision point access_denied (bypasses Step 2) Data input (metadata / RP request) Ctrl-N references correspond to CEN/TS 18297 control identifiers (Table 1, Clause 5.2.1)