Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 23.222  Word version:  19.5.0

Top   Top   Up   Prev   Next
0…   4…   5…   6…   6.3…   6.4…   7…   8…   8.5…   8.8…   8.9…   8.13…   8.17…   8.21…   8.25…   8.26…   8.28…   8.30…   8.33…   8.36…   9…   10…   10.4…   10.7…   11…   A   B…   B.2…   B.3…   C…   D…

 

8.30  Deregistering the API provider domain functions on the CAPIF |R16|p. 105

8.30.1  Generalp. 105

The procedure in this subclause corresponds to the architectural requirements for deregistering the API provider domain functions on the CAPIF. This procedure deregisters the API provider domain functions as authorized users of the CAPIF functionalities.

8.30.2  Information flowsp. 105

8.30.2.1  Deregistration requestp. 105

Table 8.30.2.1-1 describes the information flow, deregistration request, from the API management function to the CAPIF core function.
Information element Status Description
Security informationMInformation for CAPIF core function to validate the deregistration request
Up

8.30.2.2  Deregistration responsep. 105

Table 8.30.2.2-1 describes the information flow, deregistration response, from the CAPIF core function to the API management function.
Information element Status Description
ResultMIndicates the success or failure of the deregistration operation
Up

8.30.3  Procedurep. 105

Figure 8.30.3-1 illustrates the procedure for deregistering API provider domain functions on the CAPIF core function.
Reproduction of 3GPP TS 23.222, Fig. 8.30.3-1: Procedure for deregistration of API provider domain functions on CAPIF
Up
Step 1.
For deregistration of API provider domain functions on the CAPIF core function, the API management function sends a deregistration request to the CAPIF core function.
Step 2.
The CAPIF core function validates the received request and processes the deregistration request.
Step 3.
The CAPIF core function sends a deregistration response message to the API management function.
Step 4.
The API management function processes the deregistration to the individual API provider domain functions.

8.31  API invoker obtaining authorization from resource owner |R18|p. 106

8.31.1  Generalp. 106

CAPIF may authorize the API invoker to invoke the service API based on the authorization information from the resource owner given before the API invocation.
Clause 8.31.3 shows the procedure for obtaining the authorization information.

8.31.2  Information flowsp. 106

8.31.3  Procedurep. 106

Figure 8.31.3-1 illustrates the procedure for API invoker obtaining authorization from resource owner.
Pre-conditions:
  1. The resource owner function (ROF) can communicate with the CCF (Authorization function).
  2. Access to an API exposing function offered service API requires obtaining authorization from a resource owner (RO).
Reproduction of 3GPP TS 23.222, Fig. 8.31.3-1: Procedure for API invoker obtaining authorization from resource owner
Up
Step 1.
The API invoker requests to obtain authorization information to invoke the service API exposed by the API exposing function (AEF) and to access information owned by the resource owner at the AEF through the invocation of an obtain service API authorization request to the CCF. The request contains API invoker information (its identity and optionally application service information such as application service provider and application identifier), the purpose for data processing and any information required for authentication of the API invoker. The request may include resource owner-related finer level service API access requirements (e.g., access per service API operation or access per API service resource) and resource owner-related information the API invoker intends to provide to the AEF at service invocation (i.e., service API data model information elements the API invoker seeks authorization to provide to the AEF).
Step 2.
The CCF performs the authentication of the API invoker (using authentication information). Then the Authorization function determines the authorization by checking the authorization information provided by the RO via the ROF. The request to the ROF contains the request parameters described in step 1.
Step 3.
Based on the RO authorization information obtained via the ROF, the CCF sends an obtain service API authorization response to the API invoker.
Step 4.
The API invoker sends service API invocation request to the API exposing function with the authorization information received from CCF (Authorization function) in step 3.
Step 5.
The API invoker receives the service API invocation response resulting from the service API invocation once the API exposing function has checked whether the API invoker is authorized to invoke that service API based on the authorization information received from CCF (Authorization function).
Up

8.32  Reducing authorization information inquiry in a nested API invocation |R18|p. 108

8.32.1  Generalp. 108

The nested API invocation scenario is a scenario where an API invocation towards a first API exposing function triggers that API exposing function to request an API invocation towards a second API exposing function, which is in the same API provider domain as the first API exposing function. This scenario addresses the situation in which a service API may require the services of other service APIs. For example, if the API invoker invokes SEAL SS_LocationInfoRetrieval API (clause 9.4.4 of TS 23.434), the location management server (acting as an API exposing function for the API invoker and as an API invoker for the NEF) may invoke NEF API to retrieve UE location information from 5GC. In this scenario, the CAPIF may reduce the authorization information inquiries for a nested API invocation using procedure described in clause 8.32.3.
Up

8.32.2  Information flowsp. 108

8.32.3  Procedurep. 108

Figure 8.32.3-1 illustrates the procedure to obtain authorization information in a nested API invocation, in which an API exposing function receiving the service API invocation request interacts with another API exposing function to provide the service.
Pre-conditions:
  1. The resource owner function can communicate with the API invoker.
  2. The API exposing functions 1 and 2 are in the same trust domain.
Reproduction of 3GPP TS 23.222, Fig. 8.32.3-1: Procedure for obtaining authorization information in a nested API invocation
Up
Step 1.
The API invoker requests authorization information to invoke the service API exposed by API exposing function 1.
Step 2.
The API invoker sends a service API invocation request to API exposing function 1 with the authorization information received in step 1.
Step 3.
Based on the service API invocation request, API exposing function 1 decides to invoke another service API exposed by API exposing function 2.
Step 4.
API exposing function 1, acting as an API invoker, obtains from the CCF the authorization information to access the service API exposed by API exposing function 2.
Step 5.
API exposing function 1, acting as an API invoker sends a service API invocation request to API exposing function 2 with the authorization information received in step 4.
Step 6.
The API exposing function 1 receives the service API invocation response resulting from the service API invocation once API exposing function 2 has checked whether the API invoker is authorized to invoke that service API based on the authorization information.
Step 7.
The API invoker receives the service API invocation response resulting from the service API invocation.
Up

Up   Top   ToC