LuxID as OpenRoaming IdP

Who this page is for. OpenRoaming operates at the network layer, not the app layer, so it sits apart from the rest of the Features section. It is relevant to two audiences: network-infrastructure teams onboarding a Wi-Fi network, and developers who will use LuxID's planned APIs to generate and manage OpenRoaming (Passpoint) profiles programmatically. The profile-generation APIs are not yet available; this page describes the model so you can plan for them.

What is OpenRoaming?

OpenRoaming is a wireless federation standard operated by the Wireless Broadband Alliance (WBA) (opens in a new tab).

It enables users to automatically connect to participating Wi-Fi networks - without manually entering credentials each time - using an identity they have already established with a trusted identity provider.

LuxID operates as an OpenRoaming Identity Provider (IdP). Users who have a LuxID Account and have set up OpenRoaming on their device can seamlessly roam onto any participating Wi-Fi network in Luxembourg (and globally within the OpenRoaming federation) using their LuxID identity as the authentication credential. No browser, no login form, no re-authentication.

How OpenRoaming works

OpenRoaming operates outside the standard browser-based OAuth/OIDC flow. Authentication happens at the network layer using:

• EAP-TTLS (Extensible Authentication Protocol - Tunneled Transport Layer Security) as the authentication mechanism, with an anonymous outer identity (anonymous@idp.luxid.lu) and a per-device pseudonymous credential (a per-device pseudonym and password) as the inner identity
• RadSec (RADIUS over TLS, RFC 6614 (opens in a new tab)) as the secure transport for authentication messages between the Wi-Fi access point and the LuxID authentication backend
• Passpoint (also known as Hotspot 2.0, based on IEEE 802.11u (opens in a new tab)) as the device-side protocol that enables automatic network selection and authentication without user intervention

The user's device is provisioned with a Passpoint profile containing a per-device pseudonymous credential issued by LuxID. When the device detects a participating OpenRoaming network, it automatically starts EAP-TTLS: the outer identity presented to the network is always anonymous@idp.luxid.lu (only the realm is visible to the network operator), and the per-device pseudonym is exchanged inside the encrypted TLS tunnel. The network's RADIUS server forwards the authentication request via RadSec to LuxID. LuxID validates the pseudonymous credential (stored server-side only in hashed form) and grants or denies network access. Certificate-based EAP-TLS is on the roadmap as a later phase, backed by a LuxID internal CA; it is not the launch mechanism.

From the user's perspective: they set up OpenRoaming once (install the Passpoint profile), and from that point forward their device connects to participating networks automatically.

Participating networks

OpenRoaming via LuxID is available on Wi-Fi networks deployed by POST Luxembourg and partner network operators. Use cases and deployment environments include:

• POST public Wi-Fi hotspots (transport hubs, public spaces, commercial areas in Luxembourg)
• Hospitality venues (hotels, conference centres) participating in the OpenRoaming federation
• Transit infrastructure (train stations, bus terminals)

The OpenRoaming standard is global: a LuxID OpenRoaming identity is also valid on any network operated by other WBA OpenRoaming members internationally. Network availability outside Luxembourg depends on WBA federation coverage.

Event signals (POST-internal only)

OpenRoaming sign-in events combine identity (sub, email), network and location context in a single payload. Because of that sensitivity, they are delivered only to the POST-internal OpenRoaming operations application - never to partner Event Hub subscriptions. Partner applications receive no per-connection OpenRoaming events, regardless of their Event Hub configuration or Sphere.

When a user connects to a Wi-Fi network via OpenRoaming, LuxID emits a user.signed_in event with OpenRoaming-specific context to that internal application (the example below is what the internal consumer receives; it is shown here so developers understand what exists and what they will not be sent):

{
  "event_type": "user.signed_in",
  "event_id": "evt_4b5c6d7e-8f9a-0b1c-2d3e-4f5a6b7c8d9e",
  "occurred_at": "2026-05-22T08:45:00Z",
  "application": {
    "id": "app_openroaming_post",
    "name": "POST OpenRoaming"
  },
  "subject": {
    "sub": "a3f2c1d8-9b4e-4a2f-8c1d-3e7b9a2f1c4d",
    "email": "utilisateur@example.lu"
  },
  "context": {
    "ip_address": "192.0.2.200"
  },
  "data": {
    "channel": "openroaming",
    "network": "POST_WiFi_LuxGare",
    "ssid": "OpenRoaming",
    "location": "Luxembourg Gare Centrale"
  }
}

The distinguishing fields:

• channel: "openroaming" - identifies this as a Wi-Fi federation sign-in, not a browser-based login
• network - the operator-assigned network identifier
• ssid - the Wi-Fi SSID the device connected to
• location - a human-readable location label (where configured by the network operator)

These fields together form a location trace of an identified user, which is why the event's only audience is POST-internal operations. The events power internal purposes such as federation health monitoring, capacity planning and abuse investigation - not partner-facing features.

Use cases for Partners

Profile provisioning, not event consumption

What a Partner application can do with OpenRoaming is provision and manage Passpoint profiles for its users via the planned profile-generation APIs (see Configuration below) - for example, a transit or tourism app issuing a profile at the end of onboarding so the user's device connects on their first visit.

What a Partner application can not do is consume per-connection OpenRoaming signals. Contextual triggers ("show a welcome message when the user joins my Wi-Fi"), Wi-Fi usage tracking, and correlation of web sessions with Wi-Fi sessions are not possible by design: connection events are identity-plus-location data and stay inside POST Luxembourg. Capacity planning and usage analysis based on these events are POST-internal operations, performed by POST Luxembourg as the data controller for the OpenRoaming service.

This is not a standard OAuth flow

OpenRoaming authentication does not involve a browser, an authorisation code, or OIDC tokens. The identity is asserted at the network layer via EAP-TTLS with per-device pseudonymous credentials. LuxID does not issue an ID Token or access token for OpenRoaming connections.

OpenRoaming connections do not surface in any partner-facing channel at all: no tokens are issued, and no events are delivered to partner Event Hub subscriptions. The user.signed_in events with channel: "openroaming" exist only on the POST-internal stream described above, and there are no amr or acr claims for OpenRoaming connections in that payload.

Configuration

Programmatic profile generation (planned)

LuxID plans to expose APIs for Partners to generate and manage OpenRoaming Passpoint profiles programmatically - for example, to issue a profile to a user at the end of an onboarding flow, or to revoke one. These APIs are not yet available.

When released, they will let a Partner application drive profile issuance rather than relying on the user to download a profile manually from their LuxID Account. Until then, profile provisioning is the manual user-setup flow below.

User setup

Users set up OpenRoaming by:

1. Signing in to their LuxID Account (opens in a new tab).
2. Navigating to the Wi-Fi Roaming or OpenRoaming section.
3. Downloading or installing the Passpoint profile for their device.
4. The profile installs a per-device pseudonymous credential (a per-device pseudonym and password unique to that device), which the device presents automatically - inside the EAP-TTLS tunnel - when a participating network is detected.

Setup is a one-time process per device. Each device receives its own credential, which LuxID can revoke or rotate individually (for example when a device is lost, replaced, or removed from the account) without affecting the user's other devices or the LuxID Account itself.

Partner / network operator onboarding

OpenRoaming is not part of standard LuxID Partner onboarding. Network operators and Partners wishing to integrate with LuxID's OpenRoaming infrastructure must contact LuxID separately.

The onboarding process involves:

1. Agreeing a network operator agreement with POST Luxembourg covering OpenRoaming participation.
2. Exchanging RadSec details: you provide your RADIUS infrastructure's source addresses and RadSec client certificate, and LuxID provides its federation endpoint. Your network initiates the RadSec connection (TCP 2083, outbound) to the LuxID federation endpoint - LuxID does not connect inbound to your RADIUS server.
3. Providing the SSID and location metadata for your network (used in the POST-internal event payloads and operations tooling).
4. Testing federation connectivity against the LuxID staging environment, which is federation-connected via the WBA test realm. (api-uat.luxid.lu is the UAT environment for the Partner API only; login-uat.luxid.lu plays no role in federation testing.)
5. Promoting to production.

This process is distinct from, and independent of, registering a web application as a LuxID Partner.

Security and privacy notes

Tunnelled pseudonymous authentication. EAP-TTLS wraps the credential exchange in a server-authenticated TLS tunnel, and the credential itself is a per-device pseudonym - never the user's LuxID email or password. The outer identity visible to the network is always anonymous@idp.luxid.lu, so the network operator learns only that a valid user of a trusted IdP authenticated; POST Luxembourg alone holds the pseudonym-to-account mapping. This is materially stronger than shared-passphrase Wi-Fi (WPA2-PSK) and captive portals.

EAP-TLS is roadmap. Certificate-based EAP-TLS with a LuxID internal CA is planned as a later phase of the OpenRoaming service. Documentation and profiles will be updated when it becomes available; today's profiles authenticate via EAP-TTLS.

No captive portal. OpenRoaming eliminates captive portals. Users do not enter credentials on a web page to access Wi-Fi. This removes phishing risk associated with fake Wi-Fi login pages (evil twin attacks).

Credential revocation. Each device credential can be revoked individually - when the user removes the device, when a profile is reissued, or when the LuxID Account is suspended or deleted. Devices using a revoked credential will be refused network access on their next authentication attempt. The revocation takes effect on the RADIUS authentication cycle, which may mean there is a brief window before revocation is enforced on an already-connected device.

Events are POST-internal. OpenRoaming sign-in events are delivered only to the POST-internal OpenRoaming operations application. The sub in those events is scoped to that internal application; because no partner ever receives the events, cross-referencing a Wi-Fi connection with a Partner's web sessions is not possible - by design, not by configuration.

Privacy - location data stays with the controller. OpenRoaming events include network location metadata (network name, SSID, location label) - a record of where an identified user connected. POST Luxembourg, as the sole data controller for the OpenRoaming service, processes this data under GDPR Article 5(1)(c) (data minimisation) for service operation, security and abuse handling, within the scope of the updated LuxID DPIA. Partners never receive or hold this data, so no partner-side lawful basis, retention rule or register entry arises from OpenRoaming connections.

GDPR - Wi-Fi connection as personal data. A record of which Wi-Fi network a user connected to, when, and for how long constitutes personal data (location history). That is precisely why it is not shared: the network operator sees only a rotating pseudonym on its own network, and partner applications see nothing at all.

Related pages

• Events and Event Hub
• Single sign-on and LuxID Pro