Figure 5.1-1 shows the functional security model for the CAPIF architecture. The interfaces CAPIF-1, CAPIF-1e, CAPIF-2, CAPIF-2e, CAPIF-3, CAPIF-4, CAPIF-5, CAPIF-3e, CAPIF-4e, CAPIF-5e, CAPIF-7 and CAPIF-7e are defined in TS 23.222 and support the CAPIF functionality defined in TS 23.222. CAPIF-1, CAPIF-2, CAPIF-3, CAPIF-4, CAPIF-5 and CAPIF-7 are interfaces that lie within the PLMN trust domain while the CAPIF-1e , CAPIF-2e, CAPIF-3e, CAPIF-4e, CAPIF-5e and CAPIF-7e interfaces are CAPIF core and AEF access points for API Invokers outside of the PLMN trust domain. Security for the CAPIF-1, CAPIF-2, CAPIF-3, CAPIF-4, CAPIF-5 and CAPIF-7 interfaces support TLS and are defined in subclauses 6.2, 6.4 and 6.6 of the present document. Security for the CAPIF-1e, CAPIF-2e and CAPIF-7e interfaces support TLS, and are defined in subclause 6.3, subclause 6.5, and subclause 6.9 respectively. Security for the CAPIF-3e, CAPIF-4e and CAPIF-5e interfaces support NDS/IP security to secure communication between different IP security domains. This avoids multiple secure connections between API provider domain and CAPIF core domain by leveraging the NDS/IP security procedures specified in TS 33.210. Authentication and authorization are required for both API invokers that lie within the PLMN trust domain and API invokers that lie outside of the PLMN trust domain. For an API invoker that is outside of the PLMN trust domain, the CAPIF core function in coordination with the API exposing function utilizes the CAPIF-1e, CAPIF-2e and the CAPIF-3 interfaces to onboard, authenticate and authorize the API invoker prior to granting access to CAPIF services. Security flow diagrams for onboarding security, CAPIF-1e security and CAPIF-2e security can be found in Annex B. When the API invoker is within the PLMN trust domain, the CAPIF core function in coordination with the API exposing function performs authentication and authorization of the API invoker via the CAPIF-1, the CAPIF-2 and the CAPIF-3 interfaces prior to granting access to CAPIF services. Authentication and authorization of API invokers (both internal and external to the PLMN trust domain) is specified in clause 6 of the present document.

Figure 5.2-1 shows the functional security architecture of CAPIF framework when RNAA is supported. CAPIF-8 interface connects the ROF with the CCF for transfer of resource owner authorization information and resource owner authorization revocation information. The resource owner can be the user of the UE or the owner of the subscription depending on the use case and regulations. The resource owner function (ROF) may be deployed on the UE. The authorization function is a part of the CCF. The API invoker is the OAuth 2.0 client. The OAuth 2.0 client and the CCF shall communicate using https. Different functional security models can be envisioned for API invoker in relation to the ROF:

• API invoker can be part of the UE and located on the device;
• API invoker can be independent from the UE but still located on the device (e.g., deployed by a third party);
• API invoker can be independent from the UE and located outside of the device (e.g., a game server).

TS 23.222, Figure 6.2.2-1, provides the architectural model for the CAPIF interconnection which allows API invokers of a CAPIF provider to utilize the service APIs from the 3rd party CAPIF provider. CAPIF-6/6e interfaces are interconnecting two CAPIF core functions. CAPIF provider A interconnects with CAPIF provider B via CAPIF-6e, both CAPIF provider A and CAPIF provider B are in different trust domains. The API invoker within its trust domain of CAPIF provider A onboards in CCF of CAPIF provider A. The API invoker within the trust domain of CAPIF provider A interacts with the CAPIF core function of the CAPIF provider A via CAPIF-1. The API invoker within the trust domain of CAPIF provider A discovers the service APIs of both CAPIF provider A and B as defined in clause 8.25.3 of TS 23.222. The API invoker within the trust domain of CAPIF provider A invokes the service APIs in the trust domain of CAPIF provider A via CAPIF-2 and invokes the service APIs in the trust domain of CAPIF provider B via CAPIF-2e. TS 23.222, Figure 6.2.2-2, provides the architectural model for the CAPIF interconnection within the same CAPIF provider domain.