Passpoint Certified Hotspot 2.0
Seamless and Secure
Imagine if Wi-Fi connectivity was as secure, simple, and seamless as cellular. Just switch on your device, and you are connected. This is the vision behind Hotspot 2.0 (HS 2.0), nowadays mostly referred to by Wi-Fi Alliance’s equipment certification name – Passpoint®.
It enables compatible devices to automatically and silently discover Wi-Fi access points that have roaming agreements with the user’s home network. The device will then automatically and securely connect to the secure Wi-Fi network.
The roaming use case is where Passpoint shines. The WBA OpenRoaming initiative has quickly transformed Passpoint from a promising technology to potential mass adoption. The fact that Passpoint profiles for OpenRoaming are now enabled in many handsets from the factory will vouch for rapid development. OpenRoaming has the potential to make Wi-Fi roaming just as seamless for the user as roaming with cellular phones.
This opens up new business opportunities for Carrier Wi-Fi when a critical mass of Hotspot 2.0-enabled Wi-Fi access points, roaming agreements, and devices have been rolled out.
A Passpoint certified Hotspot 2.0 network is defined by supporting the following functions:
- The network (Wi-Fi access point) should broadcast its capabilities and available services using 802.11u and a protocol called ANQP.
- The network must use 802.1x-based authentication and WPA2 or WPA3 for over-the-air encryption.
- Support for EAP-SIM/AKA (SIM identity-based) or EAP-TLS/TTLS (certificate-based methods usually for non-SIM devices) authentication.
- Optional Wi-Fi roaming with home operator billing.
Passpoint is designed to create a carrier-grade Wi-Fi service with a familiar and seamless user experience like that of cellular networks. However, mobile operators can comfortably apply EAP-SIM/AKA authentication and mobile core integration outside the complete Hotspot 2.0/Passpoint specification. Aptilo Networks was already providing such solutions long before the release of the first Passpoint-capable devices. This also means that EAP-based authentication (SIM/AKA and TLS/TTLS) is not equivalent to Passpoint as such, which is a common misunderstanding.
Passpoint Under the Hood
How Passpoint Works
- The 802.11u-capable Wi-Fi Access Point (AP) advertises Passpoint support in the beacon.
- The device probes with Passpoint support.
- The device selects Wi-Fi AP and performs an ANQP request to determine what providers are supported, roaming consortiums supported, authentication methods available, and other capabilities of the Wi-Fi AP.
- The Wi-Fi AP responds to the ANQP query with the requested information.
- The device compares its provisioned connection profile information against the Passpoint data from the Wi-Fi APs and associates it with the best BSSID (Basic Service Set Identifier). The device is connected to the Wi-Fi Network.
Note that this happens in the background without user interaction, except in the last step, where the user may or may not be involved in deciding how to connect, for instance, if the Wi-Fi network and the device support the same set of multiple Passpoint services.
Enea’s Role in a Passpoint-Enabled Wi-Fi Service
The Enea Aptilo SMP (software) or SMP-S (service on AWS) includes EAP authentication support and all the necessary back-end service management functions for a Passpoint-certified Hotspot 2.0 Wi-Fi network.
In our solution, SIM-based devices use SIM authentication (EAP-SIM/AKA) as the preferred EAP method. Operators can typically perform mass-provisioning of the necessary Passpoint profiles through central device management systems.
This provisioning is more challenging for non-SIM devices using EAP-TLS/TTLS. There is also a need to provision ad-hoc users at the Hotspot 2.0 service. The Passpoint Release 2 (R2) with its online signup server (OSU) was created for this purpose, but has been removed from the standard (learn more here Passpoint releases) The best practice for provisioning Passpoint profiles on non-SIM devices is to use a simple tablet or smartphone app that automatically provisions EAP-TLS/EAP-TTLS-based profiles.
For those that don’t want to deploy and maintain apps, we propose a pragmatic approach to Passpoint based on release 1 and the Internet Engineering Task Force (IETF) Captive Portal API (RFC8908 and RFC8910).
Let’s explore the
Different Passpoint Releases
Passpoint exists in three sequential releases.
Passpoint Release 1 (R1)
Passpoint was first introduced in 2012, bringing a new set of protocols and standards, including 802.11u and ANQP. These innovations allowed devices to automatically discover and connect to networks that support Passpoint, selecting the most optimal connection.
Nearly all modern mobile phones and laptops, including Apple iPhones (despite not being formally certified by Apple), support Passpoint Release 1 (R1). However, onboarding new devices remains a challenge. Users typically need to manually provision Passpoint R1 credentials by downloading a file that contains the necessary connection profile and credential information. While mobile operators can push these profiles to devices over-the-air (OTA), other service providers can streamline this process using an app. SDKs are available to help integrate this functionality into existing apps, making it seamless for users.
Passpoint Release 2 (R2) – Removed by Wi-Fi Alliance
In 2023, the Wi-Fi Alliance removed Passpoint Release 2 (R2) from the standard due to the industry’s inability to secure support from Apple. The key feature of R2 was the Online Sign-Up (OSU) function, which allowed users to provision Passpoint profiles on an ad-hoc basis. Although this feature might be reintroduced in a simplified form in the future, Passpoint profiles can currently be provisioned over-the-air, through an app, or via a third option—our pragmatic approach using a portal and the Captive Portal API.
Passpoint R2, released in 2014, included the now-discontinued OSU server. This feature enabled new users to create accounts and easily provision Passpoint credentials at the point of access, allowing for seamless ad-hoc sign-up. Users could even choose their preferred service provider if multiple options were available. Passpoint R2 required a separate SSID for Online Sign-Up, which could be either an open SSID or an OSEN (OSU Server-only Authenticated L2 Encryption Network).
Passpoint Release 3 (R3)
Passpoint Release 3 (R3), introduced in 2019, is supported by Android 12 and higher, while iPhone remains on R1. Passpoint R3 introduces several new ANQP protocol elements and enhances operator and end-user interaction. While earlier versions focused primarily on automatic connection and user onboarding, Passpoint R3 aims to improve captive portal functions through enhanced ANQP messaging.
For the first time, Passpoint allows operators to provide B2B customers with tools to engage visitors through a Venue URL. This feature displays information about the Wi-Fi service while also offering local promotions and deals. Additionally, R3 includes functionality for end-users to approve the Wi-Fi service’s terms, conditions, and charges.
However, we believe Passpoint R3 may have overextended its focus on user engagement features. Deploying these features via ANQP locally at access points complicates central management, particularly in multi-vendor deployments where support for different Passpoint versions varies. Given the challenges in management and the lack of widespread device support, there is a risk that R3 may never be widely adopted in carrier Wi-Fi networks.
Security in R3 has been further enhanced, with support for WPA3-Enterprise, compared to the WPA2-Enterprise support in R2 and R1. Additionally, R3 allows the use of the same SSID for both the Wi-Fi service (WPA2/WPA3) and the online sign-up (OSEN) functionality if the OSU feature from R2 were to be reintroduced.
Strategies for deploying Passpoint in the real world
The Passpoint certification is a moving target, and things may have changed by the time you read this. But, as of October 2024, iPhones does not support Passpoint release (R3). Android from version 12 and above support R3, but Android OEM vendors usually customize the Android platform to match their product requirements. So, just because it works with one vendor it doesn’t mean it works with another.
The Passpoint certification from Wi-Fi Alliance only certifies the radio protocols. In practice, new releases from R2 and above, which include more complex service-related features, cannot be guaranteed to work end-to-end in a Wi-Fi service. We have experienced this through the testing conducted by the Wireless Broadband Alliance (WBA).
Conversely, it is probably true that devices with R3 support that has not been Passpoint certified also exist, just as R1 is supported in iPhones without official certification. But as a service provider, you cannot rely on so many unknown parameters. On a more positive note, it is generally true that most smartphones, tablets, and laptops now support at least Passpoint R1. Therefore, operators should create and deploy Wi-Fi services based on R1, possibly with an extension for selective use of R3.
One thing is certain: Operators who wait for new standards to be fully deployed and for mobile device manufacturers to adopt them risk waiting for a very long time. It is not only the complexity of the technology that decides whether a handset manufacturer develops support for standards like Passpoint R2/R3 or not. Thus, the wait could go on forever. Fortunately, there is no reason to delay the introduction of carrier-grade Wi-Fi services.
In our upcoming blog post, A Pragmatic Approach to Passpoint, we will discuss how Passpoint R1, together with the new Captive Portal API, may well be the interim solution that, in the end, becomes the permanent pragmatic solution for Passpoint-enabled networks.
pragmatic approach to passpoint
Captive Portal API
The Internet Engineering Task Force (IETF) Captive Portal API (RFC 8908 and RFC 8910), introduced in September 2020, is a significant advancement.
The Captive Portal API not only enhances the user experience for traditional Captive Portal implementations but, when combined with Passpoint R1, has the potential to deliver much of the user experience intended for Passpoint R2 and R3.
The adoption of the Captive Portal API among handset manufacturers has been swift. Google was the first to integrate it with Android 11, and Apple quickly followed with support in iOS 14 and macOS Big Sur. With a growing number of supporting devices, widespread adoption across major operating systems seems imminent.
The Captive Portal API also offers service management platforms, such as the Enea Aptilo Service Management Platform (SMP), improved control over Captive Portal flows in traditional hotspots. This results in a more reliable service experience for users.
The Captive Portal API significantly enhances the overall user experience. Traditionally, Access Gateways intercepted user web requests and redirected them to a Captive Portal. With the Captive Portal API, this interception is no longer necessary. Instead, when users connect to the Wi-Fi network and receive an IP address via DHCP (or Router Advertisement in IPv6), the DHCP server provides the URL to the Captive Portal API. The device then queries the API to determine if it is in captive mode.
If the API indicates that the device is in captive mode, the device will launch the Captive Network Assistant (CNA) browser for login. If the API indicates that the device is not in captive mode, the device will proceed directly to the Internet.
A More Stable User Experience with User Engagement through Venue Portal
New standards take time to be fully integrated into every device, so some details of the Captive Portal API may still need to be implemented on certain devices. However, the standardized interaction defined by the Captive Portal API ensures consistent support for devices to determine their state and access auxiliary information, such as remaining session time or data usage. This allows devices to take proactive steps before reaching these limits, enabling users to extend their session in a controlled manner. As a result, the interaction between the device and the Wi-Fi service management system is smoother. Previously, with only device-based captive portal detection and system control, devices often remained unaware of post-authentication status, leading to sessions that could freeze once time or data limits were exceeded.
Another key advantage of the Captive Portal API is its capability to provide a Venue Info URL. This feature allows service providers to empower their B2B customers to engage users locally with targeted information and offers.
Currently, users receive a link to the Venue Info URL through an on-screen system message, which appears as a text alert during the session. This message remains on the lock screen or the network details page (device-dependent). The Venue Info URL is included in the message, and clicking the link directs users to the brand or location-specific portal.
The Venue Info URL is displayed when users connect either manually via an open SSID or automatically through a secure Passpoint-enabled network. It also enables anonymous Network Providers to present local information and customized advertising to users connecting through services like OpenRoaming.
Offering such a portal experience on a secure SSID represents a significant advancement, allowing venue owners to engage users effectively. This is crucial for establishing secure Wi-Fi as the standard rather than relying predominantly on open SSIDs with traditional captive portals.
A pragmatic approach
Building from Passpoint R1
The Captive Portal API’s compatibility with secure Passpoint-enabled networks (802.1x) and its similarity to the Venue URL concept in Passpoint R3 open up new possibilities. We believe that combining the Captive Portal API with Passpoint R1 can deliver much of the user experience intended for Passpoint R2 and R3. With Passpoint R2’s online sign-up (OSU) now removed, alternative methods for provisioning Passpoint profiles for ad-hoc users must be considered. Building specialized venue portal flows for the few devices that support an end-to-end Passpoint R3 service would be impractical. Instead, leveraging R1 support as a common denominator is a more sensible approach.
Devices not yet provisioned for Passpoint R1 through methods such as SIM profiles (EAP-SIM/AKA/AKA’) or apps (EAP-TLS/TTLS) need to be provisioned ad-hoc via a sign-up portal over an open SSID or through another connection in advance.
We propose a pragmatic approach to provisioning Passpoint R1 profiles for ad-hoc users:
- Profile Download and Installation: The user will download and install the Passpoint profile on their device at the captive portal. For Android devices, this typically involves a simple click on a link, while users of other devices, such as iPhones, may require device-specific instructions provided at the portal.
- Wi-Fi Reconnection: After installing the Passpoint profile, the Wi-Fi connection will be restarted. When the device reconnects, it will automatically log in to the secure SSID (802.1x) specified in the Passpoint profile.
- Terms and Conditions Approval: The Captive Portal API can then be used for the approval of terms and conditions for new users or existing users if an update is needed. Additionally, the Venue Info URL can be used optionally to display venue-specific information and promotions.
Critical mass of R2/R3 devices
Add Passpoint R2-R3 Later
Again, we recommend a pragmatic approach to Passpoint: begin with Passpoint R1 and add support for R3 when there is a critical mass of device support. If R2 online sign-up reappears in the standard, it can also be incorporated.
We have shifted the approval of terms and conditions (T&C) from the sign-up page to the initial connection on the Passpoint-enabled network. This allows the T&C process to be applied to R2/R3 devices as well as to the many devices that support only R1. Users who sign up at the site will experience a nearly seamless flow, as the connection can be terminated immediately after profile installation, allowing users to reconnect as pre-provisioned.
It remains to be seen whether the additional benefits of Passpoint R3’s terms and conditions and user engagement features will outweigh the advantages of using a uniform and established process for all devices (R1, R2, and R3), as indicated by the dotted line in the figure.
Hotspot 2.0 is a standard for seamless and secure connectivity to Wi-Fi hotspots. Hotspot 2.0 use 802.1x, offering an encrypted connection between the device and the Wi-Fi access point (AP). It uses IEEE 802.11u and the ANQP protocol to, without user interaction, communicate with the provider before it establishes a connection. Through this communication, the device gets valuable metadata for the network selection process, including the provider’s domain name, available EAP authentication methods, the IP addresses available at the Wi-Fi AP, and information about potential roaming partners accessible through the service.
Authentication and encryption are enabled by using WPA2 or WPA3-Enterprise together with one of several EAP methods.
The Wi-Fi Certified Passpoint® program was launched by Wi-Fi Alliance through partnerships between mobile device manufacturers and network equipment vendors. The purpose was to certify devices based on the Hotspot 2.0 specification. The industry is increasingly referring to Hotspot 2.0 by its certification name – Passpoint.
It depends on the individual behavior of different device brands, but generally speaking, the answer is yes.
Suppose it is the first time a user visits the location. The device will then automatically connect to the Passpoint-enabled Wi-Fi network if their Hotspot 2.0 service or a roaming partner is included in the device’s Passpoint profile.
This is also the case even if the user previously has been connected to an open Wi-Fi network (non-802.1x SSID) at the same location. When the device selects Wi-Fi network, it will always prioritize connection to a network with a higher security grade.
If the device has been connected to other secure Wi-Fi networks (802.1x) at the same location, it might prioritize this connection over the Hotspot 2.0 service. The behavior is very device dependent. It is affected by factors such as how frequently the device has been connected to the network and how often a user has forced the “forget” network option.
OpenRoaming is a Wi-Fi roaming initiative originally conceived and launched by Cisco but since taken over and today operated by the Wireless Broadband Alliance (WBA). In essence, OpenRoaming is a Passpoint-based roaming scheme bringing together ‘identity providers’ and ‘network providers’ into an OpenRoaming federation.
The beauty of OpenRoaming is that anyone maintaining secure user credentials can be an identity provider without having their own network. One excellent example would be users who log in with their Google account. OpenRoaming is also a catalyst for the mass deployment of Passpoint. Many handset manufacturers have already implemented a Passpoint OpenRoaming profile from the factory.