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:
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.
The Moowifi 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).
Passpoint exists in three sequential releases.
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.
Challenges still 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. Many service providers use an app to make this process seamless for the user. More or less, all mobile phones and laptops support Passpoint R1. This includes Apple iPhones, although Apple has never formally certified them.
Update 2023: Wi-Fi Alliance has removed this version from the standard as the industry couldn’t get Apple to support it. The OSU described below may return in a simplified version at a later stage. Meanwhile Passpoint profiles can be provisioned by mobile operators over-the-air (OTA), through an app or using our pragmatic approach to passpoint which is based on Passpoint R1.
This version, released in 2014, included the Online Sign-Up (OSU) server allowing new users to create an account and, in a user-friendly way, provision Passpoint credentials at the point of access. This enables easy ad-hoc sign-up of new users, where they can select the service provider of choice if several options exist. The client validates the OSU server certificate to ensure that the server is trusted. SOAP-XML or OMA-DM messages over HTTPS are then used for secure communications between the client and the provisioning servers.
Passpoint R2 requires a separate SSID for Online Sign-Up, either an open SSID or a so-called OSEN (OSU Server-only Authenticated L2 Encryption Network). This version also includes enhanced policy control for service providers. Device support is still limited.
The Passpoint R3 was released in 2019, but has not yet been certified by any major handset manufacturers (as of September 2022). This version includes several new ANQP protocol elements and improvements in the 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.
Passpoint R3 also makes roaming much quicker and easier as the client can indicate its membership of a roaming consortium to a Wi-Fi access point.
Security is further improved in R3 with support up WPA3-Enterprise, whereas R2 and R1 only support up to WPA2-Enterprise. It is also possible to use the same SSID for both the actual Wi-Fi service (WPA2/WPA3) and the online sign-up (OSEN) functionality.
The Passpoint certification is a moving target, and things may have changed by the time you read this. But, as of September 2022, only niche handset brands have been certified for the latest Passpoint release (R3). Some Android-based phones are R2 certified, but many are old and not in the market anymore. In addition, smartphone vendors usually customize the Android platform to match their product requirements. So, just because it works with one vendor 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 R2 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 R2.
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.
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.
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 Moowifi 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.
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.
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.
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.
We suggest a pragmatic approach to Passpoint. Start with Passpoint R1, and then add support for R2 and R3 when there is a critical mass device support. Utilize the Captive Portal API to fill the gaps in functionality.
Note that we have moved the approval of terms and conditions from the sign-up page to the first connection on the Passpoint-enabled network. This means that the process can also be used for already provisioned devices and devices with Passpoint R2 support, as well as the large volume of devices that only support R1. Users of Passpoint R1 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.
Online signup through the R2 online signup server (OSU) has many benefits to users once there is sufficient device support.
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/R2 capable devices (dotted line in the figure).