OpenRoaming, what’s in a name?

‘Open’ sounds good, but it implies roaming without control. Nothing could be more incorrect! Both an Identity Provider and an Access Network Provider can control the characteristics of a roaming partner by using the appropriate Roaming Consortium Organisation Identifier (RCOI) extension to implement Closed Access Group policies (CAG) across the federation. This is perhaps one of the most important but less known features of the OpenRoaming concept and is crucial for successful implementation of use cases such as neutral host Wi-Fi Offload.

We will continue to post chapters from the white paper, and here you can find all relevant OpenRoaming Insights to date.

Another benefit of using the RCOI for policy control is that it is not a new standard dependent on device support. Passpoint has been around since 2012, and all devices active today support this standard if they have installed a Passpoint profile such as the one for OpenRoaming.

The current Passpoint device support include

• iPhone 5 (or higher)
• Android 6.0 (or higher)
• iPad 3rd Generation (or higher)
• Mac OS7 (or higher)
• Mac Laptops: OSX Mavericks and
• OSX Yosemite (or higher)
• Windows 10 (or higher)

Settled or Settlement-free Service

The vast majority of the over three million hotspots currently (December 2023) participating in the OpenRoaming federation are settlement-free, meaning that ANPs should not expect to receive payment for providing Wi-Fi access to roaming users. In return, an ANP will get free roaming for their own subscribers when acting as IDP. Note that IDPs can still charge their users for OpenRoaming access by, for example, a one-time or yearly charge.

No multi-vendor protocol is currently defined for the WBA Wireless Roaming Intermediary eXchange (WRIX) data settlement and financial clearing. Consequently, individual roaming partners in a settled OpenRoaming service must base the roaming on a bilaterally agreed approach and protocol. However, the roaming partners for the settled service must still support the WRIX-d/f protocol. OpenRoaming uses the application service/protocol
tag to indicate that the queried IDP supports financial settlement.

RCOI Extensions for Closed Access Group Policies

Let’s now move into the more advanced use cases of OpenRoaming using the last 12-bit extension in the OpenRoaming RCOIs to encode the Closed Access Group (CAG) policies. The aim is to deliver an equivalent functionality to the CAG policies encoded in 3GPP using one or more CAGIDs. We have a chapter in the white paper called OpenRoaming for Techies  which go into detail how they are encoded. Here, we will focus on how you can use them.

There is a limit to how many policies you can encode in 12 bits. But more policies may come to the OpenRoaming standard; WBA has reserved the last 4 bits for future use.

User Identity

Identity handling is essential, especially for a global federation such as OpenRoaming. In some countries, it is a legal requirement to know the identity of the users.

OpenRoaming uses the identity policy (PID) field to determine if the IDP has agreed to return a Permanent ID to the ANP in the Access-Response. If the ANP has set the PID field to Permanent ID, they must, in a RADIUS attribute, return the user’s identity as a mobile number or an email address. The baseline PID value is anonymous.

An ANP that, for legal reasons or otherwise, only wants to accept users with a Permanent ID must strictly advertise only RCOIs with the PID set to Permanent ID.

Conversely, as discussed, regarding the exact matching of RCOIs, an ANP that accepts anonymous users still needs to advertise two RCOIs: one that includes the baseline PID, which is to accept anonymous users, and one for accepting users with Permanent ID.

Moreover, an IDP that agrees to provide a permanent ID for their users should also advertise two RCOIs: one for Permanent ID and one for anonymous. Otherwise, users will not get access to ANP networks that are only advertising the baseline Permanent ID policy.

Level of Assurance of User Identity

WBA introduced the Level of Assurance (LoA) field in the OpenRoaming version 4.0 specification (June 2023).

As discussed, the user identity (PID) field enables ANPs to require a permanent identity from the IDP in the form of an email address or phone number for all roaming users.

However, there is no visibility of how the IDP verified the identity. Was the user enrolled with a form submission so the user could type anything in the email or mobile number field? Or was it verified adequately through an email/SMS loop or via the SIM identity?

The LoA field answer this question by following the end-user enrollment, credential management, and authentication principles specified for LoA in ISO/IEC 29115.

The OpenRoaming baseline identity proofing requirement on IDPs ensures that all permanent identities (PID) are managed with at least a medium level of assurance corresponding to ISO LoA level 2. The enhanced identity proofing corresponds to ISO LoA level 3.

The OpenRoaming specification does not currently give any examples of identity proofing according to ISO LoA 2 and 3. However, we argue that verification through an email/SMS loop will satisfy the baseline identity proofing (ISO LoA level 2).

A SIM identity coupled with a person verified by showing an identity card at the store or with equally strong proofing online would satisfy the enhanced identity proofing (ISO LoA level 3).

The baseline or enhanced identity proofing is used in the RCOI for the IDP (providing) and the ANP (requiring) in the same way as described in the PID diagram.

Please note that having a user entering a phone number or email in a web form without proofing the identity, would have no proofing value. Anyone can enter anyone’s details in such a form. In this case, you should set the PID to anonymous and the LoA field to to the lowest, even if it is nowhere near LoA level 2.

Controlling the Quality of Service (QoS)

The ANP’s Wi-Fi and network Quality of Service (QoS) is advertised using the QoS field in three levels: Baseline, Silver, and Gold.

OpenRoaming defines four Key Performance Indicators (KPI) for QoS:

Availability – The availability of the service, when used for accessing the Internet, measured over any one-month period.

Bandwidth – The aggregated bandwidth to receive Internet service must be sufficient to enable each and every end user to receive a certain sustained speed in Kbit/s.

Video – Users must be able to stream video content at a certain downlink rate in Mbit/s, measured over a one-minute interval.

Latency – Users must be able to stream video from one or more third-party content distribution networks with an end-to-end latency of less than a certain amount in milli seconds.

ANPs can advertise (provide), and IDPs include in their OpenRoaming Passpoint profiles (require) RCOIs with any or all of the following QoS field settings:

Only those ANPs that support a service level are permitted to broadcast the OpenRoaming RCOI with the corresponding value in the QoS field.

Access network providers that operate an OpenRoaming service on moving platforms, such as buses and trains, are not required to meet the baseline criteria. Instead, they must signal their capabilities in another way: signal one or more service availability/bandwidth tuples that the installation supports.

ANPs should currently (November 2023) not use the Gold QoS level as it is not yet defined. However, an IDP could set it to prepare for the future.

Again, ANPs should advertise the highest QoS level they provide as well as all the tiers below. The IDPs should use RCOIs with the lowest QoS level they accept and all tiers above.

Controlling type of Identity Provider

OpenRoaming uses the ID-type field to realize closed access group policies based on the identity type used by the IDP. WBA has currently defined the following identity types:

• Any identity type is permitted
• A service provider identity
• A cloud provider identity
• A generic enterprise identity
• A government identity (including city)
• An automotive identity
• A hospitality identity
• An aviation industry identity
• An education or research identity
• A cable industry identity
• A manufacturer identity
• A retail identity

IDPs should set their own ID-type and the “any permitted” to match with ANPs allowing any identity providers. The ANPs should set the ID-Types they permit; the most common setting is “Any identity type is permitted.”

But there can be use cases also for other settings. If an ANP only wants to accept IDPs of specific ID-Types, they can specify the ID types they wish to permit instead of using the “any permitted” setting. If an ANP wants to identify certain ID-Types for some special handling in the network but still wants to permit any provider, they can specify those while also using the “any permitted” setting. In this case, the “any permitted” RCOI should be last in the list of RCOIs.

Choosing What IDP To Prioritize

A device may have multiple OpenRoaming IDP Passpoint profiles matching the ANP’s RCOI-based closed access group policy.

The ANP can utilize the Home Service Provider preference functionality defined in Passpoint, where the device will prioritize using particular profiles. In such a scenario, the ANP shall configure the Domain Name list to include the fully qualified domain name(s) (FQDN) associated with the profile(s) to be prioritized.

One example could be an ANP desiring to prioritize a partner service provider (IDP) over, for instance, the device manufacturer.

Learn more about this in the The Silver Bullet for Neutral Host Wi-Fi Offload post.

When no explicit prioritization is made by the ANP, we have seen in tests that many devices seem to prioritize SIM-based EAP methods over other EAP methods.

Even Tighter Control

The preferred approach for realizing authorization policies is to use the Closed Access Group (CAG) policies. However, alternative methods, Deny and Allow lists, are available in the OpenRoaming specifications to gain even more granular control over who is roaming with whom.

You should use these alternative methods with precaution as they may defeat the purpose of OpenRoaming. Let’s take an extreme usage of these methods as an example. If they so wish, two service providers acting as ANPs can decide to only roam with each other. At the same time, they could, when working as IDPs, let their users roam freely in the OpenRoaming federation. Another example is an IDP hindering its users from roaming into a specific ANP.

The members of the OpenRoaming federation would generally not appreciate such behaviors. You should only use the deny and allow listing in extraordinary circumstances, e.g., for testing or avoiding head-to-head competing organizations. Below, we will discuss how OpenRoaming has implemented the allow and deny lists.

NAI Realm Based Allow List

Suppose an ANP does not want to authorize all users associated with a CAG-based RCOI. In that case, the ANP may avoid broadcasting that RCOI and instead use an “allow list” of permitted roaming partners based on their Network Access Identifier (NAI) realms. The standard syntax for NAI is “user@realm,” for instance, [email protected], where example.com is the NAI realm.

The NAI realm is often the same as the company’s domain name, with one exemption. Mobile operators all have NAI realms ending with 3gppnetwork.org. Since those realms are not publicly resolvable for security reasons, there must be some special handling of those. More about this in the OpenRoaming for Techies chapter in our white paper.

WBAID Based Deny List

An IDP can forbid roaming with certain ANPs by implementing a “deny list” based on the WBAID. The IDP must share this list of prohibited WBAIDs with the WBA. One example could be that the hamburger chain A doesn’t want its users to roam into hamburger chain B’s Wi-Fi network.