WBA OpenRoaming Wireless Federation
draft-tomas-openroaming-08
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Bruno Tomas , Mark Grayson , Necati Canpolat , Elizabeth A Cockrell , Sri Gundavelli , Seb Adamski | ||
| Last updated | 2026-06-12 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-tomas-openroaming-08
Independent Submission B. Tomas
Internet-Draft Wireless Broadband Alliance, Inc.
Intended status: Informational M. Grayson
Expires: 14 December 2026 Cisco Systems
N. Canpolat
Intel Corporation
B. A. Cockrell
Independent
S. Gundavelli
Cisco Systems
S. Adamski
IronWiFi
12 June 2026
WBA OpenRoaming Wireless Federation
draft-tomas-openroaming-08
Abstract
This document describes the Wireless Broadband Alliance's OpenRoaming
system. The OpenRoaming architecture enables a seamless onboarding
experience for devices connecting to access networks that are part of
the federation of access networks and identity providers. The
primary objective of this document is to describe the protocols that
form the foundation for this architecture, enabling providers to
correctly configure their equipment to support interoperable
OpenRoaming signalling exchanges. In addition, the topic of
OpenRoaming has been raised in different IETF working groups, and
therefore a secondary objective is to assist those discussions by
describing the federation organization and framework.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 14 December 2026.
Tomas, et al. Expires 14 December 2026 [Page 1]
Internet-Draft WBA OpenRoaming June 2026
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Wireless Broadband Alliance . . . . . . . . . . . . . . . . . 7
3. OpenRoaming Architecture . . . . . . . . . . . . . . . . . . 8
4. Identifying OpenRoaming Entities . . . . . . . . . . . . . . 11
5. Scaling Secured Signalling . . . . . . . . . . . . . . . . . 12
6. IDP Discovery . . . . . . . . . . . . . . . . . . . . . . . . 14
6.1. Dynamic Discovery . . . . . . . . . . . . . . . . . . . . 14
6.2. Discovery of EAP-AKA/AKA' Servers . . . . . . . . . . . . 14
6.3. Proving a Discovered RadSec Server is Authoritative for a
Realm . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.4. Co-existence with Other Federations . . . . . . . . . . . 16
7. Connection Management for Dynamically Discovered RadSec
Peers . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.1. ANPs not supporting reverse CoA . . . . . . . . . . . . . 16
7.2. ANPs supporting reverse CoA . . . . . . . . . . . . . . . 17
7.3. Load Balancing RadSec Connections . . . . . . . . . . . . 18
7.4. Connection Management for IDP RadSec Servers . . . . . . 18
8. OpenRoaming Passpoint Profile . . . . . . . . . . . . . . . . 18
8.1. OpenRoaming Policy Controls . . . . . . . . . . . . . . . 18
8.2. OpenRoaming Closed Access Group Policies . . . . . . . . 19
8.2.1. Level of Assurance Policies . . . . . . . . . . . . . 20
8.2.2. Quality of Service Policies . . . . . . . . . . . . . 20
8.2.3. Privacy Policies . . . . . . . . . . . . . . . . . . 24
8.2.4. ID-Type Policies . . . . . . . . . . . . . . . . . . 25
8.2.5. On-boarding Credential Policies . . . . . . . . . . . 26
8.3. Prioritizing Policies . . . . . . . . . . . . . . . . . . 27
9. OpenRoaming RADIUS Profile . . . . . . . . . . . . . . . . . 28
9.1. Operator-Name . . . . . . . . . . . . . . . . . . . . . . 28
9.2. Chargeable-User-Identity . . . . . . . . . . . . . . . . 28
9.3. Location-Data/Location-Information . . . . . . . . . . . 29
9.4. Session-Timeout . . . . . . . . . . . . . . . . . . . . . 29
9.5. Acct-Session-Id . . . . . . . . . . . . . . . . . . . . . 29
9.6. Acct-Multi-Session-Id . . . . . . . . . . . . . . . . . . 30
Tomas, et al. Expires 14 December 2026 [Page 2]
Internet-Draft WBA OpenRoaming June 2026
9.7. Event-Timestamp . . . . . . . . . . . . . . . . . . . . . 30
9.8. Connect-Info . . . . . . . . . . . . . . . . . . . . . . 30
9.9. Enhanced Reply-Message . . . . . . . . . . . . . . . . . 31
9.10. WBA-Identity-Provider . . . . . . . . . . . . . . . . . . 33
9.11. WBA-Offered-Service . . . . . . . . . . . . . . . . . . . 33
9.12. WLAN-Venue-Info . . . . . . . . . . . . . . . . . . . . . 33
9.13. WBA-Custom-SLA . . . . . . . . . . . . . . . . . . . . . 33
9.14. Filter-Id . . . . . . . . . . . . . . . . . . . . . . . . 33
9.15. Operator-NAS-Identifier . . . . . . . . . . . . . . . . . 34
9.16. Reverse Change of Authorization . . . . . . . . . . . . . 34
9.17. Additional Attributes Related to OpenRoaming Settled . . 35
9.17.1. WBA-Financial-Clearing-Provider . . . . . . . . . . 35
9.17.2. WBA-Data-Clearing-Provider . . . . . . . . . . . . . 36
9.17.3. WBA-Linear-Volume-Rate . . . . . . . . . . . . . . . 36
9.17.4. OpenRoaming Session Mediation . . . . . . . . . . . 36
10. Security Considerations . . . . . . . . . . . . . . . . . . . 36
10.1. Network Selection and Triggering Authentication . . . . 36
10.2. ANP RadSec Connectivity . . . . . . . . . . . . . . . . 37
10.3. Dynamic Discovery of RadSec Peers . . . . . . . . . . . 37
10.4. End-User Traffic . . . . . . . . . . . . . . . . . . . . 38
10.5. ANP Inspection of End-User Traffic . . . . . . . . . . . 38
10.6. End-User Location . . . . . . . . . . . . . . . . . . . 38
11. Future Enhancements . . . . . . . . . . . . . . . . . . . . . 39
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 39
13.1. Normative References . . . . . . . . . . . . . . . . . . 39
13.2. Informative References . . . . . . . . . . . . . . . . . 39
Appendix A. Example OpenRoaming Signalling Flow . . . . . . . . 44
Appendix B. Example OpenRoaming RCOI Usage . . . . . . . . . . . 47
B.1. OpenRoaming RCOI Based Policy for Supporting QoS Tiers . 47
B.2. OpenRoaming RCOI Based Policy for Supporting Identity Type
Policies . . . . . . . . . . . . . . . . . . . . . . . . 48
B.3. OpenRoaming RCOI Based Policy for Supporting Different
Identity Proofing Policies . . . . . . . . . . . . . . . 50
Appendix C. OpenRoaming Legal Framework . . . . . . . . . . . . 52
C.1. Seamless Experience . . . . . . . . . . . . . . . . . . . 52
C.2. OpenRoaming Organization . . . . . . . . . . . . . . . . 52
C.3. OpenRoaming Legal Terms . . . . . . . . . . . . . . . . . 53
C.4. ANP Performance Data . . . . . . . . . . . . . . . . . . 54
C.5. Service Abuse . . . . . . . . . . . . . . . . . . . . . . 54
C.6. OpenRoaming Troubleshooting . . . . . . . . . . . . . . . 54
C.6.1. Issue Response . . . . . . . . . . . . . . . . . . . 55
C.6.2. Issue Escalation . . . . . . . . . . . . . . . . . . 55
C.7. Breach of Contract . . . . . . . . . . . . . . . . . . . 56
Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 57
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 57
Tomas, et al. Expires 14 December 2026 [Page 3]
Internet-Draft WBA OpenRoaming June 2026
1. Introduction
WBA OpenRoaming is a roaming federation service of Access Network
Providers (ANPs) and Identity Providers (IDPs), enabling an automatic
and secure Wi-Fi experience globally. WBA OpenRoaming creates the
framework to seamlessly connect billions of users and things to
millions of Wi-Fi networks.
ANP-1 --\ _----_ /-- IDP-1
\ Access _( Open )_ Identity /
ANP-2 ---<== Network ---( Roaming )--- Providers <==-- IDP-2
/ Providers (_ _) \
ANP-3 --/ '----' \-- IDP-3
Figure 1: OpenRoaming Federation
WBA OpenRoaming recognizes the benefits that the likes of eduroam
[RFC7593] provides to the education and research community. WBA
OpenRoaming defines a global federation that is targeted at serving
all communities, while supporting both settlement-free use cases
where "free" Wi-Fi is being offered to end-users in order to support
some alternative value proposition, as well as traditional settled
"paid" for Wi-Fi offered by some cellular providers.
OpenRoaming is designed to deliver end-to-end security between a
Network Access Server (NAS) deployed by an OpenRoaming Access Network
Provider and an EAP Server [RFC3748] deployed by an OpenRoaming
Identity Provider. The security of the solution is based on mTLS
using certificates issued under Wireless Broadband Alliance's Public
Key Infrastructure [RFC5280].
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
1.2. Terminology
Access Network Query Protocol (ANQP):
An IEEE 802.11 defined protocol that allows for access network
information retrieval in a pre-association state. ANQP has been
further extended by the Wi-Fi Alliance (WFA) as part of its
Passpoint program [PASSPOINT].
Tomas, et al. Expires 14 December 2026 [Page 4]
Internet-Draft WBA OpenRoaming June 2026
Access Network Provider (ANP):
An entity that has joined the federation and serves OpenRoaming
end-users by configuring the OpenRoaming RCOI(s) on its Wi-Fi
equipment. Entities do not have to join the WBA in order to
oeprate as an OpenRoaming ANP.
Broker:
An entity that is a WBA member which has joined the federation and
performs certain specific roles to help scale the operation of the
federation. The separate roles of a broker can include:
1. Assigning WBA identities (WBAIDs) to ANPs and IDPs.
2. Operating an issuing intermediate certification authority
under the WBA's PKI and issuing certificates to ANPs and
IDPs.
3. Operating a registration authority to a third party
operated issuing intermediate certification authority under
WBA's PKI to enable certificates to be issued to ANPs, hub-
providers and IDPs.
Closed Access Group (CAG):
The definition of the 12 most significant bits of an OUI-36 RCOI
to indicate OpenRoaming policy controls that can be enforced by
ANPs and IDPs.
Identity Provider (IDP):
An entity that has joined the federation and includes the
OpenRoaming RCOI(s) in the Passpoint profile of its end-user
devices and authenticates end-user devices on OpenRoaming ANP
networks. Entities do not have to join the WBA in order to
oeprate as an OpenRoaming IDP.
Level of Assurance (LoA):
An ISO/IEC 29115 term [ISO29115] that is used to define equivalent
levels for handling of end-user enrollment, credential management
and authentication amongst different IDPs.
OpenRoaming-Settled:
Tomas, et al. Expires 14 December 2026 [Page 5]
Internet-Draft WBA OpenRoaming June 2026
The "base RCOI" of BA-A2-D0 that is used to indicate that the ANP
expects to receive payment for providing OpenRoaming service to
end-users.
OpenRoaming-Settlement-Free:
The "base RCOI" of 5A-03-BA that is used to indicate that the ANP
provides the OpenRoaming service to end-users at no cost to the
IDP.
Passpoint Profile:
Passpoint is a Wi-Fi Alliance (WFA) certification program that
defines the use a Passpoint profile, that includes the user's
credentials and the access network identifiers, that enables Wi-Fi
devices to automatically discover and authenticate to Wi-Fi
hotspots that provide Internet access [PASSPOINT].
PLMN Id:
A unique identifier for a mobile network (cellular) operator. The
identifier consists of a MCC (Mobile Country Code) and a MNC
(Mobile Network Code). ITU-T Recommendation [E212] defines both
MCC and MNC. The ITU allocates MCC values to national regulators
who are then responsible for allocating MNC values to individual
mobile network operators. [PASSPOINT] defines how the PLMN Id can
be sent in ANQP messages.
Roaming Consortium Identifier (RCOI):
An RCOI identifies the groups of identity providers that are
supported by the network. It is a 3-octet, or a 5-octet value
carried in the 802.11 beacon information element (IE). It is also
sent in the ANQP messages. Based on the access technologies, the
specific link-layer protocols will be used for carrying the RCOI.
RCOI is also part of the Passpoint profile.
NOTE: OpenRoaming only uses 5-octet RCOIs.
Subscriber Identity Module (SIM):
The SIM is traditionally a smart card distributed by a mobile
operator.
WBA Identity (WBAID):
A hierarchical namespace that is used to uniquely identify every
OpenRoaming entity (ANP, IDP, broker or hub-provider).
Tomas, et al. Expires 14 December 2026 [Page 6]
Internet-Draft WBA OpenRoaming June 2026
Wireless Roaming Intermediary eXchange (WRIX):
A framework, aimed at facilitating interconnectivity between
operators and the Wi-Fi roaming hub services.
2. Wireless Broadband Alliance
The Wireless Broadband Alliance (WBA) defines the Wireless Roaming
Intermediary eXchange (WRIX) framework, aimed at facilitating
interconnectivity between Wi-Fi operators and the Wi-Fi roaming hub
services, as well as the Carrier Wi-Fi Services program that provides
guidelines to improve customer experience on Carrier Wi-Fi networks.
Both of these programs leverage the Wi-Fi Alliance specified
Passpoint functionality [PASSPOINT] to enable automatic and secure
connectivity to Wi-Fi networks, allowing devices to be provisioned
with network access credentials with minimal user interaction.
WBA programs have traditionally focussed on "offloading" cell phone
data from cellular networks onto Wi-Fi networks. Deployments of such
systems have seen uneven adoption across geographies, with cellular
operators frequently limiting their engagement to premier locations
that have deployed Wi-Fi and experience a significant footfall of
operator's customers.
Whereas conventional Carrier Wi-Fi has focused on premier locations,
the last decade has seen a continued increase in the requirements of
private Wi-Fi networks to be able to serve visitors, contractors and
guest users. Moreover, in most of these scenarios, the Wi-Fi network
is primarily being used to support some alternative value
proposition; an improved retail experience in a shopping mall, a more
efficient meeting in a carpeted office, a superior stay in a
hospitality venue, or a better fan experience in a sporting arena.
Traditionally, this segment has made wide-scale use of captive
portals and unencrypted Wi-Fi links to onboard end-users onto their
networks [RFC8952]. However, increasing concerns around sending
Internet traffic over open, untrusted networks, together with the
decreasing costs for cellular data, mean that end-users are less
motivated to search out and attach to such "free" Wi-Fi networks, and
as a consequence, captive portal conversion rates continue to
decrease.
As a consequence, in 2020 WBA launched its OpenRoaming federation,
designed to provide a better on-boarding experience to end-users,
that is seamless, scalable and secure.
Tomas, et al. Expires 14 December 2026 [Page 7]
Internet-Draft WBA OpenRoaming June 2026
3. OpenRoaming Architecture
Figure 2 contrasts a conventional carrier Wi-Fi roaming system with
OpenRoaming. As illustrated, conventional Wi-Fi roaming has
typically been based on:
1. IPSec [RFC6071] tunnels established between access networks, hub-
providers and identity providers used to protect exchanged
signalling.
2. Static routing of RADIUS signalling [RFC2865] based on realm
routing tables populated according to agreements between access
networks and hub-providers.
3. Passpoint primarily used with SIM based identifiers, where
individual PLMN Ids are configured on the access networks WLAN
equipment enabling them to be sent in ANQP messages, and cellular
providers enable Passpoint based SIM authentication in end-user
devices.
4. EAP-AKA [RFC4187] based Passpoint authentication exchanged
between the Supplicant in the end-user device and the EAP Server
in the cellular provider's network.
5. A primary focus on carrier based identities where the end-user
has a billing relationship with the carrier.
In contrast, OpenRoaming is based on:
1. RadSec signalling [RFC6614] secured using mTLS with certificates
issued under WBA's private certification authority.
2. Dynamic routing of RADIUS based on DNS-based discovery of
signalling peers, as specified in [RFC7585].
3. Passpoint based network selection based on 36-bit Roaming
Consortium Organization Identifiers (RCOIs), where WBA defines
the use of the 12 most significant bits of the 36-bit RCOI to
embed closed access group policies.
4. Passpoint authentication that can use any suitable EAP method.
5. Encompassing new identity providers who do not necessarily have a
billing relationship with their end-users.
Example EAP methods used with Passpoint include EAP-TLS, EAP-SIM,
EAP-AKA, EAP-AKA' and EAP-TTLS with MS-CHAP-V2 that are included in
Table 4 of the Passpoint specification [PASSPOINT]. In addition to
Tomas, et al. Expires 14 December 2026 [Page 8]
Internet-Draft WBA OpenRoaming June 2026
these 5 EAP methods, Wi-Fi devices are available that can be
configured to use different EAP type with Passpoint, including
Passpoint with Protected EAP (PEAP) [PEAP], EAP-TEAP [RFC7170] and
EAP-FAST [RFC4851] outer methods, together with alternative inner
methods to MS-CHAP-V2 used inside EAP-TTLS, including EAP-TLS.
Because OpenRoaming ANPs have no direct relationship with OpenRoaming
IDPs that decide the credential type and EAP method to use when
authenticating end-user devices, OpenRoaming ANPs SHOULD ensure that
all EAP Methods compatible with Passpoint can be used to authenticate
end-user devices.
Tomas, et al. Expires 14 December 2026 [Page 9]
Internet-Draft WBA OpenRoaming June 2026
+---------+ +--------+ +--------+ +--------+
| Visited | | Wi-Fi | | Wi-Fi | |Cellular|
| Wi-Fi | | Hub | | Hub | |Provider|
| Network |<------>|Provider|<------>|Provider|<------>|Network |
| | RADIUS | | RADIUS | | RADIUS | |
| NAS | | RADIUS | | RADIUS | | RADIUS |
| |<------>| proxy |<------>| proxy |<------>| Server |
|Passpoint| IPSec +--------+ IPSec +--------+ IPSec +--------+
|PLMNId(s)|
+---------+
/|\
|
\|/
+---------+ A) Conventional Carrier Wi-Fi
|Passpoint|
| device |
| with |
| PLMN-Id |
| profile |
+---------+
+---------+ +---+ +--------+
| Visited |<----------------->|DNS|<------------------>|Identity|
| Wi-Fi | DNS based peer +---+ Configure NAPTR, |Provider|
| Network | discovery SRV and A/AAAA |Network |
| | records | |
| NAS | | RADIUS |
| |<------------------------------------------>| Server |
|Passpoint| RadSec/TLS secured using mTLS +--------+
| RCOI(s) | and WBA PKI
+---------+
/|\
|
\|/
+---------+ B) OpenRoaming
|Passpoint|
| device |
| with |
| RCOI(s) |
| profile |
+---------+
Figure 2: Contrasting Conventional Carrier Wi-Fi and OpenRoaming
Architectures
Tomas, et al. Expires 14 December 2026 [Page 10]
Internet-Draft WBA OpenRoaming June 2026
4. Identifying OpenRoaming Entities
All OpenRoaming providers (access, identity and hub) and OpenRoaming
brokers are allocated a WBA Identity (WBAID). The WBAID is defined
to be transported in the RADIUS Operator-Name attribute (#126)
[RFC5580]. WBA has been allocated the Operator Namespace identifier
0x34 "4" to identify an Operator-Name attribute carrying a WBAID.
The WBAID is a hierarchical namespace that comprises at its top level
the identity allocated by WBA to a WBA Member and is of the form
shown in Figure 3 where the optional 2 upper case characters
represent an ISO-3166 Alpha-2 country code [ISO3166] e.g.,
"WBAMEMBER:US".
WBAID = member-string [ ":" country-code ]
member-string = 1*( member-char )
member-char = UPPERALPHA / DIGIT / SPECIAL
country-code = 2UPPERALPHA
UPPERALPHA = %x41-5A ; "A"-"Z"
DIGIT = %x30-39 ; "0"-"9"
; SPECIAL: permitted special characters
; excludes ":", ".", "_", "#", pound (%xA3), "*", '"'
SPECIAL = %x21 / %x24-26 / %x28-29 / %x2B-2D /
%x2F / %x3C-40 / %x5B-5E / %x7B-7E
Figure 3: ABNF definition of Primary WBAID Structure
When operating as an OpenRoaming broker, the WBA Member is able to
allocate subordinate identities to OpenRoaming providers who are not
WBA members by pre-pending a subordinate identity , plus "." (%x2e)
to the Member's WBAID, e.g., a broker assigned the WBAID
"WBAMEMBER:US" by the WBA is able to assign the WBAID
"OPENROAMINGPROVIDER.WBAMEMBER:US" to a third-party ANP/IDP who has
agreed terms with the broker and joined the federation. In this way,
any receiving entity of a WBAID can identify the WBA Member who is
acting as an OpenRoaming broker to the provider by assigning it an
identity.
Tomas, et al. Expires 14 December 2026 [Page 11]
Internet-Draft WBA OpenRoaming June 2026
5. Scaling Secured Signalling
As described in Appendix C, the OpenRoaming legal framework does not
assume any direct relationship between ANPs and IDPs. In order to
scale the secured signalling between providers, the federation makes
use of a Public Key Infrastructure (PKI) using a private Certificate
Authority specifically designed to secure the operations of the
roaming federation. WBA and its members have published the WBA
Certificate Policy [WBAPKICP] that defines the policies which govern
the operations of the PKI components by all individuals and entities
within the infrastructure. The OID for Wireless Broadband Alliance
is:
{ iso(1) identified-organization(3) dod(6) internet(1) private(4)
enterprise(1) The Wireless Broadband Alliance(14122) }
The Wireless Broadband Alliance organizes its OID arcs for the
Certificates Policy Documents using the object identifier
1.3.6.1.4.1.14122.1.1. At the time of writing, the current
certificate policy is 1.3.6.1.4.1.14122.1.1.7.
This Certificate Policy is based on a 4-level hierarchy, as
illustrated in Figure 4.
Tomas, et al. Expires 14 December 2026 [Page 12]
Internet-Draft WBA OpenRoaming June 2026
+---------+-------------------------+---------------------------+
| Level | Description | Comment |
+---------+-------------------------+---------------------------+
| Level 1 | OpenRoaming Root | Operation managed by WBA. |
| | Certificate Authority | |
+---------+-------------------------+---------------------------+
| Level 2 | OpenRoaming Policy | Operation managed by WBA. |
| | Intermediate Certificate| Instantiates WBA policy |
| | Authority | OID. |
+---------+-------------------------+---------------------------+
| Level 3 | OpenRoaming Issuing | Operated by an OpenRoaming|
| | Intermediate Certificate| broker. |
| | Authority | |
+---------+-------------------------+---------------------------+
| Level 3 | OpenRoaming Registration| Optional and when used, |
| | Authority | operated by an OpenRoaming|
| | | broker. |
+---------+-------------------------+---------------------------+
| Level 4 | OpenRoaming Entity | A WBA member or |
| | | non-member. WBA's |
| | | Certificate Policy |
| | | requires the Entity's |
| | | WBAID is included in the |
| | | Subject UID field in the |
| | | certificate. |
+---------+-------------------------+---------------------------+
Figure 4: OpenRoaming PKI Hierarchy
Certificates issued under the WBA PKI are used by Entities to perform
mutual authentication with other Entities and to secure RadSec
signalling [RFC6614] that carries EAP-based Passpoint authentication.
This is typically between a RadSec client in the OpenRoaming ANP's
network and an RadSec Server in the OpenRoaming IDP's network,
although a provider can decide to outsource the operation of the
RadSec endpoint to a third party provider.
OpenRoaming is a distributed federation that lacks a centralized
RADIUS element for identifying and troubleshooting signalling issues.
Instead, the WBA operates cloud-based systems capable of verifying
the correct configuration of DNS and TLS endpoints for OpenRoaming
IDPs that have registered their realms with the WBA. This baseline
testing by the WBA ensures that ANPs and IDPs can establish a TLS
connection, such as when an end-user from an IDP roams into the
coverage area of Wi-Fi networks operated by an ANP.
Tomas, et al. Expires 14 December 2026 [Page 13]
Internet-Draft WBA OpenRoaming June 2026
To provide a scalable system that enables access and identity
providers to collaboratively troubleshoot and resolve issues, the WBA
Certificate Practice Statement [WBAPKICPS] REQUIRES the Subject
Alternative Name (SAN) attribute in issued end-entity certificates
includes a contact email address responsible for handling issues
raised by third-party providers. The OpenRoaming legal framework
requires ANPs and IDPs to make reasonable efforts to support
troubleshooting procedures. This includes monitoring the email
address listed in the SAN attribute of the certificate and responding
to any issues raised by legitimate third parties.
6. IDP Discovery
6.1. Dynamic Discovery
OpenRoaming defines the use of dynamic discovery [RFC7585] by which
an ANP discovers the IP address of the IDP's RadSec server. Whereas
[RFC7585] defines the use of separate service tags for identifying
RADIUS Authentication ("aaa+auth") and RADIUS Accounting ("aaa+acct")
servers, OpenRoaming uses the "aaa+auth" tag to identify the IP
address of a RadSec server that supports both RADIUS authentication
and accounting.
[RFC7585] additionally defines the use of DNS to enable the dynamic
discovery of a RADIUS endpoint for supporting dynamic authorization
services, i.e., for RADIUS Change of Authorization (CoA) and
Disconnect Message (DM) support. OpenRoaming does not use dynamic
discovery for dynamic authorization, instead defining the use of
"reverse CoA" [I-D.draft-ietf-radext-reverse-coa] that allows an IDP
to send CoA packets in "reverse" down a RADIUS/TLS connection that
was previously established by an ANP originated signaling exchange,
as defined in Section 9.16.
6.2. Discovery of EAP-AKA/AKA' Servers
Passpoint defines the use of EAP-AKA' based authentication [RFC5448]
which uses the 3GPP 23.003 [TS23003] defined realm of
wlan.mnc<mnc>.mcc<mcc>.3gppnetwork.org, where <mcc> represent an
E.212 Mobile Country Code and <mnc> represents the E.212 Mobile
Network Code allocated to the IDP. GSMA is responsible for operating
the 3gppnetwork.org domain and GSMA IR.67 [GSMAIR67] limits access to
the DNS systems supporting such records to those systems connected to
the inter-PLMN IP backbone (known as "GRX/IPX"). As OpenRoaming ANPs
do not connect to this inter-PLMN backbone, then conventional realm
based lookup cannot be used over the Internet to discover the RadSec
server supporting EAP-AKA' authentication.
Tomas, et al. Expires 14 December 2026 [Page 14]
Internet-Draft WBA OpenRoaming June 2026
GSMA IR.67 does allow systems to be discoverable from the public
Internet, specifically calling out the use of the pub.3gppnetwork.org
sub-domain name for such procedures. In order for ANPs to
dynamically discover the RadSec server supporting EAP-AKA'
authentication, GSMA has defined the use of the
wlan.mnc<mnc>.mcc<mcc>.pub.3gppnetwork.org by OpenRoaming systems.
This means that whenever a RadSec client receives a user-name
containing an NAI formatted as
user@wlan.mnc<mnc>.mcc<mcc>.3gppnetwork.org, the dynamic peer
detection functionality MUST insert ".pub" into the realm and perform
DNS based dynamic discovery using the
wlan.mnc<mnc>.mcc<mcc>.pub.3gppnetwork.org domain name. The RADIUS
user-name attribute MUST NOT be similarly modified.
IR.67 defines the procedure by which a cellular operator can request
the delegation of their mnc<mnc>.mcc<mcc>.pub.3gppnetwork.org sub-
domain. GSMA PRD IR.67 also allows an MNO to delegate the entire
mnc<MNC>.mcc<MCC>.pub.3gppnetwork.org sub-domain which could have
already occurred, e.g., to enable use of the
epdg.epc.mnc<MNC>.mcc<MCC>.pub.3gppnetwork.org domain used with
3GPP's Wi-Fi calling service. Using this approach, a cellular
operator operating as an OpenRoaming IDP can authenticate their end-
users on third party ANP Wi-Fi networks.
6.3. Proving a Discovered RadSec Server is Authoritative for a Realm
The OpenRoaming preferred approach to dynamically discover the RadSec
server IP address serving a particular realm or set of realms is to
use DNS records that are protected with DNSSEC [RFC9364]. However,
GSMA has not enabled DNSSEC on its 3gppnetwork.org domain, meaning
that DNSSEC cannot be applied on the publicly resolvable domains
under pub.3gppnetwork.org. Because of this situation, OpenRoaming
does not currently mandate operation of DNSSEC.
If the DNS records for a realm are not protected with DNSSEC, because
the realm has been provided directly by the OpenRoaming end-user, the
IDP SHOULD ensure that the discovered RadSec server(s) supporting its
realm(s) is/are configured with a WBA-PKI server certificate that
includes the realm(s) used in the dynamic peer detection in the
certificate SubjectAltName.
Where the DNS records are protected with DNSSEC, the IDP SHOULD
ensure that the discovered RadSec server(s) supporting its realm(s)
is/are configured with a WBA-PKI server certificate that includes the
derived name(s) from the secured DNS NAPTR/SRV query in the
certificate SubjectAltName.
Tomas, et al. Expires 14 December 2026 [Page 15]
Internet-Draft WBA OpenRoaming June 2026
Where the OpenRoaming IDP has offloaded the operation of RadSec
termination to a third party hub-provider that is responsible for
supporting a number of independent realms, the hub-provider SHOULD
ensure that the discovered RadSec server(s) supporting the
independent realms from its partner IDPs is/are configured with a
WBA-PKI server certificate that includes the derived name(s) from the
DNS NAPTR/SRV query in the certificate SubjectAltName.
6.4. Co-existence with Other Federations
Other federations which want to interface to the OpenRoaming
federation may use dynamic discovery with distinct NAPTR application
service tags to facilitate integration. For example, an eduroam
service provider can use the use the "x-eduroam" application service
tag, specified in [RFC7593], to discover the home institution's
RadSec peer for authentication, and OpenRoaming ANPs can use the
"aaa+auth" tag to discover a separate RadSec peer that can be defined
for handling all inter-domain authentications.
Where a separate inter-federation RadSec peer is not used, the other
federation AAA operating as an OpenRoaming IDP needs to determine
which certificate chain to return in its ServerHello message. An
OpenRoaming ANP operating with TLS 1.3 SHOULD use the
"certificate_authorities" extension [RFC8446] in its ClientHello
message to indicate that the ANP supports the WBA PKI Certification
Authority trust anchor. Similarly, an OpenRoaming ANP operating
using TLS 1.2 SHOULD use the "trusted_ca_keys" extension [RFC6066] in
its ClientHello message to indicate the DistinguishedName of the WBA
PKI Certification Authority whose root keys the ANP possesses. The
federation AAA operating as an OpenRoaming IDP MAY use information in
the ClientHello extension to guide its certificate selection.
7. Connection Management for Dynamically Discovered RadSec Peers
The procedures for connection management for dynamically discovered
peers depends on whether the ANP supports reverse CoA functionality,
as defined in Section 9.16.
7.1. ANPs not supporting reverse CoA
An OpenRoaming ANP MAY operate with a short TCP idle timeout,
sufficient to complete the RADIUS Access-Request exchange and the
initial RADIUS Accounting-Request exchange with Acct-Status-Type set
to "Start". Subsequent RADIUS Accounting-Request messages to the IDP
may require TLS resumption, for example, if no other inbound roamers
from the IDP are active on the ANP's network.
Tomas, et al. Expires 14 December 2026 [Page 16]
Internet-Draft WBA OpenRoaming June 2026
NOTE: When performing TLS resumption, the ANP MUST consider the
server IP address stale if its corresponding DNS record has
expired and perform a new DNS query to resolve the current IP
address.
Operation using short TCP-idle timeouts avoids the need for the
operation of an additional RADIUS application watchdog. In such
cases, ANPs are NOT REQUIRED to support Status-Server extension as a
RADIUS application-level watchdog.
7.2. ANPs supporting reverse CoA
An OpenRoaming ANP supporting the reverse CoA functionality defined
in Section 9.16 SHOULD manage connections such that the RadSec
connection to the dynamically discovered peer is considered as
"temporarily static" while active RADIUS sessions exist that may
require the sending of future CoA packets.
While the connection is "temporarily static", the ANP MUST monitor
the RadSec connection liveness. The ANP SHOULD use the Status-Server
extension, defined in [RFC5997] for monitoring the liveness of a
RadSec connection. IDPs and hubs supporting OpenRoaming settled-
service MUST respond to Status-Server requests.
NOTE 1: OpenRoaming recognizes that despite [RFC5997] recommending
RADIUS clients SHOULD NOT generate RADIUS Access-Request packets
solely to see if a server is alive, some OpenRoaming ANPs do use
RADIUS Access-Request for such purposes. In such cases, the
Access-Request MUST be sufficient for the IDP to reject the
request without performing an Access-Challenge.
The OpenRoaming ANP supporting reverse CoA MUST NOT configure any
TCP-idle timeout shorter than the shortest inter-RADIUS message
duration, (e.g., the accounting interim period or connection
liveliness checking repetition period). Reconnection procedures
SHOULD follow section 3.8.1 of [I-D.ietf-radext-radiusdtls-bis].
This section REQUIRES the ANP implement an algorithm for handling the
timing of such reconnection attempts that includes an exponential
back-off.
NOTE 2: When performing TLS-reconnection, the ANP MUST consider
the server IP as stale when its corresponding DNS record has
expired and perform a new DNS query to resolve the current IP
address.
NOTE 3: This does not prevent an ANP performing a new DNS query,
e.g., if a reconnection attempt fails in case the server has had
its IP address configuration changed unexpectedly.
Tomas, et al. Expires 14 December 2026 [Page 17]
Internet-Draft WBA OpenRoaming June 2026
7.3. Load Balancing RadSec Connections
An ANP MAY perform load balancing on dynamically discovered RadSec
connections, according to the ANPs load balancing policies. Load
balancing can trigger the opening of a new TLS connection to a RadSec
server even if an existing TLS session is present. ANPs that support
reverse CoA MUST use the same TLS session for sending RADIUS Access-
Request and RADIUS Accounting-Request messages that correspond to the
same individual user session.
7.4. Connection Management for IDP RadSec Servers
Since TCP-idle timeout and reverse CoA support are ANP policies, all
IDPs and hubs SHOULD enable support for Status-Server extension, as
specified in [RFC5997].
Dynamically established connections between ANPs and IDPs with
frequent authentication exchanges may never trigger idle timeouts,
potentially hindering IDPs from updating RadSec server IP address
configurations. IDPs can operate their DNS systems and RadSec
servers TCP configuration to facilitate RadSec server IP address re-
configuration. For example, a DNS TTL of 86400 seconds coupled with
a maximum TCP connection lifetime of 86400 seconds, ensures that
connections between ANPs and IDPs experiencing frequent
authentications are re-established using an updated DNS record at
least once every 24 hours. In such cases, if the session was closed
by the RadSec server, the ANP SHOULD NOT consider the closure as
normal. If the ANP supports reverse CoA, the ANP SHOULD follow
section 3.8.1 of [I-D.ietf-radext-radiusdtls-bis] that permits the
triggering of an immediate reconnection to the RadSec server by the
ANP.
8. OpenRoaming Passpoint Profile
8.1. OpenRoaming Policy Controls
In order to avoid possible fragmentation of roaming federations,
OpenRoaming recognizes that there is a need to permit OpenRoaming to
be integrated into a variety of different use-cases and value
propositions. These use-cases include scenarios where providers are
able to enforce policy controls of which end-users are authorized to
access the service. The realization of authorization policy controls
in the OpenRoaming federation is a balance between the requirements
for fine grain policy enforcement versus the potential impact of
policy enforcement (access rejection) on the end-user experience.
Tomas, et al. Expires 14 December 2026 [Page 18]
Internet-Draft WBA OpenRoaming June 2026
Such a level of control is realized using Closed Access Group (CAG)
based policies. A Closed Access Group identifies a group of
OpenRoaming users who are permitted to access one or more OpenRoaming
access networks configured with a particular CAG policy. These
Closed Access Group policies are encoded using one or more Roaming
Consortium Organization Identifiers (RCOIs), first defined in
Passpoint Release 1.0, and well supported across the smartphone
device ecosystem.
NOTE: encoding CAG policies in OpenRoaming using one or more RCOIs
is aimed at delivering an equivalent functionality to the CAG
policies encoded in 3GPP using one or more CAG-IDs.
8.2. OpenRoaming Closed Access Group Policies
OpenRoaming defines the use of multiple RCOIs to facilitate the
implementation of Closed Access Group policies across the federation.
The currently defined RCOIs are:
* OpenRoaming-Settled: BA-A2-D0-xx-x
* OpenRoaming-Settlement-Free: 5A-03-BA-xx-x
Figure 5 shows how the 24-bit length OpenRoaming RCOIs are further
extended into 36-bit length OUI-36s with additional context dependent
identifiers used to encode specific Closed Access Group policies.
Following Passpoint Release 1.0 specification, only when there is a
bitwise match of all 36 bits of the configured RCOI in the WLAN
equipment and the Passpoint profile configured in the end-user device
will an EAP authentication be triggered.
The encoding of Closed Access Group policies is defined so that the
"no-restrictions" policy is encoded using the 12-bit value "00-0",
i.e., 54-03-BA-00-0 represents a policy that accepts all OpenRoaming
settlement-free end-users onto a particular ANP installation.
+---------------------------------------+-------------------+
| OUI-36 Octet 4 | OUI-36 Octet 5 |
+---------------------------------------+-------------------+
| B7 | B6 | B5 | B4 | B3 | B2 | B1 | B0 | B7 | B6 | B5 | B4 |
+----+---------+----+-------------------+-------------------+
| LoA| QoS |PID | ID-Type |On-b| Reserved - |
| | | | |oard| set to 0 |
+----+---------+----+-------------------+-------------------+
Figure 5: Extension of Octets 4 and 5 for OpenRoaming Context
Dependent RCOI Field
Tomas, et al. Expires 14 December 2026 [Page 19]
Internet-Draft WBA OpenRoaming June 2026
8.2.1. Level of Assurance Policies
The format of the Level of Assurance (LoA) field is as shown in
Figure 6.
+-----------------------------------------------------------+
| LoA Field | Description |
+-----------------------------------------------------------+
| B7 | |
+-----------------------------------------------------------+
| 0 | Baseline Identity Proofing |
+-----------------------------------------------------------+
| 1 | Enhanced Identity Proofing |
+-----------------------------------------------------------+
Figure 6: OpenRoaming CAG LoA Field
The baseline identity proofing requirement on IDPs ensures that all
OpenRoaming identities are managed with at least a medium level of
assurance (LoA level 2) for end-user enrollment, credential
management and authentication, as specified in ISO/IEC 29115
[ISO29115].
The LoA field is used to support ANPs which operate in regulatory
regimes that require enhanced identity proofing to be used in the
provision of credentials on OpenRoaming devices, equivalent to LoA
level 3 in ISO/IEC29115 [ISO29115]. In such a scenario, the ANP can
set the LoA bit field to 1 in all configured RCOIs to ensure that
only identities provisioned using enhanced LoA 3 procedures can
access via the ANP's network.
Any IDP that manages its identities according to ISO/IEC 29115 LoA
level 2 MUST NOT configure any RCOI in their end-users' Passpoint
profile with the LoA field set to "1". Conversely, an IDP that
manages its identities according to ISO/IEC 29115 LoA level 3 MAY
configure multiple RCOIs in their end-users' Passpoint profile,
including RCOIs with the LoA field set to "0" and RCOIs with the LoA
field set to "1".
8.2.2. Quality of Service Policies
Tomas, et al. Expires 14 December 2026 [Page 20]
Internet-Draft WBA OpenRoaming June 2026
8.2.2.1. Access Network Requirements
One of the challenges faced by users of Wi-Fi hotspots is when the
Wi-Fi network is configured sub-optimally and results in a poor user
experience. Often the only remedy open to a user it to disable the
Wi-Fi interface on their smartphone and continue to use cellular
data. This is especially the case where the Wi-Fi hotspot has been
automatically selected with no user intervention. As a consequence,
OpenRoaming defines specific service tiers across the federation and
uses the QoS field to differentiate between different tiers. The
format of the QoS field is shown in Figure 7.
+-----------------------------------------------------------+
| QoS Field | Description |
+-----------------------------------------------------------+
| B6 | B5 | |
+-----------------------------------------------------------+
| 0 | 0 | Bronze |
+-----------------------------------------------------------+
| 0 | 1 | Silver |
+-----------------------------------------------------------+
| 1 | 0 | Reserved |
+-----------------------------------------------------------+
| 1 | 1 | Reserved |
+-----------------------------------------------------------+
Figure 7: OpenRoaming CAG QoS Field
The "Bronze" and "Silver" values of QoS field are used to identify
specific minimum quality of service policy aspects.
The bronze service tier corresponds to the following:
1. The availability of OpenRoaming service when used to access the
Internet measured during scheduled operations across the ANP's
network exceeds 90% over any one month period.
2. The ANP shall ensure that the maximum download speed that end-
Users can access the Internet shall be at least 50 megabits per
second.
3. During the busy hour, the aggregate bandwidth used to receive
Internet service on the ANP's network is sufficient to enable
each and every authenticated and authorized OpenRoaming end-user
to simultaneously receive a sustained 256 kilobits per second
connection.
The silver service tier corresponds to the following:
Tomas, et al. Expires 14 December 2026 [Page 21]
Internet-Draft WBA OpenRoaming June 2026
1. The availability of OpenRoaming service when used to access the
Internet measured during scheduled operations across the ANP's
network exceeds 95% over any one month period.
2. The ANP shall ensure that the maximum download speed that end-
users can access the Internet shall be at least 100 megabits per
second.
3. During the busy hour, the aggregate bandwidth used to receive
Internet service on the ANP's network is be sufficient to enable
each and every authenticated and authorized end-user to receive a
sustained 512 kilobits per second connection.
4. At least 10% of authenticated and authorized users are able to
stream video content at a downlink rate of at least 5 megabits
per second (when measured over a one-minute interval) over all of
the ANP's OpenRoaming enabled Wi-Fi networks.
5. The authenticated and authorized end-users are able to stream
video from one or more third party content distribution networks
with an end-to-end latency of less than 150ms from all of the
ANP's OpenRoaming enabled Wi-Fi networks.
The QoS field can be used by those IDPs that are only interested in
providing their end-users with a higher quality service level when
automatically authenticated onto an OpenRoaming network. For
example, an IDP configures the QoS field as bronze in a Passpoint
profile that uses the "5A-03-BA" settlement free RCOI and configures
the QoS field as silver in a Passpoint profile that uses the "BA-
A2-D0" OpenRoaming-settled paid service.
ANPs that only support the bronze service tier MUST set the QoS Field
to "00" in all RCOIs configured on their WLAN equipment. ANPs that
support the silver service tier MAY configure multiple RCOIs on their
WLAN equipment that include values where the QoS field is set to "01"
and values where the QoS field is set to "00".
Exceptionally, ANPs that operate OpenRoaming installations on moving
platforms are permitted to deviate from the normal OpenRoaming
service level requirements listed above. This is because such
installations can necessitate use of cellular-based backhaul and/or
backhaul via Non-Terrestrial Networks (NTN) which may not be able to
meet the OpenRoaming minimum "bronze" service level requirements. If
an ANP wants to benefit from such deviations, it MUST signal using
the WLAN-Venue-Info attribute [RFC7268] that it is operating in a
venue category identified using a Venue Group value of "10", which is
defined in Section 8.4.1.34 of [IEEE80211] as being used for
vehicular installations. In such cases, the OpenRoaming ANP MAY
Tomas, et al. Expires 14 December 2026 [Page 22]
Internet-Draft WBA OpenRoaming June 2026
signal one or more WBA-Custom-SLA vendor specific attributes
Section 9.13 to indicate one or more (availability, per-user
sustained bandwidth) tuples to the IDP.
OpenRoaming also defines the ability of the ANP to signal additional
real-time metrics associated with the Wi-Fi connection to an end-
user, using the enhanced syntax for the RADIUS Connect-Info
attributes as defined in Section 9.8. This information can be used
by an IDP to derive a quality metric for the performance of the ANP's
OpenRoaming Wi-Fi network.
8.2.2.2. Identity Provider Requirements
Irrespective of the service-levels supported by their users, the IDP
shall ensure that the availability of their authentication service
measured during scheduled operations shall exceed 99% over any one
month period.
8.2.2.3. Rationale for Busy Hour Sustained Throughput Values
The ANP requirements for sustained busy hour throughput requirements
defined in Section 8.2.2.1 are based on equating a notional per month
consumption to a sustained busy hour throughput. The following
calculation represents the mapping of sustained throughput to monthly
consumption.
* Busy hour sustained throughput = 256 kilobits per second
* Busy hour consumption = 256 x 1024 x 3600 / 8 = 118 megabytes per
hour
* Daily consumption, assuming 7% consumed in busy hour = 118 / 0.07
= 1.69 gigabytes
* Monthly consumption, assuming 22 busy days per month = 1.69 x 22 =
37.1 gigabytes/month
Comparing to a cellular usage, we need to use smartphone consumption
figures that precludes Wi-Fi as well as broadband specific fixed
wireless access subscriptions.
Using an example 10 gigabytes/month consumption per cellular
subscription, it is evident that OpenRoaming bronze is dimensioned to
accommodate 3.7 times the example cellular traffic, or 78% of total
traffic when cellular and Wi-Fi are combined. Similarly, OpenRoaming
silver is dimensioned to carry 88% of total traffic when cellular and
Wi-Fi are combined.
Tomas, et al. Expires 14 December 2026 [Page 23]
Internet-Draft WBA OpenRoaming June 2026
8.2.3. Privacy Policies
The baseline privacy policy of OpenRoaming [ORPRIVACY] ensures the
identities of end-users remain anonymous when using the service. The
WBA WRIX specification specifies that where supplicants use EAP
methods that support user-name privacy, i.e., which are compatible
with the "@realm" (or "anonymous@realm") (outer) EAP-Identifier, then
the supplicant SHOULD use the anonymized outer EAP identifier.
Supplicants supporting other EAP methods SHOULD support EAP method
specific techniques for masking the end-user's permanent identifier,
for example pseudonym support in EAP-AKA/AKA' [RFC4187] and/or
enhanced IMSI privacy protection [WBAEIPP]. OpenRoaming IDPs SHOULD
support and enable the corresponding server-side functionality to
ensure end-user privacy is protected.
The WBA WRIX specification also recognizes that the privacy of end-
users can be unintentionally weakened by the use of correlation
identifiers signalled using the Chargeable-User-Identity attribute
(#89) [RFC4372] and/or the Class attribute (#25) [RFC2865] in the
RADIUS Access-Accept packet. The WBA WRIX Specification recommends
that the default IDP policy SHOULD ensure that, when used, such
correlation identifiers are unique for each combination of end-user/
ANP and that the keys and/or initialization vectors used in creating
such correlation identifiers SHOULD be refreshed at least every 48
hours, but not more frequently than every 2 hours.
This 2 hour limit is designed to assist the ANP in performing
autonomous troubleshooting of connectivity issues from authentic end-
users/devices that are repeatedly re-initiating connectivity to the
ANP's network and/or to assist the ANP in identifying a new session
originated by an authentic user/device that has previously been
identified by the ANP as having violated the OpenRoaming end-user
terms and conditions [ORTERMS]. When using typical public Wi-Fi
session durations, it is estimated that, with this 2 hour
restriction, the ANP will be able to correlate a RADIUS Access-
Request/Access-Accept exchange that immediately follows a RADIUS
Accounting-Request stop message in over 50% of the sessions.
In contrast to this default policy, there can be scenarios where the
ANP desires to derive value from its OpenRoaming settlement-free
service by analysing aggregate end-user behaviour. Whereas the use
of aggregated end-user information does not violate the OpenRoaming
privacy policy, the derivation of such can benefit from the ANP being
able to uniquely identify end-users. In order to support such
scenarios, the OpenRoaming closed access group policies include the
PID field.
Tomas, et al. Expires 14 December 2026 [Page 24]
Internet-Draft WBA OpenRoaming June 2026
The PID field can be used to support scenarios where the end-user has
consented with their IDP that an immutable end-user identifier can be
signalled to the ANP in the RADIUS Access-Accept. The format of the
PID field is illustrated in Figure 8. The PID field can be
configured to "1" in the RCOIs used by those ANPs that want to be be
able to account for unique OpenRoaming end-users.
The OpenRoaming IDP terms [ORTERMS] ensure subscribers MUST
explicitly give their permission before an immutable end-user
identity is shared with a third party ANP. When such permission has
not been granted, an IDP MUST NOT set the PID field to "1" in any of
the RCOIs in its end-user Passpoint profiles. When such permission
has been granted, an IDP MAY configure multiple RCOIs in their end-
users' Passpoint profile, including RCOIs with the PID field set to
"1".
+-----------------------------------------------------------+
| PID Field | Description |
+-----------------------------------------------------------+
| B4 | |
+-----------------------------------------------------------+
| 0 | Baseline ID Policy applies, i.e., users |
| | remain anonymous whilst using the service.|
+-----------------------------------------------------------+
| 1 | An immutable end-user ID will be returned |
| | by the IDP in the Access-Accept packet. |
+-----------------------------------------------------------+
Figure 8: OpenRoaming CAG PID Field
8.2.4. ID-Type Policies
The ID-Type field can be used to realize policies which are based on
the business sector associated with the identity used by the IDP.
The format of the ID-Type field is illustrated in Figure 9.
All IDPs configure at least one RCOI in their end-user's Passpoint
profile with ID-Type set to "0000" (Any identity type is permitted).
An IDP MAY configure additional RCOIs in their end-users' Passpoint
profile with an ID-Type representing the sector type of IDP.
An ANP what wants to serve all end-users, irrespective of sector,
configures RCOIs in the WLAN equipment with ID-Type set to "0000".
Alternatively, an ANP which operates a sector specific business that
only desires to serve a subset of OpenRoaming end-users MAY set the
ID-Type to their desired sector in all configured RCOIs.
Tomas, et al. Expires 14 December 2026 [Page 25]
Internet-Draft WBA OpenRoaming June 2026
+-----------------------------------------------------------+
| ID-Type Field | Description |
+-----------------------------------------------------------+
| B3 | B2 | B1 | B0 | |
+-----------------------------------------------------------+
| 0 | 0 | 0 | 0 | Any identity type is permitted|
+-----------------------------------------------------------+
| 0 | 0 | 0 | 1 | A service provider identity |
+-----------------------------------------------------------+
| 0 | 0 | 1 | 0 | A cloud provider identity |
+-----------------------------------------------------------+
| 0 | 0 | 1 | 1 | A generic enterprise identity |
+-----------------------------------------------------------+
| 0 | 1 | 0 | 0 | A government identity, e.g., |
| | | | | including city |
+-----------------------------------------------------------+
| 0 | 1 | 0 | 1 | An automotive identity |
+-----------------------------------------------------------+
| 0 | 1 | 1 | 0 | A hospitality identity |
+-----------------------------------------------------------+
| 0 | 1 | 1 | 1 | An aviation industry identity |
+-----------------------------------------------------------+
| 1 | 0 | 0 | 0 | An education or research |
| | | | | identity |
+-----------------------------------------------------------+
| 1 | 0 | 0 | 1 | A cable industry identity |
+-----------------------------------------------------------+
| 1 | 0 | 1 | 0 | A manufacturer identity |
| | | | | (note 1) |
+-----------------------------------------------------------+
| 1 | 0 | 1 | 1 | A retail identity |
+-----------------------------------------------------------+
| other values | Reserved |
+-----------------------------------------------------------+
| NOTE 1: A manufacturer identity closed access group policy|
| applies to IoT credentials corresponding to manufacturer |
| installed identities as well as IoT credentials |
| corresponding to owner installed identities. |
+-----------------------------------------------------------+
Figure 9: OpenRoaming CAG ID-Type Field
8.2.5. On-boarding Credential Policies
The format of the on-boarding credential policy (On-board) field is
as shown in Figure 10.
Tomas, et al. Expires 14 December 2026 [Page 26]
Internet-Draft WBA OpenRoaming June 2026
+-----------------------------------------------------------+
| On-board Field | Description |
+-----------------------------------------------------------+
| B7 Octet 5 | |
+-----------------------------------------------------------+
| 0 | A long-lived identity |
+-----------------------------------------------------------+
| 1 | A short-lived identity |
+-----------------------------------------------------------+
Figure 10: OpenRoaming CAG On-board Field
The On-board field is used to identify closed access group policy
aspects related to whether the identity/profile is long-lived, or
whether the identity/profile is short-lived. Short-lived profiles
are intended to only be used to provide connectivity such that the
procedure for configuring a long-lived identity/profile can be
performed.
Sessions authorized with short-lived credentials MUST have a session-
timeout value of less than 300 seconds.
8.3. Prioritizing Policies
The definition of OpenRoaming closed access group policies assumes
the configuration of multiple RCOIs in ANP WLAN equipment and IDP
end-user devices.
When a device has multiple Passpoint profiles matching the ANP's
Closed Access Group policy, an OpenRoaming ANP may want to prefer
OpenRoaming subscribers use a particular IDP's profile when attaching
to its access network. Such a preference can be because the
OpenRoaming ANP has a preferential relationship with certain
OpenRoaming IDPs.
The OpenRoaming ANP is able to use the Home SP preference
functionality defined in Passpoint [PASSPOINT] to prioritize the use
of a particular profile by a Passpoint enabled device. In such a
scenario, the ANP configures the Domain Name list to include the
FQDN(s) associated with the profile(s) to be prioritized.
Tomas, et al. Expires 14 December 2026 [Page 27]
Internet-Draft WBA OpenRoaming June 2026
9. OpenRoaming RADIUS Profile
The OpenRoaming RADIUS profile is based on the WBA WRIX Specification
which in turn are derived from [RFC3580] and [RFC3579]. All ANPs
MUST support RADIUS Accounting for all OpenRoaming sessions,
irrespective of which RCOIs are supported, i.e., for both settled and
settlement free service. All IDPs MUST respond to any RADIUS Access-
Request and Accounting-Request packet received.
Additionally, OpenRoaming defines the use of the following RADIUS
attributes.
9.1. Operator-Name
As described in Section 4, OpenRoaming uses the Operator-Name (#126)
[RFC5580] attribute to signal the WBAID of the OpenRoaming ANP. All
ANPs MUST support the Operator-Name attribute and use it to signal
the WBAID of the OpenRoaming ANP, using the WBA allocated Operator
Namespace identifier, as specified in Section 4.
Exceptionally, if the RADIUS client does not support the WBA
allocated namespace identifier, the WBAID MAY be encoded in the realm
namespace, by using the base64 encoded [RFC4648] WBAID as a subdomain
to the realm "wballiance.com". For example,
ANP1.INTERMEDIARY2:PT
is encoded as
QU5QMS5JTlRFUk1FRElBUlkyOlBU.wballiance.com
9.2. Chargeable-User-Identity
All OpenRoaming ANPs MUST support the Chargeable-User-Identity
attribute (#89) [RFC4372] and indicate such by including a CUI
attribute in all RADIUS Access-Request packets. An ANP that has
configured the OpenRoaming-Context PID Field set to "1" MAY treat a
RADIUS Access-Accept received without a CUI attribute as an Access-
Reject. An ANP that has configured the OpenRoaming-Context PID Field
set to "0" MUST NOT treat any RADIUS Access-Accept received without a
CUI attribute as an Access-Reject.
When an end-user has explicitly given their permission to share an
immutable end-user identifier with third party ANPs, the CUI returned
by the IDP MUST be invariant over subsequent end-user authentication
exchanges between the IDP and the ANP.
Tomas, et al. Expires 14 December 2026 [Page 28]
Internet-Draft WBA OpenRoaming June 2026
9.3. Location-Data/Location-Information
All OpenRoaming ANPs MUST support signalling of location information
using [RFC5580]. As a minimum, all OpenRoaming IDPs need to be able
to determine the country in which the OpenRoaming ANP operates. The
OpenRoaming legal framework described in Appendix C serves as an
"out-of-band agreement" as specified in clause 3.1 of [RFC5580].
Hence, all OpenRoaming ANPs MUST include the Location-Data attribute
(#128) in the RADIUS Access-Request packet, where the location
profile is the civic location profile that includes the country code
where the ANP is located [RFC5580].
When the OpenRoaming ANP supports the OpenRoaming-Settled RCOI ("BA-
A2-D0"), the RADIUS Access-Request packet MUST include the Location-
Data attribute (#128) where the location profile is the civic
location profile containing Civic Address Type information that is
sufficient to identify the financial regulatory regime that defines
the taxable rates associated with consumption of the ANP's service.
OpenRoaming also defines the optional use the geospatial location
profile as specified in [RFC5580]. ANPs MAY signal coordinate-based
geographic location of the NAS or end-user device.
The OpenRoaming Privacy Policy [ORPRIVACY] restricts the use of all
location information signalled to an IDP for either:
1. Making service authorization decisions based on the location of
the ANP's wireless network; or
2. Compliance with applicable law, or law enforcement requests.
9.4. Session-Timeout
An OpenRoaming ANP receiving a RADIUS Access Accept message including
a Session-Timeout attribute MUST operate according to [RFC3580].
An IDP authenticating using a credential associated with a Passpoint
profile with an RCOI where the On-board value is set to 1, as defined
in Section 8.2.5, MUST set the session-timeout value to less than 300
seconds in the RADIUS Access-Accept message.
9.5. Acct-Session-Id
All OpenRoaming enabled ANPs MUST support attribute Acct-Session-Id
[RFC2866]. If an OpenRoaming IDP receives a RADIUS Access-Request
message without an Acct-Session-Id attribute, it SHOULD reject the
Access-Request.
Tomas, et al. Expires 14 December 2026 [Page 29]
Internet-Draft WBA OpenRoaming June 2026
When supported, the Acct-Session-Id attribute SHOULD be temporally
unique within an ANP's access network.
An OpenRoaming IDP that receives a RADIUS Accounting-Request message
without either an Acct-Session-Id or an Acct-Multi-Session-Id
corresponding to an authenticated RADIUS session SHOULD create a log
of the message non-compliance, including the WBAID of the ANP.
9.6. Acct-Multi-Session-Id
All OpenRoaming enabled ANPs configured to generate multiple related
accounting sessions for a single EAP-Supplicant roaming between Wi-Fi
Access points MUST support attribute Acct-Multi-Session-Id [RFC2866].
The Acct-Multi-Session-Id attribute SHOULD be temporally unique
within an ANP's access network.
An OpenRoaming IDP that receives a RADIUS Accounting-Request message
without either an Acct-Session-Id or an Acct-Multi-Session-Id
corresponding to an authenticated RADIUS session SHOULD create a log
of the message non-compliance, including the WBAID of the ANP.
9.7. Event-Timestamp
All OpenRoaming ANPs MUST include the Event-Timestamp attribute
[RFC2869] in all RADIUS Accounting-Request messages.
9.8. Connect-Info
An OpenRoaming ANP MAY include the RADIUS Connect-Info (#77)
attribute in RADIUS messages sent to an IDP, as specified in
[RFC2869]. When included, the ANP SHOULD use the syntax defined in
[I-D.draft-grayson-connectinfo] to signal Wi-Fi network connection
metrics to an OpenRoaming IDP. An IDP authenticating an OpenRoaming
end-user MAY use the information signalled in the Connect-Info
attribute when making authorization decisions.
The ANP MAY use the enhanced Connect-Info syntax to signal real-time
information, including:
* transmit and receive bit rates,
* received signal strength indicator (RSSI),
* frame loss rate,
* frame retry rate, and
Tomas, et al. Expires 14 December 2026 [Page 30]
Internet-Draft WBA OpenRoaming June 2026
* the Wi-Fi global operating class(es) associated with the
connection, as defined in Annex E of [IEEE80211].
When supported by the ANP, these quality metrics SHOULD be included
in both RADIUS Access-Request and RADIUS Accounting-Request messages.
The OpenRoaming legal framework (see Appendix C) ensures that IDPs
that do not separately agree to terms with an ANP governing use of
Wi-Fi network connection metrics MUST solely process signaled
performance data for the purposes of making service authorization
decisions and network troubleshooting, and are prohibited from
disclosing such data to any third party except as necessary for
direct network troubleshooting with the originating ANP.
When included in the RADIUS Access-Request and initial RADIUS
Accounting-Request message, because the raw samples used to calculate
the metrics will be restricted by the number of IEEE 802.11 frames
over which the calculation are based, the transmit bit rates, receive
bit rates and RSSI level MAY correspond to the instantaneous value of
the specific parameter.
In other cases, i.e., where the Connect-Info attribute is signaled in
RADIUS Accounting-Request messages with Acct-Status-Type set to
Interim-Update or Stop, the ANP SHOULD use multiple measurements when
calculating the reported value:
* the reported transmit and receive bit rates SHOULD represent the
maximum values experienced since the last time the connect-info
was signaled, i.e. the "ALGO" term SHOULD be set to "MAX".
* the received signal strength indicator (RSSI) SHOULD represent the
average RSSI value, where the average value calculated MAY be
either a linear average or an exponential weighted average, i.e.
the "ALGO" term SHOULD be set to "AVG".
* frame loss rate and frame retry rate SHOULD represent the
accumulated ratio, i.e. the "ALGO" term SHOULD be set to "ACC".
9.9. Enhanced Reply-Message
Reply-Message was originally defined in [RFC3579] as being forbidden
from being included in any RADIUS message containing an EAP-Message
attribute. This was to prevent earlier systems from attempting to
interwork the Reply-Message text into an EAP Notification packet.
Tomas, et al. Expires 14 December 2026 [Page 31]
Internet-Draft WBA OpenRoaming June 2026
In contrast to using Reply-Message to signal a displayable text
string to authenticating users, WBA's WRIX framework defines the re-
use of the attribute in WRIX-based Passpoint networks to signal
additional information from the IDP to the ANP, specifically
regarding why a connection has been rejected. The message received
MUST NOT be shown to end-users.
The enhanced reply-message is encoded using UTF-8 characters. The
WBA defines additional information is appended after the NUL ASCII
character (0x00). The ABNF syntax of the Reply-Message is shown in
Figure 11.
Reply-message = [ displayable-string ] %x00 [ wba-info ]
displayable-string = *CHAR
wba-info = "Reject-Reason=" cause-code
cause-code = "10" ; failed user authentication
cause-code =/ "11" ; invalid user identity
cause-code =/ "12" ; expired client certificate
cause-code =/ "20" ; generic AAA failure
cause-code =/ "21" ; backend failure
cause-code =/ "22" ; protocol timeout
cause-code =/ "30" ; failure due to badly formatted request
cause-code =/ "31" ; rejected - missing charging model
cause-code =/ "32" ; rejected - missing geospatial location
cause-code =/ "40" ; failure due to subscription - permanent
cause-code =/ "41" ; authorization rejected - no service
; subscription
cause-code =/ "42" ; authorization rejected - roaming not
; allowed in this network
cause-code =/ "43" ; authorization rejected - offered charging
; model not acceptable
cause-code =/ "44" ; authorization rejected - roaming to this
; location not allowed
cause-code =/ "45" ; authorization rejected - offered service
; level not acceptable
cause-code =/ "50" ; failure due to subscription - temporary
cause-code =/ "51" ; authorization rejected - offered charging
; model not acceptable at this time
cause-code =/ "52" ; authorization rejected - roaming to this
; location not allowed at this time
cause-code =/ "53" ; authorization rejected - concurrency
; limits exceeded
cause-code =/ "54" ; authorization rejected - insufficient
; credit
Figure 11: WBA Enhanced Reply-Message Syntax
Tomas, et al. Expires 14 December 2026 [Page 32]
Internet-Draft WBA OpenRoaming June 2026
9.10. WBA-Identity-Provider
The Operator-Name attribute allows the WBAID of the ANP to be
signalled to the IDP. In the reverse direction, the IDP MUST use the
WBA-Identity-Provider vendor specific attribute [WBAVSA] to signal
the WBAID of the IDP back to the ANP. In this case the first
character of the Identity-Provider attribute identifies the WBAID
namespace and is equal to "4" (0x34).
9.11. WBA-Offered-Service
The ANP MAY use the WBA-Offered-Service vendor specific attribute to
signal the highest OpenRoaming service tier supported on its network
[WBAVSA].
If a RADIUS Access-Request is received without either a WBA-Offered-
Service or WBA-Custom-SLA attribute, the IDP SHOULD assume that the
authorization request is associated with the OpenRoaming Bronze
service.
9.12. WLAN-Venue-Info
The ANP MAY use the WLAN-Venue-Info attribute [RFC7268] to signal the
category of venue hosting the WLAN.
9.13. WBA-Custom-SLA
When the ANP uses the WLAN-Venue-Info attribute to signal that the
venue hosting the WLAN is a vehicular installation, the ANP SHOULD
use the WBA-Custom-SLA vendor specific attribute [WBAVSA] to indicate
one or more (availability, per-user sustained bandwidth) tuples to
the IDP.
9.14. Filter-Id
If the IDP accepts the offered service corresponding to the WBA-
Offered-Service attribute, then it MUST copy the contents of the text
string received in the WBA-Offered-Service attribute and include the
same text string in a RADIUS Filter-Id attribute returned in the
Access-Accept message.
If the IDP accepts the offered service corresponding to the WBA-
Custom-SLA attribute, then the IDP shall include the text string
"OpenRoaming Custom" in the RADIUS Filter-Id attribute returned in
the RADIUS Access-Accept message.
Tomas, et al. Expires 14 December 2026 [Page 33]
Internet-Draft WBA OpenRoaming June 2026
9.15. Operator-NAS-Identifier
An OpenRoaming ANP supporting the Reverse CoA functionality defined
in Section 9.16, MAY use the Operator-NAS-Identifier (#241.8) as
specified in [RFC8559]. When received by the IDP, the Operator-NAS-
Identifier attribute MUST be stored along with any end-user session
identification attributes. When sending a CoA packet for an end-user
session, the IDP MUST include verbatim any Operator-NAS-Identifier it
has recorded for that session.
9.16. Reverse Change of Authorization
The connection management procedures described in Section 7 ensure
that an ANP supporting Reverse CoA is reachable from an IDP whenever
an IDP's OpenRoaming user is active on an ANP's OpenRoaming wireless
network. This reachability allows the IDP, or its authorized hub, to
send a Change of Authorization (CoA) request packet to the ANP in
"reverse" over the existing TLS connection, and for the ANP to send
responses towards the message originator.
* ANPs and hubs supporting OpenRoaming settled SHOULD support the
Reverse CoA in RADIUS/TLS defined in
[I-D.draft-ietf-radext-reverse-coa].
* IDPs supporting OpenRoaming settled operation MAY support the
Reverse CoA in RADIUS/TLS defined in
[I-D.draft-ietf-radext-reverse-coa], where the CoA refers to
either the CoA-Request or Disconnect-Request messages as defined
in [RFC5176].
There is no explicit negotiation of support for Reverse CoA between
OpenRoaming ANPs, hubs and IDPs.
An IDP supporting Reverse CoA SHOULD interpret the lack of response
to a CoA-Request or Disconnect-Request as being due to the silent
discard of the packet by an un-supporting ANP, or an intermediate
hub. The CoA originator SHOULD associate the reverse CoA capability
with each ANP, as identified by the Operator-Name attribute (#126).
The CoA originator that has identified an un-supporting ANP SHOULD
cease sending further Reverse CoA requests to that ANP.
IDPs and hubs supporting Reverse CoA MUST be able to forward the CoA
packet to the correct next hop based on the TLS session used to
support the user-session. When load balancing is employed, the
routing of reverse CoA packets MUST account for the possibility that
multiple CoA servers can be associated with the same Operator-Name
attribute:
Tomas, et al. Expires 14 December 2026 [Page 34]
Internet-Draft WBA OpenRoaming June 2026
* The IDP and hub MUST maintain session affinity or "stickiness" to
the specific TLS session corresponding to the user session, so
that CoA packets are routed to the same server instance that
established the original session.
* The routing logic SHOULD use additional session identification
attributes, such as Charegable-User-Id, Acct-Session-Id, Operator-
Name, Called-Station-Id and/or Operator-NAS-Identifier, to
disambiguate among multiple possible next hops when load balancing
is in effect.
* If multiple TLS sessions exist for the same WBAID due to load
balancing, the IDP SHOULD select the appropriate next hop based on
the user session context to avoid routing CoA packets to an
incorrect CoA server.
* The CoA packet is sent to the next proxy/CoA Server according to
the routing logic. This process continues with any subsequent
proxies until the packet reaches the ANP's CoA server.
IDPs MUST include the Operator-Name attribute in all CoA-Request and
Disconnect-Request packets, as described in [RFC8559]. The value of
the Operator-Name attribute MUST be the value that was recorded
earlier for that user session.
If a proxy/CoA Server receives a CoA packet with an unknown Operator-
Name, the server MUST operate as per [RFC8559] and return a NAK
packet that contains an Error-Cause Attribute having value 502
("Request Not Routable").
The ANP MAY use the Operator-NAS-Identifier as specified in
[RFC8559]. When received by the IDP, the Operator-NAS-Identifier
attribute MUST be stored along with any user session identification
attributes. When sending a CoA packet for a user session, the IDP
MUST include verbatim any Operator-NAS-Identifier it has recorded for
that session.
9.17. Additional Attributes Related to OpenRoaming Settled
OpenRoaming settled defines the use of additional RADIUS attributes.
9.17.1. WBA-Financial-Clearing-Provider
All OpenRoaming ANPs and IDPs that support the OpenRoaming settled
service MUST use the WBA-Financial-Clearing-Provider vendor specific
attribute to signal the identity of the provider of financial
clearing services [WBAVSA].
Tomas, et al. Expires 14 December 2026 [Page 35]
Internet-Draft WBA OpenRoaming June 2026
9.17.2. WBA-Data-Clearing-Provider
All OpenRoaming ANPs and IDPs that support the OpenRoaming settled
service MAY use the WBA-Data-Clearing-Provider vendor specific
attribute to signal the identity of the provider of data clearing
services [WBAVSA].
9.17.3. WBA-Linear-Volume-Rate
In cellular roaming, inter-operator tariff information is exchanged
in the roaming agreements between operators. In OpenRoaming, as
there is no direct agreement between ANPs and IDPs, the tariff
information is exchanged in RADIUS messages. All OpenRoaming ANPs
that support the OpenRoaming settled service MUST use the WBA-Linear-
Volume-Rate vendor specific attribute to signal the charging model
being offered by the ANP [WBAVSA]. An IDP that authorizes an offered
charging model MUST include the agreed WBA-Linear-Volume-Rate in the
Access-Accept packet.
9.17.4. OpenRoaming Session Mediation
OpenRoaming-Settled necessarily requires end-entities, which may
include ANPs, IDPs and/or their respective hub-providers, to be able
to perform session mediation between RADIUS Access-Request/Access-
Accept and RADIUS Accounting-Request messages. This can be performed
using RADIUS attributes Acct-Session-Id (#44) and Acct-Multi-Session-
Id (#50) together with Operator-Name (#126).
To allow for possible non-uniqueness of Acct-Session-Id and/or Acct-
Multi-Session-Id attributes between different Network Access Servers
(NAS) within the same ANP, it is recommended to additionally use the
attribute NAS-Identifier (#32) or NAS-IP-Address (#4) or NAS-
IPv6-Address (#95) or Called-Station-Id (#30) in the matching
process.
10. Security Considerations
10.1. Network Selection and Triggering Authentication
OpenRoaming defines the use of Passpoint with Roaming Consortium
Organization Identifiers. A bit-wise match between an RCOI
configured in the Passpoint profile of an end-user's device and the
RCOI signalled by WLAN equipment will trigger a Passpoint defined
EAP-based authentication exchange. The security associated with the
Passpoint RCOI information element is identical to other PLMN Id and
Realm information elements, allowing an unauthorized system to
configure the OpenRoaming RCOI with the aim of triggering a Passpoint
authentication. Because such an unauthorized system will not have
Tomas, et al. Expires 14 December 2026 [Page 36]
Internet-Draft WBA OpenRoaming June 2026
been issued with a certificate from WBA's PKI, the unauthorized
system is unable to communicate with any other OpenRoaming provider.
In such a scenario, after successive multiple failed authentications,
the device's supplicant SHOULD add the Access Point's BSSID to a deny
list to avoid future triggering of an authentication exchange with
the unauthorized system.
10.2. ANP RadSec Connectivity
The ANP's RadSec client connects to the IDP's RadSec server over the
public Internet. Recommended best practice for firewall deployment
on public Internet facing interfaces SHOULD be followed. Firewall
rules SHOULD permit outbound RadSec traffic (TCP destination port
2083) and allow return traffic for the same TCP connections while
denying any TCP socket initiation from outside of the ANP's network.
10.3. Dynamic Discovery of RadSec Peers
Whereas the dynamic discovery mechanisms specified in [RFC7585]
permit the IDP to use their DNS SRV record to indicate a non-standard
TCP port to be used in a RadSec connection, IDPs SHOULD recognize
that ANP systems may only be configured to permit outbound
connections on the standardized RadSec port of 2083.
OpenRoaming recommends the use of DNSSEC to ensure a dynamically
discovered RadSec server is authoritative for a particular realm or
set of realms. Where this is not possible, e.g., when using dynamic
resolution with the pub.3gppnetwork.org sub-domain, the OpenRoaming
certificate policy [WBAPKICP] permits the configuration of supported
realm(s) in the SubjectAltName of the certificate(s) issued to the
IDP.
An ANP MAY decide to continue with the RadSec establishment, even if
a server cannot prove it is authoritative for a realm. As the ANP's
RadSec client uses a dedicated trust store corresponding to the WBA's
private Certificate Authority, if DNS is hijacked by a third-party
non-federation member who has not been issued a certificate under
WBA's PKI, the subsequent TLS establishment will fail.
In order to prevent denial of service/brute force attacks, IDPs
SHOULD implement intrusion prevention functionality that monitors
systems to identify TLS mutual authentication failures. Monitoring
SHOULD identify source IP addresses that are causing repeated TLS
authentication failures and use firewall functionality to temporarily
block packets from those source IP addresses
Tomas, et al. Expires 14 December 2026 [Page 37]
Internet-Draft WBA OpenRoaming June 2026
10.4. End-User Traffic
The OpenRoaming federation ensures RADIUS traffic is secured between
ANP and IDP and ensures Wi-Fi traffic is protected between the end-
user device and the WLAN equipment of the ANP. The ANP is therefore
able to observe IP traffic to/from end-users who have performed a
successful authentication with their IDP. The OpenRoaming legal
framework (see Appendix C) ensures that the ANP has agreed to the
OpenRoaming Privacy Policy [ORPRIVACY] to correctly handle the
personally identifiable information collected as part of providing
the ANP service.
The Open-Roaming end-user terms and conditions [ORTERMS] ensure that
end-users are aware that the federation does not provide a secure
end-to-end service. The end-user MUST NOT rely on the encryption
delivered by OpenRoaming for providing security of services accessed
using the ANP's Wi-Fi network.
10.5. ANP Inspection of End-User Traffic
All OpenRoaming ANPs MUST implement layer 2 traffic inspection and
filtering, as specified in clause 5.1 of the [PASSPOINT]
specification. ANPs MUST prohibit the delivery of any packet
received from an OpenRoaming device directly to another OpenRoaming
end-user device.
All ANPs MUST use traffic inspection and filtering to help protect
OpenRoaming users from malicious activity on the Internet as well as
possible malicious activity by other authenticated OpenRoaming users.
ANP traffic filtering function SHOULD NOT block ports associated with
Wi-Fi calling, including UDP ports 500 and 4500 used by Internet Key
Exchange (IKE), Internet Security Association and Key Management
Protocol (ISAKMP) and IPSec [RFC7296]. Recommended best practice for
firewall deployment on public Internet facing interfaces SHOULD be
followed, including configuring the traffic inspection and filtering
using information derived from reliable sources of threat
intelligence.
10.6. End-User Location
The OpenRoaming legal framework (see Appendix C) ensures that the IDP
has agreed to the OpenRoaming Privacy Policy [ORPRIVACY] to correctly
handle the location-based personally identifiable information
collected as part of providing the IDP service. Unless the IDP has
agreed a separate privacy policy with the end-user, the IDP MUST only
use location information signalled by an ANP for either:
Tomas, et al. Expires 14 December 2026 [Page 38]
Internet-Draft WBA OpenRoaming June 2026
1. Making service authorization decisions based on the location of
the ANP's wireless network; or
2. Compliance with applicable law, or law enforcement requests.
11. Future Enhancements
WBA announced the launch of its OpenRoaming Federation in June 2020.
Since then, WBA members have continued to enhance the technical
framework to address new market requirements. WBA encourages those
parties interested in adapting OpenRoaming to address new
opportunities and use-cases to join the Alliance and help drive the
definition of OpenRoaming forward.
12. IANA Considerations
This document has no IANA actions.
13. References
13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
13.2. Informative References
[E212] ITU-T Study Group 2, "The international identification
plan for public networks and subscriptions", June 2024,
<https://www.itu.int/itu-t/recommendations/
rec.aspx?rec=E.212>.
[GSMAIR67] GSMA, "GSMA IR.67: DNS Guidelines for Service Providers
and GRX and IPX Providers", 25 November 2022,
<https://www.gsma.com/newsroom/wp-content/
uploads//IR.67-v21.0.pdf>.
Tomas, et al. Expires 14 December 2026 [Page 39]
Internet-Draft WBA OpenRoaming June 2026
[I-D.draft-grayson-connectinfo]
Grayson, M. and J. Redmore, "A syntax for the RADIUS
Connect-Info attribute used in Wi-Fi networks", Work in
Progress, Internet-Draft, draft-grayson-connectinfo-09, 19
May 2026, <https://datatracker.ietf.org/doc/html/draft-
grayson-connectinfo-09>.
[I-D.draft-ietf-radext-reverse-coa]
DeKok, A. and V. Cargatser, "Reverse Change-of-
Authorization (CoA) in RADIUS/(D)TLS", Work in Progress,
Internet-Draft, draft-ietf-radext-reverse-coa-08, 27
August 2025, <https://datatracker.ietf.org/doc/html/draft-
ietf-radext-reverse-coa-08>.
[I-D.ietf-radext-radiusdtls-bis]
Rieckers, J., Cullen, M., and S. Winter, "RadSec: RADIUS
over Transport Layer Security (TLS) and Datagram Transport
Layer Security (DTLS)", Work in Progress, Internet-Draft,
draft-ietf-radext-radiusdtls-bis-16, 5 May 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-radext-
radiusdtls-bis-16>.
[IEEE80211]
IEEE, "Wireless LAN Medium Access Control (MAC) and
Physical Layer (PHY) Specifications", n.d.,
<https://standards.ieee.org/ieee/802.11/5536/>.
[ISO3166] ISO 3166-2:2020, "Codes for the representation of names of
countries and their subdivisions", August 2020,
<https://www.iso.org/standard/72483.html>.
[ISO29115] ISO/IEC 29115, "Information technology - Security
techniques: Entity authentication assurance framework",
April 2013.
[ORPRIVACY]
Wireless Broadband Alliance, "OpenRoaming End-User Privacy
Policy", n.d.,
<https://wballiance.com/openroaming/privacy-policy/>.
[ORTERMS] Wireless Broadband Alliance, "OpenRoaming End User Terms
and Conditions", n.d.,
<https://wballiance.com/openroaming/toc/>.
[PASSPOINT]
Wi-Fi Alliance, "Wi-Fi Alliance Passpoint", n.d.,
<https://www.wi-fi.org/discover-wi-fi/passpoint>.
Tomas, et al. Expires 14 December 2026 [Page 40]
Internet-Draft WBA OpenRoaming June 2026
[PEAP] Microsoft Corporation, "Protected Extensible
Authentication Protocol (PEAP)", April 2024,
<https://winprotocoldocs-bhdugrdyduf5h2e4.b02.azurefd.net/
MS-PEAP/%5bMS-PEAP%5d.pdf>.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, DOI 10.17487/RFC2865, June 2000,
<https://www.rfc-editor.org/rfc/rfc2865>.
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866,
DOI 10.17487/RFC2866, June 2000,
<https://www.rfc-editor.org/rfc/rfc2866>.
[RFC2869] Rigney, C., Willats, W., and P. Calhoun, "RADIUS
Extensions", RFC 2869, DOI 10.17487/RFC2869, June 2000,
<https://www.rfc-editor.org/rfc/rfc2869>.
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
Dial In User Service) Support For Extensible
Authentication Protocol (EAP)", RFC 3579,
DOI 10.17487/RFC3579, September 2003,
<https://www.rfc-editor.org/rfc/rfc3579>.
[RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese,
"IEEE 802.1X Remote Authentication Dial In User Service
(RADIUS) Usage Guidelines", RFC 3580,
DOI 10.17487/RFC3580, September 2003,
<https://www.rfc-editor.org/rfc/rfc3580>.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, Ed., "Extensible Authentication Protocol
(EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004,
<https://www.rfc-editor.org/rfc/rfc3748>.
[RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication
Protocol Method for 3rd Generation Authentication and Key
Agreement (EAP-AKA)", RFC 4187, DOI 10.17487/RFC4187,
January 2006, <https://www.rfc-editor.org/rfc/rfc4187>.
[RFC4372] Adrangi, F., Lior, A., Korhonen, J., and J. Loughney,
"Chargeable User Identity", RFC 4372,
DOI 10.17487/RFC4372, January 2006,
<https://www.rfc-editor.org/rfc/rfc4372>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/rfc/rfc4648>.
Tomas, et al. Expires 14 December 2026 [Page 41]
Internet-Draft WBA OpenRoaming June 2026
[RFC4851] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The
Flexible Authentication via Secure Tunneling Extensible
Authentication Protocol Method (EAP-FAST)", RFC 4851,
DOI 10.17487/RFC4851, May 2007,
<https://www.rfc-editor.org/rfc/rfc4851>.
[RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B.
Aboba, "Dynamic Authorization Extensions to Remote
Authentication Dial In User Service (RADIUS)", RFC 5176,
DOI 10.17487/RFC5176, January 2008,
<https://www.rfc-editor.org/rfc/rfc5176>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/rfc/rfc5280>.
[RFC5448] Arkko, J., Lehtovirta, V., and P. Eronen, "Improved
Extensible Authentication Protocol Method for 3rd
Generation Authentication and Key Agreement (EAP-AKA')",
RFC 5448, DOI 10.17487/RFC5448, May 2009,
<https://www.rfc-editor.org/rfc/rfc5448>.
[RFC5580] Tschofenig, H., Ed., Adrangi, F., Jones, M., Lior, A., and
B. Aboba, "Carrying Location Objects in RADIUS and
Diameter", RFC 5580, DOI 10.17487/RFC5580, August 2009,
<https://www.rfc-editor.org/rfc/rfc5580>.
[RFC5997] DeKok, A., "Use of Status-Server Packets in the Remote
Authentication Dial In User Service (RADIUS) Protocol",
RFC 5997, DOI 10.17487/RFC5997, August 2010,
<https://www.rfc-editor.org/rfc/rfc5997>.
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
Extensions: Extension Definitions", RFC 6066,
DOI 10.17487/RFC6066, January 2011,
<https://www.rfc-editor.org/rfc/rfc6066>.
[RFC6071] Frankel, S. and S. Krishnan, "IP Security (IPsec) and
Internet Key Exchange (IKE) Document Roadmap", RFC 6071,
DOI 10.17487/RFC6071, February 2011,
<https://www.rfc-editor.org/rfc/rfc6071>.
[RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga,
"Transport Layer Security (TLS) Encryption for RADIUS",
RFC 6614, DOI 10.17487/RFC6614, May 2012,
<https://www.rfc-editor.org/rfc/rfc6614>.
Tomas, et al. Expires 14 December 2026 [Page 42]
Internet-Draft WBA OpenRoaming June 2026
[RFC7170] Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna,
"Tunnel Extensible Authentication Protocol (TEAP) Version
1", RFC 7170, DOI 10.17487/RFC7170, May 2014,
<https://www.rfc-editor.org/rfc/rfc7170>.
[RFC7268] Aboba, B., Malinen, J., Congdon, P., Salowey, J., and M.
Jones, "RADIUS Attributes for IEEE 802 Networks",
RFC 7268, DOI 10.17487/RFC7268, July 2014,
<https://www.rfc-editor.org/rfc/rfc7268>.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
2014, <https://www.rfc-editor.org/rfc/rfc7296>.
[RFC7585] Winter, S. and M. McCauley, "Dynamic Peer Discovery for
RADIUS/TLS and RADIUS/DTLS Based on the Network Access
Identifier (NAI)", RFC 7585, DOI 10.17487/RFC7585, October
2015, <https://www.rfc-editor.org/rfc/rfc7585>.
[RFC7593] Wierenga, K., Winter, S., and T. Wolniewicz, "The eduroam
Architecture for Network Roaming", RFC 7593,
DOI 10.17487/RFC7593, September 2015,
<https://www.rfc-editor.org/rfc/rfc7593>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/rfc/rfc8446>.
[RFC8559] DeKok, A. and J. Korhonen, "Dynamic Authorization Proxying
in the Remote Authentication Dial-In User Service (RADIUS)
Protocol", RFC 8559, DOI 10.17487/RFC8559, April 2019,
<https://www.rfc-editor.org/rfc/rfc8559>.
[RFC8952] Larose, K., Dolson, D., and H. Liu, "Captive Portal
Architecture", RFC 8952, DOI 10.17487/RFC8952, November
2020, <https://www.rfc-editor.org/rfc/rfc8952>.
[RFC9364] Hoffman, P., "DNS Security Extensions (DNSSEC)", BCP 237,
RFC 9364, DOI 10.17487/RFC9364, February 2023,
<https://www.rfc-editor.org/rfc/rfc9364>.
[TS23003] 3GPP, "3GPP 23.003: Numbering, addressing and
identification v18.1.0", 28 March 2023,
<https://www.3gpp.org/ftp/Specs/
archive/23_series/23.003/23003-i10.zip>.
Tomas, et al. Expires 14 December 2026 [Page 43]
Internet-Draft WBA OpenRoaming June 2026
[WBAEIPP] Wireless Broadband Alliance, "WBA Enhanced IMSI Privacy
Protection", August 2022,
<https://wballiancec.wpenginepowered.com/wp-
content/uploads/2021/02/IMSI_Privacy_Protection_for_Wi-
Fi_Technical_Specification_v1.1.0_Revision_FINAL.pdf>.
[WBAPKICP] Wireless Broadband Alliance, "WBA PKI Certificate Policy
v4.0.0", April 2024,
<https://wballiance.com/openroaming/pki-repository/>.
[WBAPKICPS]
Wireless Broadband Alliance, "WBA PKI Certificate Practise
Statement v1.0.0", September 2025,
<https://wballiance.com/openroaming/pki-repository/>.
[WBAVSA] Wireless Broadband Alliance, "Vendor Specific Attributes",
n.d., <https://github.com/wireless-broadband-alliance/
RADIUS-VSA>.
Appendix A. Example OpenRoaming Signalling Flow
An example signalling flow for OpenRoaming is illustrated in
Figure 12.
1. In step 1, the WLAN is configured with Passpoint information and
includes configured RCOIs in its beacon.
2. The beacon can only contain 3 RCOIs and so if none of the RCOIs
match a profile provisioned in the device, the device queries
for the list of RCOIs supported.
3. If the list includes an RCOI that matches a configured profile
in the device, then device sends an EAPOL Start message to the
authenticator.
4. The authenticator in the AP/WLC requests the EAP-Identity of the
device.
5. The device responds with its EAP-Identity, which is a user@realm
Network Access Identifier (NAI)
6. The NAS in the WLC/AP embeds the NAI in the user-name attribute
in a RADIUS Access-Request packet and forwards to the configured
RadSec client.
7. The RadSec client recovers the realm from the NAI/user-name
attribute and performs a DNS-based dynamic peer discovery.
Tomas, et al. Expires 14 December 2026 [Page 44]
Internet-Draft WBA OpenRoaming June 2026
8. The RadSec client established an mTLS authenticated TLS session
with the discovered peer using certificates issued by the WBA
PKI.
9. Once TLS is established, the RadSec client forwards the Access-
Request to the RadSec server.
10. If the EAP Server is not co-located with the RadSec server, the
RadSec server proxies the Access-Request to the EAP-Server.
11. The EAP-Server continues the EAP dialogue with the EAP
Supplicant in the end-user device using a Passpoint defined EAP
method.
12. Following successful authentication, the EAP-Server responds
with a RADIUS Access-Accept packet containing the EAP-SUCCESS
message and the keying material generated through the EAP method
to secure the Wi-Fi session.
13. The Access-Accept packet is forwarded back to the RadSec client.
14. The RadSec client forwards the Access-Accept packet to the NAS
in the AP/WLC.
15. The AP/WLC recovers the keying material from the Access-Accept
packet and forwards the EAP-SUCCESS message to the device.
16. The keying material is used to secure the Wi-Fi interface
between the end-user device and AP/WLC.
17. The AP/WLC generates a RADIUS Accounting-Request packet with
Acct-Status-Type Start which is forwarded to the RadSec client.
18. The RadSec client forwards the Accounting-Request packet over
the TLS tunnel to the RadSec server.
19. The RadSec server can forward the Accounting-Request packet to
the EAP-Server.
20-22. After the Wi-Fi session terminates, an Accounting-Request
message with Acct-Status-Type Stop is proxied towards the RadSec
Server.
Tomas, et al. Expires 14 December 2026 [Page 45]
Internet-Draft WBA OpenRoaming June 2026
+------+ +------+ +------+ +------+ +------+ +------+
| | |Wi-Fi | |RadSec| | | |RadSec| | EAP |
|Device| |AP/WLC| |Client| | DNS | |Server| |Server|
+------+ +------+ +------+ +------+ +------+ +------+
| 1) Beacon | | | | |
|<----------| | | | |
| 2) ANQP | | | | |
| Query | | | | |
|<--------->| | | | |
| 3) EAPOL | | | | |
| Start | | | | |
|---------->| | | | |
| 4) EAP-ID | | | | |
| Request | | | | |
|<----------| | | | |
| 5) EAP-ID | 6) RADIUS | | | |
| Response | Access- | 7) DNS | | |
|---------->| Request | Query | | |
| |---------->| NAPTR,SRV,| | |
| | | A/AAAA | | |
| | | Records | | |
| | |<--------->| | |
| | | 8) mTLS | | |
| | |<--------------------->| |
| | | 9) RadSec | | |
| | | Access-Request | |
| | |---------------------->| |
| | | | | 10) RADIUS|
| | | | | Access- |
| | | | | Request |
| | | | |---------->|
| | 11) EAP Dialogue | |
|<--------------------------------------------------------->|
| | | | | 12) RADIUS|
| | | | | Access- |
| | 14) RADIUS| | | Accept |
| | Access- | | | (EAP- |
| | Accept | 13) RadSec Access- | SUCCESS) |
| | (EAP- | Accept (EAP-SUCCESS) |<----------|
| 15) EAP- | SUCCESS) |<----------------------| |
| SUCCESS |<----------| | | |
|<----------| | | | |
+---------------+ | | | |
| 16) Secured | | | | |
| OpenRoaming 17) RADIUS| | | |
| Service Accounting| | | |
| Request | | | 19) RADIUS|
| (Start) | 18) RadSec Accounting | Accounting|
Tomas, et al. Expires 14 December 2026 [Page 46]
Internet-Draft WBA OpenRoaming June 2026
| |-------->| -Request (Start) | Request |
| | |---------------------->| (Start) |
| | | | |---------->|
+---------------+ | | | |
| | 20) RADIUS| | | |
| | Accounting| | | |
| | Request | | | 22) RADIUS|
| | (Stop) | 21) RadSec Accounting | Accounting|
| |---------->| -Request (Stop) | Request |
| | |---------------------->| (Stop) |
| | | | |---------->|
+------+ +------+ +------+ +------+ +------+ +------+
|Device| |Wi-Fi | |RadSec| | DNS | |RadSec| | EAP |
| | |AP/WLC| |Client| | | |Server| |Server|
+------+ +------+ +------+ +------+ +------+ +------+
Figure 12: Example OpenRoaming Signalling Flow
Appendix B. Example OpenRoaming RCOI Usage
This Annex illustrates the use of OpenRoaming RCOIs to enforce
different policies in the OpenRoaming federation, ensuring that when
there is a policy mismatch between the end-user device and access
network, that the end-user device will avoid triggering an
authentication exchange that would subsequently have to be rejected
because of policy enforcement decisions.
B.1. OpenRoaming RCOI Based Policy for Supporting QoS Tiers
Figure 13 illustrates the use of OpenRoaming RCOIs for supporting the
standard (bronze) and silver QoS tiers across the federation. The
figure shows two different devices:
* Device 1 has been provisioned by its IDP to require the basic
bronze QoS policy.
* Device 2 has been provisioned by its IDP to require the silver
tier of QoS handling.
The figure also shows illustrates the RCOI configuration of two ANP
Access Networks:
* ANP#1 is configured to support the silver tier of QoS handling
corresponding to the silver RCOI. Because the network
requirements associated with the silver tier are a superset of the
bronze QoS tier, the ANP also configures the bronze RCOI on its
Wi-Fi access network.
Tomas, et al. Expires 14 December 2026 [Page 47]
Internet-Draft WBA OpenRoaming June 2026
* ANP#2 is only configured to support the standard (bronze) QoS tier
and as such only configures the RCOI corresponding to the bronze
QoS tier on its Wi-Fi access network.
The figure shows how normal Passpoint RCOI matching rules can be used
to ensure that devices only trigger authentication with ANP access
networks which support the required QoS tier according to the
device's policy.
+----------------------+ +----------------------+
|OpenRoaming Device #1 | |OpenRoaming Device #2 |
| Bronze Service Level | | Silver Service Level |
| +------------------+ | | +------------------+ |
| |Passpoint Profile | | | |Passpoint Profile | |
| | Bronze RCOI | | | | Silver RCOI | |
| +------------------+ | | +------------------+ |
| /|\ /|\ | | /|\ |
+------|----------|----+ +------------|---------+
| | | RCOI
| | | Match
| +-----------------------------+
RCOI | | |
Match | | |
| | +------------------------+
| | | RCOI
| | | Match
\|/ \|/ \|/
+----------------------+ +----------------------+
| OpenRoaming ANP#1 | | OpenRoaming ANP#2 |
| Silver QoS | | Bronze QoS |
| +--------------+ | | +--------------+ |
| | WLAN | | | | WLAN | |
| | Bronze RCOI | | | | Bronze RCOI | |
| | Silver RCOI | | | | | |
| +--------------+ | | +--------------+ |
+----------------------+ +----------------------+
Figure 13: Use of OpenRoaming RCOIs to realize QoS policies
B.2. OpenRoaming RCOI Based Policy for Supporting Identity Type
Policies
Figure 14 illustrates the use of OpenRoaming RCOIs for supporting
different identity type policies across the federation. The figure
shows two different devices:
Tomas, et al. Expires 14 December 2026 [Page 48]
Internet-Draft WBA OpenRoaming June 2026
* Device#1 has been provisioned by an IDP corresponding to a service
provider. It provisions the device's Passpoint profile with the
RCOI policy identifying the service provider ID-type policy as
well as the "any ID-type" RCOI policy.
* Device 2 has been provisioned by a IDP corresponding to a
hospitality provider. It provisions the device's Passpoint
profile with the RCOI policy identifying the hospitality ID-type
policy as well as the "any ID-type" RCOI policy.
The figure also shows the RCOI configuration of three different ANP
Access Networks:
* ANP#1 only supports access using service provider type-IDs and so
has configured the service provider ID-type policy RCOI.
* ANP#2 supports access from all identity types and so has
configured the any ID-type policy RCOI.
* ANP#3 only supports access using hospitality type IDs and so has
configured the hospitality ID-type policy RCOI.
The figure shows how normal Passpoint RCOI matching rules can be used
to ensure that devices only trigger authentication with ANP access
networks which support the required identity types according to the
ANP's policy.
Tomas, et al. Expires 14 December 2026 [Page 49]
Internet-Draft WBA OpenRoaming June 2026
+----------------------------+ +-----------------------------+
| OpenRoaming Device #1 | | OpenRoaming Device #2 |
| IDP is Service Provider | | IDP is Hospitality Provider |
|+------------++------------+| |+------------++------------+ |
|| Passpoint || Passpoint || || Passpoint || Passpoint | |
|| Profile || Profile || || Profile || Profile | |
|| SP ||Any ID-Type || ||Any ID-Type || Hospitality| |
||ID-Type RCOI|| RCOI || || RCOI ||ID-Type RCOI| |
|+------------++------------+| |+------------++------------+ |
| /|\ /|\ | | /|\ /|\ |
+-------|------------|-------+ +-------------------|---------+
| | | |
| RCOI | RCOI | RCOI | RCOI
| Match | Match | Match | Match
| | | |
| +-----+ +-----+ |
| | | |
\|/ \|/ \|/ \|/
+------------------+ +------------------+ +------------------+
|OpenRoaming ANP#1 | |OpenRoaming ANP#2 | |OpenRoaming ANP#3 |
| Only accepts | | Accepts all | | Only accepts |
| Service Provider | | ID-Types | | Hospitality |
| ID-Types | | | | ID-Types |
| +--------------+ | | +--------------+ | | +--------------+ |
| | WLAN | | | | WLAN | | | | WLAN | |
| | SP ID-Type | | | | Any ID-Type | | | | Hospitality | |
| | RCOI | | | | RCOI | | | | ID-Type RCOI | |
| +--------------+ | | +--------------+ | | +--------------+ |
+------------------+ +------------------+ +------------------+
Figure 14: Use of OpenRoaming RCOIs to realize ID-Type policies
B.3. OpenRoaming RCOI Based Policy for Supporting Different Identity
Proofing Policies
Figure 15 illustrates the use of OpenRoaming RCOIs for supporting
different identity proofing policies across the federation. The
figure shows two different devices:
* Device 1 has been provisioned by an IDP that uses enhanced
identity proofing controls that meet the enhanced OpenRoaming
requirements, equivalent to LoA 3 in [ISO29115]. Because the
enhanced identity proofing requirements are a superset of the
requirements of the baseline identity proofing policy, the IDP
also configures the use of the RCOI with baseline identity
proofing.
Tomas, et al. Expires 14 December 2026 [Page 50]
Internet-Draft WBA OpenRoaming June 2026
* Device 2 has been provisioned by an IDP that uses identity
proofing with controls that meet the baseline OpenRoaming
requirements.
The figure also shows the RCOI configuration of two ANP Access
Networks:
* ANP#1 is operated in a geography where regulations require support
of enhanced identity proofing.
* ANP#2 is operated in a geography where regulations permit support
of authentications with identities managed using the OpenRoaming
baseline identity proofing requirements.
The figure shows how normal Passpoint RCOI matching rules can be used
to ensure that devices only trigger authentication with ANP access
networks which support the required identity proofing according to
the ANP's policy.
+----------------------------+ +----------------------------+
| OpenRoaming Device #1 | | OpenRoaming Device #2 |
| IDP uses enhanced | | IDP uses baseline |
| identity proofing | | identity proofing |
|+------------++------------+| | +------------+ |
|| Passpoint || Passpoint || | | Passpoint | |
|| Profile || Profile || | | Profile | |
||Enhanced LoA||Baseline LoA|| | |Baseline LoA| |
|| RCOI || RCOI || | | RCOI | |
|+------------++------------+| | +------------+ |
| /|\ /|\ | | /|\ |
+-------|------------|-------+ +--------------|-------------+
| RCOI | RCOI | RCOI
| Match | Match | Match
| +--------------------+ +-----+
| | |
\|/ \|/ \|/
+------------------------+ +------------------------+
| OpenRoaming ANP#1 | | OpenRoaming ANP#2 |
| Operates in a country | | Operates in a country |
| where the regulator | | where the regulator |
| requires enhanced | | permits baseline |
| identity proofing | | identity proofing |
| +--------------+ | | +--------------+ |
| | WLAN | | | | WLAN | |
| | Enhanced LoA | | | | Baseline LoA | |
| | RCOI | | | | RCOI | |
| +--------------+ | | +--------------+ |
+------------------------+ +------------------------+
Tomas, et al. Expires 14 December 2026 [Page 51]
Internet-Draft WBA OpenRoaming June 2026
Figure 15: Use of OpenRoaming RCOIs to realize identity proofing
policies
Appendix C. OpenRoaming Legal Framework
C.1. Seamless Experience
In order for OpenRoaming to avoid the need for end-users to be
presented with and accept legal terms and conditions covering their
use of the Wi-Fi hotspot service, there needs to be a legal framework
in place.
C.2. OpenRoaming Organization
The federation is based on a legal framework that comprises a set of
policies, templated agreements and immutable terms as agreed to by
the WBA and its membership. The framework defines a hierarchy of
roles, responsibilities and relationships that are designed to enable
the federation to scale to millions of Wi-Fi access networks.
Figure 16 shows the relationships between WBA, OpenRoaming Brokers,
who are members of the WBA that have agreed terms with WBA to perform
the OpenRoaming broker role and the OpenRoaming providers.
OpenRoaming brokers agree terms with OpenRoaming Providers that can
act as Access Network Providers (ANPs) and/or Identity Providers
(IDPs). OpenRoaming providers do not have to be members of the WBA
to provide OpenRoaming services. Finally, OpenRoaming IDPs agree
terms with OpenRoaming end-users who then benefit from seamless
authentication onto the Wi-Fi networks deployed by the different
OpenRoaming ANPs.
Tomas, et al. Expires 14 December 2026 [Page 52]
Internet-Draft WBA OpenRoaming June 2026
+----------+
| Wireless |
| Broadband|
| Alliance |
+----------+
/|\ /|\
| |
Agrees terms with
| |
+-----------+ | | +-----------+
|OpenRoaming|<-------+ +------->|OpenRoaming|
|Broker | |Broker |
+-----------+ +-----------+
/|\ /|\ /|\ /|\
| | | |
Agrees terms with Agrees terms with
| | | |
+-----+ +-----+ +-----+ +-----+
| | | |
\|/ \|/ \|/ \|/
+-----------+ +-----------+ +-----------+ +-----------+
|OpenRoaming| |OpenRoaming| |OpenRoaming| |OpenRoaming|
|Access | |Identity | |Identity | |Access |
|Network | |Provider | |Provider | |Network |
|Provider | | | | | |Provider |
+-----------+ +-----------+ +-----------+ +-----------+
/|\ /|\ /|\ /|\
| | | |
Agrees terms with Agrees terms with
| | | |
+-------------+ | | +------------+
| | | |
\|/ \|/ \|/ \|/
+-----------+ +-----------+ +-----------+ +-----------+
|OpenRoaming| |OpenRoaming| |OpenRoaming| |OpenRoaming|
|End-User | |End-User | |End-User | |End-User |
+-----------+ +-----------+ +-----------+ +-----------+
Figure 16: Organization of the OpenRoaming Federation
C.3. OpenRoaming Legal Terms
In OpenRoaming there is no direct agreement between individual ANPs
and individual IDPs or between end-users and ANPs. As a consequence,
OpenRoaming brokers agree to use certain federation-specific terms in
their agreements with OpenRoaming providers.
Tomas, et al. Expires 14 December 2026 [Page 53]
Internet-Draft WBA OpenRoaming June 2026
This arrangement ensures that all ANPs agree to abide by the
OpenRoaming privacy policy [ORPRIVACY] and all end-users agree to
abide by the OpenRoaming end-user Terms and Conditions [ORTERMS].
C.4. ANP Performance Data
ANPs MAY voluntarily share performance data with IDPs related to the
performance of ANP's wireless network used by the IDP's OpenRoaming
end-users. IDPs that do not separately agree to terms with ANP
governing use of performance data MUST solely process collected
performance data for the purposes of provision of the service,
including making service authorization decisions and network
troubleshooting. These IDPs MUST NOT disclose such performance data
to any third party except as necessary for direct network
troubleshooting with the originating ANP.
C.5. Service Abuse
If an ANP detects service abuse by an end-user in contravention of
the end-user Terms and Conditions, the ANP SHOULD record logs
relevant to the abuse and use the email address embedded in the
Subject Alternative Name (SAN) attribute in IDP's issued end-entity
certificate to contact the abuser's IDP, indicating the nature of the
abuse together with any relevant logs. The immutable terms of
OpenRoaming REQUIRE IDPs to make reasonable efforts to address the
service abuse experienced by the ANP, which may include the
withdrawal of the OpenRoaming service from the identified abusive
end-user.
C.6. OpenRoaming Troubleshooting
The immutable terms included in the OpenRoaming templated agreements
require OpenRoaming providers to make reasonable efforts to support
troubleshooting procedures, including monitoring email addresses
shared for troubleshooting purposes.
OpenRoaming defines the following severity levels:
* Severity 1: OpenRoaming service is not available,
* Severity 2: OpenRoaming service is severely impacted,
* Severity 3: OpenRoaming service is partially degraded, and
* Severity 4: Informational.
Tomas, et al. Expires 14 December 2026 [Page 54]
Internet-Draft WBA OpenRoaming June 2026
Prior to escalating any issue with a third party, the initiating
provider should conduct an initial assessment, logging any
troubleshooting steps and recording all logs relevant to the issue.
The initiating provider should designate a contact for handling
troubleshooting and share such with the third-party provider contact
identified via the respective WBA PKI certificate, together with
details of the issue, including its severity.
C.6.1. Issue Response
The third-party shall respond to all escalations raised by initiating
providers. The recommended maximum timeframes for the initial email
response for issue response associated with the OpenRoaming Settled
Service are as follows:
* Severity 1: Email response within 2 days.
* Severity 2: Email response within 4 days.
* Severity 3: Email response within 8 days.
* Severity 4: Email response within 28 days.
This does not preclude a provider unilaterally agreeing to shorter
timeframes for responding to initial issues. The initiating provider
and the third-party shall use reasonable efforts to try and identify
any issues and remediate any problems. Both providers should record
affected systems and attempted resolutions.
C.6.2. Issue Escalation
If the issue cannot be resolved to the acceptance of both providers
within an acceptable timeframe, the provider may escalate the issue
to WBA.
The recommended maximum timeframes before escalations associated with
OpenRoaming Settled Service are escalated to WBA as follows:
* Severity 1: Escalate after 4 working-days of issue non-resolution.
* Severity 2: Escalate after 8 working-days of issue non-resolution.
* Severity 3: Escalate after 28 working-days of issue non-
resolution.
* Severity 4: Escalation is not applicable.
Tomas, et al. Expires 14 December 2026 [Page 55]
Internet-Draft WBA OpenRoaming June 2026
This does not preclude both access network and identity providers
bilaterally agreeing to shorter timeframes for handling issue
escalation.
Escalation includes sharing all logs and correspondence regarding the
issue and attempts at resolution.
C.7. Breach of Contract
Where it can be determined that an End-Entity is in breach of their
contract terms as defined in the OpenRoaming legal framework, WBA
reserves the right to cancel the End-Entity's OpenRoaming enrolment
and revoke any WBA issued certificates.
Changelog
* 01 - added details of WBA-Custom-SLA for OpenRoaming ANP networks
that signal using [RFC7268] that they operate on a vehicular
platform. Added clarifications regarding use of direct and
indirect names in certificate validation.
* 02 - added details of OpenRoaming protection of end-user privacy,
including WRIX recommendations on use of correlation identifiers
in RADIUS Access-Accept packet that may unintentionally weaken
end-user privacy.
* 03 - updated DNSsec reference. Added section on interworking with
other federations.
* 04 - updated PKI Policy OID to reflect new certificate chain.
Added IDP availability requirements. Added session-timeout
requirements. Added new onboarding capabilities for short lived
credentials. Added text concerning OpenRoaming Privacy Policy and
restrictions on location usage.
* 05 - added new section on use of Reply-Message, added new text on
troubleshooting, clarified RADIUS accounting handling, clarified
CUI usage in Access-Accept, clarified use of EAP types.
* 06 - corrected ePDG FQDN. Added missing enhanced Reply-Message
for cause-code = 45. Added new text regarding recommended best
practice for firewall deployment on public Internet facing
interfaces should be followed for ANP RADSEC connections and for
protecting end-users.
Tomas, et al. Expires 14 December 2026 [Page 56]
Internet-Draft WBA OpenRoaming June 2026
* 07 - added details of service abuse handling. Added further
details of RADIUS attributes. Added rationale for busy hour
sustained throughput values. Introduced requirements on minimum
speeds for OpenRoaming bronze and silver tiers. Corrected WBAID
ABNF by adding in permitted special characters.
* 08 - added clarification on the use of "aaa+auth" to identify a
RadSec server that supports both RADIUS authentication and
accounting. Added requirements for reverse CoA and associated
RadSec connection management. Added support for enhanced RADIUS
connect-info for connection instrumentation and authorization.
Acknowledgements
The authors would like to thank all the members of the WBA's
OpenRoaming Workgroup who help define the OpenRoaming specifications.
Authors' Addresses
Bruno Tomas
Wireless Broadband Alliance, Inc.
5000 Executive Parkway, Suite 302
San Ramon, 94583
United States of America
Email: bruno@wballiance.com
Mark Grayson
Cisco Systems
10 New Square Park
Feltham
TW14 8HA
United Kingdom
Email: mgrayson@cisco.com
Necati Canpolat
Intel Corporation
2111 NE. 25th Ave
Hillsboro, 97124
United States of America
Email: necati.canpolat@intel.com
Betty A. Cockrell
Independent
San Antonio,
United States of America
Tomas, et al. Expires 14 December 2026 [Page 57]
Internet-Draft WBA OpenRoaming June 2026
Email: bcbeti@outlook.com
Sri Gundavelli
Cisco Systems
170 West Tasman Drive
San Jose, 95134
United States of America
Email: sgundave@cisco.com
Seb Adamski
IronWiFi
100 E Pine St, Ste 110
Orlando, 32801
United States of America
Email: seb@ironwifi.com
Tomas, et al. Expires 14 December 2026 [Page 58]