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.
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.
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:
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.
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.
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:
The network hosts individual resource(s) for a UE which can be accessed via AEF provided the necessary security conditions are met.
UE 1 and UE 2 belong to the same CAPIF provider domain. The API invoker in UE2 knows the RO identifier for UE1.
The CCF may have stored the resource owner authorization information for UE1 (e.g. whether UE2 is allowed to access to UE1 network resources).
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.
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.
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.
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.
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.
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.
Indicates the success or failure of the open discovery of the service API information.
Service API information
O
(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.
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:
The requestor is not a recognized user of the CAPIF.
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.
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.