Patent Description:
To meet the demand for wireless data traffic having increased since deployment of 4th generation (<NUM>) communication systems, efforts have been made to develop an improved 5th generation (<NUM>) or pre-<NUM> communication system. The <NUM> or pre-<NUM> communication system is also called a 'beyond <NUM> network' or a 'post long term evolution (LTE) system'. To decrease propagation loss of the radio waves and increase the transmission distance, beamforming, massive multiple-input multiple-output (MIMO), full dimensional MIMO (FD-MIMO), array antenna, analog beamforming, and large scale antenna techniques are discussed with respect to <NUM> communication systems. In the <NUM> system, hybrid frequency shift keying (FSK) and Feher's quadrature amplitude modulation (FQAM) and sliding window superposition coding (SWSC) as an advanced coding modulation (ACM), and filter bank multi carrier (FBMC), non-orthogonal multiple access (NOMA), and sparse code multiple access (SCMA) as an advanced access technology have been developed.

The Internet of everything (IoE), which is a combination of the loT technology and the big data processing technology through connection with a cloud server, has emerged. As technology elements, such as "sensing technology", "wired/wireless communication and network infrastructure", "service interface technology", and "security technology" have been demanded for loT implementation, a sensor network, a machine-to-machine (M2M) communication, machine type communication (MTC), and so forth have been recently researched.

In line with this, various attempts have been made to apply <NUM> communication systems to loT networks. Application of a cloud RAN as the above-described big data processing technology may also be considered to be as an example of convergence between the <NUM> technology and the loT technology.

<NPL> discloses a common approach for API development within 3GPP, corresponding solutions for the CAPIF for 3GPP northbound APIs.

The embodiments herein is to provide a method and system for secure on-boarding of application programming interface (API) invoker of on-boarding devices to a Common API Framework (CAPIF) Core function (CCF) server.

Provided is an API invoker and a CAPIF core function server for performing an onboarding as defined by the appended set of claims.

This method is 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:.

According to an embodiment of the disclosure, an API invoker of performing an on-boarding, the API invoker includes a transceiver; and a processor coupled with the transceiver and configured to: obtain, from a service provider, onboarding information including an onboarding credential and information of a CAPIF core function, establish a secure session with the CAPIF core function based on the onboarding information and control the transceiver to: transmit, to the CAPIF core function, an onboard API invoker request message along with the onboarding credential and receive an onboard API invoker response message based on a result of a validating the onboarding credential at the CAPIF core function.

The processor may be further configured to: generate a key pair including a private key and a public key, and provide the public key along with the onboard API invoker request message.

The information of the CAPIF core function may include an address and root CA certificate.

The onboard API invoker response message may include an assigned API invoker ID, authentication and authorization information and API invoker's certificate.

The onboarding credential may include an OAuth <NUM> access token.

The service provider may include an AEF (API exposing function), APF (API publishing function) and AMF (API management function).

The onboard API invoker request message includes a list of APIs in which the API invoker intends to invoke.

The onboard API invoker response message includes a list of APIs allowed to invoke.

In response to a certificate of the API invoker being issued by a certificate authority, the onboard API invoker request message includes the certificate.

According to another embodiment of the disclosure, a CAPIF core function of performing an onboarding, the CAPIF core function includes a transceiver; and a processor coupled with the transceiver and configured to: establish a secure session with an API invoker based on onboarding information including an onboarding credential, control the transceiver to receive, from the API invoker, an onboard API invoker request message along with the onboarding credential, validate the onboarding credential, and control the transceiver to transmit an onboard API invoker response message based on a result of a validating the onboarding credential.

The processor may be further configured to: in response to a validation of the on-boarding credential being successful, generate an API invoker profile including authentication and authorization information between the API invoker and the AEF.

In response to a certificate of the API invoker being issued by a certificate authority and the certificate authority being determined to be trusted, the API invoker profile may include the certificate.

According to another embodiment of the disclosure, a method of performing an on-boarding, by an API invoker, the method includes: obtaining, from a service provider, onboarding information including an onboarding credential and information of a CAPIF core function; establishing a secure session with the CAPIF core function based on the onboarding information; transmitting, to the CAPIF core function, an onboard API invoker request message along with the onboarding credential; and receiving an onboard API invoker response message based on a result of a validating the on-boarding credential at the CAPIF core function.

According to another embodiment of the disclosure, a method of performing an on-boarding, by an CAPIF core function, the method includes: establishing a secure session with an API invoker based on onboarding information including an onboarding credential; receiving, from the API invoker, an onboard API invoker request message along with the onboarding credential; validating the onboarding credential; and transmitting an onboard API invoker response message based on a result of a validating the onboarding credential.

As is traditional in the field, embodiments may be described and illustrated in terms of blocks which carry out a described function or functions. These blocks, which may be referred to herein as managers, units, modules, hardware components or the like, are physically implemented by analog and/or digital circuits such as logic gates, integrated circuits, microprocessors, microcontrollers, memory circuits, passive electronic components, active electronic components, optical components, hardwired circuits and the like, and may optionally be driven by firmware and software. The circuits may, for example, be embodied in one or more semiconductor chips, or on substrate supports such as printed circuit boards and the like. The circuits constituting a block may be implemented by dedicated hardware, or by a processor (e.g., one or more programmed microprocessors and associated circuitry), or by a combination of dedicated hardware to perform some functions of the block and a processor to perform other functions of the block. Each block of the embodiments may be physically separated into two or more interacting and discrete blocks without departing from the scope of the disclosure. Likewise, the blocks of the embodiments may be physically combined into more complex blocks without departing from the scope of the disclosure.

The accompanying drawings are used to help easily understand various technical features and it should be understood that the embodiments presented herein are not limited by the accompanying drawings. As such, the present disclosure should be construed to extend to any alterations, equivalents and substitutes in addition to those which are particularly set out in the accompanying drawings.

The terms "CAPIF core function entity", "CAPIF core function", "CCF", "CCF entity" and CCF server are used interchangeably in the disclosure. The CCF provides mechanisms (e.g. publish service APIs, authorization, logging, charging) to support service API operations.

The terms 'service provider' and 'API provider domain' mean same and refer to the service API provider domain. The terms are used interchangeably throughout the document and related drawings.

3rd Generation Partnership Project (3GPP) has defined a common API framework to support 3GPP Northbound APIs with common functional aspects such as authentication, authorization, discovery, registration, monitoring etc. Further, 3GPP TS <NUM> defines a functional architecture and information flows for the common API framework. The specification of the 3GPP TS <NUM> defines functional entities such as API invoker (AI) and Common API Framework (CAPIF) Core function (CCF) entity along with service provider domain functions such as API Exposing Function (AEF), API publishing function (APF) and API management function (AMF). The specification also defines the reference points between the functional entities - CAPIF-<NUM> / CAPIF-1e reference points between AI and CCF, CAPIF-<NUM> / CAPIF-2e between the AI and the AEF, CAPIF-<NUM> reference points between the CCF and the AEF, CAPIF-<NUM> reference points between the CCF and the APF, and CAPIF-<NUM> reference points between the CCF and AMF.

In order to access APIs (Framework APIs and Service APIs), the API invoker first needs to be on-boarded to the common API Framework. The on-boarding process involves obtaining, from CAPIF, an ID of the API invoker, authentication information, authorization information etc., which are necessary to access the APIs.

<FIG> is example scenario illustrating a functional model for the CCF server <NUM>. In an example, the on-boarding device 100a within a PLMN trust domain interacts with the CAPIF server <NUM> via the CAPIF-<NUM> and the CAPIF-<NUM>. The on-boarding device 100b from outside the PLMN trust domain interacts with the CAPIF server <NUM> via CAPIF-1e and CAPIF-2e. The API exposing function, the API publishing function and the API management function of the API provider domain (together known as API provider domain functions) within the PLMN trust domain interacts with the CCF server <NUM> via CAPIF-<NUM>, CAPIF-<NUM> and CAPIF-<NUM> respectively.

Accordingly, the embodiments herein achieve a method for handling secure on-boarding of at least one on-boarding device. The method includes determining, by the at least one on-boarding device, at least one of a symmetric key-pair, a client certificate associated with an API invoker, and enrollment information associated with the at least one API invoker. Further, the method includes establishing, by the at least one on-boarding device, a TLS session with a CCF server. Further, the method includes sending, by the at least one on-boarding device, an onboard API invoker request to the CCF using the TLS session to onboard the at least one on-boarding device. The onboard API invoker request includes at least one of the symmetric key-pair, the client certificate associated with the API invoker, OAuth <NUM> access token, and the enrollment information. Further, the method includes validating, by the CCF server, the at least one of the symmetric key-pair, the client certificate associated with the API invoker, OAuth <NUM> access token, and the enrollment information associated with the API invoker. Further, the method includes generating, by the CCF server, an API invoker profile in response to successful validation of the at least one of the symmetric key-pair, the client certificate associated with the API invoker, OAuth <NUM> access token, and the enrollment information. Further, the method includes sending, by the CCF server, an onboard API invoker response comprising the API invoker profile to the at least one on-boarding device. Further, the method includes configuring, by the API invoker of the at least one on-boarding device, the API invoker profile to enable the at least one on-boarding device to access services provided by the CCF server and a service provider.

Unlike conventional methods, the proposed method can be used to establish the service contract by the API invoker and a service provider. Further, the method can be used to provide the API invoker with the on-boarding information by the service provider. Further, the CCF server verifies the validity (verifies the authenticity) of the on-boarding information and provides the API invoker with API invoker profile (i.e. information necessary for accessing the APIs (e.g., framework APIs and service APIs)) securely according to the proposed method. This provisions the API invoker to access the services provided by the CCF server and service provider. This enables API invoker to consume CCF server and the service provider services through the framework and the service APIs securely and effective manner.

Various embodiments of the proposed method is adopted in the 3GPP TS <NUM> and 3GPP TS <NUM>. The method allows for a systematic way of authorizing onboarding request from the API invoker and establish a security context between API invoker to be on boarded and CCF server to conduct onboarding process.

<FIG> illustrates a system <NUM> for handling secure on-boarding of an on-boarding device <NUM>, according to the embodiments as disclosed herein. In an embodiment, the system <NUM> includes an on-boarding device <NUM>, a service provider <NUM>, and a CCF server <NUM>. The on-boarding device <NUM> can be, for example but not limited to, an internet of things (IoT) devices, a cellular device, a smart watch or the like.

In an embodiment, the on-boarding device <NUM> is configured to determine at least one of a symmetric key-pair, a client certificate associated with an API invoker, an OAuth <NUM> access token, and enrolment information associated with the at least one On-boarding device <NUM>. In an embodiment, the enrollment information is obtained from the service provider <NUM> based on a service API contract between the service provider <NUM> and the API Invoker. In an embodiment, the symmetric key-pair is generated by the On-boarding device <NUM>. In an embodiment, the client certificate associated with the API invoker is obtained from a third party (not shown).

In an embodiment, the enrollment information includes at least one of information about the CCF server <NUM> comprising at least one of a CCF server address, a CCF server identity and certificate, and a root certificate to validate the CCF server certificate for a client/server verification, a private-public key pair with a certificate for the API invoker, security credentials for on-boarding, and an OAuth <NUM> access token.

Further, the on-boarding device <NUM> is configured to establish a TLS session with the CCF server <NUM>. Based on the TLS session, the on-boarding device <NUM> is configured to send an onboard API invoker request to the CCF server <NUM> to onboard the at least one on-boarding device <NUM>. The onboard API invoker request includes at least one of the symmetric key-pair, the client certificate, and the enrolment information.

The CCF server <NUM> receives the onboard API invoker request and the CCF server <NUM> is configured to validate the at least one of the symmetric key-pair, the client certificate, and the enrollment information. The CCF server <NUM> is configured to generate an API invoker profile in response to successful validation of the at least one of the symmetric key-pair, the client certificate, and the enrollment information. Further, the CCF server <NUM> is configured to send an onboard API invoker response comprising the API invoker profile to the at least one on-boarding device <NUM>.

After receiving the API invoker profile, the On-boarding device <NUM> configures the API invoker profile to enable the at least one on-boarding device <NUM> to access services provided by the CCF server <NUM> and the service provider <NUM>.

In an embodiment, the API invoker profile includes information about at least one of: an identity of the API invoker to be used to invoke the API framework, the at least one of APIs, and service APIs, a private-public key pair with a certificate signed by the CCF for the API invoker for a IDAI-CCF, a certificate for the API invoker for an identity IDAI-CCF or IDAI-SP which is digitally signed by the service provider or a CAPIF certificate authority or a trusted certificate authority, and authentication and authorization information for allowed service APIs.

<FIG> illustrates various component of the on-boarding device <NUM>, according to the embodiments as disclosed herein. In an embodiment, the on-boarding device <NUM> includes an on-boarding device <NUM>, a processor <NUM>, a memory <NUM>, and a communicator <NUM>. The processor <NUM> is coupled with the memory <NUM> and the communicator <NUM>.

In an embodiment, the processor <NUM> is configured to determine at least one of the symmetric key-pair, the client certificate associated with the API invoker, and the enrolment information associated with the API Invoker <NUM>. Further, the processor <NUM> is configured to establish the TLS session with the CCF server <NUM>. Based on the TLS session, the processor <NUM> is configured to send the onboard API invoker request to the CCF server <NUM> to onboard the On-boarding device <NUM>. Further, the processor <NUM> is configured to receive the onboard API invoker response comprising the API invoker profile from the CCF server <NUM>. The processor <NUM> configures the API invoker profile to enable the at least one on-boarding device to access services provided by the CCF server <NUM> and the service provider <NUM>.

The processor <NUM> is configured to execute instructions stored in the memory <NUM> and to perform various processes. The communicator <NUM> is configured for communicating internally between internal hardware components and with external devices via one or more networks.

The memory <NUM> stores instructions to be executed by the processor <NUM>. The memory <NUM> may include non-volatile storage elements. Examples of such non-volatile storage elements may include magnetic hard discs, optical discs, floppy discs, flash memories, or forms of electrically programmable memories (EPROM) or electrically erasable and programmable (EEPROM) memories. In addition, the memory <NUM> may, in some examples, be considered a non-transitory storage medium. The term "non-transitory" may indicate that the storage medium is not embodied in a carrier wave or a propagated signal. However, the term "non-transitory" should not be interpreted that the memory <NUM> is non-movable. In some examples, the memory <NUM> can be configured to store larger amounts of information than the memory. In certain examples, a non-transitory storage medium may store data that can, over time, change (e.g., in Random Access Memory (RAM) or cache).

Although the <FIG> shows various hardware components of the on-boarding device <NUM> but it is to be understood that other embodiments are not limited thereon. In other embodiments, the on-boarding device <NUM> may include less or more number of components. Further, the labels or names of the components are used only for illustrative purpose and does not limit the scope of the invention. One or more components can be combined together to perform same or substantially similar function to handle secure the on-boarding of the API invoker 110a.

<FIG> illustrates various components of the processor <NUM> of the on-boarding device <NUM> to handle secure on-boarding of the on-boarding device <NUM>, according to the embodiments as disclosed herein. In an embodiment, the processor <NUM> includes an API invoker 110a, a TLS session handler 110b, and a secure service provision engine 110c. In an embodiment, the TLS session handler 110b is configured to establish the TLS session with the CCF server <NUM>. Based on the TLS session, the secure service provision engine 110c is configured to send the onboard API invoker request to the CCF server <NUM> to onboard the API invoker 110a. Further, the secure service provision engine 110c is configured to receive the onboard API invoker response comprising the API invoker profile from the CCF server <NUM>. The secure service provision engine 110c configures the API invoker profile to enable the at least one on-boarding device to access services provided by the CCF server <NUM> and the service provider <NUM>.

Although the <FIG> shows various hardware components of the processor <NUM> but it is to be understood that other embodiments are not limited thereon. In other embodiments, the processor <NUM> may include less or more number of components. Further, the labels or names of the components are used only for illustrative purpose and does not limit the scope of the invention. One or more components can be combined together to perform same or substantially similar function to handle secure the on-boarding of the On-boarding device <NUM>.

<FIG> illustrates various component of the CCF server <NUM>, according to the embodiments as disclosed herein. In an embodiment, the CCF server <NUM> includes a processor <NUM>, a communicator <NUM>, and a memory <NUM>. The processor <NUM> is coupled with the communicator <NUM>, and the memory <NUM>.

The processor <NUM> is configured to establish the TLS session with the API invoker 110a. Further, the processor <NUM> is configured to receive the onboard API invoker request from the API invoker 110a using the TLS session to onboard the API invoker 110a. Further, the processor <NUM> is configured to validate the at least one of the symmetric key-pair, the client certificate associated with the API invoker 110a, and the enrollment information associated with the API invoker 110a. Further, the processor <NUM> is configured to generate the API invoker profile in response to successful validation of the at least one of the symmetric key-pair, the client certificate associated with the API invoker, OAuth <NUM> access token, and the enrollment information. Further, the processor <NUM> is configured to send the onboard API invoker response comprising the API invoker profile to the on-boarding device <NUM>.

Although the <FIG> shows various hardware components of the CCF server <NUM> but it is to be understood that other embodiments are not limited thereon. In other embodiments, the CCF server <NUM> may include less or more number of components. Further, the labels or names of the components are used only for illustrative purpose and does not limit the scope of the invention. One or more components can be combined together to perform same or substantially similar function to handle secure the on-boarding of the On-boarding device <NUM>.

<FIG> illustrates various components of the processor <NUM> of the CCF server <NUM> to handle secure on-boarding of the on-boarding device <NUM>, according to the embodiments as disclosed herein. In an embodiment, the processor <NUM> includes a TLS session handler 310a, an On-board API invoker handler 310b, and a secure service provision engine 310c.

The TLS session handler 310a is configured to establish the TLS session with the On-boarding device <NUM>. Further, the On-board API invoker handler 310b is configured to receive the onboard API invoker request from the On-boarding device <NUM> using the TLS session to onboard the On-boarding device <NUM>. Further, the On-board API invoker handler 310b is configured to validate the at least one of the symmetric key-pair, the client certificate associated with the On-boarding device <NUM>, and the enrollment information associated with the On-boarding device <NUM>. Further, the secure service provision engine 310c is configured to generate the API invoker profile in response to successful validation of the at least one of the symmetric key-pair, the client certificate associated with the API invoker, OAuth <NUM> access token, and the enrollment information. Further, the secure service provision engine 310c is configured to send the onboard API invoker response comprising the API invoker profile to the on-boarding device <NUM>.

<FIG> is example scenario of a token based secure on-boarding to handle secure on-boarding of the on-boarding device <NUM>, according to the embodiments as disclosed herein.

As shown in the <FIG>, the service provider <NUM> issues the access token (e.g., OAuth <NUM> access token) to on-boarding device <NUM>, which is submitted by the on-boarding device <NUM> to the CCF server <NUM> based on the on-boarding request. Consider a first scenario, the service provider <NUM> shall include the API invoker profile and list of all allowed service APIs information in the OAuth <NUM> access token. In a second scenario, the list of allowed service APIs shall be outside the OAuth <NUM> access token. In both scenarios, the OAuth <NUM> access token shall include JWS (JSON Web signature) from the service provider <NUM>.

The OAuth <NUM> access token can be the SAML (Security Assertion Mark-up Language) token, JSON Web Token or the like. The access tokens authenticate and authorize the API invoker's on-boarding request, if the OAuth <NUM> access token based mechanism is used.

As shown in the <FIG>, the OAuth <NUM> access token based mechanism can be used to authenticate the API invoker 110a and authorization of API invoker's on-boarding request. The OAuth <NUM> access token received from the service provider <NUM>, shall be encoded as JSON web token, include the JWS (JSON web signature) and shall be validated per OAuth <NUM>.

At step <NUM>, the service provider <NUM> provides the on-boarding information to the On-boarding device <NUM> to authenticate and communicate with the CCF server <NUM>. The information includes, details of CCF server <NUM> (e.g., at least one of the Address, and Root CA certificate for validation), OAuth <NUM> access token. The OAuth <NUM> access token will be encoded as the JSON web token (e.g., IETF RFC <NUM> or the like) and will embed API invoker information (for example, profile details, subscription details, API invoker ID, or the like), list of allowed Service APIs, in authorization claims section of the OAuth <NUM> access token. The OAuth <NUM> access token shall also include the JSON web digital signature (e.g., IETF RFC <NUM> or the like). This information can be provided/provisioned to on-boarding device <NUM>, as a prerequisite to the on-boarding procedure, over the air, wired, via physical medium or as static configuration on the on-boarding device or a Universal Subscriber Identity Module (USIM) etc..

At step <NUM>, the On-boarding device <NUM> and CCF server <NUM> establishes the secure communication channel (e.g., TLS using a server side certificate authentication, a CCF certificate validated by a root CA certificate) using the enrolment information obtained in at the step <NUM>. The TLS connection provides one-way authentication of the CCF based on the CCF certificate i.e., server side certificate based authentication.

At step <NUM>, the On-boarding device <NUM> generates a key pair (i.e., public key and private key). Over the secure channel, the On-boarding device <NUM> shall send the on-boarding request to the CCF server <NUM>. The on-boarding request includes the OAuth <NUM> access token (received from the service provider <NUM>), generated public key of the On-boarding device <NUM> and optionally the list of service APIs.

At step <NUM>, the CCF server <NUM> validates the OAuth <NUM> access token access token as per OAuth <NUM>, IETF RFC <NUM> and IETF RFC <NUM>, optionally including the on-boarding request against authorization information (the API invoker information, List of allowed service APIs) in the access token. Alternatively, the CCF <NUM> sends the token to the issuer (i.e., service provider <NUM> or a third party) and request for validation of the OAuth <NUM> access token.

At step <NUM>, after successful verification of the on-boarding request, the CCF server <NUM> generates API invoker profile for each of the on-boarding device <NUM>, wherein the API invoker profile comprising at least one of the API invoker ID (generate a new one or use the API invoker ID if present in the OAuth <NUM> access token or based on service agreement between the service provider <NUM> and the CCF server <NUM>), the API invoker certificate, the list of accessible service APIs by the On-boarding device <NUM>, and authentication and authorization information for the accessible service APIs (i.e., the selected method for AEF authentication and authorization, and an Onboard_Secret).

At step <NUM>, the CCF server <NUM> sends the on-boarding response to the On-boarding device <NUM> with the API invoker's profile information generated at the step <NUM>.

<FIG> is a flow chart <NUM> illustrating a method, implemented by the on-boarding device <NUM>, for handling secure on-boarding of the On-boarding device <NUM>, according to the embodiments as disclosed herein. The steps <NUM>-<NUM> are performed by the secure service provisioning engine 110c.

At step <NUM>, the method includes determining at least one of the symmetric key-pair, the client certificate associated with the API invoker, the OAuth <NUM> access token, and the enrollment information associated with the at least one on-boarding device <NUM>. At step <NUM> the method includes establishing the TLS session with the CCF server <NUM>. At <NUM>, the method includes sending the onboard API invoker request to the CCF server <NUM> using the TLS session to onboard the at least one on-boarding device <NUM>. At <NUM>, the method includes receiving the onboard API invoker response comprising the API invoker profile from the CCF server <NUM>. At <NUM>, the method includes configuring the API invoker profile to enable the at least one on-boarding device <NUM> to access services provided by the CCF server <NUM> and the service provider <NUM>.

The various actions, acts, blocks, steps, or the like in the flow diagram <NUM> may be performed in the order presented, in a different order or simultaneously. Further, in some embodiments, some of the actions, acts, blocks, steps, or the like may be omitted, added, modified, skipped, or the like without departing from the scope of the invention.

<FIG> is a flow chart <NUM> illustrating a method, implemented by the CCF server <NUM>, for handling secure on-boarding of the on-boarding device <NUM>, according to the embodiments as disclosed herein. The step <NUM>-<NUM> are performed by the secure service provisioning engine 310c.

At <NUM>, the method includes establishing the TLS session with the On-boarding device <NUM>. At <NUM>, the method includes receiving the onboard API invoker request from the On-boarding device <NUM> using the TLS session to onboard the at least one On-boarding device <NUM>. At <NUM>, the method includes validating the at least one of the symmetric key-pair, the client certificate associated with the On-boarding device <NUM>, and the enrollment information associated with the On-boarding device <NUM>. At <NUM>, the method includes generating the API invoker profile in response to successful validation of at least one of the symmetric key-pair, the client certificate associated with the API invoker, OAuth <NUM> access token, and the enrollment information. At <NUM>, the method includes sending, by the CCF server <NUM>, the onboard API invoker response comprising the API invoker profile to the at least one on-boarding device <NUM>.

<FIG> and <FIG> illustrates another example scenario in which system <NUM> handles secure on-boarding of the on-boarding device <NUM>, according to embodiment as disclosed herein.

As shown in the <FIG>, the on-boarding device <NUM> can access the framework APIs (exposed by the CCF server <NUM>) via CAPIF-<NUM>/CAPIF-1e reference points and the service APIs (exposed by the API exposing function) via the CAPIF-<NUM>/CAPIF-2e reference points. In order to access such APIs (e.g., framework APIs or Service APIs), the On-boarding device <NUM> first needs to be (initially should have) on-boarded to the common API Framework. The on-boarding process involves obtaining, from CAPIF server <NUM>, the identifier (ID) of the On-boarding device <NUM>, the authentication information, the authorization information, etc. which is necessary to access the APIs. The proposed method can be used to securely on-board the On-boarding device <NUM> and provide such necessary information to the On-boarding device <NUM> and to the CCF server <NUM> to on-board and also to access the APIs (Framework APIs and Service APIs) later.

Following high level process for on-boarding of an on-boarding device <NUM>:
In an embodiment, the On-boarding device <NUM> and the service provider <NUM> establish a service contract and the service provider <NUM> provides the on-boarding information with the on-boarding device <NUM>.

Further, the on-boarding device <NUM> requests the CCF server <NUM> to on-board the On-boarding device <NUM> by providing the on-boarding information received from the service provider <NUM>.

Further, the CCF server <NUM> verifies the validity (or verifies the authenticity) of the on-boarding information and provides the API invoker profile i.e. information necessary for accessing the APIs (Framework APIs and Service APIs) securely to the API invoker <NUM>. This provisions the On-boarding device <NUM> to access the services provided by the CAPIF <NUM> and the service providers <NUM>. This enables the On-boarding device <NUM> to consume the CAPIF <NUM> and the service provider <NUM> services through the framework and the service APIs securely.

The On-boarding information may constitute of, but not limited to, the following information:.

The API invoker profile may constitute of, but not limited to, the following information:.

In another embodiment, the service provider <NUM> can directly request the CCF server <NUM> to on-board the On-boarding device <NUM> by providing the details of the On-boarding device <NUM> to the CCF server <NUM>. On receiving the request, the CCF server <NUM> generates the API invoker profile and provides the API invoker profile to the service provider <NUM>. The service provider <NUM> directly provides the API invoker profile with the API invoker <NUM>. This API invoker profile can be provided/provisioned over the air, wired, via physical medium (e.g., memory stick, memory card) or as static configuration on the device or Universal Subscriber Identity Module (USIM) etc..

The automatic on-boarding process involves providing both, the On-boarding device <NUM> and the CCF server <NUM> with the information required for successful on-boarding of the On-boarding device <NUM>.

In another embodiment, the CCF server <NUM> and the service provider <NUM> can be co-located. In such deployments, the service provider <NUM> may not need to share (can be exchanged using internal interfaces) the on-boarding information with the CCF server <NUM>.

Referring to the <FIG>, at <NUM>, the service provider <NUM> provides the on-boarding information to the API invoker 110a. The API invoker 110a uses the on-boarding information to identify and communicate with the CCF server <NUM>. The on-boarding information includes details of the CAPIF core function (e.g., CCF IP address, CCF identity, certificate or the like), the API invoker authentication information (e.g., identity information (for example, anonymous ID, IP address, IDAI-SP like so), security credentials for on-boarding (for example, DH details like DH Group, Root CA to validate the CCF certificate, Key pair with certificate for the API invoker, a Security Assertion Mark-up Language (SAML) token, JSON Web token, like so) and a list of service APIs the API invoker is allowed to invoke.

The information can be provided/provisioned over the air, wired, via physical medium (e.g., memory stick, memory card) or as static configuration on the device or USIM etc..

At <NUM>, the service provider <NUM> shares the API invoker's on-boarding information with the CCF server <NUM>, so that the CCF server <NUM> can validate the incoming on-boarding requests on its own. Alternatively, the CCF server <NUM> may fetch the information from the service provider <NUM>. In an embodiment, the service provider <NUM> is identified by the CCF server <NUM> using the IDAI-SP or the On-boarding device <NUM> provides the details of the service provider <NUM> to the CCF server <NUM>.

At <NUM>, the On-boarding device <NUM> and the CCF server <NUM> establish a secure communication channel (for illustration purpose, using the Diffie-Hellman key exchange for establishment of secret key and then using security mechanism specific to the protocol (like HTTP over TLS carrying necessary information in object formats like JSON, XML, HTML, like so) to protect the communication (may be at the application layer or at the transport layer or at the IP layer).

At <NUM>, the On-boarding device <NUM> sends an on-boarding request to the CCF server <NUM>. The on-boarding request contains a subset of the on-boarding information that the On-boarding device <NUM> received from the service provider <NUM>.

At <NUM>, the CCF server <NUM> validates the received On-boarding information against the information received in at <NUM>.

At <NUM>, if the information validation is successful, the CCF server <NUM> generates an API invoker profile comprising of at least one of the API invoker ID, List of APIs accessible by the On-boarding device <NUM> and authentication and authorization information for the accessible APIs. If the CCF server <NUM> generates an identity for the API invoker, IDAI-CCF, the CCF server <NUM> may also provide the certificate using the newly assigned ID for the Key pair.

At <NUM>, the CCF server <NUM> sends the on-boarding response to the API invoker securely. The On-boarding response provides the API invoker with the API invoker Profile generated in at <NUM>.

As shown in the <FIG> The On-boarding device <NUM> provides the information required for successfully requesting the CCF server <NUM> for on-boarding. On receiving the on-boarding request, the CCF server <NUM> in-turn contacts the service provider <NUM> to validate the received information in the on-boarding request. Based on the response from the service provider <NUM>, the CCF server <NUM> generates the API invoker profile and on-boards the On-boarding device <NUM>.

Referring to the <FIG>, at <NUM>, the service provider <NUM> provides the on-boarding information to the On-boarding device <NUM>. The On-boarding device <NUM> uses the on-boarding information to communicate with the CCF server <NUM>. The information includes details (at least one of the CCF address, CCF identity, Root certificate), of the CCF server <NUM>, API invoker authentication information (e.g., at least one of the identity information for e.g. anonymous ID, IP Address, IDAI-SP like so), security credentials for on-boarding (for example, DH details like DH Group, root CA to validate the CCF certificate, Key pair with certificate signed by the service provider <NUM> for the API invoker, SAML token, JSON Web token, like so) and a list of service APIs the API invoker is allowed to invoke. This information can be provided over the air or as static configuration on the device or the USIM etc..

At <NUM>, the On-boarding device <NUM> and CCF server <NUM> establish the secure communication channel (for illustration purpose, using the Diffie-Hellman key exchange for establishment of secret key and then using security mechanism specific to the protocol (JSON or XML) to protect the communication (may be at the application layer or at the transport layer or at the IP layer).

At <NUM>, the API invoker <NUM> sends an on-boarding request to the CCF server <NUM>. The on-boarding request contains a subset of the on-boarding information that the On-boarding device <NUM> received from the service provider <NUM>.

At <NUM>, the CCF server <NUM> sends the on-boarding request acknowledgement and acknowledges the receipt of the request.

At <NUM>, the CCF server <NUM> sends an on-boarding information validation request to the service provider <NUM> including the received on-boarding information for validation.

At <NUM>, the service provider <NUM> validates the on-boarding information. This process can be automated or can be manual at the service provider <NUM>.

At <NUM>, once the validation is successful, the service provider <NUM> sends an on-boarding information validation response to the CCF server <NUM>. The on-boarding information validation response can contain a list of accessible service APIs if the validation was successful.

At <NUM>, on receiving the on-boarding information validation response, the CCF server <NUM> generates the API invoker profile comprising of at least one of the API invoker ID, list of APIs allowed for the API invoker, and authentication and authorization information for the accessible APIs. If the CCF server <NUM> generates the identity for the On-boarding device <NUM>, IDAI-CCF than, the CCF server <NUM> may also provide the certificate using the new assigned ID for the Key pair.

At <NUM>, the On-boarding device <NUM> and CCF server <NUM> establish the secure communication channel using the Diffie-Hellman key exchange along with an application layer protection mechanism or a TLS session. The connection may be initiated by the On-boarding device <NUM> (may be after the wait timer indicated by the CCF server <NUM> at the step <NUM>) or may be the connection initiated by the CCF server <NUM>.

At <NUM>, the CCF server <NUM> sends a notification to the On-boarding device <NUM> with the API invoker profile securely.

At <NUM>, the On-boarding device <NUM> acknowledges the notification from the CCF server <NUM>.

<FIG> is another example scenario of the token based secure on-boarding for handling secure on-boarding of the on-boarding device, according to embodiment as disclosed herein.

As shown in the <FIG>, OAuth <NUM> access token based mechanism can be used to authenticate and authorize API invoker's on-boarding request. This scenario is used with large list of allowed service APIs, which cannot be embedded in the OAuth access token. The list of allowed service APIs shall be outside OAuth access token. The OAuth <NUM> access token shall include JWS (JSON Web signature) signature from service provider <NUM>.

At <NUM>, the service provider <NUM> provides the on-boarding information to the On-boarding device <NUM>. Based on the on-boarding information, the On-boarding device <NUM> authenticates and communicates with the CCF server <NUM>. The information includes, at least one of the details of CCF (at least one of the address, certificate and root CA certificate for validation), OAuth <NUM> access token and list of allowed service APIs. The OAuth <NUM> access token will be encoded as JSON web token (i.e., IETF RFC <NUM>) and will embed API invoker information (for example, profile details, subscription details, API invoker ID, like so) in authorization claims section of the OAuth <NUM> access token. The OAuth <NUM> access token shall also include the JSON web digital signature (IETF RFC <NUM>). This information can be provided/provisioned to the On-boarding device <NUM> over the air, wired, via physical medium or as static configuration on the device or the USIM etc..

At <NUM>, the On-boarding device <NUM> and the CCF server <NUM> establishes the secure communication channel (i.e., TLS using the server side certificate and the CCF certificate validated by a root CA certificate). The TLS connection provides one-way authentication of the CCF server <NUM> based on the CCF certificate.

At <NUM>, the On-boarding device <NUM> generates a key pair (i.e., public key and private key). Over the secure channel, the On-boarding device <NUM> sends the on-boarding request to the CCF server <NUM>. The on-boarding request will include at least one of the OAuth <NUM> access token (received from the service provider <NUM>), generated public key of the On-boarding device <NUM> and list of service APIs.

At <NUM>, the CCF server <NUM> shall validate the OAuth <NUM> access token and JWS (JSON web signature) as per OAuth <NUM>, IETF RFC <NUM> and IETF RFC <NUM>. Post successful validation, the CCF server <NUM> shall follow process <NUM> and process <NUM> to verify the on-boarding request from the On-boarding device <NUM>.

At <NUM>, the CCF server <NUM> sends the on-boarding information validation request to the service provider <NUM> including the received on-boarding information (at least one of the API invoker's information from OAuth <NUM> access token and the list of service APIs) for validation.

At <NUM>, once the validation is successful, the service provider <NUM> sends the on-boarding information validation response to the CCF server <NUM>. The on-boarding information validation response can contain the list of accessible service APIs if the validation is successful.

At <NUM>, after successful verification of the on-boarding request, the CCF server <NUM> shall generate the API invoker's profile comprising of at least one of the API invoker ID (generates a new one or use the API invoker ID if present in OAuth <NUM> access token or based on service agreement between the service provider <NUM> and the CCF server <NUM>), the API invoker certificate, the list of accessible service APIs by the On-boarding device <NUM>, authentication and authorization information for the accessible service APIs.

At <NUM>, the CCF server <NUM> shall send the on-boarding response along with the API invoker's profile information to the On-boarding device <NUM>.

<FIG> is a sequential diagram illustrating a certificate based authentication between the On-boarding device <NUM> and the CCF server <NUM> for on-boarding of API invoker for automated secure on-boarding, according to the embodiments as disclosed herein.

At <NUM>, the service provider <NUM> provides the on-boarding information to the API invoker <NUM>. Based on the on-boarding information, the On-boarding device <NUM> authenticates and communicates with the CCF server <NUM>. The information includes, details of CCF (Address, root CA certificate for validation), the key pair (i.e., public key and private key) generated for the On-boarding device <NUM>, the certificate for the On-boarding device <NUM> (which is digitally signed by the service provider <NUM> or CAPIF certificate authority or trusted certificate authority, which includes the IDAI-SP and public key generated for the API invoker), IDAI-SP and list of allowed service APIs. This information can be provided/provisioned to the On-boarding device <NUM> over the air, wired, via physical medium or as static configuration on the device or the USIM etc..

Alternatively, instead of Key pair (i.e., public key and private key) generated by the service provider <NUM> for the On-boarding device <NUM>, the On-boarding device <NUM> generates the key pair (i.e., public key and private key) and provide the public key to the service provider before process <NUM>. So that, the service provider <NUM> provides the certificate for the On-boarding device <NUM> (which is digitally signed by the service provider <NUM> or certificate authority of the CAPIF or trusted certificate authority, which includes the IDAI-SP and public key generated for the On-boarding device <NUM>).

At <NUM>, the On-boarding device <NUM> and the CCF server <NUM> establishes the secure communication channel (i.e., TLS using server and client certificate authentication (i.e. CCF certificate and API invoker certificate are validated by the root certificate).

At <NUM>, the On-boarding device <NUM> generates a key pair (i.e., public key and private key). Over the secure TLS session, the On-boarding device <NUM> sends the on-boarding request to the CCF server <NUM>. The on-boarding request includes API generated public key of the On-boarding device <NUM> and list of service APIs. In an embodiment, the On-boarding device <NUM> receives the indication in process <NUM>, whether IDAI-SP is used as IDAI-CCF or new IDAI-CCF will be assigned by the CCF server <NUM>. If the CCF server <NUM> assigns the IDAI-CCF and indication to generate the key pair is received by the On-boarding device <NUM>, then the On-boarding device <NUM> generates the key pair (i.e., public pair and private key).

At <NUM>, the CCF server <NUM> validates the on-boarding information.

At <NUM>, after successful verification of the on-boarding request, the CCF server <NUM> generates the API invoker's profile comprising of the API invoker ID (Generate a new IDAI-CCF), API invoker certificate (which is digitally signed by the service provider <NUM> or the CAPIF certificate Authority or trusted certificate authority, which includes the IDAI-CCF and public key generated for the On-boarding device <NUM>), the list of accessible service APIs by the On-boarding device <NUM>, authentication and authorization information for the accessible service APIs. Alternately, the CCF server <NUM> may also generate the key pair (i.e., public key and private key) for the On-boarding device <NUM> and provides the keys along with the certificate for the On-boarding device <NUM>. The CCF server <NUM> generates the key pair for the On-boarding device <NUM>, instead of On-boarding device <NUM> if the CCF server <NUM> is configured to generate the key pair.

Alternately, instead of generating the new IDAI-CCF by the CCF server <NUM>, the IDAI-SP provided by the service provider <NUM> is used and also the certificate provided by the service provider <NUM> for the API invoker is used for subsequent authentication with the CCF server <NUM>.

At <NUM>, the CCF server <NUM> shall send the on-boarding response to the On-boarding device <NUM> with the API invoker's profile information generated in at <NUM>.

<FIG> is a sequential diagram illustrating an example scenario in which a DH based key is established between the API invoker 110a and the CCF server <NUM> for secure on-boarding of the API invoker 110a, according to the embodiments as disclosed herein. At <NUM>, the service provider <NUM> provides the on-boarding information to the API invoker. Based on the on-boarding information, the On-boarding device <NUM> authenticates and communicates with the CCF server <NUM>. The information includes, details of CCF (address, root CA certificate for validation), security information (information on the DH details like, group details or elliptic curve details), IDAI-SP and list of allowed service APIs. This information can be provided/provisioned to the On-boarding device <NUM> over the air, wired, via physical medium or as static configuration on the device or USIM etc..

At <NUM>, the API invoker and the CCF server <NUM> establishes the secure communication channel (using the DH and communication protocol specific security mechanism (like HTTP over TLS carrying necessary information in object formats like JSON, XML, HTML, like so).

At <NUM>, the On-boarding device <NUM> generates the key pair (i.e., public key and private key). Over the secure connection, the On-boarding device <NUM> sends the on-boarding request to the CCF. The on-boarding request includes generated public key of the API invoker and the list of service APIs.

At <NUM>, after successful verification of the on-boarding request, the CCF server <NUM> generates API invoker's profile comprising of API invoker ID (Generate a new IDAI-CCF), API invoker certificate (which is digitally signed by the service provider <NUM> or certificate authority of the CAPIF or trusted certificate authority, which includes the IDAI-CCF and public key generated for the API invoker <NUM>), list of accessible service APIs by the On-boarding device <NUM>, authentication and authorization information for the accessible service APIs.

Alternately, instead of generating the new IDAI-CCF by the CCF server <NUM>, the IDAI-SP provided by the service provider is used and also the certificate provided by the service provider <NUM> for the API invoker is used for subsequent authentication with the CCF server <NUM>.

At <NUM>, the CCF server <NUM> shall send the on-boarding response to the On-boarding device <NUM> with the API invoker's profile information generated in process <NUM>.

<FIG> is a diagram illustrating an API invoker <NUM> according to another embodiment of the present disclosure.

Referring to the <FIG>, the API invoker <NUM> may include a transceiver <NUM>, a processor <NUM> and a memory <NUM>. However, all of the illustrated components are not essential. The API invoker <NUM> may be implemented by more or less components than those illustrated in <FIG>. In addition, the transceiver <NUM>, the processor <NUM> and the memory <NUM> may be implemented as a single chip according to another embodiment.

The processor <NUM> may include one or more processors or other processing devices that control the proposed function, process, and/or method. Operation of the API invoker <NUM> may be implemented by the processor <NUM>.

The processor <NUM> may obtain, from a service provider, onboarding information including an onboarding credential and information of a CAPIF core function. The processor <NUM> may establish a secure session with the CAPIF core function based on the onboarding information. The processor <NUM> may control the transceiver to transmit, to the CAPIF core function, an onboard API invoker request message along with the onboarding credential and to receive an onboard API invoker response message based on a result of a validating the onboarding credential at the CAPIF core function.

The memory <NUM> may store the control information or the data included in a signal obtained by the API invoker <NUM>. The memory <NUM> may be connected to the processor <NUM> and store at least one instruction or a protocol or a parameter for the proposed function, process, and/or method. The memory <NUM> may include read-only memory (ROM) and/or random access memory (RAM) and/or hard disk and/or CD-ROM and/or DVD and/or other storage devices.

The processor <NUM> may establish a secure session with an API invoker based on on-boarding information including an onboarding credential. The processor <NUM> may receive, from the API invoker, an onboard API invoker request message along with the onboarding credential. The processor <NUM> may validate the onboarding credential and control the transceiver to transmit an onboard API invoker response message based on a result of a validating the onboarding credential.

Claim 1:
An application programming interface, API, invoker (110a, <NUM>) for performing an onboarding, the API invoker (110a, <NUM>) comprising:
a transceiver (<NUM>); and
a processor (<NUM>) coupled with the transceiver (<NUM>) and configured to:
obtain, from a service provider (<NUM>) via the transceiver (<NUM>), onboarding information including an onboarding credential and information of a common API framework, CAPIF, core function (<NUM>), wherein the onboarding information is used to authenticate an onboarding of the API invoker (110a, <NUM>) to the CAPIF core function (<NUM>);
establish a transport layer security, TLS, session with the CAPIF core function (<NUM>) using the onboarding information;
transmit, to the CAPIF core function (<NUM>) via the transceiver (<NUM>), an onboard API invoker request message along with the onboarding credential; and
in case that the onboarding credential is successfully validated, receive, from the CAPIF core function (<NUM>) via the transceiver (<NUM>), an onboard API invoker response message including a certificate of the API invoker,
wherein the onboard API invoker response message includes an assigned API invoker identifier, ID, and authentication and authorization information, and
wherein the certificate of the API invoker is generated by the CAPIF core function (<NUM>), after a successful validation of the onboarding credential.