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.
A critical component is the capability of Passpoint services to deliver Wi-Fi offload services based on credentials stored in the subscriber’s SIM. This means mobile operators can integrate Carrier Wi-Fi services into their total service offering.
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.
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. However, due to the limited device support for the latest Passpoint releases (R2, R3), some of our customers have developed a simple tablet/smartphone app that automatically provisions EAP-TTLS certificates in non-SIM devices.
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)
The first release was introduced in 2012, and all the protocols and standards mentioned above, including 802.11u and ANQP, were included with the ability for the device to discover Passpoint-enabled networks and automatically connect to the optimal one.
More or less, all mobile phones and laptops support Passpoint R1. This includes Apple iPhones, although Apple has never formally certified them.
Challenges remain in the onboarding of new devices. Users need to provision Passpoint R1 credentials manually by downloading a particular file that contains profile and credential information. Mobile operators can push such Passpoint profiles to the devices over the air (OTA). Other service providers can use an app to make this process seamless for the user. There are SDKs available to integrate this function with their existing apps.
Passpoint Release 2 (R2) – Removed by Wi-Fi Alliance
In 2023, Wi-Fi Alliance removed this version from the standard as the industry couldn’t get Apple to support it. The main feature was the online sign-up (OSU) described below to provision Passpoint profiles, and this function may return in a simplified version at a later stage. Meanwhile, Passpoint profiles can, as discussed, be provisioned over the air through an app or via a third option using our pragmatic approach to Passpoint with provisioning through a portal.
The Passpoint R2 was released in 2014 and included the now-removed Online Sign-Up (OSU) server, which would allow new users to create an account and, in a user-friendly way, provision Passpoint credentials at the point of access. This would enable easy ad-hoc sign-up of new users, where they could select the service provider if several options existed.
Passpoint R2 required a separate SSID for Online Sign-Up, either an open SSID or an OSEN (OSU Server-only Authenticated L2 Encryption Network).
Passpoint Release 3 (R3)
The Passpoint R3 was released in 2019 but has not yet been certified by major handset manufacturers (as of December 2023). This version includes several new ANQP protocol elements and improved interaction between operators and end-users. While previous versions have focused entirely on automatic connection and onboarding of the users, Passpoint R3 aims to enhance captive portal functions by leveraging ANQP messaging.
For the first time, Passpoint allows operators to offer B2B customers a tool to engage with visitors. They can do this through a Venue URL, which displays information about the Wi-Fi service and, at the same time, provides offers and local promotions. The R3 version also includes features for end-users to approve terms and conditions and charges for the Wi-Fi service.
We think Passpoint R3 may have attempted to push the user engagement features too far. Deploying these features through ANQP locally in the access points will make it harder to maintain central control, especially in a multi-vendor deployment scenario with various support for the different Passpoint versions. Because of the challenges in management and lack of device support, there is a risk that R3 will never be implemented in carrier Wi-Fi networks.
Security is further improved in R3 with support up to WPA3-Enterprise, whereas R2 and R1 only support up to WPA2-Enterprise. It is also possible to use the identical SSID for both the actual Wi-Fi service (WPA2/WPA3) and the online sign-up (OSEN) functionality if the R2 OSU would re-emerge.
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 December 2023, only niche handset brands have been certified for the latest Passpoint release (R3), and R2 has, as discussed above, been removed from the standard (at least for now). In addition, smartphone vendors usually customize the Android platform to match their product requirements. So, just because it is certified for one Android vendor, it doesn’t mean it works with another.
Furthermore, 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 have not been Passpoint certified also exist, just as R1 is supported in iPhones without official certification. But you cannot rely on so many unknown parameters as a service provider.
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 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.
Under the Pragmatic Approach to Passpoint tab, 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 for devices that need to be provisioned ad-hoc and not over-the-air or through an app.
pragmatic approach to passpoint
Captive Portal API
The Internet Engineering Task Force (IETF) Captive Portal API (RFC8908 and RFC8910), introduced in September 2020, is a game-changer.
The Captive Portal API does not only improve the user experience in connection with traditional Captive Portal implementations. We believe that the Captive Portal API – in combination with Passpoint R1 – has the potential to deliver much of the user experience that Passpoint R2 and R3 were designed to accomplish.
The adoption of Captive Portal API among handset manufacturers has also been fast. Google was first to support the Captive Portal API for Android 11, and Apple soon followed with support in iOS14 and macOS Big Sur. With a critical mass of supporting devices, adoption across all the major operating systems appears imminent.
The Captive Portal API gives service management platforms, such as the Enea Aptilo Service Management Platform (SMP), greater control of the Captive Portal flows for traditional hotspots. As a result, users will experience a more reliable service than ever before.
The overall user experience will also benefit hugely from the Captive Portal API. We have traditionally designed Access Gateways to intercept the user web request and redirect it to a Captive Portal. With the Captive Portal API, the gateway does not need to intercept such requests. Instead, when users join the Wi-Fi network and receive an IP address via DHCP (or Router Advertisement in IPv6), the DHCP server also provides the URL to the Captive Portal API. This will trigger the device to query the API to determine whether it is in captive mode.
If the API states the device is in captive mode, the device will open the Captive Network Assistant (CNA) browser to log in. And, if the API says 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
It takes time for new standards to be natively implemented in every device, so there might be some details in the Captive Portal API that still needs to be implemented for some devices. However, the standardized interaction between the device and the captive portal, as defined in the Captive Portal API, is always there to help devices determine their state and auxiliary information, such as the remaining session time or data. This allows the device to take action before it reaches the time or data limits, allowing the user to extend the session in a controlled way. This provides a smoother interaction between the device and the Wi-Fi service management system. Previously, with the guesswork of device-only captive portal detection and system-only control, the device was unaware of what was happening after authentication. This could cause sessions that appear to freeze after the session time or data has run out.
Another benefit of the Captive Portal API is that it can also provide a Venue Info URL. This excellent feature allows service providers to empower their B2B customers to engage with users locally with information and offers.
In current implementations, the user receives the link to the Venue Info URL via an on-screen system message appearing as a text alert available during the session. The message remains on their lock screen and in their message history. This makes it easy to go back to the Venue Info URL, as the message history is typically just a swipe away.
The Venue Info URL will appear when the user connects manually by selecting an open SSID or automatically through a secure Passpoint-enabled network. It will also offer otherwise anonymous Network Providers a way to show local information and customized advertising to users that connect through, for instance, OpenRoaming or Orion WiFi.
To offer the user a portal experience like this on a secure SSID is something new to ensure venue owners can engage with users. This is crucial for making secure Wi-Fi the norm rather than the prevalent open SSID.
A pragmatic approach
Building from Passpoint R1
The fact that the Captive Portal API also works on secure Passpoint-enabled networks (802.1x) and that the concept of the Venue Info URL has many similarities with the Venue URL specified in Passpoint R3, opens up new possibilities.
We believe that the Captive Portal API, in combination with Passpoint R1, can deliver much of the user experience that Passpoint R2 and R3 were designed to accomplish. It would make no sense to build special signup flows for the few devices that support an end-to-end Wi-Fi service based on Passpoint R2/R3. Why not use the R1 support as the least common denominator?
Devices that have not yet been provisioned for Passpoint R1 by other means, such as through a SIM profile (EAP-SIM/AKA) or App (EAP-TLS/TTLS), have to be provisioned ad-hoc through a sign-up portal over an open SSID or in advance via another connection.
The user will then download and install the Passpoint profile on their device. For Android phones, it is as easy as a click on a link, whereas users of other devices, such as iPhones, may need support from device-specific instructions at the portal. Once the Passpoint profile is installed, we will restart the Wi-Fi connection. When the device re-connects, it will automatically be logged in to the secure SSID (802.1x) stated in the Passpoint profile. The Captive Portal API can then be used for approval of terms and conditions for new users or existing users if there is a need for an update. The Venue Info URL can also optionally be used to display venue-specific information and promotions.
Critical mass of R2/R3 devices
Add Passpoint R2-R3 Later
We suggest a pragmatic approach to Passpoint. Start with Passpoint R1, and then add support for R3 when there is a critical mass of device support. If R2 online sign-up OSU re-appears in the standard, this support can be added as well. But, meanwhile there is an alternative to provision Passpoint profiles online, our pragmatic approach to profile onboarding for R1 devices can be used also for R3 devices (and devices with legacy R2 support of course). For users that do not need Passpoint profile provisioning ad-hoc, other methods can be used such as mobile operators pushing the profiles over the air or using an app SDK so service providers can use their consumer ”my pages” apps for provisioning Passpoint profiles.
Fill d
Note that we have moved the approval of terms and conditions (T&C) from the sign-up page to the first connection on the Passpoint-enabled network. This means that the T&C process can also be used for R2/R3 devices as well as the large volume of devices that only support R1. Users who sign-up at the site will see this as almost one flow since the connection can be terminated right after a user has installed the profile. A user will then immediately return as pre-provisioned.
It remains to be seen if the benefits of Passpoint R3 terms and conditions and user engagement features will be significant or if it would be more beneficial to use the same processes as with Passpoint R1 capable devices (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.