Methods to enable 3GPP capif context aware service API authorization

Abstract

Methods are described herein for defining context aware service API authorization functionality. Based on the awareness of the state of the API invoker, resource owner, service being invoked and the underlying 3GPP network, differentiated discovery and access to these service APIs can be realized. This provides the ability to control access for specific API invokers or categories of API invokers to certain services or types of services based on the current state of key resources within the system.

Description

METHODS TO ENABLE 3GPP CAPIF CONTEXT AWARE SERVICE API AUTHORIZATIONCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 569.460, filed March 25, 2024, which is hereby incorporated by reference in its entirety.BACKGROUND

[0002] Current 3GPP systems lack context aware authorization capabilities such as the capability to allow resource owners and sendee providers to configure a Common Application Programming Interface (API) Framework (CAPIF) core function with authorization policies comprising various context aware conditions, the capability for CAPIF to collect dynamically changing context from various sources, and the capability for CAPIF functions to determine which sendee APIs are discovered and accessed by API invokers in a context aware. Accordingly, there is a need for improved context aware services.SUMMARY

[0003] This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. Furthermore, the claimed subject matter is not limited to limitations that solve any or all disadvantages noted in any part of this disclosure.

[0004] Methods are described herein for defining context aware service API authorization functionality. Based on the awareness of the state of the API invoker, resource owner, service being invoked and the underlying 3GPP network, differentiated discovery7and access to these service APIs can be realized. This provides the ability to control access for specific API invokers or categories of API invokers to certain services or types of services based on the current state of key resources within the system.

[0005] In one example, a system may receive a request to create a context aware authorization policy, wherein the context aware authorization policy depends on one or moretypes of context. The system may determine one or more context aware authorization policies applicable to an API invoker and required types of context required by the one or more context aware authorization policies. The system may send requests to one or more context sources to cause collection of a required context. Based on the collected required context and the one or more context aware authorization policies, the system may determine which service APIs to expose to the API invoker.BRIEF DESCRIPTION OF THE DRAWINGS

[0006] In order to facilitate a more robust understanding of the application, reference is now made to the accompanying drawings, in which hke elements are referenced with like numerals. These drawings should not be construed to limit the application and are intended only to be illustrative.

[0007] FIG. 1 is a system diagram of an example machine-to-machine (M2M), Internet of Things (loT), or Web of Things (WoT) communication system in which one or more disclosed embodiments may be implemented;

[0008] FIG. 2 is a system diagram of an example architecture that may be used within the M2M / IoT / W oT communications system illustrated in FIG. 1 ;

[0009] FIG. 3 is a system diagram of an example communication network node, such as an M2M / IoT / WoT device, gateway, or server that may be used within the communications system illustrated in FIGs. 1 and 2;

[0010] FIG. 4 is a block diagram of an example computing system in which a node of the communication system of FIG. 1 and 2 may be embodied;

[0011] FIG. 5 shows an application layer architecture model;

[0012] FIG. 6 shows a 3GPP Common API Framework (CAPIF);

[0013] FIG. 7 shows an overview of CAPIF context aware authorization operations;

[0014] FIG. 8 shows CAPIF context aware authorization policy CRUD requests;

[0015] FIG. 9 shows a procedure for onboarding the API invoker to the CAPIF;

[0016] FIG. 10 shows CAPIF context aware authorization enabled access token request handling;

[0017] FIG. 11 shows CAPIF context aware authorization enabled API invocation;

[0018] FIG. 12 shows CAPIF context aware authorization revocation; and

[0019] FIG. 13 shows an example graphical user interface (GUI).DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS

[0020] Methods are described herein for defining context aware sendee API authorization functionality.

[0021] The following abbreviations and definitions are described herein:Table 1 - AbbreviationsTable 2 - Terms

[0022] FIG. 1 is a diagram of an example machine-to machine (M2M). Internet of Things (loT), or Web of Things (WoT) communication system 10 in which one or more disclosed embodiments may be implemented. Generally, M2M technologies provide building blocks for the IOT / WOT, and any M2M device, M2M gateway, M2M server, or M2M service platform may be a component or node of the IoT / WoT as well as an IoT / WoT Service Layer, etc. Any of the client, proxy, or server devices illustrated in any of FIGs. 5-13 may comprise anode of a communication system, such as the ones illustrated in FIGs. 5-13.

[0023] The service layer may be a functional layer within a network service architecture. Service layers are typically situated above the application protocol layer such as HTTP, CoAP or MQTT and provide value added services to client applications. The service layer also provides an interface to core networks at a lower resource layer, such as for example, a control layer and transport / access layer. The service layer supports multiple categories of (service) capabilities or functionalities including a service definition, service runtime enablement, policy management, access control, and service clustering. Recently, several industry standards bodies, e g., oneM2M, have been developing M2M service layers to address the challenges associated with the integration of M2M types of devices and applications into deployments such as the Intemet / Web, cellular, enterprise, and home networks. A M2M service layer can provide applications and / or various devices with access to a collection of or a set of the above mentioned capabilities or functionalities, supported by the service layer, which can be referred to as a CSE or SCL. A few examples include but are not limited to security', charging, data management, device management, discovery, provisioning, and connectivity management which can be commonly used by various applications. These capabilities or functionalities are made available to such various applications via APIs whichmake use of message formats, resource structures and resource representations defined by the M2M service layer. The CSE or SCL is a functional entity that may be implemented by hardware and / or software and that provides (service) capabilities or functionalities exposed to various applications and / or devices (i.e. , functional interfaces between such functional entities) in order for them to use such capabilities or functionalities.

[0024] As shown in FIG. 1, the M2M / I0T / W0T communication system 10 includes a communication network 12. The communication network 12 may be a fixed network (e.g., Ethernet. Fiber, ISDN. PLC, or the like) or a wireless network (e.g., WLAN, cellular, or the like) or a network of heterogeneous networks. For example, the communication network 12 may be comprised of multiple access networks that provide content such as voice, data, video, messaging, broadcast, or the like to multiple users. For example, the communication network 12 may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), and the like. Further, the communication network 12 may comprise other networks such as a core netw ork, the Internet, a sensor network, an industrial control network, a personal area network, a fused personal network, a satellite network, a home network, or an enterprise network for example.

[0025] As shown in FIG. 1, the M2M / IOT / WOT communication system 10 may include the Infrastructure Domain and the Field Domain. The Infrastructure Domain refers to the network side of the end-to-end M2M deployment, and the Field Domain refers to the area networks, usually behind an M2M gate ay. The Field Domain and Infrastructure Domain may both comprise a variety of different nodes (e.g., servers, gateways, device, and the like) of the network. For example, the Field Domain may include M2M gateways 14 and devices 18. It will be appreciated that any number of M2M gateway devices 14 and M2M devices 18 may be included in the M2M / IoT / WoT communication system 10 as desired. Each of the M2M gateway devices 14 and M2M devices 18 are configured to transmit and receive signals, using communications circuitry, via the communication network 12 or direct radio link. A M2M gateway 14 allows wireless M2M devices (e.g., cellular and non-cellular) as well as fixed network M2M devices (e.g.. PLC) to communicate either through operator networks, such as the communication network 12 or direct radio link. For example, the M2M devices 18 may collect data and send the data, via the communication network 12 or direct radio link, to an M2M application 20 or other M2M devices 18. The M2M devices 18 may also receive datafrom the M2M application 20 or an M2M device 18. Further, data and signals may be sent to and received from the M2M application 20 via an M2M Service Layer 22, as described below. M2M devices 18 and gateways 14 may communicate via various networks including, cellular, WLAN, WPAN (e.g., Zigbee, 6L0WPAN, Bluetooth), direct radio link, and wireline for example. Exemplary M2M devices include, but are not limited to, tablets, smart phones, medical devices, temperature and weather monitors, connected cars, smart meters, game consoles, personal digital assistants, health and fitness monitors, lights, thermostats, appliances, garage doors and other actuator-based devices, security devices, and smart outlets.

[0026] Referring to FIG. 2, the illustrated M2M Service Layer 22 in the field domain provides senices for the M2M application 20, M2M gateways 14, and M2M devices 18 and the communication network 12. It will be understood that the M2M Service Layer 22 may communicate with any number of M2M applications, M2M gateways 14. M2M devices 18, and communication netw orks 12 as desired. The M2M Service Layer 22 may be implemented by one or more nodes of the network, which may comprise servers, computers, devices, or the like. The M2M Service Layer 22 provides service capabilities that apply to M2M devices 18, M2M gateways 14, and M2M applications 20. The functions of the M2M Service Layer 22 may be implemented in a variety of ways, for example as a web server, in the cellular core network, in the cloud, etc.

[0027] Similar to the illustrated M2M Service Layer 22, there is the M2M Sendee Layer 22’ in the Infrastructure Domain. M2M Service Layer 22’ provides services for the M2M application 20’ and the underlying communication network 12 in the infrastructure domain. M2M Service Layer 22’ also provides services for the M2M gateways 14 and M2M devices 18 in the field domain. It will be understood that the M2M Sen ice Layer 22’ may communicate with any number of M2M applications, M2M gateways and M2M devices. The M2M Service Layer 22’ may interact with a Service Layer by a different service provider. The M2M Service Layer 22’ may be implemented by one or more nodes of the network, which may comprise servers, computers, devices, virtual machines (e.g., cloud computing / storage farms, etc.) or the like.

[0028] Referring also to FIG. 2, the M2M Service Layers 22 and 22' provide a core set of service delivery capabilities that diverse applications and verticals may leverage. These service capabilities enable M2M applications 20 and 20’ to interact with devices and perform functions such as data collection, data analysis, device management, security, billing,service / device discovery7, etc. Essentially, these service capabilities free the applications of the burden of implementing these functionalities, thus simplifying application development and reducing cost and time to market. The Service Layers 22 and 22’ also enable M2M applications 20 and 20’ to communicate through various networks such as network 12 in connection with the services that the Service Layers 22 and 22’ provide.

[0029] The M2M applications 20 and 20’ may include applications in various industries such as, without limitation, transportation, health and wellness, connected home, energy management, asset tracking, and security and surveillance. As mentioned above, the M2M Service Layer, running across the devices, gateways, servers and other nodes of the system, supports functions such as, for example, data collection, device management, security, billing, location tracking / geofencing, device / service discovery , and legacy systems integration, and provides these functions as services to the M2M applications 20 and 20’.

[0030] Generally, a Service Layer, such as the Service Layers 22 and 22’ illustrated in FIG. 2, defines a software middleware layer that supports value-added sen-ice capabilities through a set of Application Programming Interfaces (APIs) and underlying networking interfaces. Both the ETSI M2M and oneM2M architectures define a Service Layer. ETSI M2M’s Service Layer is referred to as the Service Capability Layer (SCL). The SCL may be implemented in a variety of different nodes of the ETSI M2M architecture. For example, an instance of the Serv ice Layer may be implemented within an M2M device (where it is referred to as a device SCL (DSCL)), a gateway (where it is referred to as a gateway SCL (GSCL)) and / or a network node (where it is referred to as a network SCL (NSCL)). The oneM2M Service Layer supports a set of Common Serv ice Functions (CSFs) (i.e., service capabilities). An instantiation of a set of one or more particular types of CSFs is referred to as a Common Services Entity (CSE) which may be hosted on different types of network nodes (e.g., infrastructure node, middle node, application-specific node). The Third Generation Partnership Project (3GPP) has also defined an architecture for machine-type communications (MTC). In that architecture, the Service Layer, and the service capabilities it provides, are implemented as part of a Service Capability Server (SCS). Whether embodied in a DSCL, GSCL, or NSCL of the ETSI M2M architecture, in a Service Capability7Serv er (SCS) of the 3GPP MTC architecture, in a CSF or CSE of the oneM2M architecture, or in some other node of a network, an instance of the Service Layer may be implemented as a logical entity (e.g., software, computer-executable instructions, and the like) executing either on one or more standalonenodes in the network, including servers, computers, and other computing devices or nodes, or as part of one or more existing nodes. As an example, an instance of a Service Layer or component thereof may be implemented in the form of software running on a network node (e.g., server, computer, gateway, device or the like) having the general architecture illustrated in FIG. 3 or FIG. 4 described below.

[0031] Further, the methods and functionalities described herein may be implemented as part of an M2M network that uses a Service Oriented Architecture (SOA) and / or a Resource- Oriented Architecture (ROA) to access services.

[0032] FIG. 3 is a block diagram of an example hardware / software architecture of a node of a network, such as one of the clients, serv ers, or proxies illustrated in FIGs. 5-18, which may operate as an M2M server, gateway, device, or other node in an M2M network such as that illustrated in FIGs. 5-18. As shown in FIG. 3. the node 30 may include a processor 32, non-removable memory 44, removable memory 46, a speaker / microphone 38, a keypad 40, a display, touchpad, and / or indicators 42, a power source 48, a global positioning system (GPS) chipset 50, and other peripherals 52. The node 30 may also include communication circuitry, such as a transceiver 34 and a transmit / receive element 36. It will be appreciated that the node 30 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment. This node may be a node that implements the methods described herein, e.g., in relation to the methods described in reference to FIGs. 5-18 or the data structures of FIGs. 5-18, Tables 1-9, or in a claim.

[0033] The processor 32 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. In general, the processor 32 may execute computer-executable instructions stored in the memory (e.g., memory 44 and / or memory 46) of the node in order to perform the various required functions of the node. For example, the processor 32 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the node 30 to operate in a wireless or wired environment. The processor 32 may run application-layer programs (e.g., browsers) and / or radio access-layer (RAN) programs and / or other communications programs. The processor 32 may also perform security operations suchas authentication, security key agreement, and / or cryptographic operations, such as at the access-layer and / or application layer for example.

[0034] As shown in FIG. 3. the processor 32 is coupled to its communication circuitry (e.g., transceiver 34 and transmit / receive element 36). The processor 32, through the execution of computer executable instructions, may control the communication circuitry in order to cause the node 30 to communicate with other nodes via the network to which it is connected. In particular, the processor 32 may control the communication circuitry’ in order to perform the methods described herein, e.g., in relation to FIGs. 5-13, or in a claim. While FIG. 3 depicts the processor 32 and the transceiver 34 as separate components, it will be appreciated that the processor 32 and the transceiver 34 may be integrated together in an electronic package or chip.

[0035] The transmit / receive element 36 may be configured to transmit signals to, or receive signals from, other nodes, including M2M servers, gateways, device, and the like. For example, in an embodiment, the transmit / receive element 36 may be an antenna configured to transmit and / or receive RF signals. The transmit / receive element 36 may support various networks and air interfaces, such as WLAN, WPAN, cellular, and the like. In an embodiment, the transmit / receive element 36 may be an emitter / detector configured to transmit and / or receive IR, UV, or visible light signals, for example. In yet another embodiment, the transmit / receive element 36 may be configured to transmit and receive both RF and light signals. It will be appreciated that the transmit / receive element 36 may be configured to transmit and / or receive any combination of wireless or wired signals.

[0036] In addition, although the transmit / receive element 36 is depicted in FIG. 3 as a single element, the node 30 may include any number of transmit / receive elements 36. More specifically, the node 30 may employ MIMO technology7. Thus, in an embodiment, the node 30 may include two or more transmit / receive elements 36 (e.g., multiple antennas) for transmitting and receiving wireless signals.

[0037] The transceiver 34 may be configured to modulate the signals that are to be transmitted by the transmit / receive element 36 and to demodulate the signals that are received by the transmit / receive element 36. As noted above, the node 30 may have multi-mode capabilities. Thus, the transceiver 34 may include multiple transceivers for enabling the node 30 to communicate via multiple RATs, such as UTRA and IEEE 802. 11. for example.

[0038] The processor 32 may access information from, and store data in, any ty pe of suitable memory7, such as the non-removable memory 44 and / or the removable memory 46.For example, the processor 32 may store session context in its memory, as described above. The non-removable memory 44 may include random-access memory' (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 46 may include a subscriber identity' module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 32 may access information from, and store data in, memory that is not physically located on the node 30, such as on a server or a home computer. The processor 32 may be configured to control lighting patterns, images, or colors on the display or indicators 42.

[0039] The processor 32 may receive poyver from the power source 48, and may be configured to distribute and / or control the poyver to the other components in the node 30. The power source 48 may be any suitable device for powering the node 30. For example, the power source 48 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, and the like.

[0040] The processor 32 may also be coupled to the GPS chipset 50, which is configured to provide location information (e.g., longitude and latitude) regarding the current location of the node 30. It will be appreciated that the node 30 may acquire location information by vay of any suitable location-determination method while remaining consistent with an embodiment.

[0041] The processor 32 may further be coupled to other peripherals 52, which may include one or more software and / or hardware modules that provide additional features, functionality and / or wired or wireless connectivity. For example, the peripherals 52 may include various sensors such as an accelerometer, biometrics (e.g., finger print) sensors, an e- compass, a satellite transceiver, a sensor, a digital camera (for photographs or video), a universal serial bus (USB) port or other interconnect interfaces, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, and the like.

[0042] The node 30 may be embodied in other apparatuses or devices, such as a sensor, consumer electronics, a wearable device such as a smart watch or smart clothing, a medical or eHealth device, a robot, industrial equipment, a drone, a vehicle such as a car, truck, train, or airplane. The node 30 may connect to other components, modules, or systems of suchapparatuses or devices via one or more interconnect interfaces, such as an interconnect interface that may comprise one of the peripherals 52.

[0043] FIG. 4 is a block diagram of an exemplary computing system 90 which may also be used to implement one or more nodes of a network, such as the clients, servers, or proxies illustrated in FIGs. 5-13, which may operate as an M2M server, gateway, device, or other node in an M2M network such as that illustrated in FIGs. 5-13.

[0044] Computing system 90 may comprise a computer or server and may be controlled primarily by computer readable instructions, which may be in the form of software, wherever, or by whatever means such software is stored or accessed. Such computer readable instructions may be executed within a processor, such as central processing unit (CPU) 91, to cause computing system 90 to do work. In many known workstations, servers, and personal computers, central processing unit 91 is implemented by a single-chip CPU called a microprocessor. In other machines, the central processing unit 91 may comprise multiple processors. Coprocessor 81 is an optional processor, distinct from main CPU 91, that performs additional functions or assists CPU 91. CPU 91 and / or coprocessor 81 may receive, generate, and process data related to the disclosed systems and methods for E2E M2M Service Layer sessions, such as receiving session credentials or authenticating based on session credentials.

[0045] In operation, CPU 91 fetches, decodes, and executes instructions, and transfers information to and from other resources via the computer’s main data-transfer path, system bus 80. Such a system bus connects the components in computing system 90 and defines the medium for data exchange. System bus 80 typically includes data lines for sending data, address lines for sending addresses, and control lines for sending interrupts and for operating the system bus. An example of such a system bus 80 is the PCI (Peripheral Component Interconnect) bus.

[0046] Memories coupled to system bus 80 include random access memory (RAM) 82 and read only memory (ROM) 93. Such memories include circuitry that allows information to be stored and retrieved. ROMs 93 generally contain stored data that cannot easily be modified. Data stored in RAM 82 may be read or changed by CPU 91 or other hardware devices. Access to RAM 82 and / or ROM 93 may be controlled by memory controller 92. Memory controller 92 may provide an address translation function that translates virtual addresses into physical addresses as instructions are executed. Memory controller 92 may also provide a memory protection function that isolates processes within the system and isolatessystem processes from user processes. Thus, a program running in a first mode may access only memory mapped by its own process virtual address space; it cannot access memory within another process’s virtual address space unless memory sharing between the processes has been set up.

[0047] In addition, computing system 90 may contain peripherals controller 83 responsible for communicating instructions from CPU 91 to peripherals, such as printer 94, keyboard 84, mouse 95, and disk drive 85.

[0048] Display 86. which is controlled by display controller 96. is used to display visual output generated by computing system 90. Such visual output may include text, graphics, animated graphics, and video. Display 86 may be implemented with a CRT-based video display, an LCD-based flat-panel display, gas plasma-based flat-panel display, or a touch-panel. Display controller 96 includes electronic components required to generate a video signal that is sent to display 86.

[0049] Further, computing system 90 may contain communication circuitry, such as for example a network adaptor 97, that may be used to connect computing system 90 to an external communications network, such as network 12 of FIGs. 1-4, to enable the computing system 90 to communicate with other nodes of the network.

[0050] FIG. 5 shows an example of a generalized application layer architecture 500 that divides application logic into three distinct layers: application-specific, vertical industry7enabler, and service layers. At the bottom is the service layer which provides common services to all applications. The services may include location, group management, configuration management, and security aspects. Above service layers is the vertical industry enabler layer, which is the layer that manages services for a specific vertical industry such as autonomous vehicles, drones, loT, gaming, etc. At the top is the application-specific layer which serves specific applications within the vertical industry. This layer is custom designed for a particular application and may be provided by various service providers in the vertical industry. The goal of this three-layered approach is to abstract common functionalities at the vertical industry and sen ice layers to simplify application development for faster deployments of the applications.

[0051] The architecture shown in FIG. 5 is based on the client-server communication model. One or more client applications on the device may communicate with one or more server applications on application servers. Note that the server applications may reside in one or more application servers. Between the device and application server, communications mayexist between clients of each layer, or the application-specific client / server may only need to communicate with the service layer client. A network between the client applications and server applications provides the medium for communication. The network may be a cellular network such as a mobile operator network or the network may be some broadband sendee provider network providing access to the internet.

[0052] 3GPP defines the Common API Framework (CAPIF) for 3GPP. CAPIF supports functionality to assist with the exposure, discovery, and access of service APIs. CAPIF can be used to expose APIs for services within a mobile network as well as 3rd party services.

[0053] FIG. 6 shows an example CAPIF architecture 600. CAPIF comprises API invokers, resource owners and CAPIF functions as described below.

[0054] An API invoker is typically a 3rd party application or service having a sendee agreement with the mobile network operator. The API invoker may reside within the same trust domain as the mobile network operator. The API invoker may be hosted on a server or on a UE. The API invoker interacts with the authorization function in the CAPIF core function. The API invoker supports authentication by providing the API invoker identity and other information required for authentication of the API invoker, obtaining the authorization prior to accessing the sendee API, discovering service APIs information, and invoking the sendee APIs.

[0055] A CAPIF core function supports authenticating an API invoker based on the identity and other information required for authentication of the API invoker, authorizing an API invoker to access service APIs, publishing of service APIs by API service providers, discovery' of service APIs by API invokers, monitoring API invocations and generating logs and charging records based on the API invocations.

[0056] An Authorization function is an internal entity of the CAPIF core function. It supports receiving authorization from the resource owner and providing the API invoker with the authorization information which may be needed to access the resource owner’s resources. Note, currently the authorization function may be an internal entity' of the CAPIF core function.

[0057] An API exposing function (e g. NEF, SCEF. 3rd party service provider) may be the provider of the service APIs and may also be the service communication entry point of the service API to the API invokers. The API exposing function acts as a resource owner consent enforcement point and interacts with the authorization function in the CAPIF corefunction. The API exposing function can retrieve the resource owner consent parameters from the authorization function. It authenticates the API invoker based on the identity and other information required for authentication of the API invoker provided by the CAPIF core function and validates the authorization provided by the CAPIF core function. It also logs the service API invocations at the CAPIF core function.

[0058] An API publishing function enables the API provider to publish service API information to the CAPIF core function to enable the discovery of service APIs by API invokers.

[0059] An API management function enables the API provider to perform administration of the service APIs. It performs auditing of the service API invocation logs received from the CAPIF core function, monitoring the events reported by the CAPIF core function, configuring the API provider policies to the CAPIF core function, monitoring the status of the service APIs, onboarding the new API invokers and offboarding API invokers, and registering and maintaining registration information of the API provider domain functions on the CAPIF core function.

[0060] Resource owners interact with the authorization function in the CAPIF core function to manage resource owner consent. It supports providing authorization for resource access and managing and revoking authorization for resource access.

[0061] API invokers, resource owners and CAPIF functions communicate with one another via the CAPIF reference points (e.g.. CAPIF-1, CAPIF-2. ... , CAPIF-8) to perform supported operations such as the following.

[0062] Publishing service APIs: the API provider utilizes the API publishing function over CAPIF-4 reference point to publish the service APIs on the CAPIF core function.

[0063] Discovering service APIs: the API invoker discovers the service APIs over CAPIF-l / CAPIF-le reference points.

[0064] API event subscription and notification: the API invoker subscribes to and receive service API event notifications over CAPIF-l / CAPIF-le reference points.

[0065] Authenticating with CAPIF: the API invoker authenticates over CAPIF- l / CAPIF-le reference points.

[0066] Authorizing with CAPIF: the API invoker obtains service API authorization over CAPIF-l / CAPIF-le reference points. In RNAA scenarios, API authorization may be based on the authorization information obtained from the resource owner.

[0067] Topology hiding: the API provider, to hide the topology7, utilizes the API exposing function over CAPIF-3 reference point.

[0068] Authenticating and authorizing the API invoker for service API invocation: to authenticate and authorize the API invoker for service API invocation the API provider utilizes the API exposing function over CAPIF-2 / CAPIF-2e and CAPIF-3.

[0069] Logging: to maintain the log of the API invocations at the CAPIF core function for services such as charging, invocation history, the API provider utilizes the API exposing function over CAPIF-3.

[0070] Charging: to facilitate charging of the API invocations, the API provider utilizes the API exposing function over CAPIF-3.

[0071] Service monitoring: to facilitate monitoring such as API invoker's ID and IP address, the API provider utilizes the API management function over CAPIF-5.

[0072] Auditing: for auditing, the API provider utilizes the API management function over CAPIF-5.

[0073] The current 3GPP defined Common API Framework (CAPIF) currently lacks the following context aware authorization capabilities:

[0074] Capability' to allow resource owners and service providers to configure the CAPIF core function with authorization policies comprising context aware conditions which are dependent upon the current state of dynamically changing context pertaining to resource owners, API invokers, services, and the 3GPP network yvhich interconnects these entities together with one another.

[0075] Capability for CAPIF functions (e g., CAPIF core function, CAPIF API exposing function, etc.) to collect dynamically changing context from resource oyvners, API invokers, services, and the 3GPP network, and use this context as input into context aware authorization policies.

[0076] Capability' for CAPIF functions (e.g., CAPIF core function, CAPIF API exposing function, etc.) to determine which service APIs are discovered and accessed by API invokers in a context aware fashion based on the current state of dynamically changing context and context aware authorization policies.

[0077] 3GPP networks offer a valuable set of connectivity centric services yvhich can be invoked by applications and upper layer services. For example, location-based services and QoS based services. 3GPP defines the Common API Frameyvork (CAPIF) yvhich supportsfunctionality to assist with the exposure, discovery, and access of 3GPP native service APIs as well as 3rd party service APIs. However, CAPIF currently lacks support for context aware authorization capabilities. To address this shortcoming, it is proposed to define context aware service API authorization functionality in CAPIF. This proposed functionality enables CAPIF with the awareness of up-to-date context (i.e., state) of API invokers, resource owners, services being invoked, and 3GPP network functions and services. The proposed functionality also equips CAPIF with context aware authorization policies which CAPIF uses, together with up- to-date context information, to make context aware authorization decisions related to the discover}' and access of service APIs by API invokers. This enables CAPIF to provide more intelligent decisions regarding which API invokers discover and access which sendees based on the current state of key resources within the system. In turn, this enhanced CAPIF capability can enable systems to operate more reliably and efficiently as well as provide API invokers with better quality of service.

[0078] The following are some additional details of the specific features defined herein:

[0079] A method for a CAPIF core function to:

[0080] Receive a first request from resource owner or API management function to create a context aware authorization policy, wherein the policy depends on one or more of the following types of context:

[0081] API invoker location, request rate, number of requests issued, bandwidth consumption

[0082] Resource owner location or state (e g., connected, disconnected, low battery, do not disturb)

[0083] Sendee location or service area, schedule, request rate, response time, availability, available compute, available memory, available storage, available bandwidth

[0084] Network bandwidth, latency, jitter, availability,

[0085] Upon receiving an API invoker onboarding request, determine one or more context aware authorization policies applicable to the API invoker and required ty pes of context required by the context aware authorization policy(s)

[0086] Send requests to one or more context sources in the system to collect the required context, where the context sources may be:

[0087] Other CAPIF functions, 3GPP core network functions (e.g., SCEF, NEF, PCF, UDM, UDR, etc.) and / or 3GPP application service enablers (e.g., SEAL, EDGEAPP, AD AES, etc.)

[0088] Based on the collected context and context aware authorization policies, determine which service APIs to expose to the API invoker

[0089] Upon receiving an API invoker access token request, determine one or more context aware authorization policies applicable to the API invoker and required types of context required by the context aware authorization policy(s)

[0090] Send requests to one or more context sources in the system to collect the required context, where the context sources may be:

[0091] Other CAPIF functions. 3GPP core network functions (e.g., SCEF, NEF, PCF, UDM, UDR. etc.) and / or 3GPP application service enablers (e.g., SEAL, EDGEAPP, AD AES, etc.)

[0092] Based on the collected context and context aware authorization policies, determine which service APIs to authorize access to the API invoker and under what contextbased constraints (e.g., based on certain API invoker location, based on certain API invoker service invocation rate or schedule, etc.)

[0093] Generate access token comprising context-based constraints defining conditions under which the access token may be valid and may allow the API invoker to access an associated set of service APIs.

[0094] Send context aware authorization policies and / or access tokens with other CAPIF functions (e.g., CAPIF API exposing function) such that they can make context aware authorization decisions regarding subsequent sendee invocations requests they receive from the API invoker.

[0095] Send access token comprising context-based constraints to API invoker.

[0096] A method for a CAPIF API exposing function to:

[0097] Receive context aware authorization policies and / or access tokens from other CAPIF functions (e.g., CAPIF core function)

[0098] Receive a service API invocation request from an API invoker comprising an access token comprising context-based constraints.

[0099] Determine which types of context are required by the context aware authorization policy(s) and / or access tokens

[0100] Send requests to one or more context sources in the system to collect the required context, where the context sources may be:

[0101] Other CAPIF functions, 3GPP core network functions (e.g., SCEF, NEF, PCF, UDM, UDR, etc.) and / or 3GPP application service enablers (e.g., SEAL, EDGEAPP, ADAES, etc.)

[0102] Based on the collected context, context-based access token, and context aware authorization policies, determine which service APIs to authorize access to the API invoker and under what context-based constraints (e.g., based on certain API invoker location, based on certain API invoker service invocation rate or schedule, etc.)

[0103] In an example in accordance with one embodiment, which may be used in combination with any of the embodiments described herein, an apparatus may receive, from a first device associated with a resource owner, a request to create one or more context aware authorization policies. The apparatus may comprise a Common Application Programming Interface (API) Framework (CAPIF) core function. Each context aware authorization policy, of the one or more context aware authorization policies, may require one or more types of context, and the one or more types of context comprise at least one of a resource owner context, a service context, or a network context. Each context aware authorization policy, of the one or more context aware authorization policies, may comprise one or more context aware rules instructing whether API invokers are allowed to discover and access the one or more sendee APIs. The apparatus may receive, from a second device associated with an Application Programming Interface (API) invoker, a request to access one or more service APIs associated with the resource owner. The apparatus may determine a context aware authorization policy, of the one or more context aware authorization policies, that is applicable to the API invoker and one or more required types of context for the applicable context aware authorization policy. The apparatus may send, to one or more context sources, one or more requests for the one or more required types of context. The apparatus may receive, from the one or more context sources, information associated with the one or more required types of context. The apparatus may, based on the received information and the applicable context aw are authorization policy, determine which service API, of the one or more service APIs, to expose to the API invoker. The determining which service API, of the one or more service APIs, to expose to the API invoker may comprise comparing the resource owner context, the service context, or thenetwork context to one or more context aware rules instructing whether API invokers are allowed to discover and access the one or more service APIs.

[0104] FIG. 7 shows an example procedure for CAPIF context aware authorization enhancements 700, in accordance with one embodiment, which may be used in combination with any of the embodiments described herein. Context aware authorization functionality may be supported within the authorization function of a CAPIF core function and / or within other CAPIF functions such as a CAPIF API exposing function.

[0105] At step I, a CAPIF API publishing function may publish service API information to a CAPIF core function. In addition, a CAPIF API publishing function may also publish context aware authorization policies to a CAPIF core function. These policies may contain context aware rules instructing if / when CAPIF functions (e.g.. CAPIF core function, CAPIF API exposing function) are to allow API invokers to discover and access the published service APIs. The context aw are authorization policies may be stored locally in the CAPIF core function for future reference. For example, a policy may specify that an API invoker may only be permitted to access a service w hen the API invoker resides in a specified location or provides applicable access tokens. Note that the context aware authorization policies may be available to other functions (e.g. API exposing function and API management function) in the API provider domain.

[0106] At step 2, a resource owner may publish context aw are authorization policies to a CAPIF core function. These policies may contain context aw are rules instructing if / when CAPIF functions (e.g.. CAPIF core function, CAPIF API exposing function) are to allow API invokers to perform service API operations targeting the resource owner. For example, a resource owner policy associated with a UE, may specify that sendee API operations requesting access to the UE’s current location are only permitted by API invokers hosted on other UEs within a specified distance of the resource owner's UE and which are members of a specified group (which the resource owner UE may be a member of).

[0107] At step 3, when performing API invoker on-boarding operations, a CAPIF core function may use context aware authorization policies from API publishing functions and / or resource owners to determine what service APIs are allowed to be discovered by the API invoker. When making this determination, the CAPIF core function may collect context information from the API invoker’s request as w ell as from other entities in the system such as 3GPP core network functions (e.g., SCEF, NEF, PCF, UDM, UDR, etc.) and / or 3GPPapplication service enablers (e.g., SEAL, EDGEAPP, AD AES, etc.). The CAPIF core function may compare this collected context against the applicable context aware authorization policies to determine the service API information which may be returned to the API invoker in an onboarding response. In the event that the API invoker does not include the required context which the CAPIF core function requires to make a context aware authorization decision, the CAPIF core function may inform the API invoker of the required context (e.g., by returning an indication to the API invoker in an onboarding response). Note, this additional step is not shown in FIG. 7.

[0108] At step 4, a CAPIF core function may receive an authorization request from an API invoker requesting a token which it can use to access service APIs via CAPIF API exposing function(s). When receiving this request, the CAPIF core function may process it using its context aware authorization capabilities as further described in Steps 5 - 10. Alternatively, an authorization request may be combined with the onboarding request described in Step 3, in which case a token can be returned in the onboarding response. In yet another alternative, an authorization request may be combined with a Service API discovery request, in which case a token can be returned in a Service API discovery response.

[0109] At step 5, based on information provided in the token request by the API invoker and / or information provided by the API invoker during its prior onboarding request, the CAPIF core function may retrieve applicable context aware authorization policies which the CAPIF core function uses to process the token request.

[0110] At step 6. based on any applicable context aware authorization policies deemed applicable to the token request, the CAPIF core function may collect context information required by these policies. The CAPIF core function may collect context information from the API invoker’s token request as well as from other entities in the system such as 3GPP core network functions (e.g., SCEF, NEF, PCF, UDM, UDR, etc.) and / or 3GPP application service enablers (e.g., SEAL, EDGEAPP, AD AES, etc.). In the event that the API invoker does not include the required context which the CAPIF core function requires to make a context aware authorization decision, the CAPIF core function may inform the API invoker of the required context (e.g., by returning an indication to the API invoker in an authorization response). Note, this additional step is not shown in FIG. 7.

[0111] At step 7, the CAPIF core function may compare the context it collects against any applicable context aware authorization policies to determine the types and instancesof sendee APIs the API invoker may be allowed to access, the types of operations of these sen-ice APIs that the API invoker may be allowed to perform, and / or the resource owners which the API invoker may be allowed to target via these service APIs. The CAPIF core function may also determine additional context-based constraints and conditions on if / when the API invoker may be allowed to access the service APIs. For example, access to the sendee APIs may only be authorized if / when the API invoker may be in a certain location, or if / when the senice associated with the service APIs has available service bandwidth above a specified threshold.

[0112] At step 8, after determining the allowed types and instances of service APIs the API invoker may be permitted to access, the allowed types of operations to these service APIs, the resource owners that can be targeted, and any additional context-based constraints and conditions on if / when the API invoker may be allowed to access the service APIs, the CAPIF core function may generate one or more context aware authorization policies applicable to the API invoker. The CAPIF core function may store and use these policies locally. The CAPIF core function may also share these policies with other CAPIF functions such as CAPIF API exposing functions or other CAPIF core functions.

[0113] At step 9, a CAPIF core function may generate a context-aw are access token, which may contain an identifier for the context aware authorization policies the CAPIF core function had generated for the API invoker in step 8. Within the token, the CAPIF core function may include context aware constraints specifying conditions which restrict if / when the token may be valid and can be used to grant the API invoker access to service APIs. For example, an API invoker location-based constraint or a service bandwidth availability constraint may be specified in the token.

[0114] At step 10, the CAPIF core function may send a context aware token to the API invoker. The CCF may also include information on the conditions / constraints of when the token may be valid.

[0115] At step 11, the API invoker may send a service API invocation request to a CAPIF API exposing function. Within this request, the API invoker may include a context aware token. The API invoker may also include context information. For example, the API invoker may include its current location.

[0116] At step 12, upon receiving a service API invocation request, the CAPIF API exposing function may process a context aw are token (if present) to determine if access to therequested sendee API should be allowed or not. To make this determination, the API exposing function may extract any context aware constraints and / or context aware authorization policies specified in the token. The API exposing function may also check if any context aware authorization policies exist locally at the API exposing function or at other CAPIF functions (e.g. CAPIF core function). If any context aware constraints or policies are found, the API exposing function may collect the required context to properly evaluate these constraints and policies. The CAPIF API exposing function may collect context information from the API invoker’s service invocation request, from the context aware token, as well as from other entities in the system such as other CAPIF functions (e.g., CAPIF core function, CAPIF API management function, etc.), 3GPP core network functions (e.g., SCEF, NEF, PCF, UDM, UDR, etc.) and / or 3GPP application service enablers (e.g., SEAL, EDGEAPP, AD AES, etc.). The CAPIF API exposing function may use this context information to determine whether to allow the API invoker to invoke the API. The API exposing function may also use this context information to validate the validity of the token itself.

[0117] At step 13, the API exposing function may first compare the context it collects against any constraints specified in the context aware token to determine whether the token may be valid and can be used by the API invoker under the current conditions. If valid, the API exposing function may also compare the context it collects against any applicable context aware authorization policies it deems applicable to the request. Based on these operations, the API exposing function may determine whether to grant or deny the API invoker’s service API invocation request.

[0118] At step 14, based on the context aware authorization decision made by the API exposing function, it may return a service API invocation response to the API invoker. The response may include the results of the service API invocation, or an error condition based on whether access to the service API was allowed or not.

[0119] Various forms of context information such as but not limited to the context shown in Table 3 may be used by CAPIF functions to perform context aware authorization operations. Context information may be passed within CAPIF requests (e.g., within API invoker onboarding, access token or service invocation requests). Context information may be collected and / or aggregated by CAPIF functions (e.g., CAPIF core functions. CAPIF API exposing functions, etc.) via interaction with other entities in the system such as but not limitedto 3GPP core network functions (e.g., SCEF, NEF, PCF, UDM, UDR, etc.) and / or 3GPP application sendee enablers (e g., SEAL, EDGEAPP, AD AES, etc.).Table 3 - CAPIF Authorization Context

[0120] Various types of context aware authorization policies may be supported by CAPIF such as but not limited to those defined in Table 4 and Table 5. These policies may be used by CAPIF functions to perform context aware authorization operations and may be configured by CAPIF entities such as but not limited to resource owners, API publishing functions, and API management functions. These policies may also be configured onto CAPIF functions by other entities in the system such as 3GPP core network functions (e.g., SCEF, NEF. PCF, UDM, UDR, etc.) and / or 3GPP application service enablers (e g., SEAL, EDGEAPP, ADAES, etc.). Alternatively, these policies may be configured by other means such as management and orchestration provisioning functions in the system.

[0121] A resource owner may specily CAPIF context aware authorization policies that include policy elements such as but not limited to those defined in Table 4. A resourceowner may configure policies to ensure service API operations targeting its resources are only performed by API invokers which meet the criteria specified in these policies.Table 4 - Resource Owner CAPIF Context Aware Authorization Policies

[0122] An API service provider may specify CAPIF context aware authorization policies which include policy elements such as but not limited to those defined in Table 5. The configuration of these policies may be done via the CAPIF API management function(s) and / or API publishing function(s) associated with the API service provider. An API service provider may configure policies to ensure sendee API operations targeting its service APIs are only performed by API invokers which meet the criteria specified in these policies.Table 5 - API Service Provider CAPIF Context Aware Authorization Policies

[0123] To realize context authorization capabilities within CAPIF, the following procedures are defined. A CAPIF deployment may support one or more of these procedures and the operations defined within these procedures.

[0124] FIG. 8 shows an example procedure 800 for CAPIF Context Aware Authorization Policy CRUD requests.

[0125] As shown in steps 1 and 2 of FIG. 7 and FIG. 8, a CAPIF core function may receive CAPIF context aware authorization policy CRUD (create, retrieve, update, delete) requests from other CAPIF entities such as resource owners and CAPIF API publishing, API management or API exposing functions. A CAPIF core function may also receive CAPIF context aware authorization policy configuration requests from other entities in the system notshown in FIG. 8. A CAPIF core function may also be provisioned with C APIF context aware authorization policies by means other than receiving CAPIF context aware authorization policy CRUD requests.

[0126] Referring to FIG. 8, at step 1, a CAPIF core function may receive a CRUD request from an API service provider to create, retrieve, update, or delete an API service provider CAPIF context aware authorization policy. Requests to create or update a policy may include one or more of the policy elements defined in Table 5. Requests to retrieve or delete a policy may include one or more policy IDs.

[0127] At step 2, upon receiving an API service provider CAPIF context aware authorization policy CRUD request, the CAPIF core function may process the request by validating the policy may be properly structured and only comprises policy elements which are valid and supported by CAPIF. The CAPIF core function may also check that the API service provider has permissions to perform the specified CAPIF context aware authorization policy CRUD operation on the specified service APIs. If the validation and permissions check are successful, the CAPIF core function may process the request. For a create request, the CAPIF core function may create and store a new API service provider CAPIF context aware authorization policy. For an update request, the CAPIF core function may update an existing API service provider CAPIF context aware authorization policy. For a retrieve request, the CAPIF core function may identify one or more stored API service provider CAPIF context aware authorization policy(s) matching a policy ID or query criteria specified in the request. For a delete request, the CAPIF core function may delete the API service provider CAPIF context aware authorization policy matching the policy ID specified in the request.

[0128] At step 3, the CAPIF core function may send a response to the API sendee provider. For a create or update response, the CAPIF core function may return the policy ID of the created or updated policy and optionally a representation of the policy elements within the created or updated policy. For a retrieve response request, the CAPIF core function may return a representation of the retrieved policy. For a delete response, the CAPIF core may return a status indicating whether the specified policy was successfully deleted.

[0129] At step 4, the CAPIF core function may receive a CRUD request from a resource owner to create, retrieve, update, or delete a resource CAPIF context aware authorization policy. Requests to create or update a policy may include one or more of thepolicy elements defined in Table 4. Requests to retrieve or delete a policy may include one or more policy IDs.

[0130] At step 5, similarly to step 2. upon receiving a resource owner CAPIF context aware authorization policy CRUD request, the CAPIF core function may process the request by validating the policy may be properly structured and only comprises policy elements which are valid and supported by CAPIF. The CAPIF core function may also check that the resource owner has permissions to perform the specified CAPIF context aware authorization policy CRUD operation. If the validation and permissions check are successful, the CAPIF core function may process the request. For a create request, the CAPIF core function may create and store a new resource owner CAPIF context aware authorization policy. For an update request, the CAPIF core function may update an existing resource owner CAPIF context aware authorization policy. For a retrieve request, the CAPIF core function may identify one or more stored resource owner CAPIF context aware authorization policy(s) matching a policy ID or query criteria specified in the request. For a delete request, the CAPIF core function may delete the resource owner CAPIF context aware authorization policy matching the policy ID specified in the request.

[0131] At step 6, similarly to step 3, the CAPIF core function may send a response to the resource owner. For a create or update response, the CAPIF core function may return the policy ID of the created or updated policy and optionally a representation of the policy elements within the created or updated policy. For a retrieve response request, the CAPIF core function may return a representation of the retrieved policy. For a delete response, the CAPIF core may return a status indicating whether the specified policy w as successfully deleted.

[0132] The operations shown in FIG. 8 may be occur in an order different than may be shown. For example, the CAPIF core function may receive requests from resource owners before receiving requests from API service providers.

[0133] The CAPIF context aware authorization CRUD operations shown in FIG. 8 may be combined with other CAPIF operations. For example, when a resource owner registers to a CAPIF core function, the resource owner may include context aware authorization policies to create. Similarly, when a CAPIF API exposing function published a service API to a CAPIF core function, the API exposing function may include context aware authorization policies to create.

[0134] FIG. 9 shows a an example procedure 900 for CAPIF context aware authorization enabled API invoker onboarding.

[0135] As shown in step 3 of FIG. 7 and FIG. 9, when processing API invoker onboarding requests, the CAPIF core function may perform context aware authorization operations as described within the steps below.

[0136] Referring to FIG. 9, at step 1, a CAPIF core function may receive an onboarding request from an API invoker. Included in the request are the required parameters to onboard the API invoker to the CAPIF such as authentication identifier and credential and requested list of types or instances service APIs to access. The API invoker may also include API invoker centric context information in the onboarding request such as but not limited to types of context defined in Table 3 such as the current or planned location(s) of the API invoker, the planned service API access schedule, etc.

[0137] At step 2, upon receiving the onboarding request, the CAPIF core function may determine any applicable CAPIF context aware authorization policies which apply to the request. These may include policies defined by API service providers as well as resource owners. To determine applicable policies, the CAPIF core function may use information specified within the API invoker’s onboarding request described in Step 1. The CAPIF core function may also collect context applicable to the API invoker from other entities in the system. For example, CAPIF core function may collect context information from 3 GPP core network functions (e g., SCEF, NEF, PCF, UDM, UDR, etc.) and / or 3GPP application service enablers (e.g., SEAL, EDGEAPP. AD AES, etc.). The CAPIF core function may compare this collected context against the applicable context aware authorization policies to determine whether the API invoker may be permitted to onboard the CAPIF, the service APIs to expose to the API invoker, and any context aware constraints that apply to the API invoker when accessing the exposed service APIs.

[0138] At step 3, the CAPIF core may return an onboarding response to the API invoker. Within the response, the CAPIF core function may include a list of service APIs which the API invoker may be permitted to access and any constraints or conditions that apply to the API invoker when accessing the exposed service APIs. For example, location-based constraints which only allow the API invoker to access service APIs when the API invoker may be located in a certain area of the system.

[0139] FIG. 10 shows an example procedure 1000 for CAPIF context aware authorization enabled access token request handling.

[0140] As shown in steps 4 thru 10 of FIG. 7 and in FIG. 10, when processing API invoker access token requests, the CAPIF core function may perform context aware authorization operations as described within the steps below.

[0141] Referring to FIG. 10, at step 1, once an API Invoker has successfully performed onboarding with the CAPIF core function, the API invoker may request access tokens. A CAPIF core function may receive a request from an API invoker for an access token which the API invoker requires to access a service API via an API exposure function. In addition to including access token request parameters such as the API invoker identifier and credentials required by the CAPIF core function to authenticate the API invoker, the request may also include additional information such as but not limited to information related to the context elements defined in Table 3. For example, an API invoker may specify a required service bandwidth, service latency, or response time for each service it specifies in the scope parameter. This additional information could be included in the scope parameter by appending it as additional information to each requested service. The following example provides a proposed method in which the scope parameter could be enhanced to carry this information. The proposed enhancements are shown in bold. scope = 3gpp#aefIdl:apiNamel(bandwidth:5, latency: 10, responseTime:10), 3gpp#aefIdl:apiName2(bandwidth:5, latency: 10, responseTime: 10)

[0142] A step 2, upon receiving the access token request, the CAPIF core function may determine any applicable CAPIF context aware authorization policies which apply to the request. These may include policies defined by API service providers as well as resource owners. To determine applicable policies, the CAPIF core function may use information specified within the API invoker’s access token request described in Step 1. The CAPIF core function may also use any API invoker onboarding information which it has stored locally during the API invoker onboarding process.

[0143] At step 3, the CAPIF core function may collect context applicable to the API invoker from other entities in the system. For example, the CAPIF core function may collect context information from 3GPP core network functions (e.g.. SCEF, NEF, PCF, UDM, UDR. etc.) and / or 3GPP application service enablers (e g., SEAL, EDGEAPP, AD AES, etc.).

[0144] At step 4, the CAPIF core function may compare the context collected from the request, locally stored onboarding state, and other entities in the system against the applicable context aware authorization policies to determine whether the API invoker may be permitted to access the requested service APIs. The CAPIF core function may also determine any context aware constraints that apply to the API invoker when accessing the exposed sendee APIs. For example, the CAPIF core function may determine that the current location of the API invoker does not permit the API invoker to access certain service APIs or perform certain service API operations targeting certain resource owners.

[0145] At step 5, the CAPIF core function may generate one or more context aware authorization policies specifically for the API invoker and / or the API invoker’s access token request. The CAPIF core function may share the policy (s) with other CAPIF functions (e.g., CAPIF API exposing functions corresponding to the service APIs which the CAPIF core function has determined to expose to the API invoker).

[0146] At step 6, the CAPIF core function may generate a context aware access token. Within the token, the CAPIF core function may include context aware constraints. These constraints may restrict the validity of the access token to allow the API invoker to only access service APIs if / when the context aware constraints are met. For example, within the access token, the CAPIF core function may specify that certain service APIs may be accessed by the API invoker during certain times, when the API invoker may be in a certain location, when the service bandwidth may be above a certain threshold, etc. These constraints may be defined within the access token itself, such that when the API invoker presents the token to an API exposing function, they can be checked and enforced by the API exposing function. The CAPIF core function may provide a copy of the context aware access token to other CAPIF functions (e.g., CAPIF API exposing functions corresponding to the service APIs which the CAPIF core function has determined to expose to the API invoker)

[0147] At step 7, the CAPIF core function may return an access token response to the API invoker. The context aware constraints may be included within the token. The constraints may be included in the opaque portion (i.e., encrypted portion of the token) which prevents the API invoker from accessing the constraints such that only CAPIF functions (e.g., API exposing functions) are able to decrypt and access these context aware constraints.

[0148] FIG. 11 shows an example procedure 1100 CAPIF Context Aware Authorization Enabled API Invocation.

[0149] CAPIF Context Aware Authorization Enabled API Invocation:

[0150] As shown in steps 11 thru 14 of FIG. 7 and in FIG. 11, when processing API service invocation requests received from an API invoker, the CAPIF API exposing function may perform context aware authorization operations as described within the steps below.

[0151] Referring to FIG. 11, at step 1, a CAPIF API exposing function may receive a sendee invocation request from an API invoker. An access token may be included in the request. The access token may contain context-based constraints such as but not limited to the aforementioned access token context constraints defined in this disclosure. The API invoker may also include API invoker centric context information in the service invocation request such as but not limited to types of context defined in Table 3. For example, the current or planned location(s) of the API invoker, the planned service API access schedule, etc.

[0152] At step 2, upon receiving the service invocation request, the CAPIF API exposing function may check if any context aware constraints are present in the access token. For example, constraints specifying certain service APIs may only be accessed by the API invoker during certain times, when the API invoker may be in a certain location, or when the service bandwidth may be above a certain threshold, etc.

[0153] At step 3, if applicable, the CAPIF API exposing function may also determine any applicable CAPIF context aware authorization policies which apply to the request. These may include policies defined by API service providers as well as resource owners. To determine applicable policies, the CAPIF API exposing function may use information specified within the API invoker’s service invocation request and or the access token included in the request.

[0154] At step 4, based on any context information which may be needed to process the context aware access token and / or authorization policies, the CAPIF API exposing function may collect context applicable to the API invoker from other entities in the system. For example, CAPIF API exposing function may collect context information from other CAPIF functions (e.g., CAPIF core function, CAPIF API management function, etc.) 3GPP core network functions (e.g., SCEF, NEF, PCF, UDM, UDR, etc.) and / or 3GPP application service enablers (e.g., SEAL, EDGEAPP, AD AES, etc.). For example, the API exposing function may collect the current location of the API invoker, the current available bandwidth of the sendee being invoked, or the current location of a resource owner being targeted by the API invoker.

[0155] At step 5, the CAPIF API exposing function may use the collected context to determine whether the context-based constraints specified in the access token and / or access control policies have been met. For example, if a context based constraint may be specified which limits the API invoker to using a service API only when in a specified location, or when the current load on the service may be below a certain threshold, or when a targeted resource owner may be within the same location as the API invoker, and these constraints are not met, then the CAPIF API exposing function may deny the service invocation request.

[0156] At step 6. if based on the collected context, the context-based constraints specified in the access token and / or access control policies are determined to have been met, then the CAPIF API exposing function may grant the service invocation request.

[0157] At step 7, the CAPIF API exposing function may return a service invocation response to the API invoker. If the service API invocation was allowed, the CAPIF API exposing function may include the results of the service API invocation. If denied, the CAPIF API exposing function may include a reason for the denied request. The reason may include one or more collected context values related to the context-based constraints that were not met and resulted in the request being denied.

[0158] FIG. 12 shows an example procedure 1200 for CAPIF Context Aware Authorization Revocation. The CAPIF core function may perform context aware authorization revocation operations as described within the steps of FIG. 12 below. The context aware authorization revocation operations may be triggered by the CAPIF core function itself and / or based on authorization revoke requests received from resource owners and / or API service providers. The triggering of a context aware authorization revocation operations may be based on one or more pieces of collected context information and one or more context aware authorization or revocation policies. Context revocation policies may be included as elements within context aware authorization policies, or as separate policies within CAPIF. Alternatively, the revocation may also be triggered based on the previous API accesses of an invoker or a group of invokers (e.g. for the APIs with a limited number of allowed requests).

[0159] Referring to FIG. 12, at step 1, a context aware authorization revocation trigger event may be detected in the system. This trigger event may be detected by a CAPIF core function, resource owner, CAPIF API publishing function, CAPIF API management function, CAPIF API exposure function, or another entity in the system. The trigger event may be based on one or more collected pieces of context information such as but not limited to thosedefined in Table 3. The sources of the collected context information may be CAPIF functions, entities in the 3GPP network, or other entities (e.g., 3rd party services). For example, if the CAPIF core function detects that the number of allowed API invokers and their service invocations may be unexpectedly overwhelming the service and / or network, it may trigger a context aware authorization revocation operation to deny access to certain services by certain API invokers at certain times.

[0160] At step 2, a CAPIF core function may receive an explicit context aware authorization revoke request. For example, a request may be received from a resource owner or another CAPIF function (e.g., CAPIF API exposing function, CAPIF API management function, etc.). This request may trigger the CAPIF core function to perform one or more authorization revoke operations.

[0161] At step 3, the CAPIF core function may perform one or more authorization revoke operations. One type of operation the CAPIF core function may perform may be deleting one or more authorization policies stored locally at the CAPIF core function or on other CAPIF functions. Another type of operation may involve the CAPIF core function updating expiration times of authorization policies and / or other individual elements within policies such as allowed API invokers, allowed API types, allowed API instances, allowed API operations, allowed times, etc. Another type of operation may' involve deleting an access token stored at the CAPIF core function or CAPIF API exposing function to prevent the API invoker from successfully using the access token in the future. Another operation may involve sending a notification message to an API invoker to inform them that the access token may be no longer valid or to replace their current access token with an updated access token.

[0162] At step 4, a CAPIF function may send an authorization revoke response to a resource owner or API service provider to indicate whether their authorization revoke request was successfully processed.

[0163] A GUI may be supported to configure CAPIF context aware authorization policies. FIG. 13 shows an example of such a GUI 1300.

[0164] In describing preferred embodiments of the subject matter of the present disclosure, as illustrated in the Figures, specific terminology is employed for the sake of clarity. The claimed subject matter, however, is not intended to be limited to the specific terminology so selected, and it is to be understood that each specific element includes all technical equivalents that operate in a similar manner to accomplish a similar purpose.

[0165] In describing preferred embodiments of the subject matter of the present disclosure, as illustrated in the Figures, specific terminology is employed for the sake of clarity'. The claimed subject matter, however, is not intended to be limited to the specific terminology so selected, and it is to be understood that each specific element includes all technical equivalents that operate in a similar manner to accomplish a similar purpose.

Claims

What is claimed:

1. An apparatus comprising one or more processors and memory storing instructions which, when executed by the one or more processors, cause the apparatus to: receive, from a first device associated with a resource owner, a request to create one or more context aware authorization policies, wherein each context aware authorization policy, of the one or more context aware authorization policies, requires one or more types of context, wherein the one or more types of context comprise at least one of: a resource owner context, a service context, or a network context; receive, from a second device associated with an Application Programming Interface (API) invoker, a request to access one or more service APIs associated with the resource owner; determine a context aware authorization policy, of the one or more context aware authorization policies, that is applicable to the API invoker and one or more required types of context for the applicable context aware authorization policy; send, to one or more context sources, one or more requests for the one or more required types of context; receive, from the one or more context sources, information associated with the one or more required types of context; and based on the received information and the applicable context aware authorization policy, determine which service API, of the one or more service APIs, to expose to the API invoker.

2. The apparatus of claim 1, wherein each context aware authorization policy, of the one or more context aware authorization policies, comprises one or more context aware rules instructing whether API invokers are allowed to discover and access the one or more service APIs.

3. The apparatus of claim 1, wherein the apparatus comprises a Common Application Programming Interface (API) Framework (CAPIF) core function.

4. The apparatus of claim 3, herein the CAPIF core function is in communication with the API exposing function (AEF) to enable the receiving the information associated with the one or more required types of context.

5. The apparatus of claim 3, wherein the CAPIF core function is in communication with the API exposing function (AEF) to enable the determining a context aware authorization policy that is applicable to the API invoker and the one or more required types of context.

6. The apparatus of claim 1 , wherein the resource owner context comprises at least one of: a resource owner location, or a resource owner state.

7. The apparatus of claim 1, wherein determining which service API, of the one or more service APIs, to expose to the API invoker comprises: comparing the resource owner context to one or more context aware rules instructing whether API invokers are allowed to discover and access the one or more service APIs.

8. The apparatus of claim 1. wherein the service context comprises at least one of: a service location or area, a sendee schedule, a request rate, a response time, an availability, an available compute, an available memory, or an available service bandwidth.

9. The apparatus of claim 1, wherein determining which service API, of the one or more service APIs, to expose to the API invoker comprises: comparing the senice context to one or more context aware rules instructing whether API invokers are allowed to discover and access the one or more service APIs.

10. The apparatus of claim 1, wherein the network context comprises at least one of:a network bandwidth, network latency, a network jitter, or a network availability.

11. The apparatus of claim 1 , wherein determining which service API, of the one or more service APIs, to expose to the API invoker comprises: comparing the network context to one or more context aware rules instructing whether API invokers are allowed to discover and access the one or more service APIs.

12. A method comprising: receiving, from a first device associated with a resource owner, a request to create one or more context aware authorization policies, wherein each context aware authorization policy, of the one or more context aware authorization policies, requires one or more types of context, wherein the one or more ty pes of context comprise at least one of: a resource owner context, a service context, or a network context; receiving, from a second device associated with an Application Programming Interface (API) invoker, a request to access one or more service APIs associated with the resource owner; determining a context aware authorization policy, of the one or more context aware authorization policies, that is applicable to the API invoker and one or more required types of context for the applicable context aware authorization policy; sending, to one or more context sources, one or more requests for the one or more required types of context; receiving, from the one or more context sources, information associated with the one or more required ty pes of context; and based on the received information and the applicable context aware authorization policy, determining which service API, of the one or more service APIs, to expose to the API invoker.

13. The method of claim 12. wherein each context aware authorization policy, of the one or more context aware authorization policies, comprises one or more context awarerules instructing whether API invokers are allowed to discover and access the one or more sen-ice APIs.

14. The method of claim 12, wherein the method is performed by a Common Application Programming Interface (API) Framework (CAPIF) core function.

15. The method of claim 12, wherein the resource owner context comprises at least one of: a resource owner location, or a resource owner state.

16. The method of claim 12, wherein determining which service API. of the one or more service APIs, to expose to the API invoker comprises: comparing the resource owner context to one or more context aware rules instructing whether API invokers are allowed to discover and access the one or more service APIs.

17. The method of claim 12, wherein the service context comprises at least one of: a service location or area, a service schedule, a request rate, a response time, an availability, an available compute, an available memory, or an available service bandwidth.

18. The method of claim 12, wherein determining which service API, of the one or more service APIs, to expose to the API invoker comprises: comparing the service context to one or more context aware rules instructing whether API invokers are allowed to discover and access the one or more service APIs.

19. The method of claim 12, wherein the network context comprises at least one of:a network bandwidth, network latency, a network jitter, or a network availability.

20. The method of claim 12, wherein determining which service API, of the one or more service APIs, to expose to the API invoker comprises: comparing the network context to one or more context aware rules instructing whether API invokers are allowed to discover and access the one or more service APIs.

Images