White Paper Excerpt

Staying in Control in the OpenRoaming Era

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.

All You Need To Know About OpenRoaming – White Paper

This is an excerpt from our white paper, All You Need To Know About OpenRoaming. The full white paper is available here if you like what you read. Don’t hesitate to contact us if you have any questions.

Download the full All you Need To Know About OpenRoaming White Paper

 

How to implement

Closed Access Group (CAG) Policies

There are two base Roaming Consortium Organization Identifiers (RCOIs) for OpenRoaming:

OpenRoaming-Settled: BA-A2-D0-xx-xx
OpenRoaming-Settlement-Free: 5A-03-BA -xx-xx

The OpenRoaming Passpoint RCOI is a 36-bit value where the first 24 bits are the base RCOI (settled or settlement-free), and the last 12-bit extension (xx-xx) is used to implement the Closed Access Group Policies (CAG).

The RCOIs are provisioned in the OpenRoaming Passpoint profile(s) in the device and advertised in the Wi-Fi Access Point beacon. If there are more RCOIs to be advertised than what fits in the beacon, a list of available RCOIs can be sent through the Passpoint Access Network Query Protocol (ANQP) messages.

Only IDPs and ANPs with fully matching RCOIs, including the CAG, will roam. One of the benefits of encoding policies in the RCOI is that they are applied before authentication. If there is a policy mismatch (RCOI not matching), there is no reason to send an authentication request that the ANP AAA will reject immediately. The device will thus not trigger any unnecessary authentication requests. This is important as device behaviors are not well defined and uniform across the industry, with some devices repeatedly re-attempting authentication after a rejection.

OpenRoaming RCOI

Extensive and Wide

Passpoint Device Support

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.

OpenRoaming CAG policies RCOI extension

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.

What CAG fields mean for an IDP and ANP

Currently, WBA has defined the following CAG policy fields:

CAG

What it is used for

Identity Providers (IDP)

Access Network Providers (ANP)

PID

States if users are anonymous
or have a permanent identity
(PID).

State if my users are anonymous or have permanent identities.

State if I accept anonymous users and/or users with permanent identities.

LoA

Level of Assurance (LoA) of the user identity.

State the level of proofing(s) that I have on my users’ identities.

State the level of proofing an IDP’s users’ identities must have to be accepted.

QoS

The quality of service (QoS) provided, i.e., latency and bandwidth for data and video.

State the QoS level(s) the ANP must support.

State the QoS levels(s) that
I support.

ID-Type

Identity provider type (IDP).

State my own provider type and normally “Any” to match with ANPs allowing any type of IDP.

State all IDP provider types I accept, including “Any” and/or several types.

Note that there is no implicit logic behind the RCOI extensions. It is just a matter of matching the exact RCOIs between the IDP and the ANP. As a result, IDPs and ANPs must advertise multiple RCOIs to cover all cases. This, even if it might feel superfluous to, e.g., explicitly say that you accept users with Permanent IDs if you want to allow anyone, including anonymous users, onto your network. It is vital for ANPs and IDPs to also include the tiered CAG policies that go above their minimum requirement and below what they provide.

It should be sufficient that ANPs and IDPs state what they provide and all tiers below and then only what they require. However, the OpenRoaming specification does not explicitly say that they must act this way, and there are no control mechanisms to ensure they do. So, we suggest you work according to the table below as ANP and IDP to be on the safe side.

CAG

Identity Providers (IDP)

Access Network Providers (ANP)

PID

State what they provide + all tiers below.

State what they require + all tiers above

LoA

State what they provide + all tiers below.

State what they require + all tiers above

QoS

State what they require + all tiers above.

State what they provide + all tiers below.

Diving into

CAG Policies Details

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 PID CAG poiliciesOpenRoaming 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:

OpenRoaming QoS CAG Policies

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.

 

Related insights

The c aptive portal is dead long live the casptive portal

The captive portal is dead long live the captive portal

Read more

Tags: Carrier Wi-Fi , CSP , OpenRoaming

OpenRoaming Overview happy users

OpenRoaming Overview

Read more

Tags: Carrier Wi-Fi , CSP , OpenRoaming

Why OpenRoaming

The Why? and What? of OpenRoaming

Read more

Tags: Carrier Wi-Fi , CSP , OpenRoaming

OpenRoaming – The Silver Bullet for Neutral Host Wi-Fi Offload

Read more

Tags: CSP , MNO , MVNO , OpenRoaming , Wi-Fi Offload

All You Need To Know About OpenRoaming

Read more

Tags: B2B Wi-Fi , Carrier Wi-Fi , CSP , OpenRoaming , Wi-Fi Offload