Passpoint – Hotspot 2.0

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 promise of Passpoint® (previously known as Hotspot 2.0), as defined by the Wi-Fi Alliance.

Passpoint enables compatible devices to automatically and silently discover Wi-Fi access points and then automatically and securely connect to the secure Wi-Fi network.

Introduced in 2012, but it is not until recently that the technology has reached a wider adoption stage than some service provider deployments in the USA.

Passpoint shines in the roaming use case. The WBA OpenRoaming initiative, which already has millions of hotspots globally, 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.

While Passpoint is a prerequisite for OpenRoaming, it is not for Wi-Fi offloading. Since 2011, Enea (Aptilo) have provided seamless and secure Wi-Fi offloading solutions utilizing SIM authentication. It should also be noted that EAP based authentication (SIM/AKA/AKA′ and TLS/TTLS) is not equivalent to Passpoint as such, which is a common misunderstanding.

To summarize, Passpoint offers the following key features and benefits:

• Automatic network discovery and selection.
• Forcing seamless Wi-Fi authentication and connection.
• Enhanced security through WPA2 or WPA3-Enterprise.
• Support for various EAP authentication methods (EAP-SIM/AKA/AKA’, EAP-TLS/TTLS).
• Roaming capabilities across different service providers.

1. The 802.11u-capable Wi-Fi Access Point (AP) advertises Passpoint support in the beacon.
2. The device probes with Passpoint support.
3. 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.
4. The Wi-Fi AP responds to the ANQP query with the requested information.
5. 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.

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).

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.

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.

It’s important to note that smartphone vendors typically customize the Android platform to meet their specific product requirements. Therefore, certification for one Android vendor does not guarantee compatibility with another. Furthermore, the Passpoint certification from the 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 seamlessly in a Wi-Fi service. Conversely, it’s likely that some devices support R3 without being Passpoint certified, just as iOS, MacOS and Windows support R1 without official certification. However, service providers cannot rely on such unknown variables.

On a more positive note, most smartphones, tablets, and laptops now support at least Passpoint R1. Therefore, operators should design and deploy Wi-Fi services based on R1, possibly with 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 indefinitely. The decision to support standards like 3GPP or Passpoint
R2/R3 is influenced by device manufacturers’ priorities and may also depend on whether implementing these standards aligns with their best interests. The more operators that utilize these standards, the more likely it is that device manufacturers will support them.

Fortunately, there is no reason to delay introducing Passpoint-based carrier-grade Wi-Fi services.

Below, we will explore how Passpoint R1, in conjunction with the new Captive Portal API, might serve as an interim solution that could potentially become the permanent, pragmatic approach for Passpoint-enabled networks. This is particularly relevant for devices that need to be provisioned ad-hoc and cannot utilize the best practices of over-the-air provisioning or app-based provisioning.

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.

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.

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:

1. 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.
2. 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.
3. 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.

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.