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
Release Timeline
Detected Changes Across Releases
from 3GPP Change RequestsSpecific changes extracted from the „Change history“ tables of 3GPP specifications (34 CRs across 2 releases). Complements the general historical overview above with the evidence-based evolution of this function.
In Release 18, the Resource owner-aware Northbound API Access (RNAA) function was formally introduced to the CAPIF architecture, enabling API invokers to obtain authorization from a resource owner before accessing their resources via Service APIs. The release specified the architectural model and functional security details for RNAA, including support for both 4G and 5G networks, and defined procedures for authorization flows and token revocation initiated by the CAPIF core function. Key technical additions encompassed updates to the CAPIF_Publish_Service_API and CAPIF_API_Provider_Management_API, along with alignment of security aspects in TS 33.122.
- 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
In Release 19, the RNAA (Resource owner-aware Northbound API Access) function was enhanced with new capabilities including Group Information Provisioning in CAPIF and support for service API discovery based on supported OAuth grant types. The release also completed the RNAA functional model and removed previous architectural limitations and notes, such as the dependency on 5G networks, clarifying RNAA's applicability to both 4G and 5G. Furthermore, updates were made to RNAA deployment procedures, authorization corrections, and the mechanism for the CAPIF core function to revoke an API invoker's authorization in RNAA scenarios.
- 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
+ 8 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 vj80 | Common API Framework for 3GPP Northbound APIs | Rel-19 |
| TS 28.849 vj10 | CAPIF Phase2 Charging Study | Rel-19 |
| TS 29.222 vj40 | Common API Framework (CAPIF) for 3GPP Northbound APIs | Rel-19 |
| TS 33.122 vj20 | Security Architecture for CAPIF | Rel-19 |
| TS 33.700 | 3GPP TR 33.700 | Rel-18 |