Patent Description:
The present disclosure relates to the field of cellular communications and more particularly related to authenticating application program interface (API) invokers using a common application program interface framework (CAPIF).

In order to meet wireless data traffic demands that have increased after <NUM>th Generation (<NUM>) communication system commercialization, efforts to develop an improved <NUM>th Generation (<NUM>) communication system or a pre-<NUM> communication system have been made. For this reason, the <NUM> communication system or the pre-<NUM> communication system is called a beyond <NUM> network communication system or a post-LTE system.

In order to achieve a high data transmission rate, implementation of the <NUM> communication system in a mmWave band (for example, <NUM> band) is being considered. In the <NUM> communication system, technologies such as beamforming, massive MIMO, Full Dimensional MIMO (FD-MIMO), an array antenna, analog beam-forming, and a large scale antenna are discussed to mitigate a propagation path loss in the mmWave band and increase a propagation transmission distance.

Further, technologies such as an evolved small cell, an advanced small cell, a cloud Radio Access Network (cloud RAN), an ultra-dense network, Device to Device communication (D2D), a wireless backhaul, a moving network, cooperative communication, Coordinated Multi-Points (CoMP), and interference cancellation have been developed to improve the system network in the <NUM> communication system.

In addition, the <NUM> system has developed Advanced Coding Modulation (ACM) schemes such as Hybrid FSK and QAM Modulation (FQAM) and Sliding Window Superposition Coding (SWSC), and advanced access technologies such as Filter Bank Multi Carrier (FBMC), Non Orthogonal Multiple Access (NOMA), and Sparse Code Multiple Access (SCMA).

Currently, the security aspects and respective security information flows of a common application program interface (API) framework (CAPIF) interfaces (CAPIF-<NUM>, CAPIF-1e, CAPIF-<NUM> and CAPIF-2e) are open. Therefore, there is a need for various security methods to support more than one authentication method and a secure interface establishment method/procedure, as the CAPIF will support vast services with different architectural and performance requirements. In view of the foregoing problems, there is a need of system and method for authentication of API Invokers.

<NPL>, is concerned inter alia with a procedure for authentication between an API invoker and an AEF.

Various embodiments provide a system and a method for authenticating API invokers using a common application program interface framework (CAPIF).

Further, various embodiments provide a system and a method for establishing by a CAPIF core function (CCF) a secure connection with at least one API invoker over a CAPIF-1e interface, on receiving a connection request from the at least one API invoker to access at least one service API on a CAPIF-2e interface.

Further, various embodiments provide a system and a method for determining by the CCF at least one security method to be used by the at least one API invoker for a CAPIF-2e interface security (C2eIS) of the at least one API invoker for accessing the at least one service API on a CAPIF-2e interface.

Further, various embodiments provide a system a method to enable the C2eIS for the at least one API invoker based on the determined at least one security method.

Accordingly the embodiments herein provide a method and system for authenticating application program interface (API) invokers using a common application program interface framework (CAPIF). The method includes establishing by a CAPIF core function (CCF) a secure connection with at least one API invoker, on receiving a connection request from the at least one API invoker to access at least one service API on a CAPIF-2e interface, wherein establishing the secure connection between the CCF and the at least one API invoker based on a mutual authentication between the CCF and the at least one API invoker over a CAPIF-1e interface. Further, the method includes determining by the CCF at least one security method to be used by the at least one API invoker for a CAPIF-2e interface security (C2eIS) of the at least one API invoker for accessing the at least one service API on a CAPIF-2e interface, wherein the at least one security method includes at least one of a Transport Layers Security -Pre-Shared Key (TLS-PSK), a TLS-Public Key Infrastructure (TLS-PKI), an Internet Key Exchange version <NUM> (IKEv2), an Internet Protocol Security (IPsec) and an OAuth <NUM>. The method further includes enabling the C2eIS by an API exposing function (AEF) for the at least one API invoker based on the determined at least one security method. The C2eIS includes at least one of an authentication, an interface protection and an authorization.

In an embodiment, the at least one security method is determined by the CCF and indicated to the API Invoker based on at least one of a type of service the API invoker is subscribed, an Interface type between the AEF and the API Invoker, length of the secure TLS sessions required, access scenarios, capability of the API Invoker, capability of the AEF, preferences of the API Invoker and a negotiation between the at least one API invoker and the CCF. In an embodiment, at least one determined security method is also indicated, either solicited or unsolicited, by the CCF to the AEF to perform the determined security method on the CAPIF-2e interface.

In an embodiment, enabling the C2eIS by the AEF, for the at least one API invoker based on the determined at least one security method includes establishing a secure Transport layer security (TLS) connection with the at least one API invoker over the CAPIF-2e interface using a pre-shared key (PSK) received from the CCF, if the determined at least one security method is the TLS-PSK, wherein the PSK is derived by at least one of the at least one API invoker and the CCF after establishing the secure TLS connection between the CCF and the at least one API invoker over the CAPIF-1e interface. Further, receiving authorization rights of the at least one API invoker from the CCF over the CAPIF-<NUM> interface. Further, authorizing the at least one API invoker to access the at least one service API based on the received authorization rights of the at least one API invoker from the CCF.

In an embodiment, enabling the C2eIS by the AEF, the at least one API invoker based on the determined at least one security method includes establishing a secure TLS connection with the at least one API invoker over the CAPIF-2e interface using a client and a server certificate based mutual authentication, if the determined at least one security method is the TLS-PKI. Further, receiving authorization rights of the at least one API invoker from the CCF over the CAPIF-<NUM> interface. Further, authorizing the at least one API invoker to access the at least one service API based on the received authorization rights of the at least one API invoker from the CCF.

In an embodiment, enabling the C2eIS by the AEF, the at least one API invoker based on the determined at least one security method comprises establishing a secure TLS connection with the at least one API invoker over the CAPIF-2e interface using a certificate-based mutual authentication, if the determined at least one security method is the OAuth (Open Authorization: token-based authentication and authorization). Further, receiving a service API access request from the at least one API invoker along with an access token, wherein the access token is generated by the CCF on receiving a OAuth based access token request from the at least one API invoker after establishing the secure TLS connection between the CCF and the at least one API invoker over the CAPIF-1e interface. Further, authorizing the at least one API invoker to access the at least one service API based on the received access token from the at least one API invoker.

In an embodiment, enabling the C2eIS by the AEF, the at least one API invoker based on the determined at least one security method includes establishing a secure TLS connection with the at least one API invoker over the CAPIF-2e interface using a server certificate-based authentication, if the determined at least one security method is the OAuth <NUM>. Further, receiving a service API access request from the at least one API invoker along with an access token, wherein the access token is generated by the CCF on receiving a OAuth <NUM> based access token request from the at least one API invoker after establishing the secure TLS connection between the CCF and the at least one API invoker over the CAPIF-1e interface. Further, authorizing the at least one API invoker to access the at least one service API based on the received access token from the at least one API invoker.

Accordingly the embodiments herein provide a system for authenticating application program interface (API) invokers using a common application program interface framework (CAPIF). The system includes a CAPIF core function (CCF) configured to establish a secure connection with at least one API invoker, on receiving a connection request from the at least one API invoker to access at least one service API on a CAPIF-2e interface, wherein establishing the secure connection between the CCF and the at least one API invoker is based on a mutual authentication between the CCF and the at least one API invoker over a CAPIF-1e interface. Further, the CCF configured to determine at least one security method to be used by the at least one API invoker for a C2eIS of the at least one API invoker for accessing the at least one service API on a CAPIF-2e interface, wherein the at least one security method includes at least one of a Transport Layers Security -Pre-Shared Key (TLS-PSK), a TLS-Public Key Infrastructure (TLS-PKI), an Internet Key Exchange version <NUM> (IKEv2), an Internet Protocol Security (IPsec), an application layer protection, a native authorization mechanism and an OAuth <NUM>. Further, the system includes an API exposing function (AEF) configured to enable the C2eIS for the at least one API invoker based on the determined at least one security method. In an embodiment, the at least one security method is determined based on at least one of a type of service the API invoker is subscribed, Interface details between the AEF and the API Invoker, access scenarios, length of a secure Transport layer security (TLS) sessions required, capability of the API Invoker, capability of the AEF, preferences of the API Invoker and a negotiation between the at least one API invoker and the CCF.

These and other aspects of the example embodiments herein will be better appreciated and understood when considered in conjunction with the following description and the accompanying drawings. It should be understood, however, that the following descriptions, while indicating example embodiments and numerous specific details thereof, are given by way of illustration and not of limitation.

Effects of the present disclosure are not limited to the effects described above. In addition, potential effects expected by a technical feature of the present disclosure may be clearly understood from the following descriptions.

Definitions for certain words and phrases are provided throughout this patent document. Those of ordinary skill in the art should understand that in many, if not most instances, such definitions apply to prior, as well as future uses of such defined words and phrases.

Embodiments herein are illustrated in the accompanying drawings, throughout which like reference letters indicate corresponding parts in the various figures. The embodiments herein will be better understood from the following description with reference to the drawings, in which:.

The example embodiments herein and the various features and advantageous details thereof are explained more fully with reference to the non-limiting embodiments that are illustrated in the accompanying drawings and detailed in the following description. The description herein is intended merely to facilitate an understanding of ways in which the example embodiments herein can be practiced and to further enable those of skill in the art to practice the example embodiments herein. Accordingly, this disclosure should not be construed as limiting the scope of the example embodiments herein.

Hereinafter, various embodiments will be described with reference to the accompanying drawings. However, it should be understood that there is no intent to limit the present disclosure to the particular forms disclosed herein; rather, the present disclosure should be construed to cover various modifications, equivalents, and/or alternatives of embodiments. In describing the drawings, similar reference numerals may be used to designate similar constituent elements.

As used herein, the expression "have", "may have", "include", or "may include" refers to the existence of a corresponding feature (e.g., numeral, function, operation, or constituent element such as component), and does not exclude one or more additional features.

In the present disclosure, the expression "A or B", "at least one of A or/and B", or "one or more of A or/and B" may include all possible combinations of the items listed. For example, the expression "A or B", "at least one of A and B", or "at least one of A or B" may include (<NUM>) at least one A, (<NUM>) at least one B, or (<NUM>) both at least one A and at least one B.

The expression "a first", "a second", "the first", or "the second" used in various embodiments may modify various components regardless of the order and/or the importance but does not limit the corresponding components. For example, a first user device and a second user device indicate different user devices although both of them are user devices. For example, a first element may be termed a second element, and similarly, a second element may be termed a first element without departing from the scope of the present disclosure.

It should be understood that when an element (e.g., first element) is referred to as being (operatively or communicatively) "connected," or "coupled," to another element (e.g., second element), it may be directly connected or coupled directly to the other element or any other element (e.g., third element) may be interposed between them. In contrast, it may be understood that when an element (e.g., first element) is referred to as being "directly connected," or "directly coupled" to another element (second element), there is no element (e.g., third element) interposed between them.

As used herein, the expression "configured to" may be interchangeably used with the expression "suitable for", "having the capability to", "designed to", "adapted to", "made to", or "capable of". The term "configured to" may not necessarily imply "specifically designed to" in hardware. Alternatively, in some situations, the expression "device configured to" may mean that the device, together with other devices or components, "is able to". For example, the phrase "processor adapted (or configured) to perform A, B, and C" may mean a dedicated processor (e.g., embedded processor) only for performing the corresponding operations or a generic-purpose processor (e.g., Central Processing Unit (CPU) or Application Processor (AP)) that can perform the corresponding operations by executing one or more software programs stored in a memory device.

The terms used in the present disclosure are only used to describe specific embodiments, and are not intended to limit the present disclosure. A singular expression may include a plural expression unless they are definitely different in a context. Unless defined otherwise, all terms used herein, including technical and scientific terms, have the same meaning as those commonly understood by a person skilled in the art to which the present disclosure pertains. Such terms as those defined in a generally used dictionary may be interpreted to have the meanings equal to the contextual meanings in the relevant field of art, and are not to be interpreted to have ideal or excessively formal meanings unless clearly defined in the present disclosure. In some cases, even the term defined in the present disclosure should not be interpreted to exclude embodiments.

The embodiments herein achieve a method and system for authenticating application program interface (API) invokers using a common application program interface framework (CAPIF). The method includes establishing by a CAPIF core function (CCF) a secure connection with at least one API invoker, on receiving a connection request from the at least one API invoker to access the at least one service API on a CAPIF-2e interface, wherein establishing the secure connection between the CCF and the at least one API invoker is based on a mutual authentication between the CCF and the at least one API invoker over a CAPIF-1e interface. Further, the method includes determining and indicating by the CCF at least one security method to be used by the at least one API invoker for the C2eIS (i.e., authentication, interface protection and authorization) of the at least one API invoker for accessing the at least one service API on a CAPIF-2e interface, wherein the at least one security method includes at least one of a Transport Layers Security -Pre-Shared Key (TLS-PSK), a TLS-Public Key Infrastructure (TLS-PKI), IKEv2, IPsec and an OAuth. The method further includes enabling the C2eIS by an API exposing function (AEF) the at least one API invoker based on the determined at least one security method. Referring now to the drawings, and more particularly to <FIG>, where similar reference characters denote corresponding features consistently throughout the figures, there are shown example embodiments.

<FIG> illustrates a system <NUM> diagram illustrating CAPIF functional security mechanisms for authenticating, securing the interface and authorizing the API invoker <NUM>, according to an embodiment as disclosed herein.

The system <NUM> includes one or more API invokers <NUM>, <NUM>, a CAPIF core function (CCF) <NUM>, an application program interface exposing function (AEF) <NUM>, API publishing function <NUM> and API management function <NUM>. In an embodiment, the one or more API invokers <NUM>, <NUM> can be at least one of, but not limited to a computer, laptop, mobile phone, personal digital assistants (PAD) and servers or any other device which tries to access the AEF <NUM> for one or more service API's. In embodiment, the one or more API invokers can be configured to invoke one or more service API's present on a network. The CCF <NUM> is a functional entity which can be configured to accumulate all common aspects of service API's. The CCF <NUM> can be configured for authenticating, monitoring, logging authorization, discovery which is common to all the service API's. The AEF <NUM> is the entity which can be configured for exposing the one or more service API's to the API invokers (i.e., for <NUM> and <NUM>). The API invoker <NUM> can have a direct connection with the AEF <NUM> to invoke the service API's. However, the API invoker <NUM> may not have the direct connection with the API publishing function <NUM> and the API management function <NUM>. The API publishing function <NUM> can be configured to publish library of service API's on the CCF <NUM>. Further, the API management function <NUM> can be configured to manage functions related managing of loggings and auditing of logs stored in the CCF <NUM>.

In an embodiment, the API invoker <NUM> which is present in a public land mobile network (PLMN) trust domain is trusted by an operator and the API invoker <NUM> which is present outside the PLMN trust domain may not be trusted by the operator. The API invoker <NUM> which is trusted by the operator may not go through any security checks. However, the API invoker <NUM>, which is present outside the PLMN trust domain may go through more level of security checks.

Further, the system <NUM> includes one or more interfaces /reference points. The one or more interfaces includes a CAPIF-<NUM>, CAPIF-1e, CAPIF-<NUM>, CAPIF-2e, CAPIF-<NUM>, CAPIF-<NUM> and CAPIF-<NUM> interfaces. These interfaces are defined in 3rd Generation Partnership Project (3GPP) TS <NUM> standard and the CAPIF functionality is defined in 3GPP TS <NUM> standard. The CAPIF-<NUM>, the CAPIF-<NUM>, the CAPIF-<NUM>, the CAPIF-<NUM> and the CAPIF-<NUM> interfaces are present within a public land mobile network (PLMN) trust domain while the CAPIF-1e and the CAPIF-2e interfaces are present between the CCF <NUM> and the AEF <NUM> access points for the API Invoker <NUM> present outside of the PLMN trust domain. A security for the CAPIF-<NUM>, the CAPIF-<NUM>, the CAPIF-<NUM>, the CAPIF-<NUM> and the CAPIF-<NUM> interfaces supports Transport Layer security (TLS) as defined in the 3GPP TS <NUM> standard.

Authentication and authorization are required for both the API invokers (i.e., <NUM>, <NUM>) which present within the PLMN trust domain and outside of the PLMN trust domain. To authenticate and authorize the API invoker <NUM> present outside of the PLMN trust domain, the CCF <NUM> must in coordination with the AEF <NUM> and utilizes the CAPIF-1e, the CAPIF-2e and the CAPIF-<NUM> interfaces to onboard to authenticate and authorize the API invoker <NUM> prior to granting an access to CAPIF services/service API's. When the API invoker <NUM> is within the PLMN trust domain, the CCF <NUM> in coordination with the AEF <NUM> can perform authentication and authorization of the API invoker <NUM> via the CAPIF-<NUM>, the CAPIF-<NUM> and the CAPIF-<NUM> interfaces prior to granting access to the CAPIF services.

The CAPIF-<NUM>/<NUM>-e between the API Invoker <NUM> and the CCF <NUM>. Further, the system <NUM> authenticates the API Invoker <NUM> based on the identity and credentials of the API Invoker <NUM> or presenting a valid security token. There is a mutual authentication between the API Invoker and the CCF. Further, the system <NUM> provides authorization for the API Invoker prior to accessing one or more service API's. For the CAPIF-<NUM>/2e between the API Invoker <NUM> and the AEF <NUM>, the system <NUM> authenticates the API Invoker <NUM> based on the identity and credentials of the API invoker <NUM> or presenting the valid security token (OAuth). Further, the system <NUM> provides authorization for the API invoker <NUM> prior to accessing the service API. Further, there is an authorization and verification for the API invoker upon accessing the service API. Further, the system <NUM> controls the service API access based on a PLMN operator configured policies. The CAPIF-1e and the CAPIF-2e are reference points, where the API invoker <NUM> is outside the PLMN trust domain.

The embodiments herein provides a method and system <NUM> for authenticating the API invokers using the CAPIF, the method includes establishing by the CCF <NUM> a secure connection with at least one API invoker <NUM>, on receiving a connection request from the at least one API invoker <NUM> to access the at least one service API on the CAPIF-2e interface. The secure connection is established between the CCF <NUM> and the at least one API invoker <NUM> is based on a mutual authentication between the CCF <NUM> and the at least one API invoker <NUM> over the CAPIF-1e interface. Further, the method includes determining by the CCF <NUM>, at least one security method to be used by the at least one API invoker <NUM> for the C2eIS (i.e., authentication, interface protection and authorization) of the at least one API invoker <NUM> for accessing the at least one service API on the CAPIF-2e interface. The at least one security method includes at least one of a Transport Layers Security -Pre-Shared Key (TLS-PSK), a TLS-Public Key Infrastructure (TLS-PKI),an Internet Key Exchange version <NUM> (IKEv2), an Internet Protocol Security (IPsec), an application layer protection, a native authorization mechanism and an OAuth. Further, the method includes enabling the C2eIS by the AEF <NUM>, for the at least one API invoker <NUM> based on the determined at least one security method. In an embodiment, the at least one security method is determined based on at least one of a type of service the API invoker <NUM> is subscribed, a type Interface between the AEF <NUM> and the API Invoker <NUM>, access scenarios, length of a secure Transport layer security (TLS) sessions required, a capability of the API Invoker <NUM>, capability of the AEF <NUM>, preferences of the API Invoker <NUM> and a negotiation between the at least one API invoker <NUM> and the CCF <NUM>. In an embodiment, the at least one determined security method is also indicated, either solicited or unsolicited, by the CCF <NUM> to the AEF <NUM> to perform the determined security method on the CAPIF-2e interface.

In an embodiment, enabling the C2eIS by the AEF <NUM>, for the at least one API invoker <NUM> based on the determined at least one security method includes, establishing a secure TLS connection between the AEF <NUM> and the at least one API invoker <NUM> over the CAPIF-2e interface using the PSK received from the CCF <NUM>, if the determined at least one security method is the TLS-PSK, wherein the PSK is derived by at least one of the at least one API invoker <NUM> and the CCF <NUM> after establishing the secure TLS connection between the CCF <NUM> and the at least one API invoker <NUM> over the CAPIF-1e interface. Further, receiving authorization rights of the at least one API invoker from the CCF over the CAPIF-<NUM> interface. Further, authorizing the at least one API invoker <NUM> to access the at least one service API based on the received authorization rights of the at least one API invoker <NUM> from the CCF <NUM>.

In an embodiment's, the API Invoker <NUM> discovers/identifies to contact the AEF <NUM> directly for the service API, then the API Invoker <NUM> initiates an authentication with the AEF <NUM> directly. Then, a mutual authentication based on a client and server certificates shall be performed between the API invoker <NUM> and the AEF <NUM> to establish a secure TLS connection with the help of CCF <NUM>. Here, the API invoker <NUM> is pre-configured or provisioned by the CCF <NUM> or during a service discovery and obtains an information that is required for a particular service API. Here, a request needs to be made directly with the AEF <NUM> without contacting the CCF <NUM>, provided the determined security method for the service and related valid security credentials are available with the API invoker <NUM>. Further, the AEF <NUM> may not depend on the CCF to authenticate the API invoker (for example, if the root certificate <NUM> to authenticate the API invoker <NUM> is pre-provisioned/available with the AEF <NUM>). After a successful establishment of the secure TLS connection on the CAPIF-2e between the API Invoker <NUM> and the AEF <NUM>. The AEF <NUM> requests the API Invoker's <NUM> authorization rights from the CCF <NUM> over the CAPIF-<NUM> reference point. Further, the CCF <NUM> responds with the API Invoker's <NUM> authorization rights over the CAPIF-<NUM>. Further, on establishing the secure TLS connection over the CAPIF-2e interface, the API Invoker <NUM> invokes applicable 3GPP northbound APIs/service API. Further, the AEF <NUM> honor's the API invocations based on the authorization rights of the API Invoker <NUM>.

In an embodiment, enabling the C2eISby the AEF <NUM>, for the at least one API invoker based on the determined at least one security method includes establishing a secure TLS connection with the at least one API invoker <NUM> over the CAPIF-2e interface using a client and a server certificate based mutual authentication, if the determined at least one security method is the TLS-PKI. Further, receiving authorization rights of the at least one API invoker <NUM> from the CCF <NUM> over the CAPIF-<NUM> interface. Further, authorizing the at least one API invoker <NUM> to access the at least one service API based on the received authorization rights of the at least one API invoker <NUM> from the CCF <NUM>.

In an embodiment, enabling the C2eISby the AEF <NUM>, for the at least one API invoker <NUM> based on the determined at least one security method comprises establishing a secure TLS connection between the AEF <NUM> and the at least one API invoker <NUM> over the CAPIF-2e interface using at least one of a certificate-based mutual authentication and a server side certificate-based authentication, if the determined at least one security method is the OAuth. Further, receiving a service API access request from the at least one API invoker <NUM> along with an access token, wherein the access token is generated by the CCF <NUM> on receiving a OAuth based access token request from the at least one API invoker <NUM> after establishing the secure TLS connection between the CCF <NUM> and the at least one API invoker <NUM> over the CAPIF-1e interface. Further, authorizing the at least one API invoker <NUM> to access the at least one service API based on the received access token from the at least one API invoker <NUM>.

In an embodiment, the security aspects and relevant information flows proposed for the CAPIF are applicable for other reference points like, T8 interface defined for Machine Type Communication and Service Based Architecture defined for the fifth generation (<NUM>) systems.

<FIG> shows exemplary units of the system <NUM>, but it is to be understood that other embodiments are not limited thereon. In other embodiments, the system <NUM> may include less or more number of units. Further, the labels or names of the units are used only for illustrative purpose and does not limit the scope of the embodiments herein. One or more units can be combined to perform same or substantially similar function in the system <NUM>.

<FIG> illustrates a sequence diagram illustrating a secure channel establishment for authentication and authorization of the API invoker <NUM> over the CAPIF-1e, the CAPIF-2e and the CAPIF-<NUM> reference points using the PSK, according to an embodiment as disclosed herein.

According to <FIG>, the embodiments herein establishes the dedicated secure connection/session for authenticating the API invoker <NUM>. The dedicated secure connection between the API Invoker <NUM> and the AEF <NUM> can be established using two different methods such as the PSK based and the certificate based method. The established dedicated secure session can be used for all API invocations and responses. To establish the dedicated secure session, a PSK can be derived after the successful mutual authentication between the CCF <NUM> and the API invoker <NUM> over the CAPIF-1e interface. Further, the PSK can be used to establish the secure connection (for example, TLS or IPSec) between the API invoker <NUM> and AEF <NUM> over the CAPIF-2e interface. The CAPIF-1e security mechanism can be used to "bootstrap" a key for authenticating the secure TLS connection for the CAPIF-2e. In the absence of the PSK, certificate based mutual authentication between the API invoker <NUM> and AEF <NUM> can be used to establish the secure TLS session over the CAPIF-2e interface.

The <FIG> shows a high-level security information flows between the API invoker <NUM>, the CCF <NUM> and the AEF <NUM> for establishing the secure channel using the PSK (for the access scenario: the API invoker <NUM> access the AEF <NUM> prior to the service API invocation). The security information is exchanged over the CAPIF-1e, the CAPIF-2e and the CAPIF-<NUM> reference points are detailed below in the steps.

At step <NUM>, the method includes establishing the secure TLS session/connection between the API invoker <NUM> and the CCF <NUM> over the CAPIF-1e interface. The method allows the API invoker <NUM> and the CCF <NUM> to establish the secure TLS session/connection between the API invoker <NUM> and the CCF <NUM> over the CAPIF-1e interface. The secure TLS session can be established between the API invoker <NUM> and the CCF <NUM> based on the mutual authentication between the API invoker <NUM> and the CCF <NUM>. The mutual authentication can be certificate based mutual authentication (i.e., mutual authentication based on a client (i.e., API invoker <NUM>) and a server (i.e., CCF <NUM>) certificates).

At step <NUM>, the method includes deriving the PSK over the CAPIF-1e interface. The method allows the API invoker <NUM> and the CCF <NUM> to derive the PSK. After the successful establishment of the secure TLS session, the PSK can be derived based on the TLS Session's master secret, AEF's <NUM> specific parameters, session parameters and other possible parameters. In an embodiment, derivation of the PSK at the CCF <NUM> can be delayed till a request for the PSK is received from the AEF <NUM>. In an embodiment, the PSK is specific to a particular AEF <NUM> (PSK is bound to an AEF ID). The AEF ID is unique identifier at least within the CAPIF. AEFPSK = KDF (TLS Session Master_Secret, TLS Session parameters, AEF ID, <other potential parameters>). The KDF is a Key Derivation Function. AEFPSK and the PSK terms are used interchangeably throughout this document.

At step 3a, the method includes initiating the secure channel establishment (TLS-PSK) request with the AEF <NUM>. The method allows the API invoker <NUM> to initiate the TLS-PSK request with the AEF <NUM>. On deriving the PSK at the API invoker <NUM>, the API invoker <NUM> initiates the secure channel establishment request with the AEF <NUM>. In an embodiment, the API invoker <NUM> may derive the PSK any time before establishing a Secure TLS connection between the API invoker <NUM> and the AEF <NUM>.

At step 3b, the method includes requesting the PSK from the CCF <NUM> derived from the API invoker <NUM> over the CAPIF-<NUM> reference point. The method allows the AEF <NUM> to requests the CCF <NUM> for the PSK derived from the API invoker <NUM> over the CAPIF-<NUM> reference point.

At step 3c, the method includes receiving the PSK from the CCF <NUM> over CAPIF-<NUM> reference point. The method allows the AEF <NUM> to receive the PSK from the CCF <NUM> over CAPIF-<NUM> reference point. The CCF <NUM> can be configured to respond with the derived PSK over CAPIF-<NUM> reference point on receiving the request from the AEF <NUM>. In an embodiment, the CCF <NUM> can derive the PSK and send it to the AEF <NUM> in a notification message without any solicitation from the AEF <NUM>. In such a case, steps 3b and 3c as shown in the <FIG> can be omitted to reduce latency.

At step 3d, the method includes establishing the secure TLS connection between the API invoker <NUM> and the AEF <NUM> using the PSK. The method allows the AEF <NUM> to establish the secure TLS connection between the API invoker <NUM> and the AEF <NUM> using the PSK. The secure TLS connection between the API invoker <NUM> and the AEF <NUM> can be established over the CAPIF-2e interface.

At step <NUM>, the method includes requesting the API invoker's <NUM> authorization rights from the CCF <NUM> over the CAPIF-<NUM> reference point. The method allows the AEF <NUM> to request the API invoker's <NUM> authorization rights from the CCF <NUM> over the CAPIF-<NUM> reference point.

At step <NUM>, the method includes receiving the API Invoker's <NUM> authorization rights from the CCF <NUM> over the CAPIF-<NUM>. The method allows the AEF <NUM> to receive the API invoker's <NUM> authorization rights from the CCF <NUM> over the CAPIF-<NUM> interface.

At step <NUM>, the method includes the API invoker <NUM> invoking applicable 3GPP northbound APIs/service API's with the AEF over the secured CAPIF-2e interface.

At step <NUM>, the method includes authorizing the at least one API invoker <NUM> to access the at least one service API based on the received authorization rights of the at least one API invoker <NUM> from the CCF <NUM>. The method allows the AEF <NUM> to authorize the at least one API invoker <NUM> to access the at least one service API based on the received authorization rights of the at least one API invoker <NUM> from the CCF <NUM>. The AEF <NUM> honors the API invocations based on authorization rights of API invoker <NUM>.

<FIG> illustrates a sequence diagram illustrating the secure channel establishment for authentication and authorization of the API invoker <NUM> over the CAPIF-2e and the CAPIF-<NUM> reference points using certificate based mutual authentication, according to an embodiment as disclosed herein.

The embodiment's herein allows exchange of the security information over the CAPIF-2e and the CAPIF-<NUM> reference points.

At step 1a, the API invoker <NUM> discovers/identifies to contact the AEF <NUM> directly for the service API, then the API invoker <NUM> initiates an authentication with the AEF <NUM> directly. Further, a mutual authentication based on a client and server certificates shall be performed between the API invoker <NUM> and the AEF <NUM> to establish the secure TLS connection with the help of CCF <NUM> (step 1b). In this scenario, the API invoker is pre-configured or provisioned by the CCF <NUM> or during a service discovery and obtains an information that is required for a particular service API. Here, the API invoker <NUM> can directly requests a connection with the AEF without (or after) contacting the CCF <NUM>. After a successful establishment of the secure TLS connection on the CAPIF-2e (i.e., between the API Invoker <NUM> and the AEF <NUM>), the AEF <NUM> requests the API Invoker's <NUM> authorization rights from the CCF <NUM> over the CAPIF-<NUM> reference point. Further, the CCF <NUM> responds with the API Invoker's <NUM> authorization rights over the CAPIF-<NUM> reference point. Further, on establishing the secure TLS connection over the CAPIF-2e interface, the API Invoker <NUM> invokes applicable 3GPP northbound APIs/service API. Further, the AEF <NUM> honor's the API invocations based on the authorization rights of the API Invoker.

<FIG> illustrates a sequence diagram illustrating the secure channel establishment for authentication and authorization of the API invoker <NUM> over the CAPIF-1e and the CAPIF-2e reference points using OAuth based Access Tokens, according to an embodiment as disclosed herein. The embodiments herein establishes the secure channel over the CAPIF-1e interface. The CAPIF-2e reference points uses the access tokens to authorize and honor the API Invoker's <NUM> service API invocations to the AEF <NUM>.

The <FIG> shows the high-level security information flows between the API Invoker <NUM>, the CCF <NUM> and the AEF <NUM>. The security information can be exchanged over the CAPIF-1e, the CAPIF-2e and the CAPIF-<NUM> reference points. The method is based on an OAuth <NUM> authorization framework. With reference to the OAuth <NUM>, the CCF <NUM> maps to authorization and token protocol endpoints. Further, the API Invoker <NUM> maps to a resource owner, client and redirection endpoints and the AEF <NUM> maps to a resource server. Illustration of the authentication and authorization of the API invoker <NUM> over the CAPIF-1e and the CAPIF-2e reference points using Access Tokens is based on an assumption that a client endpoint type is registered as confidential, authorization grant type is a client credentials, the access token is a bearer type (RFC <NUM>) and based on JWT (JSON web token).

At step <NUM>, the method includes establishing by the, API Invoker <NUM> and the CCF <NUM>, a secure TLS session based on the certificate based mutual authentication over the CAPIF-1e interface. The method allows the API Invoker <NUM> and the CCF <NUM> to establish the secure TLS session based on the certificate based mutual authentication.

At step <NUM>, the method includes requesting the access token from the CCF <NUM> using an https request. The method allows the API invoker <NUM> to request the access token from the CCF <NUM> using the https request. After successful establishment of the secure TLS session over the CAPIF-1e, the API Invoker <NUM> requests the access token from the CCF <NUM> using the https request. The https request contains grant type "client_credentials", scope (set of permissions requested), the API Invoker client identifier and secret generated and shared during registration with the CCF <NUM>.

At step <NUM>, the method includes verifying a grant request from the API Invoker <NUM>, for a valid credentials, a request type and a scope requested. The method allows the CCF <NUM> to verify the grant request from the API Invoker <NUM>, for the valid credentials, the request type and the scope requested.

At step <NUM>, the method includes generating the access token. The method allows the CCF <NUM> to generate the access token. Post successful grant request verification by the CCF <NUM>, the access token can be generated. The generated access token can be encoded as a JSON Web Token as defined in IETF RFC <NUM>. The access token may include the JSON web digital signature profile as defined in IETF RFC <NUM>. Further, the access token is shared over the redirect uniform resource identifier (URI), wherein the URI is given by the API Invoker <NUM> during registration with the CCF <NUM>.

At step <NUM>, the method includes establishing the secure TLS connection with the AEF <NUM> using one-way authentication of the AEF <NUM> endpoint based on a server certificate over the CAPIF-2e interface. The method allows the API invoker <NUM> to establish the secure TLS connection with the AEF <NUM> using one-way authentication of the AEF <NUM> endpoint based on the server certificate over the CAPIF-2e interface.

At step <NUM>, the method includes sending an access request/invocation for the 3GPP northbound API/service API along with the access token to the AEF <NUM> over the CAPIF-2e interface (for the access scenario: the API invoker <NUM> access the AEF <NUM> upon the service API invocation). The method allows the API invoker <NUM> to send the access request/invocation for the 3GPP northbound API/service API along with the access token to the AEF <NUM> over the CAPIF-2e interface. The Access token received from the CCF <NUM> can be sent along with API invocation request. The token is placed as "Bearer" property value under "Authorization" header of https request (API invocation).

At step <NUM>, the method includes validating the access token based on a signature which is part of the access token. The method allows the AEF <NUM> to validate the access token based on the signature which is part of the access token. A valid signature, verifies the API Invoker's request against the authorization permissions in the access token.

At step <NUM>, on successful verification of the access token and authorization rights of the API Invoker <NUM>, the requested service API is invoked and an appropriate result is sent as response to API Invoker <NUM>.

In an embodiment, various factors and requirements which can influence applicability of appropriate security method (i.e., PSK and OAuth. However, a business requirements need can be a common factor for selecting the security method, but implementations can use the following criteria in deciding the security method.

Selection criteria for method <NUM> (i.e., PSK based): This method allows for establishment of a dedicated secure session. As the dedicated secure TLS session is established (with authorization during start of session), this can be used for multiple API invocations avoiding authorization verification for every invocation request. This method can be selected based on the following criteria/scenario:
If the secure TLS channel sessions need to be active for long durations (like 12hrs or more), the API Invoker <NUM> uses these sessions for the API invocations over a period of time, without establishing the secure TLS connection for every request.

If there is need for quick burst of the API invocations in short duration (Like <NUM> invocations in <NUM> minutes), the API Invoker <NUM> can use this method to setup dedicated secure TLS session with the AEF <NUM> and avoid authorization verification for every invocation request.

If the API Invoker <NUM> or CAPIF-2e reference point or the AEF <NUM> has stringent requirements like size of the message exchange to be minimized, minimized power consumption or the like. Then the API Invoker <NUM> may select this method.

Selection criteria for method <NUM> (i.e., OAuth): This method is based on the OAuth <NUM> and provides a framework for secure asynchronous API invocation request and response. This method can be selected based on following criteria/scenario:
If the API invocations are sparse and need for secure session is short lived, then the OAuth <NUM> can be selected.

If the resources available on the AEF <NUM> are not adequate to maintain the secure TLS session after authentication, for example, due to network load or authentication and authorization functions are offloaded as a separate network entity. Then the OAuth <NUM> can be selected.

The security methods (either the PSK based or the OAuth or the PKI based or the like) can be determined and selected based on an access scenario, characteristics and constraints on a requested service, interface details (such as IP address/port), status of the reference point, capabilities of the entities, or the like.

<FIG> illustrates a sequence diagram illustrating a procedure flow for authentication between the API Invoker <NUM> and the AEF <NUM> prior to service API invocation, according to an embodiment as disclosed herein.

The embodiments herein allows the API invoker <NUM> to directly contact the AEF <NUM> and authenticates with the AEF <NUM> (no prerequisite are required to perform with the CCF <NUM>). If a service discovery is already performed, then the API Invoker <NUM> requests the CCF <NUM> to provide a Root certificate(s) of a root certificate authority (CA) to verify the AEF Certificate (s) of the AEF <NUM> that the API Invoker <NUM> discovered for subsequent API invocations. The CA may be hosted by an operator or is trusted by the operator. Alternatively, the CCF <NUM> provides the list of Root certificate(s) of the CA to verify the AEF certificate (s) with corresponding AEF <NUM> details (subscribed) to the API Invoker <NUM> at the time of service discovery or at the time of authorization or during authentication or as an independent/exclusive message exchange (request-response).

In an embodiment, during the service discovery procedure, the details about the AEF <NUM> are provided to the API Invoker <NUM> by the CCF <NUM>, in response to the API Invoker <NUM> service discovery request. The details of the AEF <NUM> includes, the security parameters (like, Authentication method, Root certificate of the CA to verify AEF Certificate, Token, lifetime of the security credentials (Token)) and access method (CAPIF based (authentication with CCF before service request) using TLS-PSK or TLS-certificate or Access Token based or TLS-public key cryptography), Third Party Token based). In another embodiment, the API Invoker <NUM> may include its preference on the Authentication method, (for example, based on the foreseen frequency of the service requests) in the service discovery request. On receiving the request from the API Invoker <NUM>, the CCF <NUM> decides the authentication method considering the API Invoker's <NUM> preference and other criteria's. The CCF <NUM> indicates the selected authentication method to the API Invoker <NUM> in response to the request. In an embodiment, the indication (selected Authentication method and reference point protection (interface security)) is included in the secure TLS connection request/protocol.

According to <FIG>, the API Invoker <NUM> authenticates with the AEF <NUM> before invoking Northbound API/service API. In such scenario, security PSK based or the certificate based secure connection establishment methods can be used. The PSK based or the certificate based method illustrates a procedure for the API Invoker <NUM> to authenticate with the AEF <NUM> and establishes the TLS session to secure subsequent API invocations.

<FIG> illustrates a sequence diagram illustrating the Non-CCF (third-party based) authentication procedure, according to an embodiment as disclosed herein. The embodiments herein provides the Non-CCF (third-party based) authentication procedure to secure the interface between the API invoker <NUM> and the AEF <NUM>. In this scenario, the API invoker is preconfigured or provisioned by the CCF <NUM> or during service discovery, obtains the information that required for a particular Service API. Further, the request needs to be made directly with the AEF <NUM> without (or after) contacting the CCF <NUM>.

<FIG> illustrates a sequence diagram illustrating a scenario of determining by the CCF, the mechanisms for authentication and authorization of an API invoker <NUM> by the AEF <NUM> and for secure communication between them, according to an embodiment as disclosed herein.

At step <NUM>, the API invoker <NUM> and the CCF <NUM> establish a secure communication channel, for e.g. TLS using mutual authentication based on the client and the server certificates.

At step <NUM>, the API invoker <NUM> sends a security method request to the CCF <NUM>. The request to the CCF <NUM> includes the API invoker ID, details of the AEF <NUM> such as service details, interface details, northbound API details along with the preferred security method of the API invoker <NUM>.

At step <NUM>, the CCF <NUM> selects a security method to be used by the AEF <NUM> for authentication and authorization of the API invoker <NUM>. The selection takes into account the information received from the API invoker <NUM> in step <NUM>.

In an embodiment, the CCF <NUM>, selects at least one of the PSK based, PKI based, OAuth <NUM>, IKEv2, IPsec, Application layer security, like so based security methods for each requested interface of all the requested AEFs.

In an embodiment, the authentication method can be decided based on at least one of the following parameters: Type of service the API invoker <NUM> subscribed, Interface details (such as IP address/port), Protocol between the AEF <NUM> and the API Invoker <NUM>, when requested for access to a particular service (when multiple services are subscribed), based on time based scenarios (subscribed APIs), based on the need on how long the TLS sessions to be alive, capability of the API Invoker, capability of the AEF <NUM>, based on the request from the API Invoker <NUM> (based on User input, time of usage, number of request known in prior), a particular method is selected by the CCF <NUM> (per AEF or per API Invoker) and indicated to the API Invoker <NUM>.

In an embodiment, the methods for secure communication, authentication and authorization of the API invoker <NUM> by the AEF <NUM> are associated with the service API interface details of the AEF <NUM> i.e. same service API hosted on two or more API interfaces of the same (or different) AEF <NUM>, may have different security methods corresponding to each API interface, if needed by the service. The CCF <NUM> takes such information into consideration when determining the security method.

At step <NUM>, the CCF <NUM>, sends the security method response to the API invoker <NUM> indicating the selected security method for each AEF <NUM> (or each service API interface of the AEF(s)), any security information related to the selected security method (for example, Pre Shared Key for establishment of TLS and/or IPsec directly and/or IPsec via IKEv2, like so). The API invoker <NUM> shall use this selected security method in the subsequent communication establishment with the AEF(s) <NUM>.

<FIG> illustrates a sequence diagram illustrating the API Invoker <NUM> invoking Northbound APIs/service API's using the TLS-PSK method as determined and indicated by the CCF <NUM>, according to an embodiment as disclosed herein.

The CCF <NUM> can send the authentication response to the API Invoker <NUM>. Further, the API Invoker <NUM> sends a Service API invocation request with authentication to the AEF <NUM>. Further, the API Invoker <NUM> information is obtained for the authentication. Further, the AEF identifies verification and authentication based on the PSK. Further, the AEF gives a Service API invocation response to the API Invoker <NUM>.

<FIG> illustrates a sequence diagram illustrating the API Invoker <NUM> invoking Northbound APIs/service API's using access token method as determined and indicated by the CCF <NUM>, according to an embodiment as disclosed herein.

According to <FIG>, the CCF <NUM> shares an authentication response to the API Invoker <NUM> based on an authentication request from the API Invoker <NUM>. Further, the API Invoker <NUM> gives a service API invocation request with the authentication information to the AEF-<NUM><NUM>. Further, the AEF-<NUM><NUM> can be configured to receive the API Invoker <NUM> information for the authentication. Further, AEF-<NUM><NUM> performs identity verification and authentication based on a token presented by the API invoker <NUM> and establishes the secure TLS connection between the API invoker <NUM> and the AEF <NUM>. Further, based on the identity verification and authentication, the AEF-<NUM><NUM> provides a service API invocation response.

The embodiments disclosed herein can be implemented through at least one software program running on at least one hardware device and performing network management functions to control the elements. The elements shown in <FIG> can be at least one of a hardware device, or a combination of hardware device and software module. For example, the embodiments disclosed herein can be implemented in a network entity managing network exposure function (NEF) in a <NUM> core network.

Claim 1:
A method performed by a first entity implementing an authenticating application program interface, API, exposing function, AEF, the method comprising:
receiving (step 3a), from a second entity implementing an API invoker, an authentication request message;
transmitting (step 3b), to a third entity implementing a common application program interface framework, CAPIF, core function, CCF, a security information request for authentication between the first entity and the second entity; and
receiving (step 3c), from the third entity, security information including a pre-shared key, PSK, associated with a security method for authentication between the first entity and the second entity, the PSK being bound to an identity of the first entity,
establishing (step 3d) a transport layer security, TLS, session between the first entity and the second entity using the PSK.