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.36  CCF Obtaining Resource Owner Authorization |R19|p. 114

8.36.1  Generalp. 114

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

8.36.2  Information flowsp. 114

8.36.3  Procedurep. 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
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.
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. 115

8.37.1  Generalp. 115

This clause specifies the procedures for API invoker on a UE to be able to access the services exposing resources of other UEs.
The following scenarios are supported:
  1. Obtaining resource owner authorization information by the API invoker when the authorization relationship between UE2 (the API invoker is in UE2) and UE1 (UE1 is the resource owner of the accessed network resources) is in the application. The difference with the procedure described in clause 8.31 is that the API invoker is deployed in a UE different to the resource owner UE.
  2. Obtaining resource owner authorization information by the API invoker when the authorization relationship between UE2 (the API invoker is in UE2) and UE1 (UE1 is the resource owner of the accessed network resources) is in the CAPIF provider domain. The difference with the procedure described in clause 8.31 is that the API invoker is deployed in a UE different to the resource owner UE and the API invoker needs to provide in the request, in addition to the identity of the resource owner, the identity of the UE accessing to resource owner's resources.
Up

8.37.2  Information flowsp. 115

8.37.3  Procedurep. 116

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 in UE2 knows the RO identifier for UE1.
  3. The CCF may have stored the resource owner authorization information for UE1 (e.g. whether UE2 is allowed to access to UE1 network resources).
Reproduction of 3GPP TS 23.222, Fig. 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. Alternatively, the request shall include the identity of UE2.
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 UE1 authorized to the API invoker the access to the network resource(s) for the specified purpose and scope. If the UE2 identity (as API invoker) was received in step 1, the CCF shall additionally validate whether UE2 is authorized by UE1. 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. 117

8.38.1  Generalp. 117

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 flowsp. 117

8.38.2.1  Open Service API discover requestp. 117

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 responsep. 117

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  Procedurep. 117

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
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, the CAPIF core function retrieves the stored service API(s) information as per the query information in the open service API discover request. 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