8 Using Common API Framework

29.5493GPPApplication Programming Interface (API) specificationRelease 18Service Enabler Architecture Layer for Verticals (SEAL)Stage 3TS

8.1 General

When CAPIF is used with a SEAL service, the SEAL server shall support the following as defined in 3GPP TS 29.222 [16]:

– the API exposing function and related APIs over CAPIF-2/2e and CAPIF-3/3e reference points;

– the API publishing function and related APIs over CAPIF-4/4e reference point;

– the API management function and related APIs over CAPIF-5/5e reference point; and

– at least one of the security methods for authentication and authorization, and related security mechanisms.

In a centralized deployment as defined in 3GPP TS 23.222 [17], where the CAPIF core function and API provider domain functions are co-located, the interactions between the CAPIF core function and API provider domain functions may be independent of CAPIF-3/3e, CAPIF-4/4e and CAPIF-5/5e reference points.

When CAPIF is used with a SEAL service, the SEAL server shall register all the features for northbound APIs in the CAPIF Core Function.

8.2 Security

When CAPIF is used for external exposure, before invoking the API exposed by the SEAL server, the VAL server as API invoker shall negotiate the security method (PKI, TLS-PSK or OAUTH2) with CAPIF core function and ensure the SEAL server has enough credential to authenticate the VAL server (see 3GPP TS 29.222 [16], clause 5.6.2.2 and clause 6.2.2.2).

If PKI or TLS-PSK is used as the selected security method between the VAL server and the SEAL server, upon API invocation, the SEAL server shall retrieve the authorization information from the CAPIF core function as described in 3GPP TS 29.222 [16], clause 5.6.2.4.

As indicated in 3GPP TS 33.122 [18], the access to the SEAL APIs may be authorized by means of the OAuth2 protocol (see IETF RFC 6749 [19]), using the "Client Credentials" authorization grant, where the CAPIF core function (see 3GPP TS 29.222 [16]) plays the role of the authorization server.

NOTE 1: In this release, only "Client Credentials" authorization grant is supported.

If OAuth2 is used as the selected security method between the VAL server and the SEAL server, the VAL server, prior to consuming services offered by the SEAL APIs, shall obtain a "token" from the authorization server, by invoking the Obtain_Authorization service, as described in 3GPP TS 29.222 [16], clause 5.6.2.3.2.

The SEAL APIs do not define any scopes for OAuth2 authorization. It is the SEAL server responsibility to check whether the VAL server is authorized to use an API based on the "token". Once the SEAL server verifies the "token", it shall check whether the SEAL server identifier in the "token" matches its own published identifier, and whether the API name in the "token" matches its own published API name. If those checks are passed, the VAL server has full authority to access any resource or operation for the invoked API

NOTE 2: For aforementioned security methods, the SEAL server needs to apply admission control according to access control policies after performing the authorization checks.