Standardization Trends of Northbound APIs in 3GPP

2.1 OAuth 2.0

The procedure to obtain user consent on the basis of OAuth 2.0 is specified for RNAA. OAuth 2.0 is a mechanism widely used on websites to protect resources such as when the API is invoked. It is specified in RFC 6749 and other related documents produced by Internet Engineering Task Force (IETF). Several grant types are applicable for OAuth 2.0, and three grant types, i.e., client credentials grant, authorization code grant, and proof key for code exchange (PKCE), are supported for RNAA in 3GPP. In this section, the OAuth 2.0 flow (Fig. 2) based on the authorization code grant is described on the basis of clauses 1.2 and 4.1 of RFC 6749.

Fig. 2. OAuth 2.0 flow.

A client that requests access to the resource (e.g., API) owned by the resource owner (e.g., end user) initiates the flow by directing the resource owner’s user agent (e.g., web browser) to the authorization endpoint inside the authorization server for obtaining the access rights to the API. The authorization server authorizes the resource owner via the user agent, and the resource owner notifies the authorization server to grant the client-access rights. This step for granting the access rights corresponds to the procedure for obtaining user consent in RNAA. The authorization server then redirects the user agent to the client. The client receives an authorization code, a one-time credential, from the user agent as an indication of the resource owner’s permission to grant the access request and sends the code to the authorization endpoint. The authorization server verifies the authorization code and validates the client, and if the result is valid, the authorization server generates an access token and sends it to the client. The client requests accessing the resource server for accessing the resources with the access token. The resource server verifies the access token, and if the request is valid, the client can access the resource on behalf of the resource owner.

2.2 RNAA architecture

3GPP is considering extending the specifications of the Common API Framework (CAPIF) [1–3] for RNAA to enable new use cases for API accessing based on user consent.

The CAPIF allows 3rd party providers to use the functionalities of an operator’s network and has been standardized by 3GPP since Release 15. The main capability of the CAPIF is discovering appropriate northbound APIs. The northbound APIs used by 3rd party operators are provided by the service capability exposure function (SCEF) and network exposure function (NEF) in the Evolved Packet Core (EPC) and 5G Core (5GC) networks. The SCEF/NEF is connected to the network functions of the EPC/5GC of carriers via the southbound interface, and the SCEF/NEF can access the EPC/5GC functionalities (e.g., QoS setting) via this interface on the basis of the request for API call from the 3rd party providers.

RNAA extends the CAPIF specifications by introducing new functional entities, called resource owner client and authorization function, and the related reference points (Fig. 3). The authorization function is inside the CAPIF core function (CCF) in Release 18, and the resource owner client resides on the user equipment.

Fig. 3. RNAA architecture.

The API invoker is the source of an API call, which can be either an operator or 3rd party provider. The API exposing function (AEF) exposes the northbound API called the service API, and the SCEF/NEF corresponds to the AEF. The API publishing function (APF) publishes information of the service APIs to the CCF. The API management function (AMF) manages the published service APIs (e.g., auditing the service API invocation logs received from the CCF). The CCF is the key functional part of the CAPIF and capable of authenticating API invokers, maintaining service API information, and discovering service APIs on the basis of the information. The API invoker can invoke the CAPIF API exposed by the CCF to execute common procedures such as authentication and authorization of the API invoker for invoking the service APIs and discovering APIs.

Although the CAPIF assumes cases in which the CCF and AEF/APF/AMF are provided by different providers, the current RNAA specification assumes that the CCF and AEF/APF/AMF are all provided by the same operator.

2.3 RNAA procedure

In the procedure [3] to obtain user consent for invoking the service API between the API invoker and AEF, the API invoker first calls the CAPIF API exposed by the CCF to authenticate itself to the CCF, which discovers the appropriate API after the API invoker’s authentication. The API invoker then calls the CAPIF API again to negotiate the method for authentication and authorization (i.e., security method) between the API invoker and AEF. If user consent is required, the authorization method used to obtain user consent is expected to be negotiated at this time. The AEF authenticates the API invoker using the negotiated security method, and the authorization server authorizes the API invoker using one of the grant types supported by RNAA (i.e., client credentials grant, authorization code grant, PKCE).