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 (73 CRs across 5 releases). Complements the general historical overview above with the evidence-based evolution of this function.
In Release 15, the RNAA (Resource owner-aware northbound API access) function was newly introduced to enable API invokers to obtain authorization from a resource owner, typically a UE user, to access protected resources. This introduction specified a new Resource Owner Function (ROF) and the CAPIF-8 reference point for interaction with the CAPIF core function, enabling the management and revocation of resource owner authorizations. The scope was limited, as interactions over CAPIF-8 and specific ROF procedures were not fully specified within this release.
- Corrections to resource figures TS 29.222CR0040
- Security adaptation for Nnef northbound APIs with CAPIF TS 29.222CR0027
- Correct resource model and add missing functions in CAPIF_Security_API TS 29.222CR0072
- Correct resource model and add missing function in AEF_Authentication_API TS 29.222CR0074
- Correction of definition of obtaining the correct resource in Security APIs TS 29.222CR0086
In Release 16, the RNAA function introduced new capabilities for resource owner authorization, including the authentication of the resource owner and mechanisms to provide, obtain, and revoke their authorization for API invokers to access protected resources. It defined the resource owner function and the CAPIF-8 reference point for these interactions, enabling scenarios where an API invoker on one UE can access resources of another UE with the resource owner's consent. The release also specified business relationships and architectural support for RNAA, distinguishing it from user consent managed by network functions like the UDM.
In Release 17, the new RNAA (Resource owner-aware Northbound API Access) function introduced support for the CAPIF core function to authenticate the resource owner and to provide mechanisms for API invokers to obtain, manage, and revoke that owner's authorization to access protected resources. This enables scenarios where an API invoker on one UE can access resources of another UE or group of UEs with the resource owner's consent. The architecture for RNAA includes a new resource owner function and the CAPIF-8 reference point for interactions between this function and the CAPIF core function's authorization component.
- Support PATCH for the update of an API Provider Domain Registration resource. TS 29.222CR0224
- Support PATCH for the update of an On-boarded API resource TS 29.222CR0225
- Support PATCH for the update of an APF published API resource TS 29.222CR0226
- Corrections to HTTP custom headers handling for Northbound APIs TS 29.222CR0165
- Resource URI correction on CAPIF APIs TS 29.222CR0210
- Resource URI overview and apiVersion placeholder TS 29.222CR0233
+ 1 more changes
In Release 18, the RNAA (Resource owner-aware Northbound API Access) function introduced new capabilities for API invokers to obtain authorization directly from the resource owner, who is a UE user, including support for the authorization code flow. The release specified the integration of RNAA within the CAPIF architecture, introducing the resource owner function and the CAPIF-8 reference point for authorization interactions, and clarified that RNAA applies to both 4G (EPS) and 5G (5GS) networks. It also defined procedures for managing and revoking this authorization, and for discovering API Exposure Functions with owner information.
- API invoker obtaining authorization from resource owner TS 23.222CR0093
- Discover a proper AEF with owner information TS 23.222CR0094
- Reducing resource owner consent inquiry in a nested API invocation TS 23.222CR0095
- 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
+ 20 more changes
In Release 19, the RNAA function introduced new capabilities for managing resource owner authorization, including specific procedures for obtaining and revoking that authorization via the resource owner function. It also expanded support for group-based scenarios, enabling a UE-deployed API invoker to access resources owned by other UEs within a group with proper consent. Furthermore, the release added clarifications and requirements for service API invocation consent and integrated RNAA aspects into the CAPIF security model.
- Requesting of collective resource owner authorization TS 23.222CR0205
- UE-deployed API invoker accessing other UEs’ resources of a group TS 23.222CR0230
- Additional RNAA-related requirements TS 23.222CR0232
- Resource owner consent upon service API invocation TS 23.222CR0233
- Updates to RNAA deployments TS 23.222CR0236
- Procedure for Revoking Resource Owner Authorization TS 23.222CR0243
+ 27 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 |