Tech-invite  3GPPspace  IETFspace
◀  ▶  21  22  23  24  25  26  27  28  29  31  32  33  34  35  36  37  38  4‑5x

Content for  TS 23.222  Word version:  19.7.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.36 CCF Obtaining Resource Owner Authorization  8.36.1 General  8.36.2 Information flows  8.36.3 Procedure  8.37 UE-deployed API invoker accessing other UEs' resources  8.37.1 General  8.37.2 Information flows  8.37.3  Procedure  8.38 Open Discover service APIs  8.38.1 General  8.38.2 Information flows  8.38.3 Procedure 
...

 

8.36  CCF Obtaining Resource Owner Authorization |R19|  p. 113

8.36.1  General  p. 113

The procedure in this subclause corresponds to the architectural requirements for CCF obtaining resource owner authorization.

8.36.2  Information flows  p. 113

The information flows for the interactions to obtain RO authorization information from the RO function are part of the Obtain service API authorization procedure described in clause 8.31.2.

8.36.3  Procedure  p. 114

Figure 8.36.3-1 illustrates the procedure for CCF obtaining resource owner authorization.
Pre-condition:
  1. ROF and CCF have successfully completed mutual authentication.
Reproduction of 3GPP TS 23.222, Fig. 8.36.3-1: Procedure for obtaining resource owner authorization
Figure 8.36.3-1: Procedure for obtaining resource owner authorization
Up
Step 1.
The CAPIF core function sends the resource owner authorization information request along with the API invoker information received in the obtaining service API authorization procedure as described in clause 8.31.3.
Step 2.
Authentication of the resource owner is performed as specified in clause 6.5.3.1 of TS 33.122.
Step 3.
The resource owner sends the resource owner authorization information response via ROF to the CAPIF core function along with the resource authorization information as specified in clause 8.31.3.
Step 4.
The CAPIF core function stores the resource owner authorization information.
Up

8.37  UE-deployed API invoker accessing other UEs' resources |R19|  p. 114

8.37.1  General  p. 114

This clause specifies the procedures for API invoker on a UE to be able to access the services exposing resources of other UEs.
The authorization relationship between UE2 (the API invoker is in UE2) and UE1 (the resource owner of the accessed network resources is at UE1) is within the Application Service Provider. The difference of this scenario compared with the procedure of an API invoker obtaining authorization from resource owner described in clause 8.31 is that the API invoker is not deployed in the resource owner's UE.
Up

8.37.2  Information flows  p. 114

8.37.3  Procedure  p. 115

Figure 8.37.3-1 presents the procedure for enabling a UE-hosted API invoker accessing network-hosted resources owned by other UEs for the scenarios introduced in clause 8.37.1.
Pre-condition:
  1. The network hosts individual resource(s) for a UE which can be accessed via AEF provided the necessary security conditions are met.
  2. UE 1 and UE 2 belong to the same CAPIF provider domain. The API invoker knows the RO identifier for UE1.
Reproduction of 3GPP TS 23.222, Fig. 8.37.3-1: UE-deployed API invoker accessing other UEs' resources
Figure 8.37.3-1: UE-deployed API invoker accessing other UEs' resources
Up
Step 1.
The API invoker in UE2 sends an Obtain service API authorization request to the CCF for obtaining permission to access the service API for other UE's (UE1) resources hosted in the network by including the API invoker identity information and any information required for authentication of the API invoker.
The request shall include the RO identity for UE1, whose resources are trying to be accessed, the API invoker information that is requesting the access, and the information about the purpose and scope to be performed on the targeted resources.
Step 2.
The CCF validates and authorizes the API invoker in UE2 as specified in TS 33.122. If the API invoker validation is successful, the CCF checks the Resource Owner authorization information of UE1. The CCF obtains whether the RO (UE1) authorized to the API invoker the access to the network resource(s) for the specified purpose and scope. If the RO authorization information is not available, the CCF may interact with UE1 via ROF to obtain it.
Step 3.
Based on the UE1 resource owner authorization obtained in step 2, the CCF sends an Obtain service API authorization response to the API invoker. The response indicates that UE1, as resource owner, authorizes the service API access for an indicated scope.
Step 4.
The API invoker sends service API invocation request to the API exposing function with the RO authorization information received in step 2.
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 RO authorization information.
Up

8.38  Open Discover service APIs |R19|  p. 116

8.38.1  General  p. 116

The following procedure in this subclause corresponds to supporting open discover service APIs. Such open discovery operation allows requestor to discover service API information about the available set of APIs offered by CCF before onboarding.

8.38.2  Information flows  p. 116

8.38.2.1  Open Service API discover request  p. 116

Table 8.38.2.1-1 describes the information flow open service API discover request from the requestor to the CAPIF core function.
Information element Status Description
Query informationO
(see NOTE)		 Criteria for discovering matching service APIs. It may contain Service API information described in Table 8.3.2.1-1, except service API interface details.
NOTE:
It should be possible to discover all the service APIs.
Up

8.38.2.2  Open Service API discover response  p. 116

Table 8.38.2.2-1 describes the information flow open service API discover response from the CAPIF core function to the requestor.
Information element Status Description
ResultMIndicates the success or failure of the open discovery of the service API information.
Service API informationO
(see NOTE)		 Filtered service APIs information that can be shared to the requestor not a recognized user of the CAPIF. It may contain Service API information described in Table 8.3.2.1-1, except service API interface details.
NOTE:
The service API information shall be present if the Result information element indicates that the open service API discover operation is successful. Otherwise, it shall not be present.
Up

8.38.3  Procedure  p. 116

Figure 8.38.3-1 illustrates the procedure for open discover service APIs.
The open service API discovery mechanism is supported by the CAPIF core function.
Pre-conditions:
  1. The requestor is not a recognized user of the CAPIF.
  2. The CAPIF core function is aware of the Service API information that can be disseminated according to the requestor who is not a recognized user of the CAPIF.
Reproduction of 3GPP TS 23.222, Fig. 8.38.3-1: Open Discover service APIs
Figure 8.38.3-1: Open Discover service APIs
Up
Step 1.
The requestor sends an open service API discover request to the CAPIF core function. It may include the query information from the requestor.
Step 2.
Upon receiving the open service API discover request, if query information is included, the CAPIF core function retrieves the stored service API(s) information as per the query information in the open service API discover request, otherwise all stored service API(s) information is retrieved. Further, since the requestor is not a recognized user of CAPIF, the CAPIF core function performs filtering of service APIs information.
Step 3.
The CAPIF core function sends an open service API discover response to the requestor with the filtered list of service API information.
Up

Up   Top   ToC