Description
Resource owner-aware Northbound API Access (RNAA) is a security and authorization framework defined in 3GPP Release 18 for the 5G Service-Based Architecture (SBA). It specifically governs how third-party Application Providers (APs) or verticals access network exposure functions, primarily the Network Exposure Function (NEF), to invoke services or query information about a User Equipment (UE) or network resource. The core innovation of RNAA is that the authorization for such API access is not solely based on the agreement between the AP and the network operator, but also incorporates the consent and policies of the end-user (the "resource owner") whose data or network capabilities are the subject of the request.
Architecturally, RNAA involves several key Network Functions (NFs). The NEF acts as the entry point, receiving API requests from the AP. The framework introduces or leverages functions like the Resource Owner-aware Authorization Server (RO-AS), which may be integrated within the operator's domain or be a trusted external entity. When an AP requests an API that involves a user's resource (e.g., "get location of UE-123"), the NEF, in conjunction with the RO-AS, must verify a multi-layered authorization policy. This includes checking the AP's credentials and the service-level agreement, but also validating that the resource owner (the user of UE-123) has granted consent for this specific type of access to this specific AP, potentially with constraints on time, location, or data usage.
The technical workflow involves the use of OAuth 2.0 and OpenID Connect standards, adapted for the 3GPP ecosystem. The resource owner (user) grants consent via a user-facing consent management interface, which results in the issuance of an access token bound to specific scopes (API permissions). The AP presents this token when invoking the NEF API. The NEF or a dedicated policy enforcement point validates the token's authenticity, its associated scopes, and the binding to the target resource. This ensures that API invocations are not just technically permitted but are also privacy-compliant and aligned with user sovereignty over their personal data and network service permissions. RNAA thus embeds the principle of "user-in-the-loop" into the network's northbound interface.
Purpose & Motivation
RNAA was created to address critical privacy, security, and regulatory shortcomings in earlier network exposure paradigms. Initial northbound APIs, while opening network capabilities, primarily relied on a binary trust model between the operator and the third-party application provider. This model did not adequately involve the end-user, whose personal data (location, connectivity status) or network resources (QoS modification) were being accessed or manipulated. This gap raised significant concerns under regulations like the GDPR, which mandate user consent for data processing, and limited the adoption of network APIs for sensitive use cases.
The motivation for RNAA stems from the need to enable innovative vertical applications (e.g., in healthcare, automotive, or smart cities) that require user-specific network information or control, while simultaneously ensuring user privacy and regulatory compliance. It solves the problem of "blind" API access by introducing a standardized, secure, and user-centric authorization layer. Before RNAA, operators might implement proprietary consent mechanisms, creating fragmentation. RNAA provides a unified 3GPP framework that gives users control over how their network data is shared, builds trust, and unlocks new business models where users can dynamically grant or revoke access to applications, fostering a more open and ethical digital ecosystem.
Classification
Detected Changes Across Releases
from 3GPP Change RequestsSpecific changes extracted from the „Change history“ tables of 3GPP specifications (36 CRs across 2 releases). Complements the general historical overview above with the evidence-based evolution of this function.
- Clarification that RNAA is for both 4G and 5G TS 23.222CR0112
- Overview of CAPIF operations for RNAA scenarios TS 23.222CR0114
- Authorization code flow for resource owner-aware northbound api access TS 29.222CR0312
- Update authorization obtaining part to support resource owner-aware northbound API access TS 29.222CR0313
- Update securitymethod data type for Resource owner-aware northbound API access TS 29.222CR0314
- Update CAPIF_Publish_Service_API and CAPIF_API_Provider_Management_API to support RNAA TS 29.222CR0341
+ 14 more changes
- Additional RNAA-related requirements TS 23.222CR0232
- Updates to RNAA deployments TS 23.222CR0236
- Group Information Provisioning in CAPIF to support RNAA TS 23.222CR0265
- Identify the RNAA-related revoked token TS 29.222CR0421
- RNAA and Interconnect aspects in function security model TS 33.122CR0080
- Remove the Note in Functional model description to support RNAA TS 23.222CR0271
+ 10 more changes
Explore further
Broader topics and technologies where RNAA plays a role.
Defining Specifications
3GPP specifications that define or reference RNAA, with the latest known release. Sourced from the 3GPP document catalog — see methodology.
| Specification | Title | Release |
|---|---|---|
| TS 23.222 vk00 | Common API Framework (CAPIF) for 3GPP Northbound APIs | Rel-20 |
| TS 28.849 vj10 | CAPIF Phase2 Charging Study | Rel-19 |
| TS 29.222 vk01 | CAPIF Protocol for 3GPP Northbound APIs | Rel-20 |
| TS 33.122 vj40 | CAPIF Security Architecture Specification | Rel-19 |
| TS 33.700 | 3GPP TR 33.700 | Rel-18 |