EU Wallet · Network Access via PID

One wallet tap. Any network.

Signed WiFi, WPA2/3-Enterprise, Hotspot 2.0, eSIM, APN and VPN profiles issued from EU Digital Identity Wallet presentations. Guest onboarding stops being a QR-hunt and a captive portal — it becomes one wallet tap that proves who you are, then hands you a signed network configuration that expires when your stay ends. Built on published EUDI, OpenID4VP and WPA-Enterprise standards. No captive portal. No shared passwords floating on Post-It notes.

Published specification

What ships today

Today: the verifier accepts scope=network_access at /oidc.ashx?action=vp-start, preserves it across the presentation session, and the wire format is documented in /openapi.json so wallets can build against it. Signed NetworkConfig issuance is not part of the standard tenant release; the flow below is the published wire specification.

The flow

1 Guest scans venue WiFi QR

→

2 Wallet opens, shows credential picker

→

3 PID presented via OID4VP

→

4 Tenant policy check

→

5 Signed WiFi/APN/VPN config issued

→

6 Device auto-connects · expiry set

The wallet never sees a shared password. The venue never handles credentials in cleartext. The RADIUS identity is derived from the PID claims per tenant policy — typically given_name.family_name@tenant.example. Expiry is signed into the profile; when your stay ends, the device drops.

What’s in the signed configuration

{
  "profile_id":         "guest-wifi-hotel-cala-galdana",
  "network_type":       "wifi-wpa2-eap",
  "ssid":               "Hotel-Cala-Galdana-Guest",
  "eap_method":         "PEAP",
  "identity":           "anna.mueller@hotel-cala-galdana.example",
  "password_or_psk":    "<ephemeral, one-time>",
  "ca_certificate_pem": "-----BEGIN CERTIFICATE-----\n...\n-----END CERTIFICATE-----",
  "expires_at":         "2026-07-24T11:00:00Z",
  "signature":          "eyJhbGciOiJFUzI1NiIsIng1YyI6WyJNSUlD..."
}

The compact JWS (ES256, x5c chain to the tenant verifier certificate) is what the wallet uses to trust the profile. The tenant policy file decides how PID claims map to identity, EAP method, VLAN, expiry and network profile.

Where it clicks — sectors we’re building for

Hotels + short-lets

Signed guest WiFi profile at check-in via the vacation-rental PMS integration. Expiry matches the reservation. No captive portal, no printed key.

Transport hubs

Airport transit WiFi, train and coach onboard WiFi, ferry terminals. PID unlocks profile scoped to the trip; expires when you disembark.

Cafes + restaurants

Age-gated guest WiFi where the wallet also proves 18+ (piggybacks on our age-verify attestation flow).

Coworking + hot-desking

Membership check via the same PID + subscription attestation; VLAN assignment by membership tier.

Universities

Eduroam alternative for student WiFi with country/institution-scoped identity. WPA3-EAP profiles per faculty.

Corporate BYOD

Employee brings their EU Wallet to onboard personal devices to guest VLAN with corporate MDM profile install. Signed VPN peer bundle for remote workers.

MVNO + eSIM

PID + KYC unlocks a signed eSIM profile bundle. Wallet installs the SIM directly. Regulatory KYC done once, per-country.

Public sector guest WiFi

City-hall, library and municipal WiFi with PID-verified age gate (no children on adult-content-filtered SSIDs), country allow-list, and audit trail per session.

Standards + specifications

OpenID4VP 1.0 §5.2 — scope=network_access (Aloaha extension, published in /openapi.json).
EUDI ARF §5f — corporate acceptance of the EU Wallet as a customer identity by December 2027 (banks, telcos, insurers, platforms, healthcare).
WPA2/3-Enterprise (EAP) — PEAP, EAP-TTLS, EAP-TLS profiles from the signed configuration.
Hotspot 2.0 / Passpoint — per-device policy applied without a captive portal.
GSMA eSIM (SGP.22) — SM-DP+ discovery hooks in the NetworkConfig for eSIM provisioning.
RFC 9432 (draft) signed WiFi QR — the QR the guest scans is itself signed so it cannot be spoofed by rogue APs.

Aloaha in-house, not a fork

Every protocol layer — SD-JWT VC parsing, JWS + KB-JWT verification, OpenID4VP request/response, DCQL, JWE ECDH-ES, x5c chain validation, StatusList revocation, OpenID Federation 1.0 — is written by the Aloaha Limited team. No eudi-lib-*, no third-party EUDI SDK anywhere in the dependency tree. Generic infrastructure libraries (JWT/JWS, HTTP, .NET BCL crypto primitives) are widely-used open-source components; the EUDI-protocol layer is 100% Aloaha-written. Built and maintained on Malta. That gives your CISO an auditable in-house EUDI stack under a single legal entity, on our own release cadence — not gated on a consortium’s next SDK version.

Status. Verifier accepts scope=network_access. Wire format published in /openapi.json. Signed NetworkConfig issuance is not part of the standard tenant release. Talk to us if you want to run a pilot for your sector.

Learn more

Frequently asked questions

Which EUDI scope powers this?

OpenID4VP 1.0 scope=network_access, an extension we've published and implemented on the verifier side. The scope is recognised at vp-start; signed NetworkConfig issuance is not part of the standard tenant release. Wallets that support scope=network_access can build against the wire format today.

What network types are covered by the specification?

WiFi WPA2/3-EAP (corporate + WPA3-Enterprise), WPA2-PSK (guest WiFi with rotated PSK), Hotspot 2.0 / Passpoint, eSIM profile provisioning (SM-DP+ discovery hooks), APN configuration (4G/5G), OpenVPN and WireGuard peer bundles. The wire schema is enumerated in the /openapi.json spec under the NetworkConfig object.

Is this shipped today?

Verifier side accepts scope=network_access and preserves it across the vp-start / vp-response session. Signed NetworkConfig issuance is not part of the standard tenant release. This page documents the wire format so wallet vendors, tenants and integrators can build against it.