RNAA

Resource owner-aware Northbound API Access

Management →
Introduced in Rel-18

RNAA is a 3GPP framework for secure, authorized API access where invocations are aware of and respect the policies of the end-user whose data or resources are being accessed.

Category
Management
Introduced
Rel-18
Where
Services › IMS
Specifications
5 specs
RNAA Description Purpose Related Classification Detected Changes Specifications

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

Part ofNEF

Release Timeline

Detected Changes Across Releases

from 3GPP Change Requests

Specific 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.

Rel-18 20 changes

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

Rel-19 14 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.

SpecificationTitleRelease
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
Patrick Zandl

About the author: Patrick Zandl (b. 1974)

Telecommunications specialist, technology journalist (founder of the Mobil server), and developer who has been running since 2025 — the largest Czech-language resource on AI-assisted programming. Formerly Chief Wizard Architect at Prusa3D and head of development for Turris at CZ.NIC; currently a consultant and instructor on AI implementation in companies.